突破容量极限：TiDB 的海量数据“无感扩容”秘籍

对于任何一家业务快速成长的企业来讲，应对峰值流量冲击，一直是摆在技术团队面前的一大难题。面对海量数据，数据库及业务团队都但愿作到“无感扩容”，但流行的分库、分表方案在扩容速度和一致性上常常不能知足需求。行业期待着性能强大、简单易用的全新数据库方案，从根本上解决企业面对流量高峰时的数据库性能瓶颈。数据库

行业需求是技术创新的最大推进力。近年来，由 PingCAP 开发的 TiDB 分布式数据库异军突起，在海量数据处理领域具备很大的优点。在此背景下，2020 年初京东智联云联合 PingCAP，基于 TiDB 打造了云端分布式数据库——Cloud-TiDB。浏览器

11 月 26 日，京东智联云与英特尔联合举办了主题为“突破极限，TiDB 在京东智联云的技术架构与实践”的线上直播活动。直播邀请到_京东智联云云产品研发部架构师葛集斌老师，和 PingCAP TiDB 生态技术布道专家戚铮老师_分别带来分享，但愿借此机会帮助更多企业和开发人员拓展思路，提供一个分库分表途径以外的新选择，并了解如何在生产实践中发挥 TiDB 的价值。性能优化

本文总结自本场直播分享，内容有调整。架构

1、TiDB在京东智联云的技术架构与实践

直播第一部分，葛老师深刻分析了京东智联云为什么选择 TiDB 数据库，并介绍了 TiDB 在京东智联云上的技术架构和技术生态细节。并发

1，TiDB数据库但愿解决哪些问题

传统单机数据库在当下的大数据时代暴露出了愈来愈多的局限性，对于一家快速增加的企业来讲，因为数据量会随着企业规模有序扩大，单机数据库很快就会遭遇多个瓶颈：负载均衡

单表、单库数据量过大；运维

单机存储容量达到上限；异步

单机处理能力达到瓶颈。分布式

读取延迟和存储需求上升，而且没法扩展写入性能。高并发

想要继续提高性能，传统方法就是对数据库进行分库分表，但分库分表也存在数日然约束。

在高可用性方面，MySQL 须要集成外部程序来处理。

MySQL 的故障检测、主从判断和转移都须要定制策略。

异步和半同步复制是非强一致性的，增长了数据丢失的风险。

此外，MySQL 的 OLAP 数据处理能力较弱，数据分析需求还须要 ETL 到外部分析系统。以上这些都是传统数据库方案现实存在的瓶颈。TiDB 的诞生，就是为了解决这些传统数据库常见的问题，但愿可以从根本上突破单机数据库的能力极限。

具体到技术层面，TiDB 数据库有哪些良药来应对上述问题呢？首先要明确的是，TiDB 不一样于传统单机架构，而是一个真正意义上的分布式数据库。采用计算、存储分离的架构设计，提供水平线性扩展能力。它还具有强一致性、高可用性，支持自动故障恢复，能够对数据进行实时分析。另外它还高度兼容 MySQL 协议。总体架构来看，TiDB 分为 TiDB Server、分布式存储层和 PD 三大部分：

TiDB Server 兼容 MySQL 协议，能够水平扩展，所以用户能够将 TiDB 看成 MySQL 使用。

TiDB 存储层 TiKV 是分布式 KV 存储，能够线性扩展，并经过多副本和 Raft 协议保证强一致性。TiKV 还分为多个 region，以 region 为单位进行管理。数据分布在各个 TiKV 节点上，节点能够水平扩展。

PD 负责集群管理，包括调度和负载均衡工做，并负责生成全局的 TSO 时间戳。PD 自己也是无单点故障的集群。

TiDB 使用 TiFlash 列存储引擎来支持实时数据分析。它经过 Raft learner 进行异步复制，配合 MVCC 提供强一致性读取，还支持计算下推，使得其 AP/TP 功能相互无干扰。使用 TiFlash 时 TiDB 优化器会计算查询代价，根据结果自动选择 TiKV 行存或 TiFlash 列存。

基于这样的架构设计，TiDB 集群实现了总体的高可用性和数据强一致性，即便少数副本丢失也能自动完成数据修复和故障转移，不会干扰业务层。TiDB 能够实现跨中心的异地多活部署。

2，云上TiDB的实现和功能

