網易雲音樂 DBA 談 TiDB 選型：效率的選擇

編者按

本文摘自由網易 DBA 團隊撰寫的《效率的選擇——分佈式數據庫 TiDB 網易內部選型介紹》一文，對比了以 TiDB 爲基礎的創新架構和 MySQL + DDB 傳統架構的差異，從業務適配、降本增效、技術創新等多個維度闡釋了網易考慮引入 TiDB 的原因。

 

作者倪山三（[email protected]），網易數據庫專家，杭研數據庫運維團隊負責人。

 

TiDB 是⽬前開源數據庫領域最熱⻔的技術熱點之⼀，無論是從發展勢頭、技術迭代速度還是社區活躍度等⽅⾯來說，在國內一直保持着領先水平。⽹易 DBA 團隊本着好奇⼼和嚐鮮的⼼態始終關注着 TiDB 技術發展，也一直在進行着 “⼩打⼩鬧” 的嘗試。但是如果要從線上選型角度去嚴謹地調研⼀款關係型數據庫產品，其動機和預期成效⽅⾯的討論應當是非常嚴謹的。

 

直⽩點說，就是我們有什麼理由要⽤⼀款新技術嘗試挑戰穩定使⽤的現有技術⽅案，特別是在⽹易⾃研分佈式數據庫 DDB 能滿⾜我們當前需求的前提下。TiDB 對我們來說並不是分佈式數據庫 0 到 1 的改變，⽽是⼀系列痛點上 1 到 1.1 創新的集合，更需要細緻地加以闡明，本⽂即是對這⼀問題較全⾯的討論。

 

DBA 團隊希望將 TiDB 逐漸引入⽹易數據庫核⼼選型，對相關技術感興趣，或者有具體需求的同學請與 DBA 保持溝通，也希望本⽂起到⼀定的解答疑問和推⼴作⽤。

 

DDB 是網易內部自研的 MySQL 之上的水平分佈式中間件，可以類比爲 ShardingShpere 或者 Vitess。

 

分佈式數據庫技術發展背景

隨着各⽅⾯成本有着顯著優勢的 PC Server 趨於絕對主流，現在提到數據庫，很少有⼈會想到⼩型機和盤櫃時代的 Oracle 或 DB2 這樣⼀個櫃⼦⼏百 T 的⼤型集中式數據庫了。但是業務數據量和請求量仍然在不斷增⻓，因此近年來我們就要依賴分佈式數據庫技術，利⽤⼩規格的 PC Server 資源，提供⼤體量的集羣式服務。

 

分佈式數據庫有着多種實現⽅式，對比單體數據庫時代我們能夠提供的接入體驗，業務通常要求分佈式數據庫⽅案滿⾜以下基本特性：

 

• 要儘可能完整地⽀持包括 CRUD 和 DDL 在內的 SQL，同時要⽀持事務特性，滿⾜這兩點才能算的上是⼀個（關係型）數據庫

• 通過統⼀集羣入⼝提供服務，屏蔽內部分佈式細節

• 要有伸縮能⼒，⽆論通過何種⼿段，數據庫要能滿⾜持續增⻓的存量數據和吞吐能⼒要求

• 作爲最重要的中間件，服務應對軟硬件故障的⾼可⽤特性也是重要考慮點

 

利⽤零碎資源組裝⼤型服務的分佈式技術可以說是⽬前服務端軟件設計的標配，理論與實踐⼀直在不斷髮展，但是其實關係型數據庫分佈式技術的發展可能沒有⼤家想象的那麼成熟與完善。關係型數據庫本⾝雖然發展較早，但是卻是在分佈式技術⽅⾯是發展爆發較晚的那⼀個。在⼴義存儲領域，2006 年⼤概是分佈式技術最重要的⼀年，當時 Google BigTable、Amazon Dynamo、Hadoop ⼏乎同時出現，奠定了⽬前整個業界分佈式存儲從技術原理到基礎設施實現的半壁江⼭。⽽關係型數據庫直到 2012 年 Google Spanner 論⽂發表前，⻓期處於商業⽅案壟斷，分佈式技術理論發展較慢的階段。可能就是由於上述 4 點特性要求使得分佈式數據庫的技術⻔檻顯然比其他不需要⽀持事務、⽀持 SQL 的服務來的高。

 

在我看來，關係型數據庫分佈式技術發展可以分爲三個主要流派線路，其各⾃有多個階段：

⽬前整個業界現狀基本如此，三個路線雖然發展有早有晚，但是⽬前都處於被⼴泛接受並且⼀直活躍的情況，並不是⼀般認爲的換代取代的關係。同時可以看到選擇其實並 不是很多，⾄少比⼤數據那龐雜的技術棧清晰多了。我們進⼀步分析⼀下我們可能的選型：

 

• sharded storage（線路 3）⽅案雖然技術含量很⾼，從性能到吞吐能⼒都⽆可指摘，但終歸是完全的商業化⽅案。我們並不排斥，將在公有云場景中適時地充分利⽤，但是依賴特殊供應商的商業⽅案顯然並不能作爲孤注⼀擲的唯⼀選型，除非有相對開放的⽅案出現（好消息是⽹易數科也確實在這⽅⾯進⾏研發，並已經取得進展）。

• DDB 是⽹易⾃研的，基於 MySQL 的分庫分表型（線路 1）中間件，也是當前我們的主流選型。在這⼀⼤類型的分佈式⽅案中，各種開源中間件的功能，實現⽅式都非常雷同，其他任何⽅案與 DDB 相比都不存在同質競爭的明顯優勢，⽽各⾃缺點都很突出，不如 DDB 普適。因此在中間件這⼀流派，DDB 就是最優解。但是分庫分表中間件在如今的業務使⽤場景中逐漸遇到⼀些效率⽅⾯的問題，這也本⽂接下來的主要論述重點，爲啥我們有 DDB 分佈式⽅案的情況下還需要嘗試新的分佈式數據庫技術。

• 這樣剩下的就只有 NewSQL（線路 2）了，要看是否能解決我們在 DDB 中間件⽅案中遇到的痛點了。⽽ NewSQL 三⼤代表中只有 TiDB 是主打 MySQL 兼容，特別是 YugabyteDB ⼲脆 Postgres 爲主，所以我們聚焦的重點⾃然⽽然變成了 DDB VS TiDB。

 

所以看着像是數據庫技術間的世代競爭，其實也沒這麼複雜，對我們的現狀來說，傳統數據庫 = DDB + MySQL，眼下的新⽣代 = TiDB。

 

