分布式数据库TiDB

分布式数据库

TiDB和OceanBase都是近几年流行度很高的国产数据库引擎，两者都是基于LSM Tree的分布式数据库。

TiDB

​ TiDB是一个开源的NewSQL数据库，支持混合事务和分析处理（HTAP）工作负载。它与MySQL兼容，并且可以提供水平可扩展性、强一致性和高可用性。它主要由PingCAP公司开发和支持，并在Apache 2.0下授权。

​ TiDB是PingCAP公司研发的开源分布式关系型数据库,具有兼容MySQL协议，易水平扩展、高可用、强一致、HTAP等特性。

发版历史：

• TiDB 6.5 LTS 版本 2022年12月

• TiDB 8.5 LTS 版本 2024年12月

五大核心特性

• 一键水平扩容或者缩容

  得益于 TiDB 存储和计算分离的架构设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

• 金融级高可用

  数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

• 实时 HTAP

  提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

• 云原生的分布式数据库

  专为云而设计的分布式数据库，通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。

• 兼容 MySQL 5.7 协议和 MySQL 生态

  兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

用户案例

​ TiDB 现已被 3000 多家不同行业的领先企业应用在实际生产环境，其中包括中国银行、建设银行、美团、Bilibili、58同城、爱奇艺、搜狗、搜狐、微博、腾讯等等。

中国光大银行

业务挑战

​ 传统集中式数据库受到单点架构的限制，造成处理能力的受限与风险的集中。随着两地三中心的建设，光大银行计划采用分布式的方案对外提供服务。数据库作为金融科技的重器，需要匹配银行业务的发展，不断提升处理性能，并且满足金融监管的要求。

​ 在分布式数据库技术日渐成熟的背景下，光大银行在关键业务系统引入TiDB，有效解决了原有数据库面临的性能、可用性和业务多活问题。

分布式数据库实践

​ 新一代财富管理平台是支撑光大银行理财公司运营的核心系统，提供理财业务的全流程管理。依托私有云基础设施与平台 4.0 开发框架，光大银行定制了分布式批处理方案，设计目标是余额宝每小时理财交易 2000 万笔，零钱通单日 5000 万笔，同时还要满足未来 3-5 年业务发展和接入更多互联网代销渠道需求。

光大银行在同城两数据中心构建 TiDB 双活集群，采用 5 副本 TiKV，设计 40TB 逻辑容量，同时将 TiDB 的数据实时复制到 MySQL，提升业务容灾能力。

北京银行

业务挑战

​ 随着互联网金融时代的到来，基于移动互联的高频访问场景成为常态，面对海量数据、高并发的挑战，北京银行分布式核心系统采用“微服务架构+分布式数据库”的建设方案，构建起一套支持高并发、高可用、可横向扩展的分布式核心系统解决方案。

​ 2018 年起，该分布式核心系统对接网联支付清算平台、银联无卡快捷支付平台、金融服务互联平台、网贷业务平台等多个核心金融业务场景，实现了将分布式数据库解决方案应用于银行核心类业务场景。

解决方案

​ 北京银行在两地三中心部署 TiDB 集群，采用主从的多活架构，主集群作为生产集群承担日常的生产服务，主从之间采用 Kafka 同步 Binlog 的形式进行数据同步。

​ 北京银行首先在网联支付清算平台和银联无卡快捷支付系统引入 TiDB 分布式数据库，以便更好地迎接互联网金融带来的大数据量和高并发的挑战。系统投产之后，已经成功应对两次双十一挑战，2019 年双十一巅峰的 QPS 达到 7500，是平时 QPS 的十倍以上。

​ 在双十一期间，北京银行 IT 团队进行多次线上的运维操作，包括版本升级、打补丁等，利用 TiDB 分布式数据库的多副本特性实现“运维零中断”的操作。随着系统升级，北京银行的网联业务链，包括上游的手机银行到网联、银联无卡快捷支付业务中台，到后台的金融日历、查询服务都已经进行了分布式架构的升级，完成了与 TiDB 的对接。

58同城

挑战

​ 58 集团拥有大量需要长期保留的数据，但 MySQL 的单机存储容量有限，扩容不便。在数据量特别大的情况下，只能采用分库分表。MySQL 的高可用方案是主从复制+ MHA，当主库挂掉时，需要切换主从，势必影响一定时间的写入。此外，MySQL 读延时比较高，读流量增加会进一步带来高延迟。

解决方案

​ 经过选型对比，58 集团选用 TiDB 来解决上述问题。 基于分布式架构的 TiDB 支持水平伸缩，在计算能力不够时直接加节点就可以进行扩展。 且 TiDB 具有多副本，可以保证数据安全及高可用。此外，TiDB Server 没有状态，支持多点读写。TiDB 也无需分库分表，操作比较简单，不用定期清理数据。

