TiDB的调研

TiDB的调研

TiDB的特性

• 高度兼容 MySQL
  大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。此外因为其兼容MySQL，所以mysql的周边工具也同样支持，同时TiDB也提供了很多周边工具。
• 水平弹性扩展
  通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
• 分布式事务
  TiDB 100% 支持标准的 ACID 事务
• 真正金融级高可用
  相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
• 一站式 HTAP 解决方案
  TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。
• 云原生 SQL 数据库
  TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。

TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。

能够解决什么问题

​ 当单表数量上亿的时候，Oracle 还能勉强抗住，而 MySQL 到单表千万级别的时候就难以支撑，需要进行分表分库。因此，一款高性能的分布式数据库，日渐成为刚需。
​ 通常在互联网公司业务量增大之后，并行扩展是最常用、最简单、最实时的手段。例如负载均衡设备拆流量，让海量流量变成每个机器可以承受的少量流量，并且通过集群等方式支撑起来整个业务。于是当数据库扛不住的时候也进行拆分。但有状态数据和无状态数据不同，当数据进行拆分的时候，会发生数据分区，而整个系统又要高可用状态下进行，于是数据的一致性变成了牺牲品，大量的核对工具在系统之间跑着保证着最终的一致性。在业务上，分库分表后遗症会产生一些后遗症，一条sql语句，可能在单库单表上能够完成，但是进行分库分表之后就难以实现其原有的功能。
​ TiDB刚好能够解决以上问题，强一致性、可水平扩展等特性。以及其对mysql语义的支持，因此几乎可以对mysql进行无缝切换数据库，且对业务代码几乎不需要改变什么。

与mysql的兼容性对比

参考官网
https://www.pingcap.com/docs-cn/sql/mysql-compatibility/

TID的架构

TiDB 的整体架构

                                                                      图1-1

SQL on KV 架构

                                                                      图1-2

SQL 层架构

                                                                                              图1-3

几个重要的概念

RocksDB
Key-Value
Raft
Region

• TiDB
  TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。
• PD
  PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。
• TiKV
  TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 结点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。

业界的应用场景

头条

https://mp.weixin.qq.com/s/GeNZ7EjLwDFSUDTFSbCLHw

为什么使用

​ 内部有一些业务，确实数据量非常大，我们用的 MySQL 的单机的盘是大概 2.8T 的 SSD 盘。我们做对象存储。因为头条，不但做视频，还做图片，这些视频图片当中，基本上都是用我们自研的一个 S3 的存储系统，这种存储系统呢，它需要一个元数据，比如说一个图片存下来，它的图片，存在 S3 系统的哪个机器、哪个文件、哪个偏移里面的数据，还有一个大的视频，S3 会把一个大视频，切成很多小的视频片段，每一个分片的位置，都会存在元数据里面。用 TiDB 之前，元数据是存在 MySQL 里的一个 2.8TB 的盘，因为增长的特别快，所以导致磁盘不够用，只能用分库分表的方案。我们以前用的的分库分表的方案是 MyCAT。使用 MyCAT 的过程中我们碰到一些问题，比如丢数据。以及连接问题。

场景

第一个是 OLTP 的场景，大数据量的场景，我们可能不仅仅是考虑到延时，而是考虑到数据量单机装不下，需要扩展性；
还有 OLAP 场景，有些用户，他用的是 Hive 或者 Tableau，然后用的过程中发现，因为后面都是接 MySQL，然后做一些 OLAP 的方式查询，就比较慢。

TIDB的缺点

TiDB对生产环境硬件的要求还是蛮高的，对于存储节点来说，SSD 或者 NVMe 或者 Optane 是刚需，另外对 CPU 及内存的使用要求也很高，同时对大规模的集群，网络也会有一些要求。参考https://blog.csdn.net/linuxheik/article/details/52575073
对网路要求的原因：
作为一个分布式集群，TiDB 对时间的要求还是比较高的，尤其是 PD 需要分发唯一的时间戳，如果 PD 时间不统一，如果有 PD 切换，将会等待更长的时间。2 块网卡可以做 bond，保证数据传输的稳定，万兆可以保证数据传输的速度，千兆网卡容易出现瓶颈，强烈建议使用万兆网卡。https://pingcap.com/blog-cn/10-questions-tidb-structure/

个人对TiDB的理解