TiDB 選型優勢與傳統分佈式⽅案⽐較分析

最本質的問題其實是我們是否需要，爲什麼需要引入 TiDB 技術。如上所言，我們希望通過新⼀代數據庫運⽤，來解決或改善當前 MySQL 分佈式中間件模式使⽤中的⼀些問題。都有哪些問題、TiDB 如何改善，我們將展開詳細介紹。

 

優勢概覽

⾸先先看選型調研下來關於 TiDB 優勢的結論總結，接着按照相關分類逐⼀進⾏論述:

 

• 提供 DDB 同等的⽔平擴容能⼒

• SQL⽀持能⼒較 DDB 好

• 資源擴縮容粒度更加靈活，不需要像 DDB，每次都翻倍擴容

• 擴容⾏爲效率和安全性

• 數據存儲成本⼀定程度降低（不需要 raid10+rocksdb 壓縮-rockdb 寫放⼤）

• 在線 DDL⽀持更好，除了加索引基本都是秒回，⼤表增加修改列成本顯著降低

• 主從複製效率顯著提⾼，降低寫負載下⼀致性和⾼可⽤降級的⻛險

• 數據⼀致性下限提升

• ⾼可⽤⾃動恢復可靠性與效率顯著提升

• HTAP 能⼒能夠減少數據傳輸環節的成本和⻛險， 提供業務更⾼效的實時分析能⼒

 

SQL ⽀持能⼒較傳統 hash 分表模式得到提升

TiDB 雖然也並不是完全兼容 MySQL 所有 SQL 功能和語法，依然有⼀定限制，其中相對重要的限制包括:

 

• 不⽀持存儲過程/觸發器， 不⽀持 select into 變量不⽀持 MySQL 較新的 WITH ROLLUP 開窗

• 不⽀持外鍵約束

• 不⽀持視圖上的 DML 更新基表

• 不⽀持顯式 XA 流程控制 (因此雖然 MySQL 兼容但⽆法作爲 DDB 的存儲節點)

• 不⽀持 savepoint 制

• 5.0 之前的版本不⽀持 DECIMAL 精度修改

 

但是對於我們來說，這些限制⼏乎沒有影響，因爲分佈式中間件 DDB 也⼤部分不⽀持或者限制很多。我們可以認爲 TiDB SQL 能⼒是 DDB 的超集，業務僅需要更換驅動，從 DDB 專有驅動 DBI 更換爲開源 MySQL 驅動如 jdbc + 連接池即可完成業務遷移。

 

這個超集部分體現最直接的就是⼦查詢和 join 的⽀持能⼒有顯著提升。DDB 模式下由於所有表都做了指定字段的 hash 分佈，join 語句如果 join 字段正好是兩個表的均衡字段，則能夠完成分佈式數據庫內連接查詢，性能尚可；但如果 join 字段必須跨節點匹配，在 DDB 中只能通過客戶端 DBI 集中緩存全部數據的⽅式進⾏中⼼化計算，極易造成 DBI OOM 進⽽崩潰。進⼀步地，⼦查詢由於優化器⼀直沒有完成相關功能，直接是不⽀持的。這⽅⾯TiDB 的⽀持顯然要優秀很多。

 

但是 TiDB 使⽤過程中還是有⼀些其他的注意點:

 

• ⾃增 ID(AUTO_INCREMENT)， 由每個 TiDB server 獨立分配， 能保證全局唯⼀， 且單個 TiDB server 內遞增， 但是⽆法保證全局遞增， 以及沒有任何連續性保證。這個其 實和 DDB 的批量分配唯⼀ID 造成結果類似的。

• 單⾏單列⻓度限制， 都是定死的 6MB， 也就是 KV 的單個 key entry 上限就是 6MB， MySQL ⾥可以通過 longtext/longblob 等突破到 G 級的記錄⻓度， 在 TiDB 不適⽤（雖然數據類型是預留了，但是⽂檔描述有誤）。

• 事務⻓度限制，在使⽤樂觀事務並開啓事務重試的情況下默認限制 5000，可調整，同時我們不太可能⼴泛使⽤樂觀鎖模式，因此影響不⼤。其他以前很坑的事務⾏數限制 30W，總⼤⼩ 100MB 等在 4.0 後不存在了。

 

⽔平擴容實際效率和能⼒顯著提升

DDB 和 TiDB 理論上都可以通過增加存儲節點，並且重均衡存量數據，實現存儲容量近乎⽆限的擴展能⼒，但是實現⽅式上⼤相徑庭。客觀來說，DDB ⽬前在⽹易的使⽤規模已經使得⽔平擴容在部分場景下困難重重。

 

傳統分佈式中間件（比如 Vitess）的擴容形式⼤同⼩異， 你需要先爲集羣添加擴容前資源成倍的新資源， 但是這些資源暫時還不可對外提供服務， 然後通過各種⼿段將存量數據以及實時增量數據同步並拆分到新資源，然後找某⼀時刻完成新老資源的替換，老資源下線，完成擴容全部流程。

由於有⼤量的經驗和⼯具開發，DDB 傳統模式擴容⽅⾯我們有着非常完善的⾃動化輔助能⼒和可靠性保障，因此能⼒⽅⾯是沒有問題的。關鍵在於效率：

 

• ⾸先是必須成倍的資源投入。我們內部較⼤規模的 DDB 集羣數據存儲量有百 T 這個量級，這是 8 年存量的結果，這個存量情況下數據的增量很難再出現成倍爆發式增⻓。但是傳統⼀拆⼆模式下的擴容通常要求成倍的新資源投入，拆完後⽔位從 100% ⼀下回到 50%，⽽⼀年實際增⻓可能還不到 15%，這個⼀次擴容的投入成本效率可⻅⼀斑。當然我們可以同重新 hash 等⽅式使⽤比例擴容，技術上是做的到的，但是下⾯就要討論時間和穩定性成本了。

• 其次是擴容過程效率太低了，我們有多種⽅式完成存量數據的遷移以及增量數據實時同步，技術上沒有問題，但是效率實在太低了。在保障線上負載相對穩定的前提下，我們的經驗數據是算上增量補償時間，每 2T 數據遷移完成物理⽅式約 10~20 ⼩時，邏輯⽅式約 30~40 ⼩時。當然分佈式集羣這些傳輸都是並⾏的，由於磁盤容量因素，我們數據庫通常以 6T 爲⼀個並⾏單位，即便如此，整個時間也得以周來計算了。

