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

PingCAP發表於2021-12-09
TiDB

title: 網易雲音樂 DBA 談 TiDB 選型：效率的選擇
author：倪山三
date: 2021-12-03
summary: 本文摘自由網易 DBA 團隊撰寫的《效率的選擇——分散式資料庫 TiDB 網易內部選型介紹》一文，對比了以 TiDB 為基礎的創新架構和 MySQL + DDB 傳統架構的差異，從業務適配、降本增效、技術創新等多個維度闡釋了網易考慮引入 TiDB 的原因。

tags: ['TiDB']

編者按

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

​

作者倪山三（hznishansan@corp.netease.com），網易資料庫專家，杭研資料庫運維團隊負責人。

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 隨著版本完善的過程中，我們也不得不為了規避某些情況堅持使⽤外部變更⼯具。

    1. 由於穩定性⻛險， 雖然 online DDL 並不會如傳⾔所說鎖表時間同增量更新有線性關係， 但是依然有其他⽅⾯的⻛險， 例如我們不太遠的過去遇到過 online ddl 中 inplace 算 法 要 求 刷 髒 導 致 寫 負 載 型 數 據 庫 卡 頓 影 響 穩 定 性 的 ⻛ 險 （想 了 解 的 同 學 可 以 參 考 : http://www.percona.com/community-blog/2020/04/23/unexpected-slow-alter-table-mysql-5-7/）。我們已經在哪種情況使⽤哪種⽅式做了非常多的策略判斷了， 多年嘗試， 實在難以根據每個特定業務場景做出完全可靠的智慧策略，有時候為了避免不必要的⻛險，不得不依然依靠業界⼴泛使⽤，⼴受考驗的外部⼯具繼續做為統⼀變更⼿段。
    2. 由於不確定性⻛險，我們⾃研運維平臺⾃動化處理的資料庫⼤⼤⼩⼩變更⼀年接近⼗萬量級， 如果說⼀種每天都在頻繁使⽤的核⼼功能其成功率要依照⼀個預設 128MB，實際不知道多⼤合適的引數的限制，在部分業務場景會經常遇到 RROR 1799 (HY000): Creating index 'idx_xxx' required more than'innodb_online_alter_log_max_size' bytes of modification log…… 類問題，不但失敗還要浪費⼤量資源進⾏回滾的。這個功能是⼀個可靠的功能嗎?
    3. 實際上在業界對 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 組保持積極溝通，⼤家⼀起來推動相關技術驗證與應⽤。

相關文章