現(xiàn)狀
小米從創(chuàng)立到今天已經(jīng)過去了 10 年，2020 年 8 月 16 日雷總在線上直播，宣布小米正式開啟新十年的創(chuàng)業(yè)者計劃。第二個月，云平臺部門的數(shù)據(jù)庫與存儲團隊啟動了 TiDB 項目，作為團隊在小米新十年中的第一個三年規(guī)劃。2021 年 1 月，TiDB 產(chǎn)品正式在小米的內(nèi)部私有云上線，落地各項業(yè)務(wù)。
先介紹一下小米與 TiDB 的現(xiàn)狀。經(jīng)過近一年的發(fā)展，TiDB 在小米已經(jīng)部署了 20 多個集群，TiKV 節(jié)點也達到了三位數(shù)，覆蓋的業(yè)務(wù)場景包括電商、供應(yīng)鏈、大數(shù)據(jù)等等。右邊這個米字 logo 的詞云是由我們的一部分業(yè)務(wù)線組成的，包括了零售中臺、小米有品、智能制造、代工廠、還有門店等。
小米經(jīng)過十年的發(fā)展，在傳統(tǒng)數(shù)據(jù)庫上的使用中，確實遇到了相當多的痛點。因為時間有限，這只列舉其中四個。
第一，容量瓶頸。我們內(nèi)部的單機只有 2.6 T，經(jīng)過十年的發(fā)展，很多業(yè)務(wù)線單機的存儲都已經(jīng)達到了 2 T 以上，甚至只有幾百 G 的空間剩余，馬上就要滿了。為了解決容量問題，之前一般采用傳統(tǒng)的分庫分表解決方案，如果你對業(yè)務(wù)邏輯沒有很深的了解，是成本非常高的事情，然而業(yè)務(wù)線的建設(shè)時間往往已經(jīng)過去很久，以至于代碼都不知道從何下手去重構(gòu)。通過引入 TiDB 就能夠比較輕松地解決這個問題。
第二，高可用。MySQL 的主從架構(gòu)下，我們嘗試使用很多方法來做高可用實現(xiàn)，比如通過 LB + Orchestrator + 中間件的方案來解決。但是，如果半夜主庫掛了，可能仍然睡不好覺。
第三，高寫入。TiDB 作為一個分布式數(shù)據(jù)庫，很好地解決了多點寫入的問題。傳統(tǒng)的 MySQL 主從架構(gòu)，只能寫到主庫上，很容易達到瓶頸，達到瓶頸之后就會帶來非常強的主從延遲。主從延遲就會帶來一致性問題，一致性問題對很多業(yè)務(wù)來說是一個災(zāi)難。
最后，我們還有一些歷史包袱。小米十年發(fā)展以來，我們內(nèi)部有各種各樣的解決方案去適應(yīng)業(yè)務(wù)規(guī)模的增長,但都各有優(yōu)劣。小米曾開源過一個叫 Gaea 的中間件，也是支持分庫分表的，我們內(nèi)部還有其他的中間件，方案非常多，而且都分散在各個業(yè)務(wù)線。一旦相關(guān)人員有一些變動，就會變得非常難以維護。但是 TiDB 實現(xiàn)了這些方案的打包，我不再需要考慮是用這個中間件還是那個中間件，他們分別適應(yīng)什么樣的場景。
發(fā)展
我們發(fā)展的非�？�，從我們剛剛了解 TiDB，到去年 9 月份接入了第一個業(yè)務(wù)，然后我們開始正式立項，建立團隊。在今年 1 月份，我們就完成了包括部署、監(jiān)控、告警、工單等基礎(chǔ)能力的建設(shè)，開始類似于一個 DBaaS 平臺，去對業(yè)務(wù)提供服務(wù)。
到今年 4 月，我們開始做質(zhì)量提升工程，完成了小時級的備份恢復(fù)，還有巡檢系統(tǒng)、兩地三中心等方案的落地，大大提升了業(yè)務(wù)質(zhì)量。到今年 7 月份，業(yè)務(wù)規(guī)模開始快速增長，TiKV 節(jié)點很快就過百了。我們現(xiàn)在看到的節(jié)點數(shù)過百，完成業(yè)務(wù)規(guī)模翻倍，其實僅僅就兩三個月的時間。因為很多業(yè)務(wù)確實看到了 TiDB 很大的一個可擴展性，在遇到存儲瓶頸時，他們也很愿意去做這個遷移接入。后面，我們也會持續(xù)的去做 TiDB、TiKV 的穩(wěn)定性、性能還有成本等方面的工作，并且會重倉云原生的方向。
我們正式成立 TiDB 團隊投入到 TiDB 產(chǎn)品的落地中還不到一年，和很多廠商相比算是后輩，我們也充分利用了后發(fā)優(yōu)勢，直接引入了大量生態(tài)產(chǎn)品如 BR、TiCDC、TiUP、DM 等等這些生態(tài)產(chǎn)品極大地減小了我們的運維成本，方便我們構(gòu)建 TiDB 服務(wù)平臺，促進了產(chǎn)品的快速發(fā)展。
挑戰(zhàn)
其實接入 TiDB 也不是那么一帆風順。
第一是從分庫分表到 TiDB 的遷移過程。歷史問題造成的上游數(shù)據(jù)質(zhì)量堪憂（如業(yè)務(wù)自行分庫分表的設(shè)計，主鍵ID重復(fù)，甚至觸發(fā)器、存儲過程等），需要業(yè)務(wù)端做改造，從而導(dǎo)致遷移周期漫長。
第二是復(fù)雜的業(yè)務(wù) SQL 導(dǎo)致查詢計劃不準。我們的老業(yè)務(wù)遷到 TiDB 之后，某一個 SQL 突然比以前執(zhí)行時間大大增長。SPM 無法完全解決，一是 SQL 變化多、數(shù)量大。二是根據(jù) cost，執(zhí)行計劃也會變化。而很多老業(yè)務(wù)的復(fù)雜 SQL 非常多，我們需要一一去調(diào)整查詢計劃，去幫業(yè)務(wù)做調(diào)優(yōu)。
第三是部分內(nèi)部工具對接，比如為了對接內(nèi)部消息隊列，我們建了一個 TiCDC 的內(nèi)部分支版本、Drainer 的內(nèi)部分支版本，當然后續(xù)比較根源的解決辦法是內(nèi)部工具去迎合外部開源工具，支持相應(yīng)開源工具的接口。
最后，硬件、軟件多方面的性能調(diào)教。比如一些反直覺的情況：我們之前使用的一款NVMe 硬盤表面上磁盤性能比 SSD 要高，但實測 sysbench 的 workload 和業(yè)務(wù)的 workload 都有不小性能差距，有的情況下甚至 NVMe 的并發(fā)性能比 SSD 還要差一倍。硬件的適配和兼容也是后期我們調(diào)優(yōu)的一個方向。
點贊
第一個是社區(qū)支持非常友好，文檔非常完善，因此我們的接入非�？焖�。我之前也講了，其實僅僅一個季度的時間，我們就把整個以前看來各種高大上的平臺做好，可以對業(yè)務(wù)提供服務(wù)了。
第二個是完善的數(shù)據(jù)庫周邊生態(tài)，降低了運維的成本。我們知道一個數(shù)據(jù)庫產(chǎn)品的落地需要有自動化部署、監(jiān)控告警、運維管理平臺等一系列基建，得益于 TiDB 社區(qū)良好的可觀測性和豐富的生態(tài)組件如 TiUP / BR / Dashboard 等等，我們很輕松的完成了相關(guān)建設(shè)，極大降低了運維成本，減輕了運維壓力。
第三個，跨機房，多機房容災(zāi)，異地多活這個話題也是一個很深的話題。我們真正實踐起來發(fā)現(xiàn) TiDB 在跨機房上表現(xiàn)得非常優(yōu)秀，很容易落地三中心的計劃。對于一些需要異地容災(zāi)的業(yè)務(wù)來說，TiDB是一個很好的選擇。
第四個，加密存儲及傳輸?shù)墓δ?/STRONG>。透明數(shù)據(jù)加密 (Transparent Data Encryption)，簡稱 TDE，是 TiDB 推出的一個新特性，應(yīng)用在風控隱私集群上，極大簡化了業(yè)務(wù)邏輯。
最后是說下 HTAP 的內(nèi)容。我們內(nèi)部也有一些 HTAP 的實踐，右邊這個指標是我們的一個核心業(yè)務(wù)做的 HTAP 的實踐，我們之前通過 TiSpark 打在 TiKV 上的任務(wù)時間是在左邊，我們換了 TiFlash 之后，我們可以看到，無論是從任務(wù)執(zhí)行時間，還是 P99 延時、負載上，我們都提高了不只三倍。如果我們自己去優(yōu)化這三倍的性能，需要投入的精力有多少，大家做過性能優(yōu)化的應(yīng)該都知道。TiFlash 的引入大大簡化了我們的工作。
連接
前面我們提到，TiDB 豐富的生態(tài)，極大降低了我們的運維成本。取之社區(qū)，回饋社區(qū)。包括 TiDB 產(chǎn)品在內(nèi)，很多生態(tài)產(chǎn)品我們都有提 patch。現(xiàn)在，小米團隊是多個產(chǎn)品的 contributor，包括 dumpling、br、ticdc、tiup 等，TiDB 產(chǎn)品目前是 active contributor。
畫虛線的產(chǎn)品 TiKV、TiDB Operator，雖然目前還不是 contributor，但是我們和 PingCAP 已經(jīng)達成合作，后續(xù)將持續(xù)貢獻 TiDB、TiKV、TiDB Operator 產(chǎn)品，同時也是符合我們持續(xù)性優(yōu)化穩(wěn)定性、性能及成本目標。
我們不僅僅是 DBA，還是研發(fā)工程師，都有代碼層面了解產(chǎn)品的執(zhí)拗，當然對生態(tài)產(chǎn)品的代碼了解也有助于我們落地到業(yè)務(wù)中，同時反哺社區(qū)，幫助完善生態(tài)，也是開源社區(qū)所倡導(dǎo)的良性循環(huán)。
探索
玩過云的，大家可能都知道，云發(fā)展歷程中經(jīng)歷過很多基礎(chǔ)設(shè)施的不同潮流，包括選擇私有云還是公有云，以及底層的一些框架如何使用。
因為小米的國際化業(yè)務(wù)現(xiàn)在越來越發(fā)達，我們對海外的公有云的需求也會越來越大。所以我們制訂了一個全球混合多云的戰(zhàn)略。我們同時使用 IDC 機房和多種公有云，并且對外封裝，把他變成一個屏蔽細節(jié)的、全球化的混合多云。
這個混合多云的具體有哪些好處呢？
首先是安全性。在國際化業(yè)務(wù)中，我們可以根據(jù)需求把數(shù)據(jù)存儲在不同的位置。這個是可以通過我們的存儲來做，業(yè)務(wù)無需關(guān)心。第二個靈活性。我們可以對業(yè)務(wù)屏蔽掉底層這個復(fù)雜的多云環(huán)境，從而提供一個通用的環(huán)境。這樣我們在切換供應(yīng)商，或者是做一些底層操作的時候，業(yè)務(wù)就不會有感知。第三個成本。云原生的好處之一，就是優(yōu)化調(diào)度，資源共享。第四個質(zhì)量。云的另一個好處就是高彈， 我們可以快速完成擴縮容。而我們?nèi)绾卧诨旌显葡伦龈邚�，又是一個非常大的挑戰(zhàn)。
我這里畫了一個非常粗粒度的規(guī)劃。
用戶層我們不展開講。服務(wù)是我們給用戶提供的服務(wù)，包括運維管控、用戶平臺、數(shù)據(jù)流以及一些調(diào)優(yōu)服務(wù)。然后是管理：由于 TiDB Operator 部署在單個 K8s 集群中，控制范圍僅能在單個 K8s 集群，而我們的需求可能包含跨機房，跨云，甚至 IDC 和 K8s 混合（比如 TiCDC 部署在云中，而 TiDB 集群在 IDC 物理機上），所以我們需要在 TiDB Operator 上另外增加一些自定義調(diào)度。所以我們可以看到除了 TiDB Operator、傳統(tǒng)的 CMDB，我們增加了一個自定義的 Operator。
底層的資源剛剛已經(jīng)介紹了大部分，需要提的一項是底層的存儲資源。從本地磁盤到云盤到 Ceph，再到其他分布式存儲。開發(fā)者嘉年華的吐槽大會環(huán)節(jié)，美團的黃瀟老師對 TiDB 對演進方向有一個靈魂拷問：我們未來 TiKV 到底是繼續(xù)提高調(diào)度呢，還是說去往 PolarDB 這邊靠，做一些共享存儲的方案？東旭的回答是：我們?yōu)槭裁床欢甲瞿兀?/P>
其實我們也在研究這個問題。在支持本地磁盤和云盤的過程中，我們也在調(diào)研云原生的分布存儲。StarFS 是我們數(shù)據(jù)庫與存儲團隊目前正在自研的分布式云原生文件系統(tǒng)，與普通分布式存儲如 HDFS、Ceph 等有區(qū)別，主打高性能、低延遲。分布式存儲有一個天然弱勢就是 latency 不穩(wěn)定，所以很難作為線上數(shù)據(jù)庫的存儲后端，目前沒有能滿足數(shù)據(jù)庫需求的開源分布式存儲。StarFS計劃采用基于高性能存儲介質(zhì) SSD、NVMe，采用 SPDK、RDMA 等技術(shù)實現(xiàn)適合數(shù)據(jù)庫的分布式存儲后端。
當然，這只是初步規(guī)劃，并在有條不紊推進過程中，也期待引進越來越多的新技術(shù)，來迭代優(yōu)化混合云的架構(gòu)設(shè)計。
云原生探索踩過一些小坑，這里技術(shù)細節(jié)比較多了�？梢院唵谓榻B一下，假如 PD-pod 假死，Operator 的控制邏輯就會失效。表面上是在 Running 的狀態(tài)，但其實這個 pod 已經(jīng)無法提供服務(wù)了，這個坑也很難受。還有一些分布式存儲的調(diào)度問題、故障切換問題造成服務(wù)不可用的問題等。另外 Controller 的串行化設(shè)計也需要注意。我們知道 Controller 是把你的集群控制在一個期望的狀態(tài)，但是這個串行化的控制邏輯會讓你在擴容 TiDB 的時候，假如 TiDB 擴容不成功，TiKV 也無法擴容成功，這樣的話就導(dǎo)致阻塞，導(dǎo)致你整個運維操作的失敗。
預(yù)見
最后表達一下期望，我們已經(jīng)和 TiDB 社區(qū)建立了深度的合作，我們會共同推進混合多云戰(zhàn)略，推進核心業(yè)務(wù)的 MySQL 遷移，以及做一些 Committer 的培養(yǎng)。在內(nèi)部也會繼續(xù)推進 TiDB 落地到小米金融、小米 AI、小米 IoT 等多個業(yè)務(wù)場景。
