中國技術出海,TiDB 資料庫海外探索之路 | 卓越技術團隊訪談錄

語言: CN / TW / HK

作者 | 辛曉亮

採訪嘉賓 | 劉松、陳辰、裴立全

據 PingCAP 介紹,目前他們旗下的 TiDB 資料庫產品已經服務海外多家巨頭企業,覆蓋網際網路、科技、金融、遊戲等行業。熟悉資料庫的開發者都知道,有著基礎軟體“三駕馬車”之一的資料庫對一家企業的重要性有多大。

PingCAP 從成立之初就堅持國際化,他們是如何成功出海,在海外這個巨頭林立的市場成功立足。TiDB 做了哪些技術上的優化,海外業務有哪些特點,它在針對這些場景做了什麼工作?他們在海外業務上遇到了什麼挑戰?本次,InfoQ 深度採訪了 PingCAP 團隊核心人員,瞭解 TiDB 資料庫海外探索的那些事兒,希望可以給你帶來啟發。

TiDB 雲端平臺化演進

對於擁有全球化業務的 PingCAP 來說,資料庫產品 TiDB 對雲的適配是一個必選項。尤其是對海外客戶,從 DB 到 DBaaS,只有雲上的服務才能突破地域的限制,提供無限算力。

不過上雲並不只是底層資源換成雲端這麼簡單,技術上,要實現降本增效、運維自動化、多租戶管理;合規上要考慮資料安全、監管規則;商業上,計價模式、商業化策略等等這些因素都需要納入考量。

下面簡單從技術的角度談談 TiDB 從本地部署向 TiDB Cloud (DBaaS)演進過程中解決的問題。

首先是分離的架構設計。過去 TiDB 使用 TiDB + TiKV 的協處理引擎,儲存與計算的邊界是模糊的,在本地部署( On-Premise ) 的情況,如果需要增加儲存容量,就需要增加儲存節點,由於硬體的限制,除了磁碟,CPU 與網路頻寬也會同步增加,比較難處理不同負載率的場景,也容易造成資源的浪費。

遷移到雲上之後,一切都變得不同。以 AWS 的塊儲存裝置 EBS 為例,尤其是 GP3 系列,它可以在不同的機器上執行,效能很好,對雲原生的整合也不錯。為了利用 GP3 的這些特性,TiDB 將計算和儲存的邊界下移,從原來的 TiKV 到儲存,變成現在 TiDB、TiKV 的大部分都可以是計算單元。

除了計算儲存分離,不同角色的元件對硬體資源要求也是不同的,按需選擇儲存服務型別、彈性計算資源、無伺服器計算、運維自動化等都會成為成本節約的方案。

總的來說雲原生技術最重要解決的就是成本問題。除了成本,雲的 安全性 也是重中之重。雲上安全體系與雲下不同,雲下只需要考慮 RBAC 資料庫內部的許可權,雲上則要有從網路到儲存的整套健全的安全體系,最關鍵的就是利用雲本身提供的安全機制,如金鑰管理、規則等。

最後回到業務,為雲上的海外客戶提供服務,技術之外還有個前提條件就是合規。而云上的生態整合主線是跟著資料走,資料上游、下游、管控是最重要的三個部分。以 TiDB 為例,其上游是 MySQL、S3 中的資料檔案;下游只需要支援 Kafka 或其他訊息佇列服務的同步;最後對於雲上的海外使用者,相比資料庫廠商去做管控,他們更願意與 DataDog、Confluent 等平臺去打通。

從 TiDB 看國產技術出海模式

中國技術出海容易遇到信任度、監管、地理位置等各種各樣的問題。以歐盟為例,雖然國家比較小,但數量非常多,而且 GDPR 非常嚴格,個人相關資料不允許出境;再比如,印尼由很多塊島嶼組成,為應對自然災害,就要求資料在幾百公里以外有存檔,另外像日本是多災害國家,經常海嘯、地震,也會要求做跨區域的備份,比如公共雲廠商一般都會在東京放一部分,大阪放一部分。所以 TiDB 也必須支援跨區域資料的災備。此外,海外人力成本越來越貴,所以部分地區會要求把所有技術設施都使用程式碼進行管理,對 Infrastructure as Code 即 IaC 的挑戰會很大,同時對自動化的運維要求也很高。

除了基礎技術 TiDB 可以順利出海有幾個關鍵因素。首先是上雲,只有雲上的服務才能突破地域的限制,前文已經提到,這裡不再贅述。TiDB 在雲平臺化完成之後,第二個重要的事情就是解除信任門檻。不得不承認,在這點上,開源是個很好的敲門磚。中國技術公司服務海外客戶,如果沒有采用開源技術,懷疑會被加大,尤其是資料庫這種基礎設施,用專家的話說:“資料庫像心臟搭橋手術一樣,是比較要命的東西。”TiDB 開源社群的活躍度在這方面也提供了很大的幫助,既解決了信任門檻的問題,同時在往國外市場做廣告和宣傳上也省掉很多麻煩。

