作者：咪咕视讯数据库和中间件专家 郭灏
导读
近年来，用户对视频内容的需求呈现爆炸式增长，这对平台的技术架构和数据管理能力也提出了更高的要求。咪咕视讯作为国内领先的综合视频服务平台，全场景月活用户高达 4.98 亿。在这一庞大的用户生态背后，咪咕采用 TiDB 作为节目分发平台的核心数据库，承载所有媒体资讯、节目和赛事的元数据，成功支撑了平台的高效运行和内容分发，也顺利完成了多项知名直播赛事的转播，包括欧洲足球联赛、NBA、CBA、中超等顶级赛事，在提升和保障用户体验方面发挥重要作用。
本文将全面介绍 TiDB 在咪咕视频的应用及收益、数据库选型思路与测评维度、TiDB 在咪咕视讯后续的应用方向与计划。
更多资料： TiDB 社区活动（上海站）回顾 & ppt 下载
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 在咪咕的实践和思考能给大家带来有价值的参考。
1008
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
