如何進行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的分析，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。