近年来，京东智联云的客户对数据处理能力的需求不断提高。针对这样的需求，京东智联云与 PingCAP 联合，基于 TiDB 打造了云端分布式数据库——Cloud-TiDB，主要面向高性能、高可靠、高可用场景。

上图为京东智联云 Cloud-TiDB 的总体架构，基于这样的架构，Cloud-TiDB 提供了一些业务价值较高的功能，包括水平弹性扩容、备份和恢复、实时数据分析、数据迁移和同步、云端监控告警等。

**水平弹性扩容。**TiDB 能够在线动态增减存储和计算节点，具有接近无限的水平扩展能力。伸缩操做后，数据库还能够自动实现数据再均衡。

**备份和恢复。**TiDB 支持自动 / 手动全量备份，并将数据备份在 OSS 中。恢复时数据不会覆盖原有集群，可有效防止误操做。

**实时数据分析。**在支持 OLTP 的同时提供业务数据的实时分析和处理。

**数据迁移和同步。**支持全量 / 增量迁移，能够将数据同步到 MySQL、Kafka 下游存储中。

**监控与告警。**TiDB 提供了丰富的监控指标，支持浏览器直接访问。云监控提供资源 / 业务层面的监控告警，云日志能够配置错误日志监控报警。除上述能力外，在实践应用中 Cloud-TiDB 的另外一大优点就是更低的运维成本。Cloud-TiDB 能够很好地知足云服务按需伸缩的需求，使用户能够精确地控制资源使用量，避免资源浪费。

选择一项新技术的同时也是在选择一个生态，生态越完善，开发和运维效率也会越高。TiDB 生态的一大特色就是兼容 MySQL 协议，从而能够受惠于成熟的 MySQL 生态资源。MySQL 的全部数据库驱动、第三方开发 / 管理工具、数据交换 / 迁移工具等，均可以用于 TiDB 数据库。

TiDB 与其余主流数据处理技术也能够方便地互联互通。例如 TiDB 数据能够导入 Kafka，接入 Flink，乃至 Hive、HDFS、Amazon S三、Spark 等。用户无需担忧技术锁定风险，这也为 TiDB 的生态繁荣打下了基础。

在分享的最后，葛老师对云端数据库的发展趋势作了展望：

分布式是将来技术发展的重要趋势之一，包括操做系统、应用程序和数据库都在向分布式转变。TiDB 做为分布式数据库，比较符合这一技术发展趋势。与此同时，数据库上云能够带来不少好处，例如弹性调度、与 AI 结合，还能更好地理解用户的业务视角，实现数据处理的智能优化。

长远来看，数据库上云能够在开发、运维和稳定性层面得到很大收益。正因如此，京东智联云选择 TiDB 上云，就是但愿能给用户带来更好的使用体验。

2、TiDB在大数据量和高并发场景下的应用

葛老师的演讲结束后，来自 PingCAP 的 TiDB 生态技术布道专家戚铮分享了 TiDB 在大数据量和高并发场景下的应用实践。

1，TiDB与SHARDING 在 OLTP场景下的解决方案对比

当企业遇到海量数据需求时，每每伴随数据量短时间内急剧增加的压力。这样的业务须要数据库具有快速扩容能力和高并发能力，在响应延迟和吞吐量指标上都有足够高的水平以应对突发流量。而 OLTP 场景主要涉及线上 2C 交易，对数据库稳定性要求较高，数据库性能波动会直接影响用户体验。

针对这样的需求特色，业内常见的解决方案分为 Sharding、New SQL 和中间的 DB-Based 几大类型。其中，ShardingSphere 和 TiDB，就是第一和第三种类型中的两个典型。二者都是当下活跃的开源项目，分别表明了应对海量数据需求的两大思路。所谓 Sharding 就是分库分表，实践中主要分为水平拆分和垂直拆分两大纬度。垂直纬度通常按照业务模块或者数据系列来拆分，水平纬度能够按取模、时间、冷热库等方式拆分。Sharding Sphere 做为分库分表思路的表明，其架构大体以下：

与前文列举的 TiDB 架构相比，Sharding 架构的数据备份、高可用、监控告警等需求，都须要周边第三方工具来配置解决。而 TiDB 自身就是完整的解决方案，能够一站式知足用户对高性能数据库的各项要求。现在 ShardingSphere 也开始在新版中开始向总体分布式数据库方案转型，从侧面印证了分布式数据库是将来的必然趋势。