​ 目前，58 集团内部在用的 TiDB 集群已经达到 80 套，版本涉及 4.0.2、4.0.9、4.0.10、4.0.11 以及最新版的 5.0.0、5.0.1，涵盖的业务线包括 58 招聘、TEG、安居客、用户增长、信息安全、金融公司及车业务。

​ 58 将 TiDB 接入到了“58 云 DB 平台”中，利用开源 inception 来处理 DDL/DML 工单。平台分为管理端和用户端，管理端是 DBA 用来做元信息维护、工单处理、运营报表、监控概览等。用户端方面，业务会在上面申请 TiDB 集群、DDL/DML 工单，账号管理，查看集群的信息及监控情况，还可以自助查询库中的数据。

收益

• TiDB基于分布式架构，可实时无线水平扩缩容，无需通过分库分表及频繁清理数据降低数据库成本
• TiDB 通过Raft协议实现强一致性的多副本数据安全，实现高可用，即使发生硬件故障也不会影响业务写入。
• TiDB Server 无状态的存储分离架构，可支持多点读写，解决了MySQL单点写入造成的性能瓶颈。

美团

业务挑战

​ 在美团，基于 MySQL 构建的传统关系型数据库服务已经难以支撑公司业务的爆发式增长，促使美团探索更合理的数据存储方案和实践新的运维方式。随着近年来分布式数据库大放异彩，美团 DBA 团队联合架构存储团队，于 2018 年初启动了分布式数据库项目。

​ 在对比了大量方案后，考虑到技术架构的前瞻性、发展潜力、社区活跃度、以及服务本身与 MySQL 的兼容性，美团最终决定选择基于 TiDB 数据库进行二次开发的整体方案，并与 PingCAP 官方和开源社区进行深入合作的开发模式。

解决方案

​ 美团业务线众多、业务体量大，业务对在线存储的服务质量要求也非常高。根据业务特点及重要程度，美团逐步推进上线了数百个 TiDB 集群，1700 多个物理节点。单集群最大 40 多个节点，单表记录最大上千亿条。目前均已稳定服务于配送、出行、闪付、酒旅等业务。

​ 过去在使用 MySQL 时，为了应对快速上涨的数据容量和性能瓶颈，美团只能分库分表。但分库分表带来了成本指数级增长，计算资源不足等问题。特别是在互联网高速发展的时代，一旦业务爆发式增长，分库分表无法做到及时应对。

​ TiDB 采用了计算存储分离的分布式架构，在存储方面，TiDB 内存主要负责 SQL 解析以及 SQL 引擎的执行，PD 主要提供元数据信息及分布式数据库的时间戳功能，TiKV 则提供无限扩展的分布式存储。TiDB 与 TiKV 集群之间可以互相独立地进行扩缩容，完全不影响其他组件。同时，TiDB 还通过 Multi-Raft 协议提供了金融级数据强一致特性，解决了 MySQL 无法保证事务整体一致性的问题。

​ 此外，随着 5G、物联网的兴起，数据量爆炸式增长，美团有很多场景要求在同一个系统里同时实现 OLTP 和 OLAP 的 T+0 分析需求，如大促活动中针对优惠券发放结果进行计算评估活动效果，仅仅依赖 T+1 的报表是很难实现的。TiDB 的 HTAP 可以帮助美团在线上传数据，直接提供给市场进行计算分析，降低了试错成本及营销成本。

小红书

业务挑战

​ 在数据报表场景，原先采用 Hadoop 数仓对数据做预聚合，然后放到 MySQL 里面做查询，随着业务增长，报表形式更加多样化，MySQL 的扩展性成为瓶颈。多节点 MySQL 的分库分表方案复杂度高，运维非常困难。在反欺诈分析场景，传统数仓方案 T+1 的时效性不佳，要求数据库提供较强的实时分析能力。

解决方案

​ 面对以上挑战，小红书引入 TiDB HTAP 方案，在数据服务层采用 TiDB 提供全部数据服务。

​ 在数据报表场景，直接使用 TiDB 直接替换 MySQL ，TiDB 可以通过增加节点进行扩容，并且可以自动实现数据的重新均衡。通过搭建实时流把在线业务层分库分表的 MySQL Binlog 写到 TiDB 并进行合库，将一万张分表合成 TiDB 的一张大表，在 TiDB 进行查询、事务和聚合等操作，都不会影响主库。

​ 反欺诈数据分析场景应用 TiDB 之后，把 T+1 的提交改成由 Flink SQL 实时写入，打点数据产生的速率峰值 QPS 达到三四万，单表一天写入 5 亿左右的数据。小红书绕过 Hadoop 数仓，通过 TiDB HTAP 提供实时查询，在分钟级就可以看到促销发放优惠券的使用与分发情况，为业务提供高效、稳健的实时数据服务。

