How strategic database migration + data (re)modeling improved latencies and cut database costs 5X ZEE 是印度最大的媒体和娱乐业务,涵盖广播电视、电影、流媒体和音乐。ZEE5 是其首屈一指的 OTT 流媒体服务,可在 190 多个国家提供,每月有 150 万活跃用户。 该系统背后的工程师们知道,持续的业务增长将强调他们的基础设施(以及审查数据库账单的人)。因此,团队决定在发生任何心脏病发作之前重新考虑该系统。 他们概述了更换的技术要求(云中立性,多租户准备,轻松启动新用例,高输出量和低延迟以最佳成本),以及如何导致ScyllaDB。 包装起来,他们分享了学到的教训,这些教训可以惠及任何考虑或使用ScyllaDB的人。 5X cost savings (from $744K to $144K annually) and single-digit millisecond P99 read latency https://youtu.be/nArmqus9fbo?embedable=true 以下是那次演讲中的一些亮点...... 什么是心跳? “Heartbeat”是指在ZEE5 OTT平台上播放视频时定期发出的请求,这些简单的请求跟踪用户正在观看的内容,以及他们在每个视频中取得的进展程度。它们对于ZEE5的“继续观看”功能至关重要,允许用户在一个设备上暂停内容,然后在任何设备上恢复。 为什么改变? ZEE5的原始心跳系统是一个由不同的数据库组成的网络,每个数据库都处理流媒体体验的特定部分,尽管在技术上是功能性的,但这种方法很昂贵,并将它们锁定在特定供应商生态系统中。 该团队认识到有机会简化他们的基础设施 - 他们选择了它. 他们想要一个不被锁定在任何特定云提供商的系统,运行成本更低,并能够以持续快速的性能处理其大规模规模 - 特别是单位毫秒响应 - 此外,他们想要灵活地轻松添加新功能,并能够为其系统提供其他流媒体平台。 系统架构,之前和之后 以下是他们与多个数据库的原始系统架构的观点: 
 
 
 
 
 
 DynamoDB 存储基本心跳数据 Amazon RDS 存储下一集和上一集信息 Apache Solr 可存储持久元数据 一个 Redis 实例来缓存元数据 另一个 Redis 实例来存储观众细节   ZEE5 团队考虑了这项项目的四个主要数据库选项:Redis、Cassandra、Apache Ignite 和 ScyllaDB. 经过评估和基准,他们选择了 ScyllaDB。 
 
 我们不需要一个额外的缓存层在持久数据库的顶部。ScyllaDB在同一个基础设施内管理缓存层和持久数据库,确保跨区域的延迟,复制和多云的准备。 我们不需要一个额外的缓存层在持久数据库的顶部。ScyllaDB在同一个基础设施内管理缓存层和持久数据库,确保跨区域的延迟,复制和多云的准备。 新的架构简化和简化了以前的系统架构结构。   现在,所有心跳事件都被推入他们的心跳主题,通过流处理处理,并通过ScyllaDB连接器进入ScyllaDB云。 Srinivas 总结道:“通过这种新架构,我们成功地将工作负载从 DynamoDB、RDS、Redis 和 Solr 迁移到 ScyllaDB。 ” 5x cost reduction, bringing our monthly expenses down from $62,000 to around $12,000. 深入到设计中 Jivesh分享了更多关于其低级别的设计... 实时流处理管道 在实时流处理管道中,心跳会定期发送到ScyllaDB。 心跳间隔设置为 60 秒,这意味着每个前端客户端在用户观看视频时每隔 60 秒都会发送一次心跳,这些心跳通过播放流处理系统传输,商业逻辑消费者将这些数据转换成所需的格式 – 然后处理的数据存储在 ScyllaDB 中。 可扩展的 API 层 可扩展的 API 层中的第一个组件是 heartbeat 服务,该服务负责处理大量的数据摄入,主题处理数据,然后通过连接器服务传输并存储在 ScyllaDB 中。 另一个引人注目的 API 层服务是 Concurrent Viewership Count 服务. 该服务使用 ScyllaDB 获取并行观看数据 - 无论是用户或资产(例如,每 ID)。 元数据管理使用案例 ZEE5面临的第一个重大挑战之一是为其庞大的OTT平台管理元数据. 最初,他们依赖三种不同的数据库(Solr、Redis 和 Postgres)的组合来处理其广泛的元数据需求。 以下是他们的元数据模型: create keyspace.meta_data (
	id text,
	title text,
	show_id text,
	…,
	…,
	PRIMARY KEY((id),show_id)
) with compaction = {‘class’: ‘LeveledCompactionStrategy’ };
 在这个模型中,ID 作为分区密钥。由于此表经历了相对较少的写作(只有在发布新资产时才会出现写作),但读取量更大,他们使用了平衡压缩策略来优化性能。 视觉计数使用案例 ZEE5 决定设计一个表,用户 ID 作为分区密钥和资产 ID 作为分类密钥 - 允许有效地查询观众数据。 他们将 ScyllaDB 的 TTL 设置为与 60 秒的心跳间隔相匹配,确保数据在指定时间之后自动到期,此外,他们还使用了 ScyllaDB 的 Time-Window 压缩策略来有效地管理内存中的数据,基于配置的 TTL 清除过期的记录。 Jivesh解释说:“这个表格不断更新来自每个前端和每个用户的心跳。随着心跳的到来,观众数被实时跟踪,并在 TTL 到期时自动清除。 以下是他们的观众数数据模型: CREATE TABLE keyspace.USER_SESSION_STREAM (
   USER_ID text,
   DEVICE_ID text,
   ASSET_ID text,
   TITLE text,
   …,
   PRIMARY KEY((USER_ID), ASSET_ID)
) WITH default_time_to_live = 60 and compaction = { 'class' : 'TimeWindowCompactionStrategy' };
 ScyllaDB 结果和学到的教训 下面的负载测试报告显示每秒41,7K请求的输出量,该基准是在数据库选择过程中进行的,以评估高负载性能。 Jivesh 评论道:“即使有如此高的传输量,我们也可以达到微秒写延迟和平均微秒读延迟,这确实给了我们一个清晰的观点,ScyllaDB 可以做什么 - 这有助于我们决定。 然后他继续分享一些揭示ZEE5的ScyllaDB部署规模的事实: 
 
 
 
 “我们在ScyllaDB上有大约9TB,即使有这么大的数据量,它也可以在微秒内处理延迟和一位数的毫秒,这是相当巨大的。 每秒,我们都会把这么多数据写入ScyllaDB,并从中获取这么多数据。 我们每天处理超过10亿次心跳,这是相当巨大的。 演讲结束了以下教训: 
 
 
 
 
 
 
 
 数据建模是实现单位数毫秒延迟的最关键因素。 选择正确的量子设置和压缩策略. 例如,在可读之前,是否需要在每个节点上写心跳,还是当地量子足够吗? 选择合适的量子保证了延迟和SLA要求之间的最佳平衡。 明智地选择分区和分组密钥 - 以后更改它们并不容易。 使用物质化视图以更快地搜索并避免过滤查询。 使用准备的陈述来提高效率。 例如,在元数据模型中,共执行了 20 个同步查询,而 ScyllaDB 则在毫秒内处理了这些查询。 区意识 ScyllaDB 客户端有助于降低跨 AZ (可用区) 网络成本. 在同一 AZ 中收集数据可最大限度地减少延迟并显著降低网络成本。

This story contains new, firsthand information uncovered by the writer.

Visit Website

ScyllaDB Vs. Apache Cassandra

ScyllaDB Vs. DynamoDB

Download ScyllaDB

Community Events

Work At ScyllaDB

該音頻是用故事的原始語言製作的！

在ZEE的流媒体平台上跟踪数以百万计的心跳

About Author

註釋

標籤

这篇文章刊登在

Related Stories

比特币 UTXO 模型，为独特的生态系统提供动力

创建以用户为中心的加密产品：客户反馈的重要性

使用这 18 种开发工具来提高你的工作效率 🚀🔥

加密货币增长：创建有效的用户角色

比特币 UTXO 模型，为独特的生态系统提供动力

创建以用户为中心的加密产品：客户反馈的重要性

使用这 18 种开发工具来提高你的工作效率 🚀🔥

加密货币增长：创建有效的用户角色

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps