分散式 NewSQL 對比
1、TiDB：
說明：
PingCAP 公司基於 Google Spanner / F1 論文實現的開源分散式 NewSQL 資料庫。
開源分散式 NewSQL 關係型資料庫 TiDB 是新一代開源分散式 NewSQL 資料庫，模型受 Google Spanner / F1 論文的啟發，實現了自動的水平伸縮，強一致性的分散式事務，基於 Raft 演算法的多副本複製等重要
特性：
SQL支援（TiDB 是 MySQL 相容的） 水平彈性擴充套件（吞吐可線性擴充套件） 分散式事務 跨資料中心資料強一致性保證 故障自恢復的高可用 海量資料高併發實時寫入與實時查詢（
2、CockroachDB：
說明：
構建於事務處理及強一致性KV儲存上的分散式SQL資料庫，支援水平擴充套件、自動容錯處理、強一致性事務，並且提供SQL介面用於資料處理，是Google Spanner/F1的開源實現。 CockroachDB
特性：
支援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。
3、FoundationDB：
2018-4 重新開源，資料較少
根據FoundationDB的官方文件，FoundationDB有一系列的侷限性：
- 單個事務資料量不能超過10MB
- 鍵的長度不能超過10KB, 值的長度不能超過100KB
- 系統針對並且只針對SSD優化，使用傳統HHD既不保證效能也不保證資料庫可用性
- FoundationDB對於需要讀比較大的主鍵值範圍的查詢效能不好
- 該系統沒有實現任何的安全和許可權管理，任何人都可以去讀和寫任意一個主鍵
- 系統不支援長時間執行的事務 ，具體來說，一個事務的第一個操作後超過5秒如果事務還沒有結束，系統就會報錯。
- 系統只在＜500個Core的情況下仔細測過，有效能保證
- 資料庫的資料大小不能超過100TB
- 系統對每個分割槽都做3份拷貝，而不會自動對熱點增加更多的拷貝，所以讀的效能有上限。
4、商用NewSQL：
Spanner、F1：谷歌
OceanBase：阿里
TDSQL：騰訊
UDDB：UCloud
RadonDB：青雲中介軟體
5、總結：
對比一番後，TiDB需要SSD及多臺伺服器，CockRoachDB 更友好，優先嚐試。
參考：
https://blog.csdn.net/u011782423/article/details/81030514
https://blog.csdn.net/erlib/article/details/78442934
https://groups.google.com/forum/#!topic/tidb-user/k_nMQWPmK-Q