分佈式 NewSQL 對比

一、TiDB：

說明：

PingCAP 公司基於 Google Spanner / F1 論文實現的開源分佈式 NewSQL 數據庫。

 

開源分佈式 NewSQL 關係型數據庫 TiDB 是新一代開源分佈式 NewSQL 數據庫，模型受 Google Spanner / F1 論文的啓發，實現了自動的水平伸縮，強一致性的分佈式事務，基於 Raft 算法的多副本複製等重要 NewSQL 特性。TiDB 結合了 RDBMS 和 NoSQL 的優勢，部署簡單，在線彈性擴容和異步表結構變動不影響業務， 真正的異地多活及自動故障恢復保障數據安全，同時兼容 MySQL 協議，使遷移使用成本降到極低

 

特性：

SQL支持（TiDB 是 MySQL 兼容的） 水平彈性擴展（吞吐可線性擴展） 分佈式事務 跨數據中心數據強一致性保證 故障自恢復的高可用 海量數據高併發實時寫入與實時查詢（HTAP 混合負載） TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更復雜的 OLAP 分析能夠經過 TiSpark 項目來完成。

 

---

二、CockroachDB：

說明：

構建於事務處理及強一致性KV存儲上的分佈式SQL數據庫，支持水平擴展、自動容錯處理、強一致性事務，而且提供SQL接口用於數據處理，是Google Spanner/F1的開源實現。 CockroachDB適用於應用對數據要求精確、可靠、徹底正確的場景，支持自動複製、均勻分佈、基於極小配置的數據恢復，可用於分佈式的、可複製的聯機事務處理（OLTP），多數據中心的部署，私有云的基礎構建，它不適用於讀少寫多的場景，能夠用內存數據庫來代替，也不適用於複雜的join查詢，重量級的數據分析及聯機分析處理（OLAP）。

 

特性：

支持PostgreSQL

對標準SQL支持較完善

較穩定

 

---

TiDB和Cockroach之間存在一些關鍵差別。

1.用戶界面和生態系統儘管TiDB和CockroachDB都支持SQL，但TiDB與MySQL協議兼容，而Cockroach選擇PostgreSQL。您可使用任何MySQL客戶端直接鏈接到TiDB服務器。

2.體系結構整個TiDB項目在邏輯上分爲兩部分：無狀態SQL層（TiDB）和分佈式存儲層（TiKV）。因爲TiDB創建在TiKV之上，開發人員能夠根據本身的業務自由選擇使用TiDB或TiKV。若是您只須要分佈式鍵值數據庫，則能夠單獨使用TiKV以得到更高的性能和更低的延遲。

總之，咱們的系統是高度分層和模塊化的，而CockroachDB是一個P2P系統。咱們系統的設計致使咱們使用兩種編程語言：Go for TiDB和Rust for TiKV以提升存儲性能。

而且受益於高度分層的架構，咱們構建了另外一個項目[1]，以便在TiDB / TiKV之上運行Apache Spark來回答覆雜的OLAP查詢。它利用了Spark平臺和分佈式TiKV集羣的優點。

3.事務模型儘管CockroachDB和TiDB都支持ACID事務，但TiDB使用了Google的Percolator引入的模型。該模型的關鍵特性是它須要一個獨立的時間戳分配器。與Spanner同樣，TiDB中的每一個事務都有一個時間戳來隔離不一樣的事務。

CockroachDB使用的模型相似於Google在其論文中描述的TrueTime API。然而，與Google不一樣，CockroachDB沒有構建原子鐘和GPS接收器來保持不一樣數據中心的時間一致。相反，它使用NTP進行時鐘同步，這致使了不肯定錯誤的問題。爲了解決這個問題，CockroachDB採用了混合邏輯時鐘（HLC）算法。

4.編程語言TiDB使用Go做爲SQL層，使用Rust做爲存儲引擎層。因爲Go具備垃圾收集器（GC）和運行時，咱們認爲調整性能將花費咱們幾天的時間。所以，咱們對TiKV使用Rust，一種靜態語言。它的表現要好得多。CockroachDB只使用Go。

 

---

三、FoundationDB：

2018-4 從新開源，資料較少

根據FoundationDB的官方文檔，FoundationDB有一系列的侷限性：

1. 單個事務數據量不能超過10MB
2. 鍵的長度不能超過10KB, 值的長度不能超過100KB
3. 系統針對而且只針對SSD優化，使用傳統HHD既不保證性能也不保證數據庫可用性
4. FoundationDB對於須要讀比較大的主鍵值範圍的查詢性能很差
5. 該系統沒有實現任何的安全和權限管理，任何人均可以去讀和寫任意一個主鍵
6. 系統不支持長時間運行的事務 ，具體來講，一個事務的第一個操做後超過5秒若是事務尚未結束，系統就會報錯。
7. 系統只在＜500個Core的狀況下仔細測過，有性能保證
8. 數據庫的數據大小不能超過100TB
9. 系統對每一個分區都作3份拷貝，而不會自動對熱點增長更多的拷貝，因此讀的性能有上限。

 

---

四、商用NewSQL：

Spanner、F1：谷歌

OceanBase：阿里

TDSQL：騰訊

UDDB：UCloud

 

RadonDB：青雲中間件

 

---

五、總結：

對比一番後，TiDB須要SSD及多臺服務器，CockRoachDB 更友好，優先嚐試。

---

2018-11-30 更新：

找到tidb的二進制文件，能夠簡單部署單機或集羣版：

https://www.pkold.com/a/TiDB_Binary__bu_shu_fang_an_xiang_jie_(_bei_fen_)

 

因爲cockroachDB支持的是postgreSQL，若是要承接mysql，須要修改爲本，並且很差估算；

tidb則幾乎徹底兼容mysql，承接mysql成本很是低，故對tidb進行了測試。

在一臺服上分別啓動mysql和tidb單機版集羣，對其進行OLTP壓力測試：

debian服務器一臺（4核cpu+8G內存）

	QPS	TPS
MySQL	16000	800
TiDB	4100	200

可見單機狀況下mysql的吞吐量比tidb高几倍，在集羣狀況下tidb表現會好點；

此處應該是沒有配置ssd硬盤致使結果沒有tidb官網所述好。

 

---

參考：

http://www.javashuo.com/article/p-rnfgjnxo-cg.html

https://blog.csdn.net/erlib/article/details/78442934

https://groups.google.com/forum/#!topic/tidb-user/k_nMQWPmK-Q

https://github.com/ixiongdi/NewSQLBenchmark

https://hn.svelte.technology/item/15499404