为了账号安全,请及时绑定邮箱和手机立即绑定

4.98 亿月活背后的国产数据库:咪咕视讯携手 TiDB 攻克内容分发核心系统挑战

标签:
数据库

作者:咪咕视讯数据库和中间件专家 郭灏

TiDB 社区活动(上海站)回顾

导读

近年来,用户对视频内容的需求呈现爆炸式增长,这对平台的技术架构和数据管理能力也提出了更高的要求。咪咕视讯作为国内领先的综合视频服务平台,全场景月活用户高达 4.98 亿。在这一庞大的用户生态背后,咪咕采用 TiDB 作为节目分发平台的核心数据库,承载所有媒体资讯、节目和赛事的元数据,成功支撑了平台的高效运行和内容分发,也顺利完成了多项知名直播赛事的转播,包括欧洲足球联赛、NBA、CBA、中超等顶级赛事,在提升和保障用户体验方面发挥重要作用。

本文将全面介绍 TiDB 在咪咕视频的应用及收益、数据库选型思路与测评维度、TiDB 在咪咕视讯后续的应用方向与计划。


TiDB 在咪咕视频的应用及收益

TiDB 在咪咕视频的应用及收益1

应用场景与需求特点

TiDB 在咪咕视频中的应用场景主要集中在内容分发平台系统,采用双中心部署架构(共 30 节点)。内容分发平台作为后端核心系统之一,承载着媒体资讯、内容分发和体育赛事等关键数据。该系统的需求特点如下:

  1. 关系型 :数据结构高度结构化,且一致性要求极高,如球员档案、俱乐部徽章等关联数据需同步更新。
  2. 写偏重 :数据持续大量写入且只增不减,影视、综艺等内容每日新增,对数据库的写入性能要求极高。
  3. 弹性扩容 :在重大赛事、影视上线等高峰期需随时扩容,匹配公司容器化资源战略,同时遵循数据不出局原则。
  4. 性能和可靠性 :节目和赛事的露出与下线有明确时效性,数据不能乱,服务不能断。
  5. 信创 :咪咕视讯作为国有企业,需符合国产化政策要求。

结合上述需求及调研结果,我们认为 TiDB 是最契合咪咕内容分发系统需求的数据库。

TiDB 在咪咕视频的应用及收益2

应用 TiDB 的收益

显性收益

  1. 设备资源节省了三分之二 :用 1 套 TiDB 集群换了 4 套 MySQL MHA 集群+ 1 套 Oracle RAC + ADG 集群 ,除了可以减少高配裸金属的数量,还去掉了诸如 SAN 存储、光纤交换机、HBA 卡等特殊 设备。
  2. 开发和实施成本节省 :项目系统工程量中数据库开发和实施相关人力约 4 个多人月,主要为验证和测试。
  3. CICD 整体效率提升 :从原先的“至少 3 天”缩短至“只要 10 分钟内”。

隐性收益

  1. 运维架构复杂性降低
  2. 降低“有状态性”(主从有别),从复杂的 MHA+Zabbix+Thanos+Log+APM+XScripts+Java… 运维体系,转变为 TiUP+Dashboard+Grafana,降低运维自身的成本和风险。
  3. 运维效率提高 80% :数据邻近、可视排序、时序关联,大大缩短故障排查时间。
  4. 技术运营改进 :通过 CICD 前置时间的缩短,将技术人员从繁琐低价值工作解放。这方面的效益不太好测量,但影响却是相当大。

咪咕视频选择 TiDB 的历程 & 分布式数据库选型思路分享

在选择 TiDB 的过程中,我们也会考虑以下几个问题:分布式数据库能做哪些事情?有哪些是以前做不到的、分布式独有的新功能?是否符合需求?能否以更低的代价和风险实现?以及一些现实问题,如价格和服务支撑,目前市场的反应和排名情况等等,了解完这些也让我们对 TiDB 的产品更有信心。

分布式数据库选型三大思路

在选型过程中,我们也建立了自己的评价体系,以及具体的标准、数据模型、方法、工具和指标,供大家参考。

测评维度

TiDB 在咪咕的实践经验分享

咪咕每一次赛事运营的更新,会发生十几个包含多表关联和大型范围扫描的 SQL,产生五位数的回表。在高并发批量更新场景下,索引回表会消耗大量 CPU 资源,从而可能拖慢数据库集群的性能。究其原理,存储引擎 TiKV 的 LSM 树优势在于将随机写转换成顺序写,写吞吐可以说是相当强劲的;而在读方面,由于会涉及对 Memtable 和跨层 SortStringTable 文件的访问,虽然文件有内置 Bloom 过滤器加速,但在高并发数据扫描下发挥受限,尤其面临大量二级索引带来的严重回表。另一方面,在读写分离的颗粒度上,MySQL 是实例级别的,而 TiKV 是区块(Region)级别的,即使我们开启了 follower read,在没有做好充分的资源隔离下也可能会互相影响。

