TiDB實例測試分析

本文小編為大家詳細介紹“TiDB實例測試分析”，內容詳細，步驟清晰，細節處理妥當，希望這篇“TiDB實例測試分析”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

首先對我來說，我覺得能夠開發數據庫，而且能夠有很深的技術情結，真是一件很cool的事情，我比較欣賞極客精神，同時滿足了業務，也在技術上的價值得以體現，這種模式值得很多開源項目參考借鑒。

首先，讓我感興趣的不是TiDB的NewSQL角色，而是對TiDB的發展過程，TiDB的架構演進對于理解TiDB技術還是很有幫助的，也對我們的工作和實踐具有一定的借鑒。如果讓我來總結，我覺得有幾個里程碑事件對我的觸發較大。

①　設計MySQL分布式存儲引擎。

整個項目從2015年4月份開始，初期是寫一個MySQL分布式存儲引擎，來期望達到分布式的基本需求，但是性能差強人意，同時存儲引擎層對優化器層面，事務模型層的支持非常有限，所以初期的架構設計沒有達到預期。

②　兼容MySQL協議，自上而下實現

后期的架構設計對標MySQL協議，自上而下重寫，完全兼容MySQL協議，實現Server層的基本需求。

TiDB 0.5版本的架構如下：

③　存儲引擎引入HBase

初期的TiDB是沒有存儲引擎的，數據都是在內存層面，接入HBase，也是一個戰略選型，主要是為了初步驗證SQL層的實現是否穩定。

④　使用Rust重寫Etcd 里的 Raft

KV存儲層使用Rust來實現，主要的難點就是對Etcd的Raft實現使用Rust完全重寫，我覺得這是最cool的一件事情了，難度可想而知，但是做成了會發現成就滿滿。

⑤　接入RocksDB

RocksDB是一個單機的key-value engine，前身其實是LevelDB，是Google在2011年左右開源的key-value的存儲引擎。RocksDB的數據結構是LSM Tree是一個對寫非常友好，在機器內存比較大的時候讀性能會非常好的數據結構。

技術架構層面，TiDB和Oracle中的RAC其實很像（組件和功能），當然最大的不同就是一個是分布式，彈性擴縮容，另外一個是集成共享式。

我測試的時候使用了如下的部署架構。

測試的過程中，對TP，AP業務做了一些基本的測試和性能壓測，對高可用，彈性擴縮容，滾動升級，備份恢復也做了一些基本的覆蓋測試。

優點的內容很明顯，可以從部署安裝感覺到，很多新技術都在大規模使用了。

亮點功能如下:

①　支持多種部署方式（離線部署，在線部署，docker部署）

②　監控部署一體化

③　快速部署

④　備份恢復,定制了主流工具mydumper,myloader,

⑤　增量復制syncer

⑥　實時備份和恢復的特性 TiDB的binlog方案，和kafka對接

⑦　承接AP的業務，基于spark

⑧　彈性擴縮容

⑨　滾動升級

⑩　讀寫混合，單不只局限于密集型寫入

11　Tidb重新部署，原有的數據不會刪除，如果優惠復用起來

12　故障自動恢復

13　產品定制能力強，定制了將近30個參數，針對TiDB的使用需求

還有一些細節的小錯誤或者問題，后續和朋友對接集中反饋下。

從我的理解來看，目前的TiDB的業務切入點可以作為對已有的MySQL方案的補充，甚至可以做到透明的集群方案，無論你是采用了PXC,MHA,還是MGR，整個過程都可以通過級聯的方式銜接起來。

另外一個切入點應該是大數據部分，目前從我的測試來看，TiDB是樂觀鎖，對于AP業務的支持其實需求是更大一些，所以能夠對接到大數據平臺，能夠實現一些基本的數據流轉甚至數據下沉至大數據，都是一些不錯的點。

讀到這里，這篇“TiDB實例測試分析”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。