• 然後就是擴容成功率的問題，⼤部分情況下⾜夠的資源投入和⾜夠⻓時間的準備週期讓我們擴容相對來說還是靠譜的， 但是近年來我們確實遇到了擴容⽅案⽆法實施的問題。例如有⼀次擴容需求來⾃於業務邏輯調整，數據寫入吞吐量劇增，負載和容量都不夠需要擴容，但是 MySQL 孱弱的主從複製效率造成了擴容後增量數據補償永遠跟不上數據寫入量，甚⾄換了更⾼效的內部邏輯並⾏ CDC ⽅案也跟不上，導致數據源切換⽆法完成的情況。也就是我們即使緊急準備了⾜夠的資源打算擴容現有集羣，依然可能出現⽤不上的情況。

 

綜上，我們可以看到 DDB ⽅式的擴容在⼀些實際場景在投入成本，效率，可⾏性⽅⾯都有⼀些難題，⽽ TiDB 的引入則能夠爲我們解決這些問題。TiKV 的擴容從運維角度上來 看是機器簡單的⼀個操作:

 

• TiDB server 由於⽆狀態，其擴容相對容易，⽽ PD 作爲管理服務本⾝⼤概率不需要擴容，因此通常來說的擴容主要是存儲服務 TiKV 的擴容。

• TiKV 擴容操作僅需要在新增服務器上合理配置並啓動服務即可， 新啓動的 TiKV 服務會⾃動註冊到現有集羣的 PD 中， PD 會⾃動做在線的逐步負載均衡， 對業務⽆感知地， 逐步地把⼀部分數據遷移到新的 TiKV 服務中。⽽新投入的 TiKV 資源可以認爲在啓動的⼀瞬間就已經將資源添加到了現有集羣， 不需要再等待漫⻓的， 外部控制的數據重分佈過程。

• 順便提⼀下， 傳統分佈式形式中數據庫的縮容和擴容基本同樣⿇煩， 都需要⾯臨數據重分佈效率低下的問題。⽽在 TiDB 中縮容 TiKV 節點， 只要不違反相關約束， 安全關閉前 TiKV 會先通知 PD， 這樣 PD 可以先把這個 TiKV 上的數據遷移到其他 TiKV 實例， 保證數據有⾜夠的副本數後完成⽆感知縮容， 效率和⾃動化程度也較傳統模式有巨⼤提升。

因此我們看到，⽆論是從擴容操作效率，過程的⾃動化程度，還是過程的可靠性來看，TiDB 都是比傳統模式有着很⼤的提升，能夠將以天乃⾄周計算的擴容流程效率提升到分鐘這個級別。

 

schema 變更⽀持能⼒提升

類似上⾯⼀條⽔平擴展，在採⽤MySQL 底層的基礎上的傳統分佈式中間件還存在着顯著的 schema 變更瓶頸，⽽且問題也是出現在存儲資源和性能上。

 

schema 變更有些是相對容易便捷的操作，例如新建⼀個表這樣，在任何情況下都不是太⼤的問題。⽽有些在 MySQL，或者說傳統塊⾏存儲數據庫中⼀直是相對⿇煩的⾏爲，例如加字段，修改字段類型屬性，加索引，改鍵等。在 Oracle 中通過正常 DDL 或者在線重定義兩種比較正規的形式就能統⼀所有操作需求，⽽在 MySQL 中這類變更功能⼀直是技術難點，⼿段多，坑也多，⼤家可以通過下⾯的圖感受⼀下:

主要痛點包括:

 

• MySQL 的 online DDL 始終讓⼈難以完全信任，即使在 online DDL 隨着版本完善的過程中，我們也不得不爲了規避某些情況堅持使⽤外部變更⼯具。

• 由於穩定性⻛險， 雖然 online DDL 並不會如傳⾔所說鎖表時間同增量更新有線性關係， 但是依然有其他⽅⾯的⻛險， 例如我們不太遠的過去遇到過 online ddl 中 inplace 算 法 要 求 刷 髒 導 致 寫 負 載 型 數 據 庫 卡 頓 影 響 穩 定 性 的 ⻛ 險 （想 了 解 的 同 學 可 以 參 考 : http://www.percona.com/community-blog/2020/04/23/unexpected-slow-alter-table-mysql-5-7/）。我們已經在哪種情況使⽤哪種⽅式做了非常多的策略判斷了， 多年嘗試， 實在難以根據每個特定業務場景做出完全可靠的智能策略，有時候爲了避免不必要的⻛險，不得不依然依靠業界⼴泛使⽤，⼴受考驗的外部⼯具繼續做爲統⼀變更⼿段。

• 由於不確定性⻛險，我們⾃研運維平臺⾃動化處理的數據庫⼤⼤⼩⼩變更⼀年接近⼗萬量級， 如果說⼀種每天都在頻繁使⽤的核⼼功能其成功率要依照⼀個默認 128MB，實際不知道多⼤合適的參數的限制，在部分業務場景會經常遇到 RROR 1799 (HY000): Creating index 'idx_xxx' required more than'innodb_online_alter_log_max_size' bytes of modification log…… 
  類問題，不但失敗還要浪費⼤量資源進⾏回滾的。這個功能是⼀個可靠的功能嗎?

• 實際上在業界對 online DDL 的⻓年不敢⼴泛使⽤是 DBA 這邊的常態，比如阿⾥雲等公有云⼚商和我們是基本相同的做法: 如果你要⼚商提供變更⽀持，則⼀律採⽤外部⼯具，即使在 PolarDB 時代依然如此。

• MySQL 內部機制不太靠譜， 外部⼯具也問題多多， 特別是效率問題， 外部⼯具變更需要比變更表更⼤的磁盤剩餘空間來完成操作， 因爲外部⼯具和原始 DDL 的 copy 模式是⼀樣的， 只是不鎖 DML⽽已。我們需要完全拷⻉⼀份原表數據應⽤變更， 並且期間還會造成⼤量 binlog。比⽅說， 你想變更⼀個 500G 的表， 我們的經驗是數據庫本地需要⾄少還有 1T~1。5T 以上空餘空間， 我們通常認爲纔是完全安全的。同時拷⻉數據同上⾯擴容是類似的情況， 需要⼤量時間。實際情況是核⼼業務存量表往往較⼤， 導致你還得先擴容再變更， 這就造成了變更的時間成本和資源成本經常讓業務難以接受——翻倍的資源， 以周計算的時間， 變更期間讀寫分離⼀致性失效， ⾼ 可⽤失效……我們的業務通常望⽽⽣畏，讓本該隨⼼所欲的數據庫變更變成⼀種僅在理論上可能，實際難以實現的需求。