​ 小红书将其他数据汇聚至基于 Amazon S3 和 EMR 所构建的数据湖中，实现对数据的预处理和聚合，然后加载至 TiDB 集群，实现统一、高效的运营分析。

中国平安

业务挑战

​ 随着业务的快速增长，Oracle 成为平安人寿 IT 基础设施链条里面最大的瓶颈。在大规模数据量下，如果使用 MySQL 就意味着读写分离、分库分表，分布式事务需要在应用层进行实现，在开发效率上大打折扣。

解决方案

​ 平安人寿构建 TiDB 分布式数据库集群，为活动类、运营类、创新类等多种应用系统提供数据服务。TiDB 在保障核心业务高效支撑的同时，向上层应用提供标准化的 API 接口，为业务运营人员提供了灵活的查询界面，满足实时、便捷、准确的查询服务请求。

​ 2019 年 “1.08 财神节” 当天成交额超过 1000 亿，在单日交易额破千亿背后是几百个 TiDB 数据库实例在提供运营保障。金管家应用到 TiDB 上的数据规模超过 30T ，预计整体应用规模将达到百 T 级别。平安金管家作为整个平安人寿下迁 Oracle 的排头兵，为保险业的科技创新提供了一套领先的借鉴模式。

为什么选择TiDB ？

• 相对于Oracle的硬件成本降低30%以上，有效提升了敏态业务的开发效率。
• 数据库集群的性能有了量级的提升，互联网保险业务可以抗住每秒几千单的压力。

中通快递

业务挑战

​ 整个物流的全链路流程会拆解成多个关键节点，每个关键节点会产生大量数据。中通快递原有架构中，大量的数据统计分析依赖于在 Oracle 上建大量存储过程，随着数据量增大，存储和计算的问题凸显，单纯靠升级 Exadata 硬件无法从根本上解决问题，并且随着硬件的升级，成本变得更加高昂。

应用场景

​ 中通快递重构了订单和运单中心的数据架构，每一个节点都支持横向扩展，解决了单点问题，同时降低了 IT 成本。通过 Spark 实时计算接入消息，与 Hive 维表在分布式计算里面做 Merge 和 JOIN，同时和离线的 T+1 以及 HBase 数据做 Merge 计算，把最终计算结果存入 TiDB。依赖 TiSpark 在 TiDB 上做数据的统计分析，轻度汇总和多维汇总基于 TiDB API 接口来提供服务。

​ 在二次配送环节，需要针对每一单快件进行全链路的路由和时效预测，对时效性要求很高。中通快递基于 TiDB 建设实时数仓，业务的 OLTP 数据通过 TiDB 实时写入，OLAP 的业务通过 TiSpark 做分钟级的分析。经过业务实测，TiSpark 同步 3 亿条数据到 Hive 大概需要 10 分钟，有效支撑全链路的时效分析与监控，准实时地定位每一票快件在每一个环节的状态。

用户收益

增效：IT 支持效率提升 300%

​ 在 2019 年双十一大促中，TiDB 同时支撑线上 OLTP 和 OLAP 的业务， QPS 峰值在 12 万+，支持百亿级的插入和更新，TiSpark 支持业务在线的分钟级统计分析，完美保障了双十一中通快递 IT 服务的稳定运行。

降本：数据驱动精细化运营，成本同比降低 17.1％

​ 目前中通快递有超过 100 个物理节点，200 余个 TiDB 实例投入生产，主要服务账单、结算中心、订单中心、运单中心、消息中心、转运智能相关产品线，数据驱动的精细化管理措施持续发挥效益，2020 年二季度，单票成本同比下降 17.1％。

知乎

业务挑战

​ 知乎首页是解决流量分发的一个关键入口，知乎通过个性化首页推荐的方式在海量的信息中高效分发用户感兴趣的优质内容。为了避免给用户推荐曾经看过的重复内容，「已读服务」会将所有知乎站上用户深入阅读或快速掠过的内容记录下来长期保存，并将这些数据应用于首页推荐信息流和个性化推送的已读过滤。

​ 当用户打开知乎进入推荐页时，系统会先向首页服务发起请求拉取“用户感兴趣的新内容”。首页根据用户画像，去多个召回队列召回新的候选内容，这些召回的新内容中可能有部分是用户曾经看过的，所以在分发给用户前，首页会先将这些内容发给已读服务过滤，然后做进一步加工并最终返回给客户端。

在整个过程中，已读服务业务具有以下主要特点：