TiDB 在咪咕的实践经验分享

于是我们针对这部分数据做了重新的设计,让它们成为自描述的文档结构。数据更新的部分,则利用 TiCDC 将变更流传递合并到结果集上。数据访问时直接定位到文档,避免了前端系统对后台库直接进行大型关联和扫描,负载流量显著降低。

同时,我们也总结了三点实践经验:

  1. 数据结构的差异往往可导致悬殊的性能差别;
  2. 存储引擎也应当择其长处发挥;
  3. 应用程序要和数据库结合优化。

实践经验

咪咕视讯 TiDB 后续方向与计划

TiDB 在咪咕分发系统的应用只是我们的第一个试点,后续也希望能把 TiDB 应用到更多合适的场景。

从 DBaaS 到容器化平台过渡

K8S + TiDB 的过渡历程 :直接用裸金属构筑的数据库服务层只是过渡的目标形态,它的使命是集约当下分散的数据库集群。我们是计划进一步走向容器化的数据库服务层。具体考虑如下:

  1. 资源战略发展需要 :公司总体资源战略向容器化发展
  2. 发挥容器化无法忽略的优势
  • 更小的资源控制颗粒度 :实现更精细的资源管理
  • 更高的部署密度和资源利用率 :提高资源利用效率
  • 更强的自治性和集成统一性 :简化运维管理
  • 更高效的局内流量通信 :提升系统性能

因此,具有成熟的容器化部署能力,也是我们在选择 TiDB 的一个重要考虑因素。

从 DBaaS 到容器化平台过渡

一二级用户中心系统的迁移

用户中心系统是一个包含了账户信息、交易订单、权益等关键数据的系统,是核心中的核心。一级是中央系统,二级是前置在各个业务板块的子集,在咪咕视讯的是二级系统。由于数据量异常庞大,目前采用的是纵横结合的大型分库分表的数据库群落技术。纵向是指根据业务模块单独建立数据库集群,横向是指在纵向的基础上对每个集群再做分库分表,每个集群的分桶数在 48-64 个不等,单片数据在 1-10 TB,不算主备冗余。

一二级用户中心系统的迁移

这里带来的挑战非常严峻:

  1. 跨库流量,高度关联 :任何业务动作都需跨库跨片,物理上互相独立的数据库需通过外部机制保证数据一致性。
  2. 高写,集中跑账 :尤其在月初月底集中跑账时,写流压力大。
  3. 结构僵化 :开发新业务程序设计必须将就现有数据库结构,运维扩展分片和数据迁移困难。
  4. 旱涝不均 :有些性能饥饿,有些富裕空闲。
  5. 复杂性传递 :离线数据层的各种管道和接口异常复杂,牵一发动全身。

这些挑战也是我们最终要努力攻克的对象。我个人认为,上述的挑战很大程度上与 TiDB 的设计出发点、功能特性是非常契合的,所以也非常期待能携手 TiDB 一起攻克咪咕后续的一些挑战。

总结:心得与感想

总结:心得与感想1

咪咕大概是 2018 年左右正式开始对分布式数据库进行研究的,到现在为止我们看到和测试过太多的国内产品。但是在当时,敢用 LSM 树而不是 B+ 树做存储引擎,敢做分布式存算引擎分离的,能够行列副本共存、优化器路由分流做 MPP shuffle 的,市面上真的真的非常非常地不多见。比较多的是精致的分库分表外挂,或某些知名国外产品的模仿版。

TiDB 的产品给我的印象是极具冲击性的,那么大胆、不随大流。验证和使用下来,效果也是切实的。可以看到,它的背后是有认真的思考的,并且是有敢于追求的魄力的,产品设计者一定是自信和热情的。

总结:心得与感想2

法国存在主义哲学家萨特说过,人并不是由既有的东西来决定,而是在自己持续的选择中才成为自己。DBA、架构师们也是一样,我们并不是由头衔、外部的身份或待遇来决定的,而是在对数据库技术、对工作、对生活持续的探索,和对困难的不断的挑战中,塑造和成为自己。希望本次分享的 TiDB 在咪咕的实践和思考能给大家带来有价值的参考。

点击查看更多内容
TA 点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
数据库工程师
手记
粉丝
61
获赞与收藏
85

关注作者,订阅最新文章

阅读免费教程

  • 推荐
  • 评论
  • 收藏
  • 共同学习,写下你的评论
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
微信客服

购课补贴
联系客服咨询优惠详情

帮助反馈 APP下载

慕课网APP
您的移动学习伙伴

公众号

扫描二维码
关注慕课网微信公众号

举报

0/150
提交
取消