TiDB 實踐 | 京東物流在云數(shù)據(jù)庫上的選擇和實戰(zhàn)

本文介紹了京東物流從 MySQL 到 Cloud-TiDB 的應(yīng)用實踐及未來規(guī)劃。TiDB 不僅解決了京東物流在 MySQL 架構(gòu)下遺留的“快、慢、煩”三大問題，更帶來了意外的驚喜：按兩年為周期計算，IT 成本將下降到原來的 1/3。TiDB 在部分業(yè)務(wù)系統(tǒng)的應(yīng)用帶來的成本改善和效率提升，已經(jīng)成為集團(tuán)內(nèi)部的標(biāo)桿案例。預(yù)計到 2021 年年底，京東集團(tuán)內(nèi)部使用 TiDB 的規(guī)模會再增長 100%。

隨著京東業(yè)務(wù)發(fā)展的快速發(fā)展，數(shù)據(jù)量的增長也越來越快，帶來了幾個方面的挑戰(zhàn)：第一，快。業(yè)務(wù)增長快、數(shù)據(jù)量增長快，系統(tǒng)頻繁需要擴(kuò)容，每次擴(kuò)容都比較麻煩，從資源申請的流程到風(fēng)險評估，預(yù)案的準(zhǔn)備以及跟業(yè)務(wù)方的溝通等，給我們的架構(gòu)師帶來了不少麻煩。第二，慢。隨著數(shù)據(jù)量的增加以及業(yè)務(wù)復(fù)雜度的上漲，SQL 查詢的效率變得越來越低，研發(fā)需要持續(xù)不斷地對系統(tǒng)進(jìn)行優(yōu)化，這給研發(fā)也造成了比較大的壓力。第三，煩。為了解決數(shù)據(jù)量的問題，不少系統(tǒng)采用了分庫分表的方式，但是這種架構(gòu)運維比較繁瑣而且容易出錯，這個時候，運維踩雷可能性就急劇地上升了。

隨著業(yè)務(wù)和數(shù)據(jù)量的不斷增長，給架構(gòu)師、研發(fā)和運維都帶來了各種各樣的挑戰(zhàn)，我們也探索了一些業(yè)界主流的方案，比如說像分庫分表。分庫分表通常只適用于一些比較簡單的業(yè)務(wù)，對業(yè)務(wù)的侵入性以及改造成本比較高，使用場景也比較受限，比如難以支撐跨分片的查詢，一些復(fù)雜 SQL 不支持等，而且大型集群的運維比較困難。

在一些分析和查詢的場景，我們還嘗試使用了 ElasticSearch 和 ClickHouse。這兩種方案都需要把數(shù)據(jù)從交易庫 MySQL 里面同步過來，還需要對業(yè)務(wù)進(jìn)行代碼改造。除此之外，還存在一些其他的限制，例如 ClickHouse 不支持事務(wù)且并發(fā)低等。 

京東云聯(lián)合集團(tuán)內(nèi)部各個業(yè)務(wù)團(tuán)隊的專家進(jìn)行了調(diào)研和分析，最后我們和 PingCAP 展開了深度合作，聯(lián)合推出了云上的分布式數(shù)據(jù)庫—— Cloud-TiDB，提供京東云上的 TiDB 服務(wù)。京東云上的 TiDB 服務(wù)主要有以下三個特點：一鍵部署、一鍵擴(kuò)容和多維監(jiān)控告警。

• 一鍵部署是指在創(chuàng)建集群的時候，可以自定義節(jié)點的規(guī)格、節(jié)點的數(shù)目，同時也支持 TiFlash，還可以在線的升級數(shù)據(jù)庫版本，這些操作都是通過鼠標(biāo)的點擊，很輕易地完成。

• 一鍵擴(kuò)容是說無論是 TiDB、TiKV 還是 TiFlash 節(jié)點，均可在線的水平增加節(jié)點的數(shù)目，提升整個集群的容量和處理能力，而且整個擴(kuò)容過程，幾乎是無感知的，對業(yè)務(wù)毫無影響。

• 多維監(jiān)控告警是指我們將云上的云監(jiān)控，和 TiDB 的 Grafana 和 Dashboard 有機(jī)地結(jié)合，進(jìn)一步幫助我們的開發(fā)、運維人員更好地使用 TiDB。

