【TIDB】三、數據庫的發展歷史、如今、將來

一、從單機數據庫提及（Mysql、Oracle、PostgreSQL）

關係型數據庫起源自1970年代，其最基本的功能有兩個：

1. 把數據存下來；  

2. 知足用戶對數據的計算需求。

第一點是最基本的要求，若是一個數據庫沒辦法把數據安全完整存下來，那麼後續的任何功能都沒有意義。當知足第一點後，用戶緊接着就會要求可以使用數據，多是簡單的查詢，好比按照某個Key來查找Value；也多是複雜的查詢，好比要對數據作複雜的聚合操做、連表操做、分組操做。每每第二點是一個比第一點更難知足的需求。

在數據庫發展早期階段，這兩個需求其實不難知足，好比有不少優秀的商業數據庫產品，如Oracle/DB2。在1990年以後，出現了開源數據庫MySQL和PostgreSQL。這些數據庫不斷地提高單機實例性能，再加上遵循摩爾定律的硬件提高速度，每每可以很好地支撐業務發展。

接下來，隨着互聯網的不斷普及特別是移動互聯網的興起，數據規模爆炸式增加，而硬件這些年的進步速度卻在逐漸減慢，人們也在擔憂摩爾定律會失效。在此消彼長的狀況下，單機數據庫愈來愈難以知足用戶需求，即便是將數據保存下來這個最基本的需求。

二、分佈式數據庫之Nosql的進擊（HBase/Cassadra/MongoDB）

HBase是其中的典型表明。HBase是Hadoop生態中的重要產品，Google BigTable的開源實現。

HBase自己並不存儲數據，這裏的Region僅是邏輯上的概念，數據仍是以文件的形式存儲在HDFS上，HBase並不關心副本個數、位置以及水平擴展問題，這些都依賴於HDFS實現。和BigTable同樣，HBase提供行級的一致性，從CAP理論的角度來看，它是一個CP的系統，而且沒有更進一步提供 ACID 的跨行事務，也是很遺憾。

HBase的優點在於經過擴展Region Server能夠幾乎線性提高系統的吞吐，及HDFS自己就具備的水平擴展能力，且整個系統成熟穩定。

但HBase依然有一些不足

• 首先，Hadoop使用Java開發，GC延遲是一個沒法避免問題，這對系統的延遲形成一些影響。
• 另外，因爲HBase自己並不存儲數據，和HDFS之間的交互會多一層性能損耗。
• 第三，HBase和BigTable同樣，並不支持跨行事務，因此在Google內部有團隊開發了MegaStore、Percolator這些基於BigTable的事務層。Jeff Dean認可很後悔沒有在BigTable中加入跨行事務，這也是Spanner出現的一個緣由。

三、分佈式數據庫之RDMS的救贖（Cobar、Zebra、Atlas、Vitess）

RDMS系統作了很多努力來適應業務的變化，也就是關係型數據庫的中間件和分庫分表方案。作一款中間件須要考慮不少，好比解析 SQL，解析出ShardKey，而後根據ShardKey分發請求，再合併結果。另外在中間件這層還須要維護Session及事務狀態，並且大多數方案並不支持跨shard的事務。還有動態的擴容縮容和自動的故障恢復，在集羣規模愈來愈大的狀況下，運維和DDL的複雜度是指數級上升。

四、NewSQL的發展

2012~2013年Google 相繼發表了Spanner和F1兩套系統的論文，讓業界第一次看到了關係模型和NoSQL的擴展性在一個大規模生產系統上融合的可能性。

Spanner 經過使用硬件設備（GPS時鐘+原子鐘）巧妙地解決時鐘同步的問題，而在分佈式系統裏，時鐘正是最讓人頭痛的問題。Spanner的強大之處在於即便兩個數據中心隔得很是遠，也能保證經過TrueTime API獲取的時間偏差在一個很小的範圍內（10ms），而且不須要通信。Spanner的底層仍然基於分佈式文件系統，不過論文裏也說是能夠將來優化的點。