• 其他的性能衝擊，約束鍵導致的⼀致性⻛險，變更期間⾼可⽤⻛險，DDB 環境下分佈式變更的調度和原⼦性控制，極端情況下⼤家都會遇到的 MDL 阻塞，對備份機制的影響 ……各種各樣問題不⼀⽽⾜。

 

以上痛點是致命的，嚴重影響業務迭代，穩定性，效率的。我們迫切希望⼀種新的模式來改變現狀，順便⼀提，變更的部分痛點即便在 PolarDB 和 Aurora⽅案下依然還是難 點，因爲他們的上層使⽤的還是 MySQL。我們 DBA 團隊隨着多年採坑，爲了能夠提供線上可靠的⾃動化變更能⼒，不算⼯具，流程，前端代碼，僅後端調度和管控代碼就投入了兩萬多⾏，⽬前除了資源喫不消難以變更的情況外，能夠基本保證⽇常變更⾼效安全。雖說這是我們喫飯的本事，但是我還是要說這個模式複雜的沒有價值，效率也隨着業務存量增加，逐漸顯得不可接受，希望技術上能夠得到突破。

 

⽽ TiDB 在這塊以我們調研和⽬前應⽤結論來看，就有較⼤的優勢了。

 

簡略來說，TiDB 主要有如下優勢:

 

• 由於 kv 模擬⾏表的數據結構，以及 LSM 存儲⽆法更新的特點，⼤量數據類型，加減字段，默認值類的操作都可以通過僅元數據變更實現完全 instant，相較 MySQL 8.0 的 instant 範圍顯然要⼴，效率非常⾼，都是 1s 級別完成變更，且業務感知⼩。

• 加索引這類必須產⽣新持久化數據，⽆法 instant 的操作，採⽤後臺任務，異步線程的機制實現對業務影響相對⼩。⽽且 ADD INDEX 時 tidb 有明確參數記錄⽬前索引 創建的進度和速度，能夠較好安排調度。

• 上述兩者都比 MySQL copy 或外部⼯具模式顯然節省空間。⽽且 TiDB 本⾝擴容就要比 MySQL 中間件⽅式容易的多，變更的效率和可⾏性都將巨⼤提升。

• 更不會有主從問題帶來的⼀系列延伸問題。

當然雖然效率提升了，但是也不能說 TiDB 的變更對業務完全沒有影響，具體來說是有些新的情況:

 

• 由於 schema version 的變化，執⾏的 DML 語句中涉及的表和集羣中正在執⾏的 DDL 的表有相同的，那麼這個 DML 語句就報錯Information schema is changed,⼀次性，但是需要業務使⽤連接池連接數據庫，並且業務端有重試機制避免事務完全失敗。

• ADD INDEX 操作，根據壓測，⽬標列被頻繁讀寫，特別是寫多時對性能影響較⼤(即 對業務原有字段加索引時可能會對性能有較⼤影響)，QPS/TPS 極端情況下下降 23% 左右，這個其實和 pt-osc 近似了。

 

總體來看，我們是非常希望通過引入 TiDB 來解決⽬前業務表結構變更中的痛點，提升相關效率，進⽽幫助業務更快更安全地實現迭代。

 

⾼可⽤可靠性與效率顯著提升

MySQL 雖然是業界最⼴泛使⽤的數據庫種類， 但是在 MGR 技術完全普及(⽬前還談不上)前其服務⾼可⽤實現⼀直是有問題的。具體設計上的問題各位可以 KM 搜索我之前的數據庫⾼可⽤⽂章，我們就不展開了，直接介紹業務痛點。

 

• 主從⼀致性雖然可以做到相對安全，但是下限非常低，需要許多相關參數和機制配合，例如多種 log 持久化，半同步，複製信息表記錄，半同步 ack 模式，non-loss 等……⼀項問題都可能導致主從不⼀致，進⽽影響可靠性。

• 不⽤ MGR 則集羣沒有內部協調機制，切換需要外界參與，⽽不能向 ZK，redis cluster ⼀樣集羣內部完成，這就導致了切換成功率，資源漂移可⾏性，以及如何防⽌極端 情況腦裂雙寫⽅⾯⼤量的坑。並不是不能做，但是要做到完全靠譜並不容易，這塊我之前的⽂章有非常詳細機制原理的介紹，如感興趣請參考。

• ⽤了 MGR，雖然集羣內部角⾊和⾃治切換問題得到了解決，但訪問模式官⽅⼀直沒有給出非常好的解決思路，⽆論是堪比 sidecar 的 proxy 模式還是⾃⼰改客戶端，或者像過去⼀樣外部控制資源漂移，都沒有很好地解決客戶端切換的問題。這塊MySQL一直沒有和 Redis 或 MongoDB 學習，讓人比較鬱悶。

• 外部切換還存在效率問題，也就是切換對客戶端恢復服務的時間間隔。有可能是域名切換，客戶端緩存導致的問題，也可能是 DDB 這⾥元數據更新串⾏化導致的。特別是⽹易內部 DDB ⼴泛使⽤的 DDB 模式下，由於通過更新路由配置中⼼實現，存在通知客戶端⽹絡超時和配置中⼼更新只能串⾏兩⽅⾯的痛點，導致硬件故障造成的最基本切換場景所需的時間只能保證在 1 分鐘級別，5 分鐘以內，這就是切換效率的問題了。

• 最⼤的痛點，即便是 MGR，MySQL binlog 複製是⾼可⽤功能上⽆法迴避的夢魘。這塊接下來要單獨講。

 

單獨來說 MySQL 最核⼼的問題之⼀，基於 binlog 主從複製的性能問題，這⼀問題並不能通過升級 MGR 技術改進:

 

• 相對 Oracle 的數據⻚邏輯複製，MySQL 的 binlog 邏輯複製性能簡直讓⼈⽆法忍受。即便是並⾏複製情況下，根據業務特徵，⼤部分情況下，⽆論哪種並⾏模式都⽆法讓複製效率實現質變，爲了提高效率我們不得不折騰日誌持久化，組提交等周邊性能要素，甚至造成一些持久化風險。通常我們認爲在 CPU，IO 和⽹絡都沒有瓶頸的情況下，單組 MySQL 實例⾄多也就只能保證簡單更新 3000~5000 tps 的複製效率，隨着邏輯複雜，部分業務可能超過 2000 tps 就可能產⽣延遲，如果在所有安全措施特別是從庫⽇志持久化相關全部嚴格要求下，性能可能更糟……複製延遲意味着⾼可⽤⾃動切換失效——雖然⽇志到了從庫，但是數據尚未被更新，不能讓業務切換後讀寫延遲的數據。