1. 系统可用性要求非常高。个性化首页和个性化推荐是知乎最重要的流量分发渠道；
2. 数据写入量非常大。峰值每秒写入 40K+ 行记录，日新增记录近 30 亿条；
3. 历史数据长期保存。知乎按照产品设计数据需要保存三年，产品迭代至今，已经保存了约 13000 亿条历史记录。按照每月近 1000 亿条记录的增长速度计算，预计两年后将膨胀到 30000 亿的数据规模；
4. 查询吞吐高。用户在线上每次刷新首页，至少要查一次，并且因为有多个召回源和并发的存在，查询吞吐量可能还会放大。峰值时间首页每秒大约产生 30000 次独立的已读查询，每次查询平均要查 400 个文档，长尾部分大概 1000 个文档。也就是说，整个系统峰值平均每秒处理 1200 万份文档的已读查询；
5. 响应时间敏感。在这样一个吞吐量级下，响应时间要求比较严格，要求整个查询响应时间（端到端超时）为 90ms，这也就意味着最慢的长尾查询都不能超过 90ms；
6. 可以容忍 false positive。有些内容虽然被过滤掉了，但是系统仍然能为用户召回足够多可能感兴趣的内容，只要 false positive rate 被控制在可接受的范围就可以。

解决方案

​ 由于知乎首页的重要性，在设计已读服务架构时，知乎重点考虑三个设计目标：高可用、高性能、易扩展。

​ 已读服务框架上层的客户端 API 和 Proxy 是完全无状态可随时扩展的组件。最底层为存储全部状态数据的 TiDB，中间组件都是弱状态的组件，主体是分层的 Redis 缓冲。除了 Redis 缓冲外，还有一些其他外部组件配合 Redis 来保证 Cache 的一致性。

存储层，知乎最初采用了 MySQL 数据库，但在面临知乎这个体量的数据时 MySQL 单机已经无法满足需求，尽管尝试了分库分表+ MHA 机制，当每月新增 1000 亿条数据的情况下也无法安心应对。寻找一款可持续发展、可维护、高可用的替代方案迫在眉睫，最终，知乎选择了对 MySQL 高度兼容的 TiDB 作为替代方案。在整个系统中，TiDB 层自身已经拥有高可用能力，可以实现自愈。系统中无状态的组件非常容易扩展，而有状态的组件中弱状态的部分也可以通过 TiDB 保存的数据恢复，出现故障时也可以自愈。

此外，系统中还有一些组件负责维护缓冲一致性，但它们自身是没有状态的。所以在系统所有组件拥有自愈能力和全局故障监测的前提下，知乎使用 Kubernetes 来管理整个系统，从而在机制上确保整个服务的高可用。

用户收益

• TiDB 高度兼容 MySQL，知乎原有业务只需进行少量修改即可平滑迁移，替换风险小；
• 基于分布式架构的 TiDB 可以进行水平弹性扩展，在遇到数据量大幅增长时只需简单地增加节点就可以实现容量和性能的线性提升；
• 大大提升知乎已读服务吞吐量，迁移至 TiDB 后，已读服务的流量已达 40000 行记录写入，30000 独立查询和 1200 万个文档判读，在这样的压力下已读服务响应时间的 P99 与 P999 仍然维持在 25ms 和 50ms。

京东云

业务挑战

​ 京东物流业务的高速发展给系统带来了极大挑战：第一，数据量增长快，系统频繁需要扩容。第二，随着数据量的增长以及业务复杂度的上涨，SQL 查询的效率变得越来越低， 给研发带来了不小的压力。第三，分库分表的方式对业务的侵入性以及改造成本比较高，使用场景也受限，难以支撑跨分片的查询，一些复杂 SQL 不支持等，且大型集群的运维比较困难。

在一些分析和查询的场景， ElasticSearch 和 ClickHouse 这两种方案都需要把数据从交易库 MySQL 里面同步过来，还需要对业务进行代码改造。ClickHouse 还存在一些其他的限制，例如不支持事务且并发低等。

解决方案

京东云联合集团内部各个业务团队的专家进行了调研和分析，和 PingCAP 展开了深度合作，联合推出了云上的分布式数据库 —— Cloud-TiDB，提供京东云上的 TiDB 服务，主要优势特性有：

• TiDB 采用的分布式架构支撑海量数据扩展，可以有效地解决单机 MySQL 容量和性能的瓶颈问题；
• TiDB 与 MySQL 兼容性非常好，迁移成本很低，接入周期短，收益见效快；
• TiDB 提供金融级可靠性，运维简单便捷；
• 支持在线扩容和在线 DDL，业务几乎无感知；
• 数据具有强一致性，支持事务，使用场景不受限制。

物流业务费用系统

​ 京东物流业务费用系统的数据量较大，几个主表的数量分别是 20 亿、50 亿和 100 亿，系统上线半年后数据翻倍到了 220 亿。原先 MySQL 分库分表的架构就遇到了一些复杂的 SQL 不支持、跨分片统计报表难于实现等问题。