2，TiDB的海量数据应用案例

TiDB 的初衷就是解决分库分表存在的许多问题，但某些场景并不太适合向 TiDB 迁移。具体来讲，这样的场景中业务不会有快速增加，业务请求比较简单，也没有分布式事务需求。除了这样的场景之外，大部分海量数据需求均可以经过向 TiDB 迁移获得较好的解决。戚老师这里列举了几个实践案例。

某社区个性化首页和推送业务。因为海量用户的个性化推送业务特性，数据库天天须要生成 30 亿条数据，历史数据高达万亿量级，业务对吞吐量和延迟也高度敏感。该用户原有的 MySQL 方案基于分库分表，但 MySQL 实例总量达到上百个，风险和延迟都难以知足需求。通过调研，用户认为 TiDB 是惟一能知足他们对高扩展、强一致、高可用需求的解决方案，所以决定全面迁移。在迁移过程当中，PingCAP 开发了一个快速导入工具 Lightning 结合 DM 工具来平滑转移数据，迁移完成后又作出了一系列优化，最终很好地知足了需求。尤为令用户满意的是新架构具有很强的扩展能力，迁移后数据量从 1.3 万亿逐渐增加至 1.8 万亿，性能、可用性依旧保持在很高的水平上，成本相比过去也没有明显增长。

某电信我的帐单系统。该用户帐单总表有 80 亿数据，对性能要求很高，而原有的 MyCAT 方案已接近扩展极限，只能存储不足一年的历史数据。因为 MySQL 分库分表的处理瓶颈，继续分片会出现很多问题，故此用户选择了 TiDB 进行升级换代。向 TiDB 迁移后，单表数据量便可达到 100 亿，数据存储周期由半年延长至 3-5 年，QPS 和延迟都有显著改善。

戚老师还介绍了某 O2O 平台 PMC 订单流水业务、某金融核心帐务系统和某互金营销平台向 TiDB 迁移的案例。这些案例的共同点都是用户原有的数据库分库分表遇到了增加瓶颈，对业务形成了愈来愈多的负面影响，而迁移到 TiDB 后彻底解决了原有瓶颈，迁移过程没有遇到严重故障，成本投入也在可控范围内。

3，TiDB 5.0 亮点解析

分享的最后环节，戚老师介绍了 TiDB 5.0 版本的性能优化亮点和细节，主要包括如下几项特性。

**Async Commit。**旧版 TiDB 采用两阶段提交模式，开销相对较大。Async Commit 主要在第二阶段实现了异步提交，对于小事务达到相似 1PC 的效果，从而带来了必定的性能提高。

**Clustered Index。**新版的这一特性很适合条件范围包含主键列的查询，相似 Innodb 聚簇索引，能够节省这类查询的回表成本。根据 TPCC 测试，新版在这方面能够带来必定性能增幅。

**Compaction Filter。**该特性主要针对后台自动整理压缩数据引发的性能抖动进行优化，开启后 QPS 的波动标准差下降到了 5% 之内。

**SATA SSD 优化。**结合 compaction filter，fsync control，compaction guard 等这些新增特性，5.0 版本在 SATA SSD 上的性能吞吐和延迟表现都比 4.0 有了较大改善，因为 SATA 盘自己抖动致使的 QPS 抖动也有明显降低。

3、突破容量极限，TiDB打破企业数据库性能瓶颈

相比传统的分库分表，TiDB 是真正一站式的分布式数据库总体解决方案，可以充分知足企业业务快速增加、海量数据高并发、实时数据分析和金融数据高可用等场景的苛刻需求。经过本场直播两位老师的精彩分享，听众对 TiDB 数据库的能力、实现细节和业务落地实践都有了更深刻的认知，也了解了 TiDB 数据库服务的各项突出优点。

正如两位老师所言，分布式数据库是业内必然的发展趋势，而 TiDB 顺应了这一潮流，将成为愈来愈多企业根治数据库性能瓶颈的良方。与此同时，TiDB 在京东智联云的应用，为企业快速采用 TiDB、尽早享受 TiDB 收益和价值开辟了一条便捷通道。

想要了解更多京东智联云与 TiDB 相关内容，获取演讲PPT，可在评论区评论PPT，咱们会及时回复获取方式。

点击_【阅读原文】_查看视频回放连接。