本文源自: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