總而言之，對于用戶來說就只管使用，其他的都可以交給京東云來處理。

我們選擇 Cloud-TiDB 作為京東一些海量業(yè)務(wù)的支撐，主要是基于以下幾方面考慮：

• TiDB 采用的分布式架構(gòu)支撐海量數(shù)據(jù)擴(kuò)展，可以有效地解決單機(jī) MySQL 容量和性能的瓶頸問題。

• 最重要的一點，TiDB 與 MySQL 兼容性非常好，遷移成本很低，接入周期短，收益見效快。

• TiDB 提供金融級可靠性，運維簡單便捷。

• 支持在線擴(kuò)容和在線 DDL，業(yè)務(wù)幾乎無感知。

• 數(shù)據(jù)具有強(qiáng)一致性，支持事務(wù)，使用場景不受限制。

下面我們來看一下京東實際的一個案例，這個是物流業(yè)務(wù)跟一些費用相關(guān)的系統(tǒng)，這個系統(tǒng)的數(shù)據(jù)量比較大，我們能夠看到它的幾個主表的數(shù)量分別是 20 億、50 億和 100 億，系統(tǒng)上線了半年后數(shù)據(jù)翻倍到了 220 億。因為數(shù)據(jù)量比較大，所以在最開始的時候，采用的就是基于 MySQL 的分庫分表架構(gòu)。在運行了一段時間之后，分庫分表的架構(gòu)就遇到了我們所說過的一些問題，比方說一些復(fù)雜的 SQL 不支持，一些跨分片統(tǒng)計報表難于實現(xiàn)等等。經(jīng)過調(diào)研、測試之后，我們決定把這個數(shù)據(jù)庫從 MySQL 切換到 TiDB。

遷到 TiDB 之后，整體的性能表現(xiàn)比較優(yōu)秀，寫入和更新的效率在 100 毫秒左右，查詢和 Sum 查詢只有 20-30 毫秒。大家可以猜一下，一個幾百億數(shù)據(jù)量的系統(tǒng)從 MySQL 遷移到 TiDB，需要修改多少代碼？實際業(yè)務(wù)代碼是零修改的，系統(tǒng)只是更換了 JDBC 連接的用戶名和密碼，真正地實現(xiàn)了從 MySQL 到 TiDB 的零代碼修改和無縫遷移。TiDB 和 MySQL 良好的兼容性讓我們在使用 TiDB 的時候，試錯、測試和遷移的成本比較低，而且收益的周期也非常短，見效快。

除此之外，遷移到 TiDB 還給了我們一個意外的驚喜，我們做了一個評估，如果按兩年的周期計算，TiDB 的使用成本僅為 MySQL 的 37%。為什么這么說？因為 TiDB 對數(shù)據(jù)的壓縮率非常好，這是當(dāng)時測試的結(jié)果，在 MySQL 里的數(shù)據(jù)占到 10.8 T，遷移到 TiDB 之后只有 3.2 T，而且這 3.2 T 還是三副本的總數(shù)據(jù)量。所以，MySQL 與 TiDB 的空間使用比是 3.4:1。

原先的架構(gòu)是一個四分片的 MySQL 集群，按照目前數(shù)據(jù)增長的速度，大概是每六個月就要進(jìn)行擴(kuò)容，每次要擴(kuò)四套主備實例。TiDB 按實際需要擴(kuò)容就行了?？梢钥吹皆诘?24 個月的時候，MySQL 有 32 個節(jié)點，TiDB 只有 14 個節(jié)點，使用的 CPU 核數(shù) MySQL 是 512 個，而 TiDB 只要 200 多個，不到 MySQL 的一半。在存儲空間上，TiDB 更是只有 MySQL 的 1/3。所以說，TiDB 帶給我們的驚喜就是幫助我們整個業(yè)務(wù)部門極大地降低了 IT 的投入成本。

第二個案例是京東物流大件分揀的業(yè)務(wù)系統(tǒng)。以前這個系統(tǒng)的一些實時看板和核心報表都是跑在 MySQL 上。隨著數(shù)據(jù)量增加，而且 SQL 比較復(fù)雜，報表和看板的性能比較低，用戶的體驗不是特別好。當(dāng)時我們也嘗試過分庫分表的方式，但是這種方式對代碼侵入性比較大，架構(gòu)需要大幅調(diào)整，風(fēng)險比較高。