• 線上⾼負載可能導致複製延遲，例如我們⼀些電商類的活動⾼峯期間，訂單等數據的寫入⾼峯造成延遲，再最關鍵的時候數據庫⾼可⽤實際上是沒有保護的。

• 變更可能造成延遲，⽆論是 online DDL 還是外部⼯具變更，都會隨着變更對象規模變化，造成不可控的延遲，嚴重的可能以天計算，在變更期間⽤於讀寫分離分流負載的從庫⽆法讀，同時主庫缺乏⾼可⽤保護，掛了就掛了……⼤家知道真相是不是會出⼀⾝冷汗?

• MySQL 解決延遲我們認爲唯⼀可⾏的辦法就是實例級別的⽔平拆分，每個實例來撐儘可能⼩的 tps 負載，⼀種非常另類的並⾏化。但是這並不是⼀種非常可⾏的模式，例如 DDB 爲代表的分佈式中間件場景下，⼀個數據庫從 64 分片拆到了 640 分片，每個客戶端連接對象，分佈式事務損耗，集羣變更和管控難度都會不斷正在，⽽且也⽆法保證真的能徹底解決延遲——比如問題是熱點造成，如果業務熱點寫集中在⼀個分片呢?

 

TiDB 在⾼可⽤和數據複製⽅⾯同樣有着巨⼤的優勢：

 

• ⼀致性下限就非常⾼，raft 機制保證數據副本可靠，想要造成不⼀致的可能反⽽困難。

• TiKV raft group ⾃治選舉，⽆狀態的 TiDB server 層⾃動更新路由，⾃治切換和業務連接漂移都不再是難事。

• 切換效率也非常好，雖然每個 group 都要選舉，但是⾼度並⾏化，穩定的 10s 數量級內完成。

• raft group 級別⾼度並⾏的複製效率，我們做過相關壓測，寫壓⼒在 MySQL 等量集羣延遲⽔位 10~20 倍以上的情況下依然沒有相關⻛險。

 

TiDB 的數據多副本⼀致性，⾼可⽤在機制上對於傳統 MySQL，特別是非 MGR 模式來說堪稱跨時代的進步——終於進入了合格的分佈式集羣時代。

 

未來，特別是業務可能⼤量使⽤公有云設施的情況下，可能 TiDB 這類⾼效和可靠機制是強需求，因爲公有云雖然整體資源池有優勢，但是單點資源的可靠性根據我們的經驗和 SLA 標準來說，是不如我們現在的⾃有機房的。如果在成本考慮，不完全依賴 RDS 的前提下，資源問題概率的提升會放⼤以前⾼可⽤機制上的多種問題，⽽TiDB 可說根治性地解決了這些問題，這也是我們希望換代的關鍵理由之⼀。

 

存儲成本有優勢

TiDB 和傳統數據庫在存儲硬件選型上沒有太⼤區別，基本我們⼀般都是使⽤ SSD。那麼存儲成本可以這樣來對比估算。

以⼀塊單獨的 SSD 磁盤爲最⼩單位，MySQL 模式即便是最⼩冗餘⼀份的前提下，我們也會有 4 塊磁盤，⽽ TiDB 這邊由於⾼度的⼀致性保障，我們可以磁盤就不做 raid1 了，這樣最⼩單位雖然是三副本，但實際投入是 3 塊磁盤。也就是⾄少節省 25% 的空間。

 

進⼀步地，TiDB 相較 MySQL 還有另外⼀個優化點，MySQL 的 innodb 由於歷史原因，我們並沒有⼴泛採⽤壓縮格式，⽽ TiDB 的 RocksDB 存儲引擎默認是壓縮的。雖然 kv 邏輯上有着較⼤區別沒有辦法直接比較，不過總歸來說，壓縮總是可以⼀定程度上節省空間的。

 

根據我們具體測試量化來看，TiDB 壓縮相較 MySQL 非壓縮情況下根據業務數據不同，差距很⼤。比如 sysbench 類隨機字符串⽆意義數據，壓縮比例不⾼，

5 億68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441
這種類似的隨機字符數據 innodb 114G，⽽ TiDB 102G。

 

但是如果是有⼤量數字，浮點，時間戳，有意義短單詞的實際業務數據對比，如果數字特別多，壓縮比例⼜非常驚⼈,

非壓縮的 innodb 要 398G，而 TiDB 不到 30G。所以還是要看數據類型，雖然並不是壓縮比⼀定非常⾼，但是肯定比 innodb 非壓縮情況要好。根據我們實踐經驗保守來看，壓縮節省比 例來看綜合在 30%~50% 左右。

 

這樣 25% 的 raid 節約，結合 30% 以上的壓縮節約，綜合起來我們可以認爲 MySQL 換 TiDB 存儲上可以有 35~50% 左右的存儲硬件成本節約。這對存量預增的業務顯然也有⼀定的意義。

 

另外順便提⼀下， 在新型（其實也沒那麼新， 只不過我們⽤的不算多）硬件， 例如 NVMe 存儲設備⽅⾯， 由於 PCIE ⽆法再接 raid 了， 因此天然適合 TiDB 這樣軟件層強⼀直冗餘， ⽽完全放棄 raid 硬件層冗餘的模式。

 

HTAP 創新模式

以上可能都是 1 到 1.1 的改進，HTAP 應該算是 0 到 1 的⼤型場景創新了。我們強烈地希望 TiDB 相關特性能在⽹易發揮業務價值。

 

傳統數據庫我們通常認爲有 MySQL 這樣的純 OLTP 數據庫，由於⾏存，優化器功能侷限，沒有 MPP 引擎，中間件功能有限，資源利⽤率⼀般……等多種技術原因，是完全跑了不 了 OLAP 分析請求的。也有 Clickhouse 這樣專注 MPP 和資源利⽤率，但寫多⼏個併發或 SQL 沒有批量就有穩定性⻛險，完全跑不了 OLTP 請求的。可謂涇渭分明。

