TiDB，為SQL注入分散式可擴展性

時下，一大批新型資料庫急劇湧現，諸如 Google nSpanner 、 FaunaDB 、 Cockroach 以及 TimeScaleDB 等等，這些資料庫都在專註解決影響標準SQL的規模問題。現在，另一位來自中國北京的競爭者—— PingCAP 開源的 TiDB 項目，旨在維持 ACID 事務的同時，使 SQL 也具備 NoSQL 系統的可伸縮性。

PingCAP 聯合創始人兼首席執行官劉奇表示，該項目全面支持 MySQL 協議，也就意味著用戶可以重新利用 MySQL 工具，大大減少遷移成本。在多數情況下，用戶甚至無需修改應用程序的任何代碼即可取代 MySQL 。另外它是橫向擴展的，通過簡單地增加機器數量就可以提高性能。

去年十月，劉奇在阿姆斯特丹的 Percona Live 會議上提出了 TiDB 項目，彼時項目還處於測試階段，目前項目已進化到候選版本。本周四， PingCAP 聯合創始人兼首席技術官愛德華黃將在加州，聖克拉拉的 Percona Live 會議上披露 TiDB 項目的新進展。

他們認為 TiDB 兼具 SQL 和 NoSQL 的優勢，並且致力於使它：

• 易於使用；
• 確保數據不會丟失，故障情況下自我修復；
• 跨平台且可以在任何環境中運行；
• 開源。

該項目還允許模式在線變化，所以可以根據實際需求來修改模式。此外，在不影響業務進展的前提下，用戶還可以添加新列和索引。

在某次郵件採訪中，劉奇提到：作為一個開源項目， TiDB 已有超過 100 名貢獻者。

TiDB 項目靈感來源於 Google F1 分散式資料庫及 Google Spanner 。 Google 在自己的專有系統上建立了 Spanner ，並不開源，這在一部分人看來是個缺點。

「如果使用 Spanner ，用戶即默認承諾在 GCE（ Googlen Compute Engine ）運行服務，並有可能貫穿服務的整個生命周期。即使用戶選擇運行自己的堆棧，也不會出棧。」 Cockroach nLabs 首席執行官 Spencer Kimball 此前曾向 The New Stack 透露。

TiDB 採用鬆散耦合的方法，由一個 MySQLn nServer 層和 SQL 層組成，其基礎是開源分散式事務鍵-值資料庫 TiKV。 TiKV 是另一個 PingCAP 項目，使用 Rust 編程語言和分散式協議Raft ，而 TiDB 用的是 Go 編程語言。 TiKV 項目內含 MVCC（多版本並發控制）、 Raft 以及使用 RocksDB 的本地鍵值存儲等功能，它同樣使用 Sparkn Connector 。

劉奇表示， TiDB 與 Spanner 相比較有兩點不同：

Spanner 底層依賴於 Google的Colossus 分散式文件系統，但 TiDB 可以確保安全日誌存儲在 Raft 層。也就是說 TiDB 不依賴任何分散式文件系統，大大降低了寫入延遲。

「我們還看到了 SQL 優化器的巨大潛力，但 Google 似乎並不打算在 F1 項目中深入研究這方面。在設計我們的項目時，我們就旨在探索優化器的能力，」他說。

受益於原子鐘的使用， Spanner 獲得了廣泛關注，用戶可以藉助它在地理分布的數據中心間獲得時間同步。 TiDB 沒有使用原子鐘和 GPS 時鐘，相反，它依靠 Percolator（ 2006 年Google 發表的一篇論文）中所介紹的 Timestampn Allocator 。

TiDB 支持流行的容器技術，例如 Docker 。目前團隊正在致力於對 Kubernetes 提供支持，劉奇表示，這方面工作中的難點，在之前的阿姆斯特丹會議上恰好提到過。

現在他們正在努力解決的最大問題是延遲，尤其是地理分布的數據中心之間存在的延遲，他希望這一問題能在不久的將來得到解決。

PingCAP 由高級分散式系統工程師黃東旭、高級系統工程師崔秋以及基礎設施工程師劉奇共同創立於 2015 年 4 月，它有 48 個在北京的工程師和其他來自中國各地的遠程工作者。

其客戶包括手機遊戲提供商 GAEA，它使用 TiDB 支持跨平台的實時廣告系統，這要求面對大容量數據時能夠在一定期限內具備高峰負荷能力和經驗。 TiDB 支持自動分片和底層， TiKV 自動分配集群中的數據，幫助 GAEA 降低操作和維護的成本。

推薦閱讀：