本文源自：https://www.cnblogs.com/GO-NO-1/p/9935195.html
1、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 項目來完成。
2、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。
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 更友好，優先嚐試。
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官網所述好。
參考：
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