Google的內部的數據庫存儲業務，大可能是3~5副本，重要的數據須要7副本，且這些副本遍及全球各大洲的數據中心，因爲廣泛使用了Paxos，延遲是能夠縮短到一個能夠接受的範圍(寫入延遲100ms以上)，另外由Paxos帶來的Auto-Failover能力，更是讓整個集羣即便數據中心癱瘓，業務層都是透明無感知的。F1是構建在Spanner之上，對外提供了SQL接口，F1是一個分佈式MPP SQL層，其自己並不存儲數據，而是將客戶端的SQL翻譯成對KV的操做，調用Spanner來完成請求。

五、Spanner和F1的追隨者

Spanner/F1論文引發了社區的普遍的關注，很快開始出現了追隨者。第一個團隊是CockroachLabs作的CockroachDB。CockroachDB的設計和Spanner很像，可是沒有選擇TrueTime API ，而是使用HLC（Hybrid logical clock），也就是NTP +邏輯時鐘來代替TrueTime時間戳，另外CockroachDB選用Raft作數據複製協議，底層存儲落地在RocksDB中，對外的接口選擇了PG協議。

另外一個追隨者就是咱們作的TiDB。TiDB本質上是一個更加正統的Spanner和F1實現，並不CockroachDB那樣選擇將SQL和KV融合，而是像Spanner和F1同樣選擇分離。

和 Spanner同樣，TiDB是一個無狀態的MPP SQL Layer，整個系統的底層是依賴 TiKV 來提供分佈式存儲和分佈式事務的支持，TiKV的分佈式事務模型採用的是Google Percolator的模型，可是在此之上作了不少優化，Percolator的優勢是去中心化程度很是高，整個繼續不須要一個獨立的事務管理模塊，事務提交狀態這些信息實際上是均勻分散在系統的各個key的meta中，整個模型惟一依賴的是一個授時服務器，在咱們的系統上，極限狀況這個授時服務器每秒能分配 400w以上個單調遞增的時間戳，大多數狀況基本夠用了（畢竟有Google量級的場景並很少見），同時在TiKV中，這個授時服務自己是高可用的，也不存在單點故障的問題。

TiKV和CockroachDB同樣也是選擇了Raft做爲整個數據庫的基礎，不同的是，TiKV總體採用Rust語言開發，做爲一個沒有GC和 Runtime的語言，在性能上能夠挖掘的潛力會更大。不一樣TiKV實例上的多個副本一塊兒構成了一個Raft Group，PD負責對副本的位置進行調度，經過配置調度策略，能夠保證一個Raft Group的多個副本不會保存在同一臺機器/機架/機房中。

 六、將來趨勢

一、數據庫會隨着業務雲化，將來一切的業務都會跑在雲端，無論是私有云或者公有云，運維團隊接觸的可能不再是真實的物理機，而是一個個隔離的容器或者「計算資源」

二、多租戶技術會成爲標配，一個大數據庫承載一切的業務，數據在底層打通，上層經過權限，容器等技術進行隔離

三、OLAP和OLTP業務會融合，用戶將數據存儲進去後，須要比較方便高效的方式訪問這塊數據，可是OLTP和OLAP在SQL優化器/執行器這層的實現必定是千差萬別的。以往的實現中，用戶每每是經過ETL工具將數據從OLTP數據庫同步到OLAP數據庫，這一方面形成了資源的浪費，另外一方面也下降了OLAP的實時性。對於用戶而言，若是能使用同一套標準的語法和規則來進行數據的讀寫和分析，會有更好的體驗。

四、在將來分佈式數據庫系統上，主從日誌同步這樣落後的備份方式會被Multi-Paxos / Raft這樣更強的分佈式一致性算法替代，人工的數據庫運維在管理大規模數據庫集羣時是不可能的，全部的故障恢復和高可用都將是高度自動化的。

