分布式数据库TiDB介绍

什么是散布式业务？

散布式数据库和许多技术概念相同，没有权威机构来做这个界说。咱们能够经过他的特性进行界说。 一般业务使用体系能够按照交易类型分为联机交易（OLTP）场景和联机剖析（OLAP）场景两大类。OLTP 是面向交易的处理进程，单笔交易的数据量小，但是要在很短的时间内给出成果，典型场景包括购物、缴费、转账等；而 OLAP 场景一般是根据大数据集的运算，典型场景包括生成个人年度账单和企业财务报表等。

只看OLTP场景的话一般有三个特色：

• 写多读少，并且读操作的杂乱度较低，一般不涉及大数据集的汇总计算；
• 低延时，用户关于延时的容忍度较低，一般在 500 毫秒以内，略微扩大一些也就是秒级，超越 5 秒的延时一般是无法承受的；
• 高并发，并发量跟着业务量而增加，没有理论上限。

散布式数据库除了详细传统联系型数据库的基本功用之外，还需求处理了⼀些传统联系型数据库存在的⼀些问题：

• 功用瓶颈： 在大规划数据和高并发拜访的状况下或许呈现功用瓶颈。
• 扩展性： 跟着业务规划的扩大，传统数据库或许面对扩展性问题。
• 可用性： 传统数据库单节点毛病或许导致整个体系不可用。
• 容错性： 传统数据库在产生毛病时或许导致数据丢掉。
• 扩展性： 跟着业务规划的扩大，传统数据库或许面对扩展性问题。

咱们能够界说散布式数据库：散布式数据库是服务于写多读少、低延时、海量并发OLTP场景的，具备海量数据存储能⼒和⾼牢靠性的联系型数据库 。

⽬前常⻅的⼀些散布式数据库基本上都是在Google Spanner的理论基本上建⽴的。

为什么需求散布式数据库

传统联系型数据库存在的问题，这⾥咱们以MySQL为例：

• 单机数据容量存在上限，一般需求经过集群布置，进⾏⽔平或垂直分表进⾏扩展
• 单机功用依赖硬件进⾏提升
• 分表后数据扩展一般伴跟着⼤量数据迁移，逻辑杂乱
• MySQL主从数据同步存储牢靠性问题，全同步仿制功用难以保证，半同步数据在极点状况下存在丢掉数据的或许，散布式数据库就是为了处理传统数据库这些问题⽽产⽣。

TiDB介绍

TiDB 是 PingCAP 公司自主规划、研发的开源散布式联系型数据库，是一款一起支撑在线业务处理与在线剖析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型散布式数据库产品，具备水平扩容或许缩容、金融级高可用、实时 HTAP、云原生的散布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户供给一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 处理方案。TiDB 适合高可用、强共同要求较高、数据规划较大等各种使用场景。

全体架构如下：

• TiDB Server：SQL 层，对外露出 MySQL 协议的衔接 endpoint，担任承受客户端的衔接，履行 SQL 解析和优化，终究生成散布式履行计划。TiDB 层本身是无状况的，实践中能够启动多个 TiDB 实例，经过负载均衡组件（如 LVS、HAProxy 或 F5）对外供给共同的接入地址，客户端的衔接能够均匀地分摊在多个 TiDB 实例上以到达负载均衡的作用。TiDB Server 本身并不存储数据，只是解析 SQL，将实践的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。
• PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，担任存储每个 TiKV 节点实时的数据散布状况和集群的全体拓扑结构，供给 TiDB Dashboard 管控界面，并为散布式业务分配业务 ID。PD 不只存储元信息，一起还会根据 TiKV 节点实时上报的数据散布状况，下发数据调度指令给详细的 TiKV 节点，能够说是整个集群的“大脑”。
• 存储节点
  • TiKV Server：担任存储数据，从外部看 TiKV 是一个散布式的供给业务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 担任存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会担任多个 Region。TiKV 的 API 在 KV 键值对层面供给对散布式业务的原生支撑，默许供给了 SI (Snapshot Isolation) 的隔离等级，这也是 TiDB 在 SQL 层面支撑散布式业务的中心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的履行计划转换为对 TiKV API 的实践调用。
  • TiFlash：TiFlash 是一类特别的存储节点。和一般 TiKV 节点不相同的是，在 TiFlash 内部，数据是以列式的形式进行存储，首要的功用是为剖析型的场景加快。

TIDB中心特性

• 自动弹性， 可按需对计算、存储分别进行在线扩容或许缩容，扩容或许缩容进程中对使用运维人员通明。
• 金融级高可用， 数据采用多副本存储，数据副本经过 Multi-Raft 协议同步业务日志，多数派写入成功业务才干提交，保证数据强共同性且少量副本产生毛病时不影响数据的可用性。
• 实时HTAP，供给行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 经过 Multi-Raft Learner 协议实时从 TiKV 仿制数据，保证行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强共同。TiKV、TiFlash 可按需布置在不同的机器，处理 HTAP 资源隔离的问题。
• 高扩展性， 云原生的散布式数据库专为云而规划的散布式数据库，经过 TiDB Operator 可在公有云、私有云、混合云中实现布置工具化、自动化。
• 无缝兼容MYSQL， 兼容 MySQL 5.7 协议和 MySQL 生态兼容 MySQL 5.7 协议、MySQL 常用的功用、MySQL 生态，使用无需或许修改少量代码即可从 MySQL 迁移到 TiDB。

总结

整体而言，TiDB 的目标是供给一个强壮、高功用、散布式的数据库处理方案，适用于处理杂乱的业务和剖析性查询作业负载。

但散布式数据库并不是为了彻底取代传统联系型数据库，相对传统联系型数据库，它也存在⼀些缺陷：

• 散布式环境，单机功用不如传统联系型数据库，如呼应时间等
• 多表关联能⼒弱
• 业务处理功用相对较差