likes
comments
collection
share

分布式数据库TiDB介绍

作者站长头像
站长
· 阅读数 5

什么是分布式事务？

分布式数据库和很多技术概念一样，没有权威机构来做这个定义。我们可以通过他的特性进行定义。 通常业务应用系统可以按照交易类型分为联机交易（OLTP）场景和联机分析（OLAP）场景两大类。OLTP 是面向交易的处理过程，单笔交易的数据量小，但是要在很短的时间内给出结果，典型场景包括购物、缴费、转账等；而 OLAP 场景通常是基于大数据集的运算，典型场景包括生成个人年度账单和企业财务报表等。

只看OLTP场景的话通常有三个特点：

  • 写多读少，而且读操作的复杂度较低，一般不涉及大数据集的汇总计算；
  • 低延时，用户对于延时的容忍度较低，通常在 500 毫秒以内，稍微放大一些也就是秒级，超过 5 秒的延时通常是无法接受的；
  • 高并发，并发量随着业务量而增长，没有理论上限。

分布式数据库除了具体传统关系型数据库的基本功能之外，还需要解决了⼀些传统关系型数据库存在的⼀些问题：

  • 性能瓶颈： 在大规模数据和高并发访问的情况下可能出现性能瓶颈。
  • 扩展性： 随着业务规模的扩大，传统数据库可能面临扩展性问题。
  • 可用性： 传统数据库单节点故障可能导致整个系统不可用。
  • 容错性： 传统数据库在发生故障时可能导致数据丢失。
  • 扩展性： 随着业务规模的扩大，传统数据库可能面临扩展性问题。

我们可以定义分布式数据库：分布式数据库是服务于写多读少、低延时、海量并发OLTP场景的，具备海量数据存储能⼒和⾼可靠性的关系型数据库 。

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

类型典型应⽤特性
SQLMySQL、Oracle、PostgreSQL等ACID⽀持，强⼀致性
NOSQLMognoDB、Redis、Cassandra、BigTable放宽ACID⽀持、采取最终⼀致性原则
NEWSQLSpanner、OceanBase、TiDB等结合了SQL和NoSQL的优点，⽀ACID、⾼扩展性、⾼性能，并不适⽤所有场景

为什么需要分布式数据库

传统关系型数据库存在的问题，这⾥我们以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介绍

  • 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 的目标是提供一个强大、高性能、分布式的数据库解决方案，适用于处理复杂的事务和分析性查询工作负载。

但分布式数据库并不是为了完全取代传统关系型数据库，相对传统关系型数据库，它也存在⼀些缺点：

  • 分布式环境，单机性能不如传统关系型数据库，如响应时间等
  • 多表关联能⼒弱
  • 事务处理性能相对较差