摘要：日前，我司聯(lián)合創(chuàng)始人兼黃東旭接受了開源中國的開源訪談，公開解讀了的探索之路及未來方向。應用場景上在行業(yè)內使用更廣泛，目前涉及互聯(lián)網游戲金融政府電信制造業(yè)等多個領域。目前也與包括騰訊云在內的多家公有云平臺完成了整合，提供公有云數據庫服務。

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

記者：王練

口述：黃東旭

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

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

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

到現在，因為前方基本已經是無人區(qū)，思考得比較多的是未來數據庫的形態(tài)和一些前沿的技術，比如如何更好利用新時代的硬件，如何和云更好的整合等等。

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

技術上有幾個重要的點：

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

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

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

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

最后一點，是持續(xù)增強穩(wěn)定性，性能以及測試，這個是一個長期的工作，優(yōu)化無止境嘛。

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

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

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

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

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

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

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

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

應用場景上：TiDB 在行業(yè)內使用更廣泛，目前涉及互聯(lián)網、游戲、金融、政府、電信、制造業(yè)等多個領域。

個人認為從傳統(tǒng)的單機 SQL 到 NoSQL 只是互聯(lián)網公司在面對大并發(fā)量的新業(yè)務時的過度的狀態(tài)，歷史是螺旋上升的，現在 SQL 的回歸是大勢所趨，畢竟 SQL 是一個更好的操作數據的用戶接口。

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

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

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

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

在未來分布式數據庫系統(tǒng)上，主從日志同步這樣落后的備份方式會被 Multi-Paxos / Raft 這樣更強的分布式一致性算法替代，人工的數據庫運維在管理大規(guī)模數據庫集群時是不可能的，所有的故障恢復和高可用都會是高度自動化的。

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