NewSQL分佈式數據庫，例如TIDB用K/V的底層邏輯

內容參考

對分佈式對定義參考這篇文章：

微服務都想用，先把分佈式和微服務之間的關係說清楚

對分佈式架構中心或無中心對比參考這篇文章：

分佈式存儲單主、多主和無中心架構的特徵與趨勢

對HDFS對內部機制參考這篇文章：

Hadoop分佈式文件系統I/O原理機制的深度解讀

分佈式文件系統HDFS無索引就無K/V

首先分佈式數據並非絕對的喜歡使用kv存儲模式，例如分佈式數據庫裏面mongodb和elasticsearch是文檔形式存儲，若把HDFS也算進去的話，它是無索引的存儲。

上圖是HDFS做爲分佈式數據存儲的文件分塊存儲模式，簡單直接，並無進行任何的kv索引創建。咱們能夠看到圖中Nginx日誌被切割成duo多份，而後分佈在三臺數據節點上，要注意的是，HDFS的副本通常是三份，圖中只作了兩份表明副本的意思，但其實是三份。客戶端在進行訪問通訊是時候，都是經過數據塊scan的方式進行，沒有索引，就沒有隨機訪問機制。

TiDB的架構特徵

像cockroach,tidb，明明是關係庫，爲啥非要弄個key，即便業務邏輯不須要表有unique key，也要給每條記錄硬加一個key，這是什麼目的？

其實cockroach，tidb都叫NewSQL，是NoSQL+關係型數據庫的合體，認爲它們是關係庫，說得不恰當。

例如：tidb分爲PD、TIKV、TIDB，PD管理者kv的關係結構，這部分能夠對標關係型數據庫。

上圖是TIDB的架構圖，圖中能夠看到TIDB造成的集羣主要是接收外部應用的SQL，處理SQL的邏輯，與PD交互獲取KV地址，與KV交互獲取數據；

PD組成的集羣主要是經過元數據的語義理解kv在集羣中的位置，實現對KV集羣的調度和負載均衡，分配全局事務ID；

TIKV就是咱們說到的重點，經過Key-Value存儲引擎，提供分佈式事務能力。每一個節點有多個Region，Region存儲一個範圍Key的數據——Key Range，主要是爲了造成連續的小組，在局部提供寫入和讀取的性能優點。而且以Region做爲原子單元，實現集羣跨節點的副本複製，複製方式用Raft協議實現。

實際上TIKV部分就是標準的NoSQL爲基礎的數據持久化層了，TIKV的持久化數據層就是RocksDB，一樣的cockroach持久化數據層也用的是RocksDB，RocksDB的就是LSM-Tree的日誌追加方式WAL (write ahead log)快速寫入數據，再經過LSM-Tree的memtable，sstable結構，索引key，獲取value，因此就是個標準的key/value數據庫。

RocksDB的核心優點LSM-Tree結構

爲何它們不約而同的都選擇了RocksDB，由於做爲核心結構LSM樹的WAL，memtable，sstable方式具備寫入數據的巨大優點並保證數據可靠性，造成不少小的順序分組，同時又獲得局部熱點上的驚人查詢優點，在內存中完成查找。

並且LSM-Tree配合Bloom Filter又能將時間線做爲優先級，快速索引數據在磁盤中的位置範圍，這就大大減小掃描磁盤的動做。

若遇到大範圍隨機查找，Bloom Filter有也查不到位置的狀況，纔會經過二分查找，並在樹的不一樣層進行多路合併，取優先級最高的數據。

那麼經過這種思路，就能比關係型數據庫的b/b+樹索引在寫的性能方面帶來質的提高，並且對於局部熱點，也就是近期數據帶來驚人的查詢性能，雖然全局範圍的查詢有所下降，數據段合併會帶來的資源消耗(rocksdb經過多線程合併提高了這一過程的效率)，但數據庫讀寫的總體性能的平衡性變得更合理了，總之未來經過集羣處理讀的問題老是比處理寫的問題更容易，這就是選擇key/value數據庫的底層邏輯。

NewSQL相對於MySQL的優點

反觀關係型數據庫，例如要給MySQL加上一條索引，那麼索引字段就是key。因此RDBMS也不能說本身跟key/value存儲沒啥聯繫。

做爲業務邏輯上不須要unique key而非要加一個key，這是由於關係型數據庫設計的初衷就不是爲了海量數據的快速寫入和查找所設計的，即使沒有索引，行集掃描也沒有問題，這纔是常態是其本質，這和Hadoo HDFS的按塊掃描同樣，都是一種原始的狀態，HDFS之上依然須要HBase數據庫來解決海量數據的隨機查找場景，本質上做爲列族分類的HBase也是Key/Value模式。

NewSQL選擇了RocksDB，也就是選擇了業務記錄中key存在的必須，但換來的是海量數據的高效寫入和查找，很是划算。

前往讀字節的知乎——瞭解更多關於大數據的知識

公衆號 "讀字節" 大數據（技術、架構、應用）的深度，專業解讀