1      前言

随着国内互联网企业的疾速倒退，传统的 oracle 数据库架构在老本和扩展性上已不能满足要求，更多的企业将眼光转向了开源的 MySQL 数据库，因为 MySQL 自身是一个单机数据库其自身并不具备横向扩大能力，于是呈现了利用侧的分库分表计划。进一步的又开发出分库分表中间件，由中间件实现分库分表的治理，防止了利用侧的复杂性，分库分表尽管肯定水平解决了扩展性的问题，但也存在着其余比较严重的问题，比方：必须指定分库键、分布式事务反对能力差、全表扫描性能影响、在线扩大能力有余等，实际上分库分表更多的只是一个路由性能。

NoSQL 数据库的呈现解决了分库分表的复杂性和扩展性问题，通过将一些简略场景运行在 NoSQL 数据库 (如 HBase、MongoDB、Cassandra 等) 上取得了利用通明和扩大能力的反对。因为 NoSQL 不反对 SQL 和事务或反对能力较差，导致很多基于 SQL 开发的利用无奈间接迁徙，须要从新开发，同时无奈应用 SQL 的一些性能，也减少开发的复杂度和老本。

基于 NoSQL 数据库的扩大能力劣势，又呈现了反对 SQL 的 NewSQL 分布式数据库，同时反对 SQL 和分布式事务，并且具备良好的扩大能力，该类数据库更多参考谷歌 spanner/ F1 等，应用 LSM 的 KV 模型，典型的代表有 TiDB、CockroachDB、oceanbase 等。同时也呈现了相似于 AWS aurora、Polardb 等基于分布式共享存储的计划。

为满足实时数仓、统计分析等需要又呈现了一种新的数据库状态 HTAP(Hybrid Transaction and Analytical Process, 混合事务和剖析解决)，同时满足 OLTP 和 OLAP 业务，典型的代表有 TiDB，也有越来越多的国产数据库公司退出 HTAP 营垒。

本文从理论应用和运维治理角度剖析 TiDB 能解决的问题痛点。

2      TiDB 架构

（1）计算节点

TiDB Server：SQL 层，负责承受客户端的连贯，执行 SQL 解析和优化，最终生成分布式执行打算。TiDB 层自身是无状态的，实际中能够启动多个 TiDB 实例，通过负载平衡组件（如 LVS、HAProxy 或 F5）对外提供对立的接入地址，客户端的连贯能够平均地摊派在多个 TiDB 实例上以达到负载平衡的成果。

（2）管制节点

PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布状况和集群的整体拓扑构造，提供 TiDB Dashboard 管控界面，并为分布式事务调配事务 ID。PD 不仅存储元信息，同时还会依据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，如热点负载平衡、raft 正本创立转移等。此外，PD 自身也是由至多 3 个节点形成，领有高可用的能力。

（3）存储节点

TiDB 作为 HTAP 混合负载数据库，同时具备反对高并发 OLTP 事务的行存 TiKV 和反对实时数仓的 MPP 列存 TiFlash。

(1)    TiKV Server：负责存储数据，从内部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的根本单位是 Region，每个 Region 负责存储一个 Key Range 的数据，每个 TiKV 节点会负责多个 Region。另外，TiKV 中的数据都会主动保护多正本（默认为三正本，采纳 raft 协定），人造反对高可用和主动故障转移。

(2)    TiFlash：通过 raft 协定实时的同步数据，数据是以列式的模式进行存储，次要的性能是为剖析型的场景减速，提供实时数仓能力。

3      痛点问题剖析

3.1  分库分表复杂性

分库分表中间件解决了单节点性能问题，提供了肯定的扩展性，但具备较大的业务侵入性，其次要问题有：

(1)    在设计时须要思考表的分库键，利用零碎须要从新开发。SQL 语句中必须带有分库键，否则中间件无奈晓得申请该发往哪个分库从而对所有分库发动全表扫描，对于反对禁用全表扫描个性的中间件不指定分库键则会报错。

(2)    当业务查问时无奈晓得分库键的状况下局部的解决形式是通过异构索引实现，首先通过异构索引等获取分库键而后再去中间件进行查问，异构索引的保护须要数据同步或者双写形式，可能会带来数据不统一而影响业务。

(3)    为缩小跨库 join，局部小表会设置为播送表或复制表，将 join 查问下推到分库执行，播送表在分库间的数据须要同步，减少了治理保护复杂性，且数据同步有可能提早而影响业务。

(4)    分库分表中间件对强一致性的分布式事务反对少数采纳 XA 协定，比拟依赖底层 MySQL 的 XA 反对和容错能力，对底层数据库版本有所要求，如阿里 DRDS、MyCat 等倡议后端 MySQL 是 5.7 版本时才应用 XA 事务。

