標籤:

【開源訪談】黃東旭:「無人區」的探索者,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. 最後就是我前面說過的要擁抱新的硬體,要跟上新硬體的迭代速度,配合設計新的數據結構來適應新的硬體。


推薦閱讀:

TiDB 助力牛板金互聯網金融營銷平台
2017 我們與世界的對話
TiDB Brings Distributed Scalability to SQL
使用 Ansible 安裝部署 TiDB
申礫:細說分散式資料庫的過去、現在與未來

TAG:TiDB |