江苏龙网

  1. 首页 > 资讯 > 科技 > >

数据库|开源分布式关系型数据库TiDB入坑指南( 二 )


本文插图

三、TiDB 整体架构TiDB 集群主要包括三个核心组件：TiDB Server ， PD Server 和 TiKV Server 。 此外 ， 还有用于解决用户复杂 OLAP 需求的 TiSpark 组件和简化云上部署管理的 TiDB Operator 组件 。

数据库|开源分布式关系型数据库TiDB入坑指南
本文插图

TiDB Server（负责数据存储 ， 是一个提供事务的分布式 Key-Value 存储引擎）
TiDB Server 负责接收 SQL 请求 ， 处理 SQL 相关的逻辑 ， 并通过 PD 找到存储计算所需数据的 TiKV 地址 ， 与 TiKV 交互获取数据 ， 最终返回结果 。 TiDB Server 是无状态的 ， 其本身并不存储数据 ， 只负责计算 ， 可以无限水平扩展 ， 可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址 。
PD Server（负责管理调度 ， 如数据和 TiKV 位置的路由信息维护、TiKV 数据均衡等）
Placement Driver (简称 PD) 是整个集群的管理模块 ， 其主要工作有三个：一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID 。
PD 通过 Raft 协议保证数据的安全性 。 Raft 的 leader server 负责处理所有操作 ， 其余的 PD server 仅用于保证高可用 。 建议部署奇数个 PD 节点 。
TiKV Server（负责 SQL 逻辑 ， 通过 PD 寻址到实际数据的 TiKV 位置 ， 进行 SQL 操作）
TiKV Server 负责存储数据 ， 从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎 。 存储数据的基本单位是 Region ， 每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据 ， 每个 TiKV 节点会负责多个 Region 。 TiKV 使用 Raft 协议做复制 ， 保持数据的一致性和容灾 。 副本以 Region 为单位进行管理 ， 不同节点上的多个 Region 构成一个 Raft Group ， 互为副本 。 数据在多个 TiKV 之间的负载均衡由 PD 调度 ， 这里也是以 Region 为单位进行调度 。
TiSpark（解决复杂OLAP需求组件）
TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件 ， 将 Spark SQL 直接运行在 TiDB 存储层上 ， 同时融合 TiKV 分布式集群的优势 ， 并融入大数据社区生态 。 至此 ， TiDB 可以通过一套系统 ， 同时支持 OLTP 与 OLAP ， 免除用户数据同步的烦恼 。
TiDB Operator（k8s支持）
TiDB Operator 提供在主流云基础设施（Kubernetes）上部署管理 TiDB 集群的能力 。 它结合云原生社区的容器编排最佳实践与 TiDB 的专业运维知识 ， 集成一键部署、多集群混部、自动运维、故障自愈等能力 ， 极大地降低了用户使用和管理 TiDB 的门槛与成本 。
四、两个核心特性1、水平扩展
无限水平扩展是 TiDB 的一大特点 ， 这里说的水平扩展包括两方面：计算能力和存储能力 。 TiDB Server 负责处理 SQL 请求 ， 随着业务的增长 ， 可以简单的添加 TiDB Server 节点 ， 提高整体的处理能力 ， 提供更高的吞吐 。 TiKV 负责存储数据 ， 随着数据量的增长 ， 可以部署更多的 TiKV Server 节点解决数据 Scale 的问题 。 PD 会在 TiKV 节点之间以 Region 为单位做调度 ， 将部分数据迁移到新加的节点上 。 所以在业务的早期 ， 可以只部署少量的服务实例（推荐至少部署 3 个 TiKV ，3 个 PD ， 2 个 TiDB） ， 随着业务量的增长 ， 按照需求添加 TiKV 或者 TiDB 实例 。
2、高可用
高可用是 TiDB 的另一大特点 ， TiDB/TiKV/PD 这三个组件都能容忍部分实例失效 ， 不影响整个集群的可用性 。 下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复 。
1）TiDB


推荐阅读


上一篇：高通|京东“牵手”高通，川普很满意，高通不愿离开中国“梦想”或成真

下一篇：|2020年5月农业类创业公司传播影响力TOP20：科技农业类公司占比超五成