第三就是對於新技術趨勢要敏感,以 TiDB 為例,開源技術快速進行迭代,才能跟其他技術如 Flink、Spark 融合在一起。海外的許多企業技術前瞻性看的非常遠,技術的進化一定要跟上客戶的新形態才能保證不掉隊。回過頭看國內,我們的雲廠商在架構上並沒有出現特別領先的技術,同質化的競爭和卷的局面仍在繼續,工具確實有很多,但是模式沒有明顯優勢。

海外的使用者基本上天然都在雲端,許多都是在雲端使用 MySQL 或者雲端的 RDS,這對 TiDB 來說也是天然的優勢。TiDB 的做法是優先選擇海外公有云上的頭部網際網路企業,公有云解決了資料安全性的問題,頭部網際網路企業解決了體量的問題。不管對方是使用 MySQL 還是其他傳統資料庫,遇到瓶頸就會有新的需求,恰巧 TiDB 向下相容 MySQL。同時,TiDB 開源的形態也起到了關鍵作用。

服務全球場景,TiDB 海外探索實踐

對於 TiDB 來說,不同地區海外客戶的需求也有明顯的區別,目前海外雲上的客戶主要有兩個分支,之前多數都使用 RDS,其中以 MySQL 的 RDS 最為普遍,在出現無法處理的資料量後就會有兩種選擇。第一種是全託管,即所有技術上的事情全都不管,全部服務交給 TiDB,這也就是 TiDB Cloud 做的事情,這個分支當前主要以日本客戶為主;另外一部分就是還需要防止雲廠商鎖定,比如美國大部分客戶希望不會被某一家雲廠商繫結,甚至未來有可能出於成本考量為選擇本地部署做準備,那麼他們會選擇一個同時滿足多雲甚至本地支援的資料庫方案。北美的使用者也對全託管的 TiDB Cloud 表現出了很大的關注度,去年 11 月 TiDB Cloud 面向開發者的免費版本 Dev Tier 就有很高的訪問量和試用者。

當然其中還有部分架構翻新的需求,比如大型技術公司往往會更積極地尋求更先進的解決方案,以期望獲得更好的業務收益。

以北美一家著名社交公司 A 為例,A 公司的使用者體量比較大,HBase 規模達到了 10PB。A 公司剛成立時正是 NoSQL 比較流行的階段,所以使用了很多 NoSQL 的服務,其中諸多業務實際上需求的是可擴充套件的關係型資料庫,但當時並沒有更好的選擇。後來隨著發展,他們慢慢發現 NoSQL 很難滿足業務的需求,需要進行大量定製開發,就準備尋找下一個資料庫解決方案,花了半年時間,看了 15 個系統,從這裡其實可以看出,A 公司在資料庫選擇的事情上還是比較嚴謹的。最後他們選擇了 TiDB,主要的原因是 TiDB 無需太多定製開發,解放心智,成熟度高、且維護成本低。A 公司經過評估後,開始逐漸把 HBase 向 TiDB 遷移。

其實從這家公司的技術棧選擇可以看出來,雖然目前典型客戶還不夠多,但是 NoSQL 替換將會是一個趨勢:不少使用者選擇 NoSQL 未必是為了解綁關係型的特性,相反他們可能僅僅是為了可擴充套件而被迫犧牲關係型資料庫的特性。

還有一個案例,B 公司之前花費了近千萬美元購買了 300 多臺機器的 Aurora,但是效果並不是太好。300 多臺機器的升級對他們來說工作量就會非常大,Aurora 也無法滿足當前的業務需求。此外,B 公司正在做 Data Service,此前的 SQL 方案對於現在的應用開發來說體驗也較差。於是基於這些事,B 公司希望使用 TiDB 來做支撐,支援 100 多萬的 QPS。B 公司選擇 TiDB 的原因是因為 TiDB 有更好的可觀測性,同時可以把架構簡化,這與他們下一代的雲原生架構很接近。B 公司的下一代雲原生架構希望在每個公有云上去部署一套 Kubernetes,讓 TiDB 在跨 Kubernetes 中提供服務,整體上是一個 TiDB 叢集。

日本市場則有其獨特的場景,經過調研後 TiDB 發現其主要特點有以下幾個方面,首先是傳統資料庫擴充套件困難的痛點比較突出,實時業務的需求使得傳統公司正在考慮逐步嘗試換掉 Oracle 等資料庫,升級 MySQL 資料庫的擴充套件能力,並提升實時分析能力;第二,新冠疫情對日本整個數字化行業有一定的助推作用,雖說總人口並不多,但場景越來越趨向於高頻業務,這種情況非常適合 TiDB 發揮;第三、由於人力成本與多方面原因,日本缺乏經驗豐富的 SRE 工程師和 DBA(資料庫管理員)。同時 TiDB 發現,基於這幾個因素 TiDB 可以做的事情加上開源社群的影響,TiDB 在日本的熱度還是比較高的。

