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

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文法協定相容、資料同步、自動化運維的工作。

原文釋出時間為：2018-05-16

本文作者：嚴龍

本文來自雲栖社群合作夥伴“

資料和雲

”，了解相關資訊可以關注“

”。