TiDB是一种100%在线联机事务处理（OLTP）和80%在线联机分析(OLAP)，因此其对事务性的支持极好；事务通常都具有以下几个几个特征，原子性、一致性、隔离型和持久性，简称为ACID特性。在上世纪70年代，只有满足事务特性的数据库才被成为数据库；但随着noSQL数据库的出现，事务特性不在是存储系统被成为文件的充分条件。随着google，发表的Spanner（全球分布式数据库）和F1两篇论文，新一代的数据库已经进入人们的视野。数据库的发展过程如下图1-4，该图摘自pingCAP官网，TiDB则是pingCAP公司的开源产品。

                                                                        图1- 4
TiDB在一定程度上借鉴了，google的Spanner&F1数据库，力求打造 HTAP (Hybrid Transactional and Analytical Processing) 数据库。我们都知道单机性数据库（如Mysql）通常可以很好的完成事务。但是对于分布式数据库中，数据分散在各台不通的机器上。如何对这些数据进行分布式事务的处理具有极其大的挑战。为解决这个问题，CAP和BASE理论被相应的提出,TiDB作为一款HTHAP的数据库同样也不得不遵循这个理论。

对TiDB架构的理解

TiDB数据库的架构由TiDB、TiKV和PD组成，其中TiDB主要负责解析结构化查询语言SQL，做计算，优化查询计划，而TiKV则是存储执行引擎，把数据存储到RocksDB中或者获取数据，PD的功能类似zookeeper或者etcd,存储一些元数据，对TiKV做负载均衡。与传统的关系型数据库（如MySql）相比，其（TIDB的逻辑架构如图1-5）具有更好的可扩展性，TiDB的各组件的耦合性极低，假如我们要是使TiDB数据库支持其他的语义，只需对TiDB组件进行替换或修改，即可使其支持其他的语义的查询语言，实现了插拔式的方式。

                                                                        图1- 5

官方跨数据中心部署方案

跨数据中心是本次调研了解的一个重点方向。跨数据中心部署的方式，官网给出了三种方案；分别为三中心部署方案、两地三中心部署方案和两数据中心 + binlog 同步方案。三种方案各有优缺点：

方案	优点	缺点	一致性	故障时
三中心部署方	所有数据的副本分布在三个数据中心，任何一个数据中心失效后，另外两个数据中心会自动发起 leader election，并在合理长的时间内（通常情况 20s 以内）恢复服务，并且不会产生数据丢失	性能受网络延迟影响	能保证数据一致性	优先考虑可用性而不是性能
两地三中心部署	两地三中心的方案与三数据中心类似，算是三机房方案根据业务特点进行的优化，区别是其中有两个数据中心距离很近（通常在同一个城市），网络延迟相对很小。这种场景下，我们可以把业务流量同时派发到同城的两个数据中心，同时控制 Region leader 和 PD leader 也分布在同城的两个数据中心	如果同城的两个数据中心同时失效，将会导致不可用以及部分数据丢失	能保证数据一致性	优先考虑可用性而不是性能
两数据中心 + binlog 同步	两数据中心 + binlog 同步类似于传统的 MySQL 中 master/slave 方案。两个数据中心分别部署一套完整的 TiDB 集群，我们称之为主集群和从集群。正常情况下所有的请求都在主集群，写入的数据通过 binlog 异步同步至从集群并写入 。这个方案的优势是数据中心内的 HA – 少部分节点故障时，通过重新选举 leader 自动恢复服务，不需要人工干预。	数据中心之间只有 binlog 异步复制。在数据中心间的延迟较高的情况下，从集群落后主集群的数据量会增大。当主集群故障后（DR），会造成数据丢失，丢失的数据量受网络延迟等因素影响。	能保证数据一致性	需要人工切换至从集群，并可能发生一些数据丢失，数据丢失的数量取决于同步延迟，和网络条件有关

由于三种方案都会受到网络的延迟的影响，因此pingCAP推荐个节点之间的网络为万兆网。同时PD、TiKV的磁盘推荐要求使用SSD，尽可能的降低各方面的延迟。

线下meetup

这次线下meetup主要是介绍，Titan。Titan 是一个基于 RocksDB 的高性能单机 key-value 存储引擎。主要是为了解决LSM写放大的问题，提高写入的性能。详情请参考连接：
https://pingcap.com/blog-cn/titan-design-and-implementation/。下图为线下meetup活动。


通过参加线下活动了解的情况来看，TiDB目前还需很多需要优化的地方；另外因为DB使用的是RocksDB，且pingCAP的理念是尽量不修改RocksDB的源码，因此有些地方不是那么好做。

参考文献

[1] TiDB官方文档 https://www.pingcap.com/docs-cn/