作者:咪咕视讯数据库和中间件专家 郭灏
导读
近年来,用户对视频内容的需求呈现爆炸式增长,这对平台的技术架构和数据管理能力也提出了更高的要求。咪咕视讯作为国内领先的综合视频服务平台,全场景月活用户高达 4.98 亿。在这一庞大的用户生态背后,咪咕采用 TiDB 作为节目分发平台的核心数据库,承载所有媒体资讯、节目和赛事的元数据,成功支撑了平台的高效运行和内容分发,也顺利完成了多项知名直播赛事的转播,包括欧洲足球联赛、NBA、CBA、中超等顶级赛事,在提升和保障用户体验方面发挥重要作用。
本文将全面介绍 TiDB 在咪咕视频的应用及收益、数据库选型思路与测评维度、TiDB 在咪咕视讯后续的应用方向与计划。
TiDB 在咪咕视频的应用及收益
应用场景与需求特点
TiDB 在咪咕视频中的应用场景主要集中在内容分发平台系统,采用双中心部署架构(共 30 节点)。内容分发平台作为后端核心系统之一,承载着媒体资讯、内容分发和体育赛事等关键数据。该系统的需求特点如下:
- 关系型 :数据结构高度结构化,且一致性要求极高,如球员档案、俱乐部徽章等关联数据需同步更新。
- 写偏重 :数据持续大量写入且只增不减,影视、综艺等内容每日新增,对数据库的写入性能要求极高。
- 弹性扩容 :在重大赛事、影视上线等高峰期需随时扩容,匹配公司容器化资源战略,同时遵循数据不出局原则。
- 性能和可靠性 :节目和赛事的露出与下线有明确时效性,数据不能乱,服务不能断。
- 信创 :咪咕视讯作为国有企业,需符合国产化政策要求。
结合上述需求及调研结果,我们认为 TiDB 是最契合咪咕内容分发系统需求的数据库。
应用 TiDB 的收益
显性收益
- 设备资源节省了三分之二 :用 1 套 TiDB 集群换了 4 套 MySQL MHA 集群+ 1 套 Oracle RAC + ADG 集群 ,除了可以减少高配裸金属的数量,还去掉了诸如 SAN 存储、光纤交换机、HBA 卡等特殊 设备。
- 开发和实施成本节省 :项目系统工程量中数据库开发和实施相关人力约 4 个多人月,主要为验证和测试。
- CICD 整体效率提升 :从原先的“至少 3 天”缩短至“只要 10 分钟内”。
隐性收益
- 运维架构复杂性降低 :
- 降低“有状态性”(主从有别),从复杂的 MHA+Zabbix+Thanos+Log+APM+XScripts+Java… 运维体系,转变为 TiUP+Dashboard+Grafana,降低运维自身的成本和风险。
- 运维效率提高 80% :数据邻近、可视排序、时序关联,大大缩短故障排查时间。
- 技术运营改进 :通过 CICD 前置时间的缩短,将技术人员从繁琐低价值工作解放。这方面的效益不太好测量,但影响却是相当大。
咪咕视频选择 TiDB 的历程 & 分布式数据库选型思路分享
在选择 TiDB 的过程中,我们也会考虑以下几个问题:分布式数据库能做哪些事情?有哪些是以前做不到的、分布式独有的新功能?是否符合需求?能否以更低的代价和风险实现?以及一些现实问题,如价格和服务支撑,目前市场的反应和排名情况等等,了解完这些也让我们对 TiDB 的产品更有信心。
在选型过程中,我们也建立了自己的评价体系,以及具体的标准、数据模型、方法、工具和指标,供大家参考。
TiDB 在咪咕的实践经验分享
咪咕每一次赛事运营的更新,会发生十几个包含多表关联和大型范围扫描的 SQL,产生五位数的回表。在高并发批量更新场景下,索引回表会消耗大量 CPU 资源,从而可能拖慢数据库集群的性能。究其原理,存储引擎 TiKV 的 LSM 树优势在于将随机写转换成顺序写,写吞吐可以说是相当强劲的;而在读方面,由于会涉及对 Memtable 和跨层 SortStringTable 文件的访问,虽然文件有内置 Bloom 过滤器加速,但在高并发数据扫描下发挥受限,尤其面临大量二级索引带来的严重回表。另一方面,在读写分离的颗粒度上,MySQL 是实例级别的,而 TiKV 是区块(Region)级别的,即使我们开启了 follower read,在没有做好充分的资源隔离下也可能会互相影响。
于是我们针对这部分数据做了重新的设计,让它们成为自描述的文档结构。数据更新的部分,则利用 TiCDC 将变更流传递合并到结果集上。数据访问时直接定位到文档,避免了前端系统对后台库直接进行大型关联和扫描,负载流量显著降低。
同时,我们也总结了三点实践经验:
- 数据结构的差异往往可导致悬殊的性能差别;
- 存储引擎也应当择其长处发挥;
- 应用程序要和数据库结合优化。
咪咕视讯 TiDB 后续方向与计划
TiDB 在咪咕分发系统的应用只是我们的第一个试点,后续也希望能把 TiDB 应用到更多合适的场景。
从 DBaaS 到容器化平台过渡
K8S + TiDB 的过渡历程 :直接用裸金属构筑的数据库服务层只是过渡的目标形态,它的使命是集约当下分散的数据库集群。我们是计划进一步走向容器化的数据库服务层。具体考虑如下:
- 资源战略发展需要 :公司总体资源战略向容器化发展
- 发挥容器化无法忽略的优势 :
- 更小的资源控制颗粒度 :实现更精细的资源管理
- 更高的部署密度和资源利用率 :提高资源利用效率
- 更强的自治性和集成统一性 :简化运维管理
- 更高效的局内流量通信 :提升系统性能
因此,具有成熟的容器化部署能力,也是我们在选择 TiDB 的一个重要考虑因素。
一二级用户中心系统的迁移
用户中心系统是一个包含了账户信息、交易订单、权益等关键数据的系统,是核心中的核心。一级是中央系统,二级是前置在各个业务板块的子集,在咪咕视讯的是二级系统。由于数据量异常庞大,目前采用的是纵横结合的大型分库分表的数据库群落技术。纵向是指根据业务模块单独建立数据库集群,横向是指在纵向的基础上对每个集群再做分库分表,每个集群的分桶数在 48-64 个不等,单片数据在 1-10 TB,不算主备冗余。
这里带来的挑战非常严峻:
- 跨库流量,高度关联 :任何业务动作都需跨库跨片,物理上互相独立的数据库需通过外部机制保证数据一致性。
- 高写,集中跑账 :尤其在月初月底集中跑账时,写流压力大。
- 结构僵化 :开发新业务程序设计必须将就现有数据库结构,运维扩展分片和数据迁移困难。
- 旱涝不均 :有些性能饥饿,有些富裕空闲。
- 复杂性传递 :离线数据层的各种管道和接口异常复杂,牵一发动全身。
这些挑战也是我们最终要努力攻克的对象。我个人认为,上述的挑战很大程度上与 TiDB 的设计出发点、功能特性是非常契合的,所以也非常期待能携手 TiDB 一起攻克咪咕后续的一些挑战。
总结:心得与感想
咪咕大概是 2018 年左右正式开始对分布式数据库进行研究的,到现在为止我们看到和测试过太多的国内产品。但是在当时,敢用 LSM 树而不是 B+ 树做存储引擎,敢做分布式存算引擎分离的,能够行列副本共存、优化器路由分流做 MPP shuffle 的,市面上真的真的非常非常地不多见。比较多的是精致的分库分表外挂,或某些知名国外产品的模仿版。
TiDB 的产品给我的印象是极具冲击性的,那么大胆、不随大流。验证和使用下来,效果也是切实的。可以看到,它的背后是有认真的思考的,并且是有敢于追求的魄力的,产品设计者一定是自信和热情的。
法国存在主义哲学家萨特说过,人并不是由既有的东西来决定,而是在自己持续的选择中才成为自己。DBA、架构师们也是一样,我们并不是由头衔、外部的身份或待遇来决定的,而是在对数据库技术、对工作、对生活持续的探索,和对困难的不断的挑战中,塑造和成为自己。希望本次分享的 TiDB 在咪咕的实践和思考能给大家带来有价值的参考。
共同学习,写下你的评论
评论加载中...
作者其他优质文章