如何进行NewSQL数据库TiDB的分析

本篇文章给大家分享的是有关如何进行NewSQL数据库TiDB的分析，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。

下面要介绍的是数据库领域的后起之秀——NewSQL-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 Server本身是无状态的，意味着当计算能力成为瓶颈的时候，可以直接扩容机器，对用户是透明的。理论上TiDB Server的数量并没有上限限制。

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

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

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

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

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

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

以上就是如何进行NewSQL数据库TiDB的分析，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。