​ 系统迁移到 TiDB 之后，整体的性能表现优秀，写入和更新的效率在 100 毫秒左右，查询和 Sum 查询只有二三十毫秒。一个几百亿数据量的系统从 MySQL 迁移到 TiDB，实际业务代码零修改，系统只是更换了 JDBC 连接的用户名和密码，真正地实现了从 MySQL 到 TiDB 的零代码修改和无缝迁移。TiDB 和 MySQL 良好的兼容性，降低了用户的试错、测试和迁移的成本，且收益周期短，见效快。

物流大件分拣系统

​ 京东物流大件分拣系统的一些实时看板和核心报表跑在 MySQL 上。随着数据量增加，而且 SQL 比较复杂，报表和看板的性能比较低，用户体验不佳。分库分表的方式对代码侵入性比较大，架构需要大幅调整，风险较高。

​ 京东物流采用 TiDB 支撑业务的实时看板和核心报表，在 MySQL 和 TiDB 之间，用自研的蜂巢系统进行数据的准实时同步。从 MySQL 迁移到 TiDB 后，总共数百个指标，整体性能实现了 8 倍提升。

运单计提明细系统

​ 运单计提明细系统用来记录部分运单的明细数据，每天的数据增长在千万级别，单表最大记录接近 200 亿条。从数据量看用 MySQL 难以支撑，京东物流尝试使用 Presto，但使用成本比较高，后来使用 ElasticSearch 做查询，但存在着不稳定的情况，维护工作量很大。

​ 业务系统迁移到 TiDB 之后解决了海量数据的问题，TiDB 可以毫无压力地支撑百亿级的数据量。TiDB 成本比起以前使用的 MySQL + ElasticSearch 方案降低了 30%。TiDB 性能满足业务的要求，从百亿的单表里面查询出业务数据的 TP99 大概在 500 毫秒左右。此外，TiDB 整个表结构的调整修改操作非常简单，带来了运维敏捷和成本下降。

业务收益

目前，京东集团在云上已经使用了数十套 TiDB 系统，支撑了集团多个 0 级关键业务系统。这些 TiDB 系统都经过了京东 618 大促的严格考验，期间没有发生过任何故障，性能平稳。预计到 2021 年年底，京东集团内部使用 TiDB 的规模会再增长 100%，总 CPU 核数将超过 10000 核。

• TiDB 降低了京东物流 IT 系统的投入成本和运营成本，运维效率得到了极大的提升；
• TiDB 在部分业务系统的应用带来的成本改善和效率提升，已经成为京东集团内部的标杆案例；
• TiDB 是一款开源产品，不会被某个云厂商所绑定，基于 TiDB 用户可以很轻松地实施多云战略，可以把 TiDB 部署在任意一个云上。

哔哩哔哩

客户简介

​ 哔哩哔哩（Bilibili）网站创建于 2009 年，是中国年轻世代高度聚集的综合性视频社区，被用户亲切地称为“B站”，2018 年在纳斯达克上市。根据艾瑞咨询报告，2020 年 B 站 35 岁及以下用户占比超 86% 。2021 年三季度，B 站月均活跃用户达 2.67 亿。

与国内其他视频网站定位不同，B 站主要围绕用户、创作者和内容，构建了一个源源不断产生优质内容的生态系统。许多优秀的专业视频创作者都聚集在 B 站创作内容，涵盖生活、游戏、时尚、知识、音乐等数千个品类和圈层，引领着流行文化的风潮。

十多年过去，从最初的二次元弹幕视频网站发展到现在的综合性视频社区，B 站的规模日益扩大，业务场景主要包含点播类业务、直播类业务、电商类业务、游戏类业务。每种场景对数据库等底层 IT 架构都提出了不同的需求，如点播对可用性要求比较高，直播是高并发场景，存在大量热点数据，电商则要求数据强一致性，游戏对性能要求比较高，这也对 B 站的 IT 架构提出了更多挑战。

业务挑战

​ 2018 年后，B 站每个季度用户都在以百分之七八十的比例增长，带给数据库的压力自然也在倍增。据了解，2018 年前，B 站数据架构大部分采用标准的主从架构。 2018 年后，B 站进入快速发展期，用户增长较快，急速增长的背后带来了大量的变更需求，数据量急速膨胀，需要频繁进行资源扩容、拆分、迁移。

当时，B 站的数据库大部分都在采用 MySQL，按照常规的技术演进方案，B 站应该开始考虑引入分库分表架构来解决 MySQL 单机瓶颈问题了。但一个理想的中间件，不论是开源还是自研都需要很长时间去打磨，才能使业务平滑适配。

解决方案

​ 在调研了 TiDB、CockroachDB、Vitess、Kingshard 等开源方案后，从应用的兼容性、改造成本、扩展性、高可用、运维的复杂度等维度评估后，发现 TiDB 是唯一的选择，没有其他更合适的数据库。TiDB 作为一款云原生分布式数据库，具有水平扩展、高度兼容 MySQL 、无需考虑分库分表等特点，可以满足海量数据规模，带来更强的业务灵活性和成本效益。

