開源NewSQL – CockroachDB在百度內部的應用與實踐

對於MySQL、Oracle、PostgreSQL這樣的單機資料庫，隨著資料量的增長在計算容量和儲存容量上都會出現問題。於是後續又推出了基於中介軟體或者NoSQL的方案，但是都並非完美，比如中介軟體在分散式事務方面以及NoSQL在SQL介面和對事務的支援方面做了一定退讓。

2011年分析師Matthew Aslett首次提出了NewSQL的概念，期望將NoSQL和傳統的資料庫的優勢融合，將現有資料庫存在的缺陷在下一代中解決掉。而Google首先將這一概念工程化，也就是Spanner。隨後開源社群也陸續跟進。

Cockroach DB於2014年託管在GitHub，遵循Apache License，基於Golang實現。 Star數量12000+，Contributor數量150+。當前2.0.1版本。母公司是Cockroach Labs，公司的三位創始人全部來自Google，有Big Table，GFS，Colossus，Gmail專案背景，已獲得來自Benchmark，Google Venture等共計5325萬的融資。總部位於紐約，目前有50+員工。

Cockroach DB採用類似Spanner的分層架構，在分散式KV上提供了SQL引擎，分散式KV之下引入了自身獨有三個概念Node、Store、Range。

Node是Cockroach DB的程式例項，一臺物理伺服器啟動一個Node即可，一個物理儲存介質（例如一塊硬碟）一般配置一個Store，一個Node中有多個Store。

Range是Cockroach DB儲存管理的最小單位，一個Range是一段鍵值區間的資料分片。一個Store中有多個Range，每個Range分片預設為64M，預設存在3個副本，分佈在不同的Node上。

Cockroach DB使用PostgreSQL協議，支援標準SQL介面，相容關係型資料庫SQL生態。支援事務、二級索引、Join等NoSQL欠缺的特性，同時還供了類MPP的分散式查詢框架。它還支援Schema線上變更，以方便應對業務的變化。

由於Cockroach DB底層是分散式KV，那麼必然就要將所有的SQL操作轉換為KV操作。於是它就在底層抽象出了Get、Put、ConditionalPut、Scan、Del這五個KV作原語。

解決完KV操作的問題後，還有另一個問題有待解決，即Schema到KV模型的對映。Cockroach DB的每個表都需要有一個Primary Key，每一列（不是每行）構成一個Key / Value儲存單元，Key由<db>、<table>、<index>、<pkey>、<columnld>這幾部分共同構成。

在KV儲存中必須保證key全域性唯一，這樣就能方便字首匹配。Cockroach DB為了實現唯一索引，首先會將<db>、<table>、<index>、<key>編碼到Key中，當做索引掃描時就要進行字首匹配，然後就能將相應的Value取出來。這裡由於<key>是全域性唯一的所以索引的唯一性也得以保證。

對於非唯一索引Cockroach DB處理就比較巧妙了，它將行的<pkey>也編譯到了Key中，這樣對索引做字首匹配時，只要相關的索引項匹配到index前面，就能將相應的<pKey>取出來，然後通過<pkey>反向索引到資料。

在行存系統中資料的更新只需要進行一次IO操作，但是由於Cockroach DB是列存的，資料在更新時要進行多次IO。為此Cockroach DB提出了column family的概念，將需要被頻繁訪問的列封裝到一起，甚至可以通過column family的方式退化到行存的方式，這樣就能有效減少IO操作。

為了實現線性擴充套件的能力，Cockroach DB採用了去中心化的架構，任意節點故障對於叢集無影響。它通過Gossip協議實現節點狀態管理，理論上單叢集支援10K節點規模。兩級路由後設資料的方式使得單叢集最大支撐4EB使用者資料儲存。整個架構中子模型都採用分散式設計，無單點瓶頸，支援多節點併發寫入。

面對單機資料庫擴充套件性的問題，一般採用雜湊的資料分佈方式。但是除非是使用的是一致性雜湊，否則普通的雜湊分佈都需要有資料遷移和停服的過程。而Cockroach DB選擇的是Range分佈，在進行擴容時無需停服，直接可以線上擴充套件，同時因為每個資料都被劃分為64M的小分片，所以在新節點加入時能做到業務無感知的自動負載均衡多副本強一致性。

MySQL資料同步採用的主從複製架構是弱一致性的，而Cockroach DB的副本資料同步是基於Raft協議，具有強一致性，不會出現當某個節點掛了同時redolog還沒有完全複製到從庫上導致資料丟失的問題。

Cockroach DB由於架構上去中心化，沒有SPDF，所以架構不存在類似Hbase HMaster和Percolator oracle等集中模組，單節點故障也不影響叢集群體的可用性。

另外因為基於Raft協議，所以只要半數以上副本存活，則服務可用；當節點異常，資料副本數量少於指定閾值時，自動補齊副本，保證可靠性。

Cockroach DB使用的是改造過的兩階段提交事務，它引入全域性事務表記錄事務狀態，事務提交/回滾只修改記錄的標記位。事務中寫入的資料被封裝成特殊結構（INTENT），這個INTENT中隱含著索引資訊可以反向索引事務狀態。這種事務處理模型的好處在於事務提交、回滾開銷比較小。

當所有的事務都是寫在一個Range上時，可以利用Raft保證原子性，一次完成資料寫入。同時能夠優化非跨Range寫事務效能，減少RPC通訊。

Cockroach DB使用MVCC的併發控制模式，它以HLC時間作版本號，逆序儲存保證最新版本資料優先被訪問。支援Time-Travel Query，多版本資料由非同步GC清理。

HLC算綜合借鑑了Physical Clock和Logical Clock思想。HLC Timestamp ID由時間和邏輯時間兩部分組成，物理時間通過NTP同步。在傳送訊息、產生本地事件和接收到訊息時，I、J都會被重置為幾個參考值中的最大值。這樣消除了單點時鐘逆變或不同節點間時鐘誤差的影響。

HCL演算法實現簡單、成本低，有一定時延。它基於NTP時鐘服務，不需要額外的硬體，演算法簡單，實現成本低。不過存在時鐘偏差，廣域網情況下偏差範圍會比較大。

True Time時鐘演算法有一定成本、時延低。它基於GPS+原子鐘等特殊硬體，實現成本較高。本質上類似Physical clock時鐘演算法，以一個誤差區間來替代時刻點。True Time時鐘系統精度遠遠高於NTP，可將時延控制在14ms內。

Cockroach DB比較適合OLTP場景，同時支援輕量級別OLAP場景。這些場景有如下特點：

- 高併發讀寫，支援多點寫入，自動負載均衡

- 大資料量儲存

- 隨時按需擴充套件、線上擴容

- 跨資料中心容災，多副本資料強一致

- 時延要求不苛刻

在之前百度內部是通過中介軟體的方式做資料的分片，但是當要扛峰值流量時就要預先擴容。而且在業務層做資料訪問時，必須按照固定的規則才能訪問資料，不能跨片做分散式事務。

在引入Cockroach DB之後我們就能對業務提供統一的資料庫檢視，使用起來也更簡單，更易於運維。

在引入Cockroach DB之前我們還做了MySQL語法協議相容、資料同步、自動化運維的工作。

Cockroach官方網站：http://www.cockroachchina.cn/