在我們當前絕⼤部分當前業務場景下，都是類似上圖，都需要從 OLTP 系統將數據錄入專⻔負責處理 ad-hoc 類分析的在線 OLAP，以及專⻔處理任務式計算的離線數倉。雖然圖看的很簡單，但是其中利⽤到的技術棧相當龐雜，在⽹易內部數科團隊，DBA 團隊，業務算法團隊，中間件研發團隊等多個團隊全拴在這⼀個鏈路上，可以說是技術含量最⾼的業務鏈路之⼀。在業界相信很多公司也是類似的情況。

 

• OLTP 部分主要就是 MySQL 及其分佈式中間件。

• pipline 環節通常也可能是有邏輯過程的 ETL 環節，技術棧可能有定期批量的 sqoop 或 datax ⽅式，實時的 CDC（內部是 NDC）方式，處理過程中爲了進⾏清洗和邏輯過濾等需求，還得⽤上 kafka 等隊列和業務代碼。

• OLAP 光處理 ad-hoc ⽅⾯⽬前我們就有 Oracle，greenplum，clickhouse，kudu+impala，presto 這⼀堆技術棧；其他 SQL 引擎如 doris，keylin，druid，hive 都有應⽤; 如果流式需要還有補上消息隊列，flink，spark 等; 離線任務側 yarn，spark……

上圖來自小米的技術分享 ， 你會發現這⾏業就是以羅列技術棧和鏈路架構爲樂， 這個現狀是業界主流。在我的角度（包括其他參與團隊的角度）來看其實挺有意思的，⼤數據嘛，多⾼⼤上，⽽且技術上確實也有必要性，⼤數據確實需要適才適⽤。但是其實也是有⼀些顯⽽易⻅的痛點的:

 

• ETL 過程時效性與數據⼀致性。

• 邏輯上的變更往往也是難點，⽆論是服務架構，存儲⽅式，或是最上游表結構變更，都需要鏈路上⼤量改動⽀持。

• 服務技術棧特徵是典型的多、專、深，依賴⼤量富有經驗的研發和運維投入。

• 投入資源較⾼，中間過程和存儲都是如此，如果需求需要多種技術棧才能滿⾜要求，則投入成倍增⻓。

• 架構和團隊複雜化帶來的⼀些效率問題。

 

業界也有數據庫不斷在兼容 OLTP 和 OLAP 兩種模式間探索，前有 Oracle 內置 MPP，後有 kudu 嘗試兼容 OLTP。⽽ TiDB 依靠其特有的⾏列雙存儲技術特點，似乎走在了更加合理的道路上。

TiDB 提出的⽬標是 100% 的 OLTP 和 80% 的 OLAP 場景，我不敢說這個⽬標是否切實，但是現狀來看替代上述龐雜的 ad-hoc 分析需求中的⼀部分技術棧應當是合理的⽬標。TiDB 的技術⽅案也在短短的⼏年內也是經過⼀次重⼤迭代的，19 年以前的單純的 TiSpark ⽅案實際上適⽤性⼀般，但是當前結合了 TiFlash 列存存儲的⽅案則真的是走出了⾃⼰的特⾊。

簡單來說我們之前談到過 TiDB 底層是有 TiKV 中的 kv 數據模擬⾏表 OLTP 數據庫， TiKV 的寫入則是通過 raft 協議和⽇志同步保證了多副本⼀致性， 那這個思路下同樣可以通過⼀致性寫入的⽅式完成⾏存 TiKV 和列存 TiFlash 存儲的數據同時寫入， 這樣 TiSpark OLAP 引擎和 TiDB OLTP 引擎可以在完全⼀致， 但存儲異構的兩種數據源間⾃由選擇訪問⽬的，我們知道列存對於 OLAP 本⾝就是極⼤的提升，加之研發團隊在相關領域的其他專業優化，⼀個真正在存儲和計算層同時做到既保證數據⼀致，又能適才適⽤的 HTAP 數據庫⽅案就出現了。

 

這⼀架構有⼀些顯著的優勢:

 

• 架構簡單緊湊，管理和實施⽅案非常完善，且 TiFlash 功能的啓⽤很靈活，業務任何階段都可以調整，任何線上表可以不開啓節約成本，可以隨時開啓⽀持新增分析需求。

• 集羣實施成本也從 HDFS 級別縮減到了正常數據庫級別，你不⽤非得⼀下⼦找⼗⼏臺來搞最⼩線上部署，按需投入資源即可。

• 分析⽤數據從表結構到內容基本同在線表完全⼀致，如果分析需求就是需要基於在線結構，那麼直接寫 SQL 即可，可以完全省下同步環節相關的資源和維護開銷。當然客觀來講，ETL 當然還有 T 的需求。

• 優化器⽀持，查詢到底走哪種形式可以通過⾃定義，也可以交給優化器判斷，⼀定程度上把純粹 SQL 暴露做的更徹底，業務可以更簡單地實現需求。

• OLAP 部分非常專業的深度優化，例如 TiSpark 可藉助類似 clickhouse 的向量化引擎，按照和 TiKV 相同的 coprocessor 協議下推任務到 TiFlash，提升資源利⽤和性能。

• 擴展與 TiKV ⼀樣容易。當然除了⼀⼩部分 (點名 clickhouse) 外的⼤部分分佈式⼤數據集羣⽅案在這⽅⾯還是可以的。

 

我們在公司內部有⼀些實踐，隨後會做簡單介紹。同時我們也並不指望 TiDB 的 HTAP ⼀下⼦能起到多⼤作⽤，只是希望在⼀些特定場景下提升服務能⼒，並簡化架構，提升效率:

 

• 替代現有相對老舊的 Oracle 和 GreenPlum 技術，主要是 roll up 類可能有些麻煩，但是絕大部分聯表類肯定是可以的。GreenPlum 還好，Oracle 以我們現在的硬件條件，擴容都很困難

• 解決一些不合適的 SQL 直接在 MySQL 或者 DDB 集羣裏跑的問題，讓 OLAP 處理效率合理化，促進更多數據分析能力和需求

• 如下圖，部分替代 Impala on Kudu 和 Presto on HDFS。數據都來自線上導入，就可以嘗試所見鏈路，提供更標準的 SQL 入口應該有的吸引力。

 

TiDB 內部實踐

適⽤場景推薦

由於並不是分佈式⽅案唯⼀選擇，所以 TiDB 嚴格來說對我們有比較確定的適⽤場景，我們總結如下:

 

• 有明顯淡旺季，週期性，需要⾼峯保障類型的業務