​ 熟悉 B 站的用户肯定都知道“一键三连”（点赞、投币、收藏），这对于提升 UP 主的创作信心具有极大功效，随着用户的快速增长，这部分的数据量也在飞速增长。点赞平台聚合了 B 站所有点赞信息，来自十几个不同业务方，截止到 2018 年时，点赞数据量已经达到百亿条，MySQL 数据库 2 TB，接口 QPS 高达数万。

​ 在业务快速增长的同时，MySQL 的磁盘空间也在快速逼近磁盘空间的上限，而 B 站的业务特点决定了相关数据不能像电商类一样进行归档。当时摆在 B 站面前的只有两条路，一是采用分库分表方案，虽然可以解决持续的空间需求，但这种方案也存在一些不足，如：中间件的打磨需要时间；对业务有入侵，需要改写代码，无法快速满足业务方的需求等。另一种就是采用 NewSQL 数据库。在对开源解决方案调研后，发现 TiDB 高度兼容 MySQL 协议、水平扩展，能很好地规避掉这些问题，部署和真正使用起来都比较快，而且对迁移数据也比较友好。

​ 在使用 TiDB 后，因为没有分表的存在，业务的 QPS 减少了 1/4，业务端耗时从 4ms 降低为 1.5ms。

​ 从 2018 年 B 站开始在生产环境上线 TiDB ，目前整体部署规模已达到 100+ 集群，数据节点 TiKV 2000+ 部署在物理机，计算节点 TiDB Server 则大部分运行在 B 站的 PaaS 上，以 Docker 方式部署，快速动态扩缩容。相关业务场景包含了大家熟知的一键三连、弹幕、评论等。

​ 在 2021 英雄联盟全球总决赛（即 S11）的直播与点播中，B 站迎来了一次最大的流量高峰。由于在本次赛事中，中国战队 EDG 战胜卫冕冠军，首次夺得全球总决赛冠军。网友都比较激动，B 站的赛事回顾视频点赞和弹幕数据一下子暴涨，数据流量瞬间变得特别大，**QPS 最高达 30w+**，比日常高 2 倍。

​ 此外，B 站的所有视频元数据都存储在 TiDB 中。这一业务对数据库的可靠性要求较高，举例来说，视频播放到哪一帧读什么素材，其实都会有一个完整的元数据存储下来。 目前，**B 站视频元数据累计达 30TB， QPS 日常维持在 5w+**。在 B 站“拜年纪”活动中，TiDB 提供了较高的稳定性。

业务价值

从业务角度看：TiDB 高度兼容 MySQL 协议，改造成本极小，业务方的需求可以得到快速满足。

从 DBA 角度看：一方面云原生分布式架构可以实现存储与计算的水平扩展，进行容量扩增更简单，从以前的几周缩短到数分钟，对业务透明无感；另一方面，TiDB 架构实现与 MySQL 是两个不同的思路，可以帮助团队技术成员扩展思路。

在深度使用下，Bilibili 的 TiDB 节点数从去年的 1000+ 涨到了今年的 2000+，未来还将在更多业务场景中进行尝试。

360

业务挑战

​ 360 网盾是一款免费的上网保护软件，可以拦截木马、欺诈网站等等保护消费者不受到病毒及虚假网站的欺诈。针对业务爆发式增长的数据量，MySQL 读写出现瓶颈。分库分表及大表改表，对业务和 DBA 来说都是不小的工作量。

​ 360 智慧商业依托覆盖用户全场景的互联网产品，为企业提供全生命周期服务。其中互联网广告是流量商业变现的重要途径之一，也是 360 集团重要的营收来源，涉及企业服务平台、广告主投放、算法策略、数据工程等多个方向。广告投放过程中实时/离线报表业务以及广告物料投放对广告主来说是最重要、最核心的业务。总数据千亿级别，单表数据量 1.2~1.5 亿，查询维度包括时间维度、地域、行业、关键词等等，同时满足多样化的展示，基于 MySQL 的分库分表无法进行全局统计。

解决方案

​ TiDB 良好的扩展性完全解决了分库分表问题，同时经过性能压测，2 小时 1.5 亿条的数据存储（TPS：2W/s），整个系统负载完全满足业务需求，通过搭配 TiFlash （TiDB 的实时分析引擎插件），可以对合并后的单表进行各种维度的全局以及明细的实时分析，并且实现了离线报表的在线统计，免去了离线数仓这种 T+1 的时效和同步流程，同时还提供金融级别的强一致性保证。

HTAP

使用 TiDB 在线事务与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 功能。

HTAP 特性及架构简介

在大数据业务领域，事务（Transaction）和分析（Analysis）具有强相关性，人们为了进行海量数据的实时分析，发明了 TA 融合这一技术，而 HTAP 则是在存储、计算等方面具有极佳的线性扩展能力，能够更好地解决海量数据的容量问题。具体而言，HTAP 的典型特性如下：

