【開源訪談】黃東旭：「無人區」的探索者，TiDB 的前行之路

> 日前，我司聯合創始人兼 CTO 黃東旭接受了開源中國的【開源訪談】，公開解讀了 TiDB 的探索之路及未來方向。本文為專訪實錄~

記者：王練

口述：黃東旭

首先請老師介紹一下自己

黃東旭，PingCAP 的聯合創始人和 CTO，TiDB 的設計者和工程師，一直以來從事的基礎軟體和分散式系統的研發，很小就開始接觸編程和開源，受到開源文化和自由軟體運動的影響很深，是一個開源信徒，所以後來基本做東西能開源的盡量都會開源，比如早期的 Codis，現在的 TiDB。

TiDB 從零到 1.0 歷時了兩年半左右，遇到的難點主要有哪些，是如何解決的呢？

技術上主要的難點，比較具體的我記得是在早期決定不復用 MySQL 代碼的同時還需要做到 MySQL 文法和網路協議上的兼容，同時還需要在很短時間內完成一個可用的查詢優化器，雖然技術本身不是特別難，但是在早期確實是個工程上的挑戰；另外底層存儲上我們選用了 Rust 作為開發語言，作為一個比較新的語言，我們花了一些時間和精力幫助 Rust 社區完善一些第三方庫，比如 gRPC 的 Rust 實現就是我們貢獻和維護的。

其實遇到技術問題也談不上有什麼特別的解決方案，仔細分析和思考，擁抱和相信社區，重視測試，我們的工程師和在 TiDB 社區活躍的 Committer 的能力都很強，我相信大方向沒問題，遇到的技術問題都是能解決的。

到現在，因為前方基本已經是無人區，思考得比較多的是未來資料庫的形態和一些前沿的技術，比如如何更好利用新時代的硬體，如何和雲更好的整合等等。

另一個方面是商業上的難點，我們幾個創始人都是技術出身，過去並沒有銷售和市場的經驗，在早期如何搭建商業和市場團隊，如何面試這方面的人才，曾經讓我們頭疼很久，不過工程師嘛，多聊多總結，發揮學習新技術的精神去了解不同行業的東西，另外我們的投資人也幫了我們不少忙，總體來說，保持一個開放學習的心態，放低姿態多和行業里比較資深的人聊，能學到不少。

1.0 之後的 TiDB 將主要圍繞哪些方面進行迭代更新？

技術上有幾個重要的點：

1. 大集群上的多租戶技術，這部分我們一個大的用戶 Mobike 的工程師們為 TiDB 提交了這方面很多重要的特性的實現和很多寶貴的建議，在這裡特別感謝一下。

2. 實時 OLAP 引擎，TiSpark 項目，TiDB 本身是一個 100% 的 OLTP 資料庫，同時它的實時複雜分析能力也會越來越強，1.0 後一個重要的方向就是我們希望能夠在 HTAP 上更進一步，打破資料庫和數據倉庫之間的界限。

3. 進一步減輕用戶的遷移成本，我們內部在開發一些工具能夠極大加速數據導入和同步線上 MySQL 的速度，降低用戶的嘗試和使用成本。

4. 擁抱新的硬體，這個時代，新的硬體層出不窮，Optane / NvmeSSD / 萬兆網卡的普及，如何設計新的數據結構，使用新的 SDK，Bypass Kernel 使得更好的適應新的硬體。

最後一點，是持續增強穩定性，性能以及測試，這個是一個長期的工作，優化無止境嘛。

1.0 發布之後勢必會吸引到更多用戶使用，但也有許多用戶迫切希望能有更多案例和背書，對此要如何解決？

其實這個是一個雞生蛋蛋生雞的問題，你需要得有第一批用戶案例，才能吸引更多的用戶，我們選在這個時間點發布 1.0 也是因為產品已經完成破冰，我們從 RC （Release Candidate）到 1.0 中間大約經過了一年，這一年時間我們已經默默的服務了很多種子用戶，在他們的生產系統中鍛煉，我們的早期客戶中已經有系統穩定運行 TiDB 大規模集群超過一年了，在確保產品質量和有足夠的用戶背書的情況下，我們這才謹慎的發布了 1.0，我們隨後也會持續的輸出案例，給予社區更多的信心。

國外和國內的用戶在特性方面的需求是否有差異，要怎麼來協調？