七、知識拓展

7.一、GPS同步時鐘工做原理

在最初的同步通訊系統中，咱們會找到一個時鐘源，而後把全部的收發子系統都接到這個時鐘源上。小型的同步通訊系統徹底能夠這樣作，好比一臺電腦中的一個同步通訊的系統，他們就用電纜線接到一個共同的時鐘源上，再來收發信號。

但是一旦同步通訊的系統變大到全國性的呢？若是還用電纜或者光纜接到同一個時鐘源上，會發生不少問題。首先，建設的成本太大了，要在全國範圍內鋪設線路，只爲傳輸一個時鐘信號，不划算。其次，若是收發信機分別在黑龍江和廣東，時鐘信號即便以光速傳過去，還會產生必定的延時。

每一個GPS衛星上都有2~3個高精度的原子鐘，這幾塊原子鐘互爲備份的同時，也互相糾正。另外地面的控制站會按期發送時鐘信號，和每一顆衛星進行時鐘校準。 

固然你可能會擔憂衛星信號傳送到地面的延遲問題。GPS信號中自帶了偏差糾正碼，接收端能夠很容易的把延遲的這段傳輸延遲去掉。另外，因爲衛星信號很微弱，只有在室外才能接受的到，所以每一個GPS授時系統都應當有室外天線，不然就不能用了。

這樣一來上面列出的兩個問題都解決了。用來鋪設全國性電纜並非每家公司都有資金實力的，並且鋪設的成本用來買GPS接收器，那確定能夠買到無數個了。而延時的問題，也被GPS出色的編碼系統所解決了。真的是太完美了。

Spanner是如何保證每一個事務最後獲得的commit timestamp介於這個事務的start和commit之間？

在事務開始階段調用一次TrueTime，返回[t-ε1,t1+ε1]，在事務commit階段時再調用一次TrueTime,返回[t2-ε2,t2+ε2]，根據TrueTime的定義，顯然，只要t1+ε1<t2-ε2，那麼commit timestamp確定位於start和commit之間。等待的時間大概爲2ε，大約14ms左右。能夠說，這個延時基本上還能夠接受。

7.二、Hybrid Logical Clock(HLC)

每一個Cockroach節點都維持了一個混合邏輯時鐘(HLC) ，相關的論文見 HybridLogical Clock paper。HLC時間使用的時間戳由一個物理部件（看做老是接近本地物理時鐘）和一個邏輯部件（用於區分相同物理部件上的事件）組成。它使咱們可以以較少的開銷跟蹤相關聯事件的因果性，相似於向量時鐘（譯註：vector clock，可參考Leslie Lamport在1978年發表的一篇論文《Time, Clocks, and the Ordering of Events in aDistributed System》）。在實踐中，它工做起來更像一個邏輯時鐘：當一個節點收到事件時，它通知本地邏輯HLC由發送者提供的事件時間戳，而當事件被髮送時會附加一個由本地HLC生成的時間戳。

Cockroach使用HLC時間爲事務選取時間戳。本文中，全部 時間戳 都是指HLC時間，HLC時鐘在每一個節點上是都是單一實例的（譯註：也就是說每一個節點上只有惟一一個HLC時鐘，不會有兩個時鐘，產生兩個時間的問題）。HLC時鐘由節點上的每一個讀/寫事件來更新，而且HLC 時間大於等於（ >= ）系統時間（wall time）。歷來自其餘節點的Cockroach請求裏接收到的讀/寫時間戳不只僅用來標識操做的版本，也會更新本節點上的HLC時鐘。這用於保證在一個節點上的全部數據讀寫時間戳都小於下一次HLC時間。

 

 

 

參考：

https://www.oschina.net/news/84386/about-distributed-database?utm_source=tuicool

https://www.syn029.com/h-nd-489.html?groupId=-1