• 一是支持 TP 与 AP 混合的事务处理和分析过程。
• 二是具有水平扩展能力，通过简单增加新节点即可按需实现 TiDB 的水平扩展，进而轻松满足高并发、海量数据场景需要。
• 三是支持 SQL 请求在不同节点自由调度，少量工作节点宕机并不影响业务连续性，且在不丢失大多数副本的前提下，还可以实现故障自动恢复。
• 四是支持两地多中心高可用架构部署，包括同城两机房双活及异地机房的实时切换。
• 五是支持强一致分布式事务以及标准的 ACID 事务。
• 六是可高度兼容 MySQL 协议和常用的功能及语法。
• 七是可对数据库服务集群环境和数据库各进程以及运行 SQL 进行实时监控和告警。
• 八是可根据请求 SQL 的特性，自动决定触发 TP 事务引擎还是 AP 分析引擎。
• 九是具有独立的 TP 和 AP 引擎来支撑存储和计算需求。
• 十是支持公有云、私有云和混合云，可实现自动化运维，简化部署、配置工作。

LSM-Tree

​ LSM-Tree（Log Structured Merge-Tree，日志结构合并树），最初由 Patrick O’Neil 等人于1996年在其论文中提出。随后便在新数据库引擎中得到广泛应用，如HBase、LevelDB 、RocksDB 、OceanBase等。

​ 目前业界中实现存储引擎的两大顶流数据结构是 B+ 树和 LSM-Tree，传统关系型数据库更青睐 B+ 树，而大数据领域的存储引擎更偏爱 LSM-Tree 。

典型应用

• LevelDB （Google）
• RocksDB
• HBase
• TiDB（PingCAP 分布式数据库）
• OceanBase（Alibaba分布式数据库）
• TDSQL（Tencent分布式数据库）

B+Tree

​ B-Tree始于1970年，B-Tree 经受住了长久时间考验，时至今日，它仍然是几乎所有关系型数据库中的标准索引实现。并且许多非关系数据库也在用它。B+ 树是它的一个变种，或者说优化。

​ B+ 树是平衡搜索树的一种，是为了磁盘搜索而诞生的。B+ 树的所有数据都存储在叶子节点中，每次查询或写入时需要从根节点搜索到叶子节点，再对叶子节点对应的位置进行操作（也就是原地更新）。传统数据库会将 B+ 树的每个叶子节点设置为一个磁盘页的大小，每次磁盘 I/O 就可以加载一个完整的叶子节点的数据到内存中，以此减少 I/O 的次数。

​ **B+ 树查询、插入、删除的时间复杂度都是 O(logN)**。

​ LSM-Tree 将数据库分解为可变大小的段，通常是几M或者更大，并且始终按照顺序写入段。相比之下，B+Tree 将数据库分解为固定大小的块或页，通常大小为4KB（有时更大），页是内部读写的最小操作单元，这种设计更接近底层硬件，因为磁盘也是以固定大小的块排列。

​ 每个页面都使用地址标识，这样就可以让一个页面引用另一个页面，类似于指针，不过指向的是磁盘地址，而不是内存地址。使用这些页面引用来可以构造树形页面。

​ 某一页被指定为B+Tree 的根（Root），每当查询索引中的一个键时，总是从这里开始。该页面包含若干个键和对子页的引用。每个子页都负责一个连续范围内的键，相邻引用之间的键可以指示这些范围之间的边界。

​ 上面的例子，如果查询id=251的数据，从根节点内部开始二分查找，沿着200~300之间的页引用，到达子页，然后继续二分查找，按照这种方式最终在叶子节点找到键值，然后根据键查到磁盘位置，从而获取目标数据。

​ B+Tree 中一个页包含的子页的引用数量成为分支因子，如上图的分支因子为6，在实际中，分支因子取决于存储页面引用和范围边界所需的空间总量，通常为几百个。

​ 如果要更新B+Tree中现有键的值，首先搜索包含该键的叶子节点，更改该页的值，并将页写回到磁盘。如果要添加新键，则需要找到其范围包含新键的页，并将其添加到该页。如果页中没有足够的可用空间，则将其分裂为两个半满的页，并且父页也需要更新以包含分裂之后的新键的范围。

​ 该算法确保树保持平衡：具有n个键的B+Tree总是具有O(log n) 的深度。大多数数据库适合3-4层的B+Tree，因此不需要遍历非常深的页面层次就可以找到所需的页。（分支因子为500的4KB页的四级树可以存储高到256TB的数据）

数据修改操作

​ B+Tree 底层的基本写操作是使用新数据覆盖磁盘上的旧页。这与LSM-Tree形成鲜明对比，LSM-Tree 仅追加更新文件，但不会修改文件（并最终删除过时的文件）。