其實特性需求上差異不大。在中國，大家會遇到 MySQL 的擴展性問題，在美國也會遇到。所以這兩個市場對於我們這種基礎軟體公司來說，不會像 to C 的產品公司那樣難以在海外複製，基礎軟體領域是沒有國界限制的，目前我們也在布局海外市場。

同樣在做 NewSQL 的 CockroachDB 在更早一點發布了 1.0 版本，能介紹一下二者的差異和相似之處嗎？在進度相差不大的情況下，二者的業務是否有所衝突？

CockroachDB 也是一個很好的項目，在很多人看來，TiDB 和 CockroachDB 都是為了解決關係型資料庫的可擴展性問題，並且二者都是受 Google Spanner/F1 的啟發。 具體細節上，有以下幾點不同：

1. 二者兼容性不同，TiDB 是 100% MySQL 協議兼容，CockroachDB 兼容的是 PostgreSQL 。我們的用戶可以直接使用 MySQL 的客戶端來連接 TiDB ；

2. 架構上的區別，TiDB 產品架構是分層的，由分散式 SQL 層（TiDB）和分散式 KV 存儲引擎（TiKV）組成，而 CockroachDB 沒有分層，所有的東西都在一個 binary 裡面；

3. 事務模型不同，雖然 TiDB 與 CockroachDB 都支持 ACID 事務，但是 TiDB 採用的是 Google Percolator 的模型，這個模型的關鍵特性是，它需要一個獨立的 timestamp allocator，CockroachDB 所採用的是與 Google 相似的 TrueTime API，但是跟 Spanner 不一樣的是，CockroachDB 並沒有原子鐘和 GPS 時鐘來保證不同數據中心時間的一致性；

4. TiDB 是一個 HTAP 資料庫，既具備 OLTP 的強大在線交易能力，也具備 OLAP 的在線分析能力。CockroachDB 暫時不具備 OLAP ；

5. 二者開發語言不同，CockroachDB 用的 Go 語言，TiDB 整體項目用了兩種語言，SQL 層（TiDB）用的是 Go，KV 層（TiKV）用的是 Rust。

應用場景上：TiDB 在行業內使用更廣泛，目前涉及互聯網、遊戲、金融、政府、電信、製造業等多個領域。

從 SQL 到 NoSQL，再到 NewSQL，如何看待資料庫的現狀和未來發展方向？

個人認為從傳統的單機 SQL 到 NoSQL 只是互聯網公司在面對大並發量的新業務時的過度的狀態，歷史是螺旋上升的，現在 SQL 的回歸是大勢所趨，畢竟 SQL 是一個更好的操作數據的用戶介面。

在可見的未來，數據量會是一直在膨脹，業務會越來越複雜。我個人覺得未來的資料庫會有幾個趨勢，這也是 TiDB 項目追求的目標：

1. 資料庫會隨著業務雲化，未來一切的業務都會跑在雲端，不管是私有雲、公有雲還是混合雲，運維團隊接觸的可能再也不是真實的物理機，而是一個個隔離的容器或者「計算資源」。這對資料庫也是一個挑戰，因為資料庫天生就是有狀態的，數據總是要存儲在物理的磁碟上，而移動數據的代價比移動容器的代價可能大很多。目前 TiDB 也與包括騰訊雲、UCloud 在內的多家公有雲平台完成了整合，提供公有雲資料庫服務。

2. 多租戶技術會成為標配，一個大資料庫承載一切的業務，數據在底層打通，上層通過許可權，容器等技術進行隔離；但是數據的打通和擴展會變得異常簡單，結合第一點提到的雲化，業務層可以再也不用關心物理機的容量和拓撲，只需要認為底層是一個無窮大的資料庫平台即可，不用再擔心單機容量和負載均衡等問題。

3. OLAP 和 OLTP 會進一步細分，底層存儲也許會共享一套，但是 SQL 優化器這層的實現一定是千差萬別的。對於用戶而言，如果能使用同一套標準的語法和規則來進行數據的讀寫和分析，會有更好的體驗。

4. 在未來分散式資料庫系統上，主從日誌同步這樣落後的備份方式會被 Multi-Paxos / Raft 這樣更強的分散式一致性演算法替代，人工的資料庫運維在管理大規模資料庫集群時是不可能的，所有的故障恢復和高可用都會是高度自動化的。

5. 最後就是我前面說過的要擁抱新的硬體，要跟上新硬體的迭代速度，配合設計新的數據結構來適應新的硬體。