• 如電商有促銷活動的場景，如⼀些業務專⻔⽀持臨時活動的模塊，如有顯著週期性的教育類業務等，可以充分享受靈活擴縮容的優勢。

• 對⾼可⽤和數據⼀致性需求特別強烈的業務

• 記賬對賬，消費憑證，外部⽀付回調等，⾼可⽤和⼀致性較⾼⽔平的保障能夠幫助業務儘可能提⾼可靠性。

• 公有云上由於資源可靠性不如內部機房，如果未使⽤ RDS，可以嘗試 TiDB。

• 核⼼模塊兩地三中⼼⽅案

• TiDB 提供⼀種非常有針對性的兩地三中⼼實施⽅案， 參考: https://docs.pingcap.com/zh/tidb/stable/three-data-centers-in-two-cities-deployment。意味着同城機房做跨機房的實時⾼可⽤冗餘切換，異地機房提供⼀份非常可靠的最終數據冗餘兜底。這⼀場景可以活⽤於重要性⾼的系統元數據，比如私有云服務元數據，像內部對象存儲元數據這塊再合適不過了，極⼤規模的關鍵數據，還能充分利⽤快速⽔平擴展的能⼒。

• 對 HTAP 有需求的業務

• 前⾯提過，如果對任何線上數據有分析查詢需求，完全可以嘗試不再使⽤傳統導數據流程，使⽤ TiDB 單系統內搞定。

   

但是，由於我們的⽬標還是把 TiDB 儘可能地引入核⼼數據庫選型，因此我建議⽬前對 TiDB 感興趣的業務不⽤太拘泥於必須是完全匹配的場景。能⽤上匹配場景當然是最好，如果並不確定適⽤性質，那隻要:

 

• 計劃使⽤ MySQL/DDB， 但也對 TiDB 非常感興趣

• 確實遇到存量⼤變更擴容難痛點

• 單純想嚐鮮⼀下

• 想要降低存儲和運維成本的

• 想要學習分享新技術的

 

都可以積極嘗試⼀下。保險考慮，無論是何種新技術的嘗試，那種⽤途相對單⼀或邊緣，但是業務和存量數據⼜相對⼤的場景作爲起步肯定是最好的。

 

技術遷移和配套⽀持⽅案

使⽤ TiDB 與其他原有數據庫的區別：

 

• 業務使⽤ TiDB 主要考慮 SQL 兼容和客戶端連接⽅案。

• 如果是⾃研系統，業務在⽹易內部習慣於使⽤ MySQL 或公私有云的 RDS，⽽非使⽤ DDB，那麼 TiDB 使⽤上和過去項⽬沒有任何差異，使⽤普通驅動和連接池，更新數據庫地址即可。以我的經驗中，TiDB 不⽀持的 SQL 功能我們正常研發也基本不會⽤到。

• 如果要作爲其他開源系統的底層元數據存儲，可能要考慮下 SQL 兼容性，因爲業界使⽤ SQL 的複雜程度有較⼤區別，我們⻅過⼀些國外開源項⽬ SQL 使⽤深度比較複雜的情況。

• 如果過去習慣使⽤ DDB，是 DBI 也就是特有驅動模式的，需要更換爲 jdbc 驅動，並增加連接池，因爲 DBI 客戶端是內置連接池，jdbc 沒有。

• 替換 DDB 的 SQL ⽅⾯⼤致沒有問題，TiDB ⽀持是 DDB 的⽗集。需要注意的主要是 DDB ⼀些老式的唯⼀ ID 分配模式，要替換爲 MySQL 兼容類型，例如隱式分配等。

• 如果過去習慣使⽤ QS 代理⽅⾯模式連接 DDB， 使⽤了 LBD 的要去掉 LBD， 改成正常 jdbc 連接⽅式即可。過去使⽤ QS 但未使⽤ LBD 模式 (比如 NLB 模式) 的不需要做任何修改。

 

TiDB server 分佈式集羣⼊⼝訪問

由於我們知道 TiDB server 是⼀組⽆狀態的計算節點，過去的 MySQL 類數據庫我們都會提供⼀個唯⼀的入⼝，例如是虛擬 IP，域名或 DDB master 地址等形式，業務不需要關 系後端服務的漂移切換等細節。TiDB 這邊的 TiDB server 對外暴露服務。我們可以選擇如下⽅案：

 

⽅案⼀，傳統 HAProxy，LVS 等負載均衡軟件，配合 VIP，域名等切換資源，這是最常⽤的⽅案。

 

該⽅案的主要問題是負載均衡代理程序⾃⾝⾼可⽤如何保障，逐級堆疊很可能最後堆到 OSPF 去了。不過⽬前依然是最簡單最可靠的接入⽅式，推薦使⽤。

 

⽅案⼆，採⽤原⽣ MySQL jdbc 驅動的 multi-host 配置⽅法，該⽅案在連接數據庫的時候採⽤如下的寫法:

static final Srting DB_URL = "jdbc:mysql:loadbalance://10.170.161.65:4121,10.200.166.102:4121/zane?useSSL=false&failOverReadOnlly=false";

 

也就是⼀次性連接提供的多個 TiDB server 服務。經過測試，可以實現多個 TiDB server 間的負載均衡和⾃動排除故障節點與連接恢復，詳情請參考上述鏈接。主要問題是 TiDB server 列表如果發⽣改動，例如擴縮容或遷移，業務就需要修改鏈接並重啓，會很⿇煩。

 

⽅案三，由於 TiDB server⽆狀態的良好特性，我們將 TiDB server 集羣移植到了 K8s 內，作爲⼀個 service 對 K8s 內外進⾏服務。

⽆狀態 TiDB server 的 K8s 化非常順利與合適，通過 Ingress 的⽅式也可以提供 K8s 外業務訪問的能⼒，相關準備和驗證⼯作都已經完成。我們最終的⽬標肯定是 TiDB 的完全雲原⽣化，⽬前部分雲內部分雲外的⽅案只是穩定性考慮的過渡模式。

 

綜合來說，三個⽅案都可⽤，我們會根據實際情況和業務討論確定具體使⽤哪種模式。

 

監控與其他運維⽀持

從 DBA 的角度來看，TiDB ⽬前有着較完善的監控機制與配套⼯具，並且完全基於業界同⾏的開源技術，因此我們⽬前也不打算再像傳統數據庫那樣爲它再重新做⼀套採集腳本與展⽰界⾯，⽽是直接復⽤原⽣的⽅案。