最后，我們選擇了 TiDB 支撐業(yè)務(wù)的實時看板和核心報表。在 MySQL 和 TiDB 之間，用我們自研的蜂巢系統(tǒng)進(jìn)行數(shù)據(jù)的準(zhǔn)實時同步。從右下角的監(jiān)控圖可以看到，從 MySQL 遷移到 TiDB 后，總共數(shù)百個指標(biāo)，整體性能提升了 8 倍。

第三個系統(tǒng)是京東物流的運單計提明細(xì)系統(tǒng)，主要是記錄部分運單的明細(xì)數(shù)據(jù)，每天的數(shù)據(jù)增長大概在千萬級別，單表最大記錄接近 200 億條。很顯然，這樣一個數(shù)據(jù)量用 MySQL 是很難支撐的。我們曾經(jīng)嘗試使用 Presto，其性能和容量都還可以，但對我們來說使用成本比較高，所以后來使用 ElasticSearch 來做查詢工作。ElasticSearch 存在著不穩(wěn)定的情況，由于業(yè)務(wù)的特性，例如計費項經(jīng)常需要調(diào)整意味著表結(jié)構(gòu)的變化，所以維護(hù)的工作量很大。

把這個業(yè)務(wù)系統(tǒng)遷移到 TiDB 之后，首先解決了海量數(shù)據(jù)的問題，TiDB 可以毫無壓力地支撐百億級的數(shù)據(jù)量。其次，TiDB 成本比起以前使用的 MySQL + ElasticSearch 方案降低了 30%。此外，TiDB 性能也滿足業(yè)務(wù)的要求，從百億的單表里面查詢出業(yè)務(wù)數(shù)據(jù)的 TP99 大概在 500 毫秒左右。還有一點比較重要，TiDB 整個表結(jié)構(gòu)的調(diào)整修改操作非常簡單，給我們帶來了運維敏捷和成本下降。

京東物流使用 TiDB 的收益主要體現(xiàn)在成本、效率和體驗三大方面。TiDB 幫助我們降低了 IT 系統(tǒng)的投入成本和運營成本，成本降低之后，就意味著這個系統(tǒng)的架構(gòu)師有了成績，業(yè)務(wù)性能的提升可以極大地改善用戶體驗。研發(fā)也不再需要成天優(yōu)化系統(tǒng)了，可以早點回家去過自己的二人世界了。運維效率得到了極大的提升，運維同學(xué)就不再需要經(jīng)常熬夜去支持系統(tǒng)運維了，可以把精力投入到其他更有價值的業(yè)務(wù)中去。不熬夜之后，我們的頭發(fā)也可以少掉幾根。

目前京東集團(tuán)在云上已經(jīng)使用了數(shù)十套 TiDB 系統(tǒng)，支撐了集團(tuán)多個 0 級業(yè)務(wù)系統(tǒng)，0 級業(yè)務(wù)系統(tǒng)是指如果這個系統(tǒng)發(fā)生故障超過 30 分鐘就要上報到 CEO，所以說 0 級業(yè)務(wù)系統(tǒng)屬于京東的關(guān)鍵業(yè)務(wù)系統(tǒng)。這幾十套 TiDB 系統(tǒng)都經(jīng)過了京東 618 大促的嚴(yán)格考驗，期間沒有發(fā)生過任何故障，性能也很平穩(wěn)。同時，TiDB 在部分業(yè)務(wù)系統(tǒng)的應(yīng)用帶來的成本改善和效率提升，已經(jīng)成為集團(tuán)內(nèi)部的標(biāo)桿案例。我們預(yù)計到 2021 年年底，京東集團(tuán)內(nèi)部使用 TiDB 的規(guī)模會再增長 100%，總 CPU 核數(shù)將超過 10000 核。