LSM-Tree

​ LSM -Tree 的核心思想就是将离散的随机写请求都转换成批量的顺序写请求。

工作流程

​ 当用户有数据写入时，会先写入内存中的 MemTable 和数据日志 log，WAL(Write-Ahead Log) 机制保证重启后通过回放数据日志可以恢复到重启之前的状态，内存表通常采用排序树（红黑树/AVL 树）。

​ 当 MemTable 的数据量达到阈值（通常为几M），会将 MemTable 冻结为只读状态的 Frozen MemTable，冻结的同时会创建一个新的 MemTable 用于提供数据写入。后台会将 Frozen MemTable 的数据以 Rowkey 递增的次序顺序写入磁盘中，生成一个 SSTable。由于树已经维护了按键排序的KV对，所以写磁盘是比较高效的。这个过程结束后，该 Frozen MemTable 与其对应的 log 可以被回收。

​ LSM-Tree 中的所有查询都会先从 MemTable 中开始查询，若 MemTable 中未发现该 key 的完整数据，再从 L0、L1 直到 LN 进行查询，直到查询到 LN 层返回 key 不存在或得到完整的行数据。

​ 后台进程周期性的执行段合并与压缩过程，以合并多个段文件，并丢弃哪些已经被覆盖或删除的值。

MemTable

​ MemTable 是纯内存状态，为了便于后续进行顺序读取生成磁盘上的 SSTable，一般采用排序树（红黑树/AVL 树）、SkipList 等这类有顺序的数据结构。

SSTable

​ SSTable 全称为 Sorted String table，意为内部有序的磁盘文件（是从 Google 的 BigTable 所借用的概念）。数据按照 Key 排序，可以使用二分搜索的方式快速得到指定 key 的数据。

​ 磁盘上的 SSTable 被划分为多个层级（Level），层级数字越低表示数据被写入的时间越近，层级数字越大表示数据越旧。

修改操作

​ 对于传统的数据库来说，UPDATE 和 DELETE 可以直接原地更新，但是由于 LSM-Tree 是 append only 类型，UPDATE 和 DELETE 都需要作为额外的一个行写入。这会导致一个 key 如果发生了多次更新，在整个 LSM-Tree 中会存储多个行。

性能优化

布隆过滤器

​ 当查询数据库中某个不存在的键时，LSM-Tree 的算法可能很慢：因为必须先读取内存表，然后将段一直回溯访问到最旧的段文件，可能从磁盘多次读取。

​ 为了优化这种访问，存储引擎通常使用额外的布隆过滤器。布隆过滤器是内存高效的数据结构，用于近似计算集合的内容，如果数据库中不存在某个键，它可以很快告诉你结果，从而节省了很多对于不存在的键的不必要的磁盘读取。

如果布隆过滤器告诉你元素在集合中，则有可能在集合中；但当告诉你没在集合中时，则一定不再集合中；

合并压缩策略

两种策略：

• 分层压缩：LevelDB、RocksDB
• 大小分级：HBase

在大小分级的压缩中，较新和较小的SSTable 被连续合并到较旧和较大的SSTable 中。

在分层压缩中，键的范围分裂成多个更小的SSTable，旧数据被移动到单独的层级，这样压缩就可以逐步进行并节省磁盘空间。

尽管有一些细微差异，但LSM-Tree 的基本思想足够简单有效，并且由于数据是顺序写入的，所以LSM-Tree可以支持非常高的写入吞吐量。

预写日志 WAL

​ 我们知道，LSM-Tree 在写数据时只管往内存表中写入，并没有立即持久化到磁盘，那么如果发生宕机，内存中没来得及持久化的数据岂不是丢失了？在MySQL等传统关系型数据库中，是通过redo log 重写日志保证数据不丢失的。那么在LSM-Tree 中是如何保证的，那就是WAL机制。

​ WAL（Write-Ahead Log，预写日志） 机制保证重启后通过回放数据日志可以恢复到重启之前的状态。在写入 MemTable 之前，往 WAL 写入日志，避免宕机出现的数据丢失的情况发生。

B+Tree VS LSM-Tree

​ 根据经验，LSM-Tree通常写入更快，而B+Tree被认为对于读取更快。读取通常在LSM-Tree 上较慢，因为它必须在不同的压缩阶段检查多个不同的数据结构和SSTable。

特性

​ 比传统的B+树有更好的写性能，将离散的随机写请求转化为批量的顺序写，无论是RAM、HDD还是SSD，顺序写的性能都要明显优于随机读写。

README

作者：

​ 2023-02-01 银法王 第一次修订

参考：

​ TiDB官方文档

​ 新一代数据库TiDB在美团的实践

​ TiDB数据库在汽车之家的应用与实践

​ 从 LSM Tree 到 HBase

​ OceanBase 存储引擎