TiDB 各組件（除了圖中⼏個主要服務外， 其他⽇志⼯具， 管理⼯具等配套⼯具都包括）均提供標準的 Prometheus 數據接⼝， 監控服務採⽤原⽣ Prometheus 拉取模式即可；另外 Grafana 有針對 TiDB 的完整模板， 並且區分度⾼， 同時數據邏輯聯繫強， 屬於經過實踐的⾼度有效模板。因此後續我們對 TiDB 監控展⽰和告警將直接使⽤原⽣⽅案， ⽽不 會遷移到哨兵或其他⾃建系統。並且報警系統對接當前 popo 或內部電話告警等接⼝也調試可⽤。

 

除了監控外，TiDB 作爲數據庫其他基本監控需求，包括不限於: 備份恢復，擴縮容⽀持，⾃動化集羣操作⼯具，⽇志處理⼯具，數據導入導出，集羣配置修改管理，版本滾動升級……等等，均有針對性⼯具，最可貴的是 TiDB 社區非常重視 SOP ⽂檔⼯作，讓社區經驗能夠轉化爲實踐指導，這在開源數據庫是非常難得的，同時我們內部也經過充分演練。我們團隊與 PingCAP 的⽀撐和⼯具研發團隊接觸也較多， 深刻體會到 PingCAP 相關研發和社區⽀持同學都是資深 DBA， 對數據庫使⽤過程中的需求和難點有着非常深刻地認識與⼤量實踐經驗，因此相關產品⼯具也相當實⽤，且相對其他開源項目可靠。

 

進⼀步地，內部⽇常使⽤中⼀些常⽤點，例如 OWL 的⽩屏數據訪問能⼒，以及⽇常變更的⾃動化⼯單⽀持能⼒均已準備就緒，經過線上驗證。業務⽇常使⽤過程中應當不會感受到 TiDB 與其他 MySQL 數據庫的差異。

結論上看，我們認爲從運維⽀撐能⼒上，TiDB 也完全具備在內部推⼴的各項條件。

 

現有業務遷移⾄ TiDB ⽅案

新上業務比較容易，但是針對已有數據和應⽤的業務將現有服務前移到 TiDB 上就是相對有難度的事情。除了上述⼀些接入⽅式和 SQL 適應性可能需要做⼀些改造，應⽤代碼需要修改發佈外，主要就是存量數據如何從 DDB 或 MySQL 錄入 TiDB 了。⼏個考慮點:

 

• 我們肯定不希望採⽤⻓期停服（⾄少停寫）的遷移⽅案， 最好數據能實時同步

• 並且肯定要考慮可隨時回滾應⽤以起到回滾數據庫的⽬的，因此要保證切換到 TiDB 後的增量數據還得實時迴流原數據庫集羣，實現隨時回滾切換回數據源的⽬標。

• 要有⼀定的灰度發佈空間，以驗證業務對 TiDB 的連接和使⽤是否可⾏。

 

經過⼀些內部實踐，我們充分利⽤了內部現有⼯具和 TiDB 配套⼯具，相關需求⽬前都是可⾏並且得到⼀定經驗驗證的:

我們通過⽀持 DDB 分佈式集羣和 MySQL 單體集羣的內部 CDC ⼯具 NDC 同步全量數據⾄⽬標 TiDB 集羣，並保持增量數據的持續實時同步。再通過 TiDB 提供的 TiCDC 訂閱 TiDB ⽇志，同步到 MySQL（使⽤ blackhole 引擎，僅做⽇志中轉）再通過標準 NDC 同步回 DDB。這樣就實現了⼀個雙向實時複製的⽅案。

 

NDC 是⽹易內部⾃研的多數據源遷移和 CDC 平臺，可以類比 xdata+canal 的平臺化產品

 

業務遷移的時候可能的步驟是:

 

• ⽬前兩個數據源雙向同步核⼼問題是沒有衝突解決和循環複製解決機制，因此⽆法實現全⾯的雙寫，應當保持單數據源單寫，這樣⽅案就是安全的。也是業務遷移步 驟最關鍵考慮點。

• ⾸先準備好 DDB->TiDB 的實時同步，直到數據⼀直追上。⾄此並不開啓 TiDB->DDB 的反向鏈路。

• 如果可能，業務灰度發佈只讀業務⾄ TiDB，驗證服務可⽤性。

• 正式發佈切換在低峯期，業務 DDB 集羣禁寫，同時暫停 DDB->TiDB 鏈路，開啓 TiDB->DDB 反向鏈路，業務發佈 TiDB 數據源版本。服務不可寫時間僅發佈期間。

• 如果上⼀步順利，則線上迴歸應⽤後遷移基本成功。

• 如果切換數據源後發現任何問題，確定要回滾應⽤和數據源解決，由於反向鏈路保證 DDB 同 TiDB 數據⼀致，因此 TiDB 禁寫，DDB 開寫，應⽤回滾即可。

 

另外，同⼀些業務溝通過程中我們發現，⽬前線上有⼤量數據 ETL 或消息總線是依賴 DDB/MySQL 的 binlog 訂閱的，因此 NDC 兼容 TiDB 也是必須的，我們採⽤與切換相同⽅案:

我們會先將 TiDB ⽇志通過專⽤⼯具回放⾄⼀箇中轉 MySQL，再⽤ NDC 訂閱，保證原有數據鏈路基本不變。

 

近期 TiDB 相關業務應⽤情況簡介

這次我們的技術推⼴實踐並不是劃劃⽔，⽽是真的期望 TiDB 能爲數據庫技術和使⽤效率帶來⼀些質變。TiDB 近期已經或者即將上線在網易支付、網易雲音樂的多個業務模塊中，TiDB 的 HTAP、秒級 DDL、擴速擴縮容等能力也將不斷提升用戶體驗。

 

總體來說，TiDB 在⽹易內部的運⽤還處於起步階段。⻓期以來我們⼀直苦於在兩個問題上糾結，⾸先是 "有了 DDB 爲什麼還需要新的分佈式系統" 以及 "HTAP 在哪些業務有價值"。經過⼀些探索和努⼒推⼴，這兩個問題的認識上我們有了⼀些進展，也因此有了本⽂。希望我們近期的⼯作能夠起到拋磚引⽟的作⽤，把數據庫技術發展帶來的能⼒ 提升真正落實到業務實際需求中去，提升⽹易數據庫服務和能⼒⽔平。也歡迎對 TiDB 相關技術感興趣的團隊與同學能夠與我們 DBA 組保持積極溝通，⼤家⼀起來推動相關技術驗證與應⽤。