除了 TiDB 之外，市面上還有一些其他的分布式數(shù)據(jù)庫，我們在當(dāng)初選型的時候，也做了一些對比。從集群規(guī)模來看，TiDB 可以支持?jǐn)?shù)百個節(jié)點，而其他的分布式數(shù)據(jù)庫大都是 1 主 15 從，共支持 16 個節(jié)點，從節(jié)點規(guī)模上來說就差了一個數(shù)量級。從讀寫的擴(kuò)展上看，TiDB 是一個多活架構(gòu)，其所有對外提供服務(wù)的 TiDB 節(jié)點都是可以讀可以寫的，都是對等的，而其他產(chǎn)品多數(shù)只有主節(jié)點可以寫，從節(jié)點只能提供讀的能力，寫還是和以前 MySQL 一樣受限于單機(jī)能力，沒法得到提升。從數(shù)據(jù)容量上來看，TiDB 可以達(dá)到 PB 級的數(shù)據(jù)量，而其他數(shù)據(jù)庫都是在 100 TB 左右。除此之外，TiDB 支持實時數(shù)據(jù)分析，而其他的數(shù)據(jù)庫不具備這個能力。TiDB 的備份效率會稍低一些，希望 TiDB 今后在這方面有更多的提升。

最重要的是 TiDB 是一個開源的產(chǎn)品，不會被某個云廠商所綁定，基于 TiDB 用戶可以很輕松地實施多云戰(zhàn)略，可以把 TiDB 部署在任何一個云上，不受到任何的綁定。如果你用得不爽了，直接換個云就行了，不像以前很多企業(yè)都是用 Oracle 數(shù)據(jù)庫，現(xiàn)在想換也換不了，非常痛苦。

接下來分享一下我們在 TiDB 使用過程當(dāng)中的一些實踐經(jīng)驗。

第一個是查詢計劃的改變，這是一個比較常見的情況，以前在 MySQL 有一些比較好的 SQL，在 TiDB 里面使用性能有一些問題，需要進(jìn)行逐個地分析和優(yōu)化，通過加一些索引以及查詢計劃，最后都可以得到解決。第二個就是自增主鍵容易引起熱點數(shù)據(jù)，可以通過使用 AUTO-RANDOM 來解決。第三，在 TiDB 的默認(rèn)配置參數(shù)中，在大數(shù)據(jù)量下新建索引的時候，tidb_ddl_reorg_worker_cnt、 tidb_ddl_reorg_batch_size 兩個參數(shù)配置比較小，我們可以調(diào)大一些，在重建索引的時候，性能可以得到比較大的改善。第四，TiDB 默認(rèn)是嚴(yán)格區(qū)分大小寫，而 MySQL 默認(rèn)是不區(qū)分的，我們只能在數(shù)據(jù)庫集群初始化的時候進(jìn)行配置，后面修改不了。最后就是 SQL Mode，如果在 MySQL 中使用了一些特殊的 SQL Mode，遷移到 TiDB 中的時候，有些 SQL 可能沒法正常執(zhí)行，只需查看當(dāng)前使用的 MySQL 的 SQL Mode 并直接替換就可以。

最后，結(jié)合我們的使用經(jīng)驗談?wù)剬?/span> TiDB 的期望。首先，我們希望單個 TiKV 可支持更大的存儲空間，目前官方給的建議是 2T，希望可以提升到 4T 或者是 5T，可以進(jìn)一步降低 TiDB 的使用成本。第二，提升備份效率，TiDB 集群的數(shù)據(jù)量通常比較大，所以備份效率比較重要，希望 TiDB 今后能夠通過其他一些方式，比如支持通過硬盤快照的方式進(jìn)行備份和恢復(fù)。第三，希望 TiDB 能夠支持一些外部表的讀寫，例如 OSS、HDFS、NFS等，用戶可以把歷史數(shù)據(jù)放到這些低成本的存儲中，實現(xiàn)數(shù)據(jù)的冷熱分層，降低使用成本。第四，進(jìn)一步提升 TiCDC 的性能和穩(wěn)定性，有些同步任務(wù)可以通過接口和 K8s Job 進(jìn)行配置，希望通過在生產(chǎn)環(huán)境實現(xiàn)主從集群的方式，進(jìn)一步擴(kuò)大 TiDB 在京東內(nèi)部的使用場景和規(guī)模。

我們希望 PingCAP 和 TiDB 能夠發(fā)展得越來越好，成為國產(chǎn)數(shù)據(jù)庫的一面旗幟，同時也歡迎大家來京東云試用 Cloud-TiDB。