浅析NewSQL数据库——TiDB

本文从诞生背景、整体架构、能力特征及兼容监控等多个方面详细介绍了TiDB这个新一代的NewSQL数据库。

上篇文章回顾：SOAR使用指南

如今的数据库种类繁多，RDBMS（关系型数据库）、NoSQL（Not Only SQL）、NewSQL凭借己之长处，在数据库领域均有一席之地，可谓百家争鸣之势。先上一张DBEngines在2018年8月发布的数据库排名：

我们可以看到数据库份额之间的竞争还是十分激烈的。而本篇文章要介绍的是数据库领域的后起之秀——NewSQL-TiDB，由于TiDB更新发版速度较快，所以本篇文章跟最新版本之间会有差异。

一、TiDB诞生背景

目前RDBMS的代表为Oracle、 MySQL 、PostgreSQL，传统关系型数据库历史比较久，在数据库领域也是“辈份”比较高的，其广泛应用在各行各业。但是此类数据库存在着一些问题，如自身容量的限制，RDBMS大多为本地存储或共享存储。随着业务量不断增加，容量渐渐成为瓶颈，此时DBA会通过多次的库表sharding，以此来缓解容量问题。大量的分库分表，不仅耗费了大量人力，还使得业务访问数据库的路由逻辑变得复杂。除此之外，RDBMS伸缩性比较差，通常集群扩容缩容成本较高，且不满足分布式的事务。

NoSQL类数据库的代表为Hbase、 Redis 、 MongoDB 、Cassandra等，这类数据库解决了 RDBMS伸缩性差的问题，集群容量扩容变得方便很多，但是由于存储方式为多个KV存储，所以对 SQL 的兼容性就大打折扣。对于NoSQL类数据库来说，只能满足部分分布式事务的特点。

NewSQL领域的代表是Google的spanner和F1，其号称可以实现全球数据中心容灾，且完全满足分布式事务的ACID，但是只能在Google云上使用。

TiDB诞生在大背景下，也弥补了国内在NewSQL领域中的空缺。TiDB自2015年5月写下第一行代码以来，至今已有3年有余，已发版几十次，版本迭代十分迅速，目前最新版本是2.0.6，在GitLab上点赞数已超过14000。

二、TiDB架构特性

1.TiDB整体架构

下图为TiDB的基本架构。TiDB中可以分为三类节点：PD Server、TiDB Server、TiKV Server。

PD Server负责存储集群的元数据，对每个事物分配全局的事物ID，并负责对TiKV集群数据进行调度和负载均衡。

TiDB Server负责接收用户的请求，并解析成执行计划，通过PD Server进行数据寻址，然后与TiKV Server节点交互，进行查询。

TiKV Server负责存储集群的数据。

Client提交任务的时候会通过LB层转发，提交到TiDB Server集群中，PD Server会给每个事务分配一个全局事务ID，紧接着TiDB Server会将application解析成具体的执行计划，并向PD集群获取数据存储地址，通过和TiKV Server节点交互，进行查询。

2.TiDB能力特征

计算能力：TiDB Server本身是无状态的，意味着当计算能力成为瓶颈的时候，可以直接扩容机器，对用户是透明的。理论上TiDB Server的数量并没有上限限制。

存储能力：TiKV Server通常是3+的，TiDB每份数据缺省为3副本，这一点与HDFS有些相似，但是通过Raft协议进行数据复制，TiKV Server上的数据的是以Region为单位进行，由PD Server集群进行统一调度，类似HBASE的Region调度。

3.TiDB的高可用

TiDB每个角色都属于高可用的，单个节点宕机不影响整个集群。TiDB Server会有多个，由于无状态，即使意外宕机，Applcation会通过重试，连接到其他节点。PD Server一般是2n+1数个，通过Raft协议进行选举，Leader宕机后Follower后通过选举成为Leader，继续完成工作。每个TiKV节点中的数据存储格式是KV结构的，通过Key-Range的方式进行 hash到一个Region中，每个Region会有额外两个副本，分布到不通的节点上。

4.兼容MySQL

TiDB基本兼容了MySQL，对于用户使用的时候，可以透明地从MySQL切换到TiDB 中，只是“新MySQL”的后端是存储“无限的”，不再受制于Local的磁盘容量。在运维使用时也可以将TiDB当做一个从库挂到MySQL主从架构中。

5.高效存储方案

上面讲到，TiKV集群存储的数据格式是KV的，在TiDB中，并不是将数据直接存储在 HDD/SSD中，而是通过RocksDB实现了TB级别的本地化存储方案，RocksDB的架构不再赘述了，有兴趣可以搜一下相关文档，着重提的一点是：RocksDB和HBASE一样，都是通过 LSM树作为存储方案，避免了B+树叶子节点膨胀带来的大量随机读写。从何提升了整体的吞吐量。

6.TIDB监控

在TiDB中选择了开源的Prometheus作为整个集群的监控，在每个节点上，都会通过Multiple角色收集并上报所有节点的数据，推送到PushGateWay中，PushGateWay接收所有Client Push上来的所有数据，Prometheus Server会定期从GateWay中拉取数据数据，整个监控通过Grafana进行可视化和监控查询。

三、总结

TiDB作为新一代的NewSQL数据库，在数据库领域已经逐渐站稳脚跟，结合了Etcd/MySQL/HDFS/HBase/Spark等技术的突出特点，随着TiDB的大面积推广，会逐渐弱化 OLTP/OLAP的界限，并简化目前冗杂的ETL流程，引起新一轮的技术浪潮。一言以蔽之，TiDB，前景可待，未来可期。

本文首发于公众号“小米运维”，点击查看原文