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 社区