TiDB 在日本的規劃是先從遊戲、網際網路行業入手,之後慢慢轉向傳統行業、金融行業。一方面遊戲行業有著天然的週期,其次網際網路行業有高頻的場景,有大資料量的增長需求,還有一個原因是他們普遍對新技術的接受度很高,比較少顧慮產品技術以外的東西,只看產品能力和成功度,這正是 TiDB 需要的。

不過不同於北美,日本的客戶更傾向於使用託管的服務,這樣可以使他們更專注於業務本身。以遊戲行業為例,日本遊戲的特點是生命週期普遍比較長,一個遊戲經營執行幾十年,有許多忠實的粉絲,使用者付費習慣也比較好,所以遊戲付費是他們最常見的場景諸如高頻交易、時效性、交易完整性等等要求都很高,另外他們一直有非常穩定的使用者,這些使用者對遊戲的穩定性和因為遊戲升級等原因導致的維護期非常看重。所以日本的遊戲公司也會在遊戲製作上重點投入,比如採集遊戲的聲音。他們並非不重視技術,只是因為人力成本的原因,相對缺乏有經驗的 SRE 工程師和 DBA(資料庫管理員),這些對雲端的資料庫來說都是很大的挑戰。

以某遊戲公司 C 為例,C 公司每年遊戲收入大概 2-3 億美元,他們一年要開發十款遊戲,但是開發團隊只有 10 個人,如果細分到資料庫和雲的開發小組,人員就更少了,基於非原生分散式方案例如 MySQL Sharding 的複雜度需要更多的工程人員,對於小型團隊而言將大幅拖慢業務推進。TiDB Cloud 這種託管方式顯然更為合適。同時,TiDB 在實時反饋、高頻交易、時效性、完整性等上面也確實達到了對方的要求。

另外還有一個比較有特點的是金融行業,日本市場非現金支付不像國內發展的這麼快,他們在幾年前有一個快速增長的過程,經過分析後發現主要有以下幾個原因,第一是電商的快速增長,第二智慧手機和電子支付的發展,第三是外來遊客的湧入,電子支付對他們來說是最方便的支付渠道,這些突增的使用者量、實時線上交易使得本地的支付公司資料庫無法承載。

以其中一個金融公司 D 為例,他們的架構非常簡單,主要包括支付、使用者、商戶、錢包、風控、活動等模組。他們在從 1500 萬用戶量增長到 4000 萬的過程中,原有 Aurora 資料庫無法處理實時線上的需求,選擇了遷移至 TiDB。 D 公司的需求是扛住 1000 TPS,由於他們架構是一寫多讀的性質,現有的 Aurora 資料庫很難突破這個瓶頸,TiDB 是多寫橫向擴充套件的架構,遷移至 TiDB 之後,TPS 也是輕鬆達到了之前的三倍。除此之外,TiDB 還解決了之前 Aurora 的效能問題同時提供了更好的恢復性。

最後簡單總結,除了基礎技術、效能等關鍵產品特效能夠滿足自己的場景和需求之外,TiDB 還有另外幾個吸引海外客戶選擇的因素,第一 TiDB 是開源的,有著活躍的開源社群;第二不作為資料容器,客戶的資料還是會存放在 AWS、GCP 等公有云上;第三是遠端支援,不必依賴當地技術團隊,可以有效解決部分地區人力資源貴的情況。

資料庫的未來趨勢

進入雲 2.0 時代,之前 RBS(遠端 Blob 儲存)覆蓋的群體,基本上已經有領先的客戶再進行升級。其中一個是跨雲、雲原生;第二就是採取全託管雲中立的類似 DBaaS 這種,比如 TiDB Cloud。另外如今的分散式資料庫已經不單單是一個數據庫,它已經逐漸變成了一個 Data Platform (資料平臺),同時它還處理了許多大資料的工作比如 HTAP 代替大資料的實時分析,受訪專家認為,最終它會藉助開源演變成雲上的 Data Ecosystem(資料生態系統)。

目前現在的資料庫,還沒有真正為雲原生比如 Serverless 去設計。真正的下一代資料庫,應該具有以下這幾個特點。第一可以從雲上獲取到更多更靈活的資源,存算可以做到隨意,現在普遍的資料庫在雲端部署,理論上白天需要 1000 臺計算節點,較少的儲存節點,晚上則相反;第二未來資料庫的底層比如在儲存層,能夠在雲端做到更深層的優化,支援像 SnowFlake 這種可以動態呼叫雲的資源,根據不同型別的請求來決定底層選用什麼樣的儲存邏輯。這個才是未來真正的雲原生,目前還在路上,但期望可以在未來實現。

採訪嘉賓介紹:

劉松:PingCAP 副總裁,曾在 Oracle,阿里雲擔任技術管理等職位

陳辰:PingCAP 日本分公司 首席技術官,曾在阿里雲,IBM 擔任技術開發顧問職位

裴立全:PingCAP 北美分公司 首席技術顧問 ,曾在 Pinterest 擔任技術運維等崗位