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

內容來源：2017 年 11 月 18 日，百度數據庫架構師嚴龍在「第七屆數據技術嘉年華」進行《百度NewSQL-CockroachDB》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方、演講者以及微信公衆號——CockroachDB（微信id：CockroachDB）審閱受權發佈。

閱讀字數：3621 | 10分鐘閱讀

嘉賓演講視頻及PPT回顧： suo.im/5bnORh

摘要

本次交流主要包括開源 NewSQL 數據庫 Cockroach DB 關鍵技術分析以及 Cockroach DB 在百度內部的應用和實踐。

NewSQL起源

對於MySQL、Oracle、PostgreSQL這樣的單機數據庫，隨着數據量的增加在計算容量和存儲容量上都會出現問題。因而後續又推出了基於中間件或者NoSQL的方案，可是都並不是完美，好比中間件在分佈式事務方面以及NoSQL在SQL接口和對事務的支持方面作了必定退讓。

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

Cockroach DB簡介

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架構

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

Node & Store

Node是Cockroach DB的進程實例，一臺物理服務器啓動一個Node便可，一個物理存儲介質（例如一塊硬盤）通常配置一個Store，一個Node中有多個Store。

Range

Range是Cockroach DB存儲管理的最小單位，一個Range是一段鍵值區間的數據分片。一個Store中有多個Range，每一個Range分片默認爲64M，默認存在3個副本，分佈在不一樣的Node上。

ockroach DB特性

標準SQL接口

Cockroach DB使用PostgreSQL協議，支持標準SQL接口，兼容關係型數據庫SQL生態。支持事務、二級索引、Join等NoSQL欠缺的特性，同時還供了類MPP的分佈式查詢框架。它還支持Schema在線變動，以方便應對業務的變化。

SQL & KV

因爲Cockroach DB底層是分佈式KV，那麼必然就要將全部的SQL操做轉換爲KV操做。因而它就在底層抽象出了Get、Put、ConditionalPut、Scan、Del這五個KV做原語。

SQL / 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>反向索引到數據。

Column Family

在行存系統中數據的更新只須要進行一次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協議，因此只要半數以上副本存活，則服務可用；當節點異常，數據副本數量少於指定閾值時，自動補齊副本，保證可靠性。

分佈式事務

2PC

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

1PC

當全部的事務都是寫在一個Range上時，能夠利用Raft保證原子性，一次完成數據寫入。同時可以優化非跨Range寫事務性能，減小RPC通訊。

MVCC

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

HLC算法

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

與True Time時鐘算法比較

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/