(5)    某个分库存在热点时，无奈通过疾速迁徙形式平衡热点拜访，须要从新将数据 Hash 到新分库后可能能力打散热点。

TiDB 作为分布式关系型数据库，由计算节点 tidb server 提供拜访服务，通过负载平衡软件保障对计算节点的平衡拜访，用户应用时齐全能够看做是一个单节点 MySQL 数据库，不用关怀是否有分库键，还能够在数据库内应用 range、hash、list 等分区表。

TiDB 采纳 raft 多数派协定，强一致性事务模式，默认为 3 正本，以 region(96M)为单位进行治理，一个 region 就是一段间断的 key 空间，tikv 内每个 region 蕴含 leader/follower 两种角色，默认状况下由 leader 提供读写申请，leader 依照算法均匀分布到所有的存储节点 tikv 实例上，零碎依据 region 的负载拜访状况能够主动进行 region 的决裂和 leader 的转移，使各节点负载尽量平衡。Follower 节点作为 leader 的实时正本，可通过 follower read、stale read 等性能将非刻薄的实时读扩散到其余节点，进而升高 leader 节点的压力晋升整体零碎解决能力。

3.2  在线扩容能力

分库分表的模式底层个别应用 MySQL 主从形式，当须要进行底层分库扩容时，对于已有的历史数据大抵须要经验增加新分库、迁徙历史数据、数据库切换、历史数据清理等步骤，步骤较为繁琐，切换之前新扩容实例不能提供服务，且当主机上分库达到上限后无奈再扩容。

TiDB 在对存储节点 tikv 进行扩容时只需一条命令即可实现扩容操作，管制节点会主动的进行 region 调度以使每个实例的 region 和 Leader 平衡，当 leader 调度到新实例后即可开始服务, 能够通过参数设置管制调度速度防止对集群造成影响。

3.3  执行打算治理

     对于 MySQL、分库分表中间件当遇到慢 SQL 时存在以下几个问题：

(1)    不能存储 SQL 执行时的理论执行打算，只能在发现慢 SQL 后应用 explain 查看，而查看时的执行打算和执行时可能会不一样。

(2)    不能以理论执行的形式查看执行打算（MySQL8.0.18 版本开始反对 explain analyze 形式）

(3)    不能对 SQL 执行打算绑定。

TiDB 的慢 SQL 日志内会记录执行打算，通过 select tidb\_decode\_plan()即可查看，同时 dashboard 内也能够查看慢 SQL 的执行打算。TiDB4.0 版本时推出 SPM 性能，实现执行打算的绑定，晋升了执行打算稳定性。可参考文档 https://tidb.io/blog/83b454f1。

从 TiDB 的执行打算相干性能上看根本实现了相似 oracle 内的罕用操作，执行打算展现也相似于 oracle 的模式，同时执行打算内还报含了每一步骤的资源耗费和工夫统计信息，比拟利于判断执行打算的问题点。

3.4  DDL 变更影响

MySQL、Oracle 数据库在执行 DDL 变更时如加列、增加索引等须要持有排他锁，会阻塞其余操作，尽管有 online ddl 能力，执行期间容许 DML 操作，但在执行开始和完结时依然要获取排他锁，避免有其余会话同时操作。而且在理论中发现当数据量较大时及时有 oneline ddl 仍会对其余会话产生锁阻塞。

TiDB 的表构造在线变更基于 Google F1 的异步 Schema 变更算法实现，变更是在线的、异步的，并且 Schema 变更过程中所有数据放弃可用，保持数据一致性，并最大限度减小对性能的影响。DDL 变更操作仅更改数据字典，很快便可实现，仅有创立索引时须要回填数据，对于大表执行工夫可能较长，能够通过设置并发线程加快速度，然而还是存在着串行执行问题。

3.5   混合负载反对

HTAP 混合剖析和事务处理是指一套数据库上既能提供 OLTP 解决能力又能提供 OLAP 的剖析能力，分库分表形式个别通过数据同步形式将 OLTP 业务的数据同步到后端的剖析型数据库，该架构下除了保护生产库，还须要保护数据同步通道和后端剖析型数据库，且在大数据量下存在着肯定提早，不能满足实时数仓要求。

TiDB HTAP 架构交融 OLTP 行存和 OLAP 列存两种模式，通过 tikv 提供 oltp 事务处理，通过 tiflash 提供 OLAP 解决，提供 MPP 能力。TiDB 内数据一致性通过 raft 实现，tikv 中数据正本蕴含 leader 和 follower 角色，由 leader 实时接管计算节点的数据写入。tiflash 中数据正本为 learner 角色，只从 leader 上同步数据，不参加 raft 投票，不影响 tikv 内 leader 选举、迁徙等，对 OLTP 事务处理无影响。

OLTP/OLAP 拜访通过对立的计算节点入口实现，能够应用计算节点的智能抉择形式，依据数据量主动抉择从 tikv 还是 tiflash 读取数据，还能够设置引擎隔离，使计算节点仅拜访 tiflash，而不影响 tikv 节点。

Oracle 12C 版本开始也反对内存列存，，将行数据以列存模式存在内存中，同时具备行存、列存两种模式。MySQL 推出了一个列存引擎 heatwave 用于 OLAP 的剖析场景，作为 mysql 的第二引擎，目前只能在 oracle cloud 服务上应用，。

3.6   冷热存储拆散

历史数据存储是 OLTP 型数据库常常面对的问题，从利用设计、数据库性能、存储层都在思考数据分层存储，实现冷热数据的拆散，将比拟低廉的高速存储资源用于频繁的业务，低速的存储资源用于不常拜访的业务数据，从而实现既能降低成本又能最大化的晋升性能。例如订单类表：1 年内的数据拜访较为频繁且拜访性能要求较高，那么能够把这些数据放到高性能设施上，而历史数据能够放到低性能设施。在利用设计时提前布局好生产表和历史表 (可能每年一个历史年表) 业务实现，对于 oracle 数据库须要新调配表空间实现冷热分层(12C 版本开始反对生命周期治理，能够实现表和分区级的主动压缩、存储分层)，对于 MySQL 可能须要新建实例通过数据导入导出实现冷热分层。

TiDB 5.3 版本开始反对 placementrules in SQL(参考 https://tidb.io/blog/2dd85a80) , 可在 DDL 语句中设置库、表、分区级的数据搁置规定，通过搁置规定能够实现不同表设置不同的正本数、不同表的 Leader 放到不同的核心、数据的冷热存储分层，搁置规定的实现通过存储层的 lable 参数辨认存储节点的数据中心、机房、机架、主机、磁盘类型等，从而实现一个集群内的不同搁置规定。比方在两地三核心的场景下(带宽满足的状况下)，能够在同城的 2 核心搁置生产表的 leader，以提供疾速的拜访，历史数据表能够放到异地的容灾核心，提供实时性要求不刻薄的历史数据拜访，从而能充分利用 3 个核心的资源。

除此之外 tidb 有着较好的数据压缩存储能力，可能节俭磁盘空间的占用，依据京东物流的测试应用状况，和 MySQL 相比压缩比可达 3:1。详见链接：https://asktug.com/t/topic/12…

3.7  监控指标精密度

TiDB 集群在部署时会同时部署一套 Prometheus 和 grafana, 数据库内蕴含有很多 metrics 接口用于监控数整个集群 (蕴含主机) 的性能和状态信息，并将这些信息写入到 Prometheus 里，细化指标达到 1000 多个，频率根本为 30 秒 / 次。告警程序只需从 TiDB 集群的 Prometheus 间接查问即可取得监控指标数据，极大的不便了告警程序接入。除了上述性能外 TiDB 在继续改良零碎可观测性，5.4 版本开始推出实时展现 TOP SQL、ContinuesProfiling 性能，这里有点相似 oracle 的 ASH 性能.

3.8  自主运维能力晋升

国产数据库官网文档普遍存在着内容简短的问题，相干原理只是粗略介绍，对于使用者来说无奈理解到外部原理，须要依附厂商实现问题解决，不便于自主运维能力晋升。

TiDB 从 2015 年 1.0 版本开始开源(目前最新版 5.4)，遵循 apache2.0 开源协定，与其余国产库开源形式不同，tidb 自开始便以开源形式在 github 上提交代码，目前已有很多大厂在应用，建设了良好的社区环境，有较多的教训可供参考（目测有些大厂正是因为看到了 tidb 开源带来的效应也开始开源本人的产品）。官网文档相较于国内其余数据库写的也绝对比拟详尽，通过每个版本的 release，就能够看出其用心和器重水平，并且博客上也有很多丰盛的技术文章，如源码剖析系列。对于数据库的理解水平有利于企业的数据库选型、运维延续性和老本升高。

据墨天轮数据库排行榜统计 TiDB 已间断多年成为最风行的国产数据库。

4      总结

在国产化的背景下，越来越多的企业放弃 oracle 而抉择国产数据库，大多数最后的策略可能会抉择分库分表形式，分库分表后端的 MySQL 相对来说还是比拟成熟稳固，但分库分表带来的成本增加(开发成本、运维老本)、复杂性也逐步成为企业痛点，TiDB 作为新兴的 NewSQL 分布式关系型数据库，在面对高并发和海量数据场景下，提供了较好的 OLTP 解决能力和疾速的扩缩容能力，很好的解决了分库分表带来的痛点问题。当然确定一款数据库是否适宜本人的业务还须要大量测试和实际测验。

本文作者：h5n1 发表于 2022-03-14

原文链接：国产化浪潮下 TiDB 解决的痛点问题 | TiDB 社区