摘要：而隨著分布式數(shù)據(jù)庫大放異彩，美團(tuán)團(tuán)隊(duì)聯(lián)合基礎(chǔ)架構(gòu)存儲(chǔ)團(tuán)隊(duì)，于年初啟動(dòng)了分布式數(shù)據(jù)庫項(xiàng)目?？鐧C(jī)房雙寫支持跨機(jī)房雙寫是數(shù)據(jù)庫領(lǐng)域一大難題，是我們對(duì)分布式數(shù)據(jù)庫的一個(gè)重要期待，也是美團(tuán)下一階段重要的需求。

近幾年，基于MySQL構(gòu)建的傳統(tǒng)關(guān)系型數(shù)據(jù)庫服務(wù)，已經(jīng)很難支撐美團(tuán)業(yè)務(wù)的爆發(fā)式增長(zhǎng)，這就促使我們?nèi)ヌ剿鞲侠淼臄?shù)據(jù)存儲(chǔ)方案和實(shí)踐新的運(yùn)維方式。而隨著分布式數(shù)據(jù)庫大放異彩，美團(tuán)DBA團(tuán)隊(duì)聯(lián)合基礎(chǔ)架構(gòu)存儲(chǔ)團(tuán)隊(duì)，于 2018 年初啟動(dòng)了分布式數(shù)據(jù)庫項(xiàng)目。

圖 1 美團(tuán)點(diǎn)評(píng)產(chǎn)品展示圖

在立項(xiàng)之初，我們進(jìn)行了大量解決方案的對(duì)比，深入了解了業(yè)界的 scale-out（橫向擴(kuò)展）、scale-up（縱向擴(kuò)展）等解決方案。但考慮到技術(shù)架構(gòu)的前瞻性、發(fā)展?jié)摿?、社區(qū)活躍度以及服務(wù)本身與 MySQL 的兼容性，我們最終敲定了基于 TiDB 數(shù)據(jù)庫進(jìn)行二次開發(fā)的整體方案，并與 PingCAP 官方和開源社區(qū)進(jìn)行深入合作的開發(fā)模式。

美團(tuán)業(yè)務(wù)線眾多，我們根據(jù)業(yè)務(wù)特點(diǎn)及重要程度逐步推進(jìn)上線，到截稿為止，已經(jīng)上線了 10 個(gè)集群，近 200 個(gè)物理節(jié)點(diǎn)，大部分是 OLTP 類型的應(yīng)用，除了上線初期遇到了一些小問題，目前均已穩(wěn)定運(yùn)行。初期上線的集群，已經(jīng)分別服務(wù)于配送、出行、閃付、酒旅等業(yè)務(wù)。雖然 TiDB 的架構(gòu)分層相對(duì)比較清晰，服務(wù)也是比較平穩(wěn)和流暢，但在美團(tuán)當(dāng)前的數(shù)據(jù)量規(guī)模和已有穩(wěn)定的存儲(chǔ)體系的基礎(chǔ)上，推廣新的存儲(chǔ)服務(wù)體系，需要對(duì)周邊工具和系統(tǒng)進(jìn)行一系列改造和適配，從初期探索到整合落地，仍然還需要走很遠(yuǎn)的路。下面將從以下幾個(gè)方面分別進(jìn)行介紹：

從 0 到 1 的突破，重點(diǎn)考慮做哪些事情。

如何規(guī)劃實(shí)施不同業(yè)務(wù)場(chǎng)景的接入和已有業(yè)務(wù)的遷移。

上線后遇到的一些典型問題介紹。

后續(xù)規(guī)劃和對(duì)未來的展望。?

我們對(duì)于 TiDB 的定位，前期在于重點(diǎn)解決 MySQL 的單機(jī)性能和容量無法線性和靈活擴(kuò)展的問題，與 MySQL 形成互補(bǔ)。業(yè)界分布式方案很多，我們?yōu)楹芜x擇了 TiDB 呢？考慮到公司業(yè)務(wù)規(guī)模的快速增長(zhǎng)，以及公司內(nèi)關(guān)系數(shù)據(jù)庫以 MySQL 為主的現(xiàn)狀，因此我們?cè)谡{(diào)研階段，對(duì)以下技術(shù)特性進(jìn)行了重點(diǎn)考慮：

協(xié)議兼容 MySQL：這個(gè)是必要項(xiàng)。

可在線擴(kuò)展：數(shù)據(jù)通常要有分片，分片要支持分裂和自動(dòng)遷移，并且遷移過程要盡量對(duì)業(yè)務(wù)無感知。

強(qiáng)一致的分布式事務(wù)：事務(wù)可以跨分片、跨節(jié)點(diǎn)執(zhí)行，并且強(qiáng)一致。

支持二級(jí)索引：為兼容 MySQL 的業(yè)務(wù)，這個(gè)是必須的。

性能：MySQL 的業(yè)務(wù)特性，高并發(fā)的 OLTP 性能必須滿足。

跨機(jī)房服務(wù)：需要保證任何一個(gè)機(jī)房宕機(jī)，服務(wù)能自動(dòng)切換。

跨機(jī)房雙寫：支持跨機(jī)房雙寫是數(shù)據(jù)庫領(lǐng)域一大難題，是我們對(duì)分布式數(shù)據(jù)庫的一個(gè)重要期待，也是美團(tuán)下一階段重要的需求。

業(yè)界的一些傳統(tǒng)方案雖然支持分片，但無法自動(dòng)分裂、遷移，不支持分布式事務(wù)，還有一些在傳統(tǒng) MySQL 上開發(fā)一致性協(xié)議的方案，但它無法實(shí)現(xiàn)線性擴(kuò)展，最終我們選擇了與我們的需求最為接近的 TiDB。與 MySQL 語法和特性高度兼容，具有靈活的在線擴(kuò)容縮容特性，支持 ACID 的強(qiáng)一致性事務(wù)，可以跨機(jī)房部署實(shí)現(xiàn)跨機(jī)房容災(zāi)，支持多節(jié)點(diǎn)寫入，對(duì)業(yè)務(wù)又能像單機(jī) MySQL 一樣使用。

針對(duì)官方聲稱的以上優(yōu)點(diǎn)，我們進(jìn)行了大量的研究、測(cè)試和驗(yàn)證。

首先，我們需要知道擴(kuò)容、Region 分裂轉(zhuǎn)移的細(xì)節(jié)、Schema 到 KV 的映射、分布式事務(wù)的實(shí)現(xiàn)原理。而 TiDB 的方案，參考了較多的 Google 論文，我們進(jìn)行了閱讀，這有助于我們理解 TiDB 的存儲(chǔ)結(jié)構(gòu)、事務(wù)算法、安全性等，包括：

Spanner: Google’s Globally-Distributed Database

Large-scale Incremental Processing Using Distributed Transactions and Notifications

In Search of an Understandable Consensus Algorithm

Online, Asynchronous Schema Change in F1

我們也進(jìn)行了常規(guī)的性能和功能測(cè)試，用來與 MySQL 的指標(biāo)進(jìn)行對(duì)比，其中一個(gè)比較特別的測(cè)試，是證明 3 副本跨機(jī)房部署，確實(shí)能保證每個(gè)機(jī)房分布一個(gè)副本，從而保證任何一個(gè)機(jī)房宕機(jī)不會(huì)導(dǎo)致丟失超過半數(shù)副本。我們從以下幾個(gè)點(diǎn)進(jìn)行了測(cè)試：

Raft 擴(kuò)容時(shí)是否支持 Learner 節(jié)點(diǎn)，從而保證單機(jī)房宕機(jī)不會(huì)丟失 2/3 的副本。

TiKV 上的標(biāo)簽優(yōu)先級(jí)是否可靠，保證當(dāng)機(jī)房的機(jī)器不平均時(shí)，能否保證每個(gè)機(jī)房的副本數(shù)依然是絕對(duì)平均的。

實(shí)際測(cè)試，單機(jī)房宕機(jī)，TiDB 在高并發(fā)下，QPS、響應(yīng)時(shí)間、報(bào)錯(cuò)數(shù)量，以及最終數(shù)據(jù)是否有丟失。

手動(dòng) Balance 一個(gè) Region 到其他機(jī)房，是否會(huì)自動(dòng)回來。

從測(cè)試結(jié)果來看，一切都符合我們的預(yù)期。

美團(tuán)的產(chǎn)品線豐富，業(yè)務(wù)體量也比較大，業(yè)務(wù)對(duì)在線存儲(chǔ)的服務(wù)質(zhì)量要求也非常高。因此，從早期做好服務(wù)體系的規(guī)劃非常重要。下面從業(yè)務(wù)接入層、監(jiān)控報(bào)警、服務(wù)部署等維度，來分別介紹一下我們所做的工作。

當(dāng)前 MySQL 的業(yè)務(wù)接入方式主要有兩種，DNS 接入和 Zebra 客戶端接入。在前期調(diào)研階段，我們選擇了 DNS + 負(fù)載均衡組件的接入方式，TiDB-Server 節(jié)點(diǎn)宕機(jī)，15s 可以被負(fù)載均衡識(shí)別到，簡(jiǎn)單且有效。業(yè)務(wù)架構(gòu)如下圖所示：

圖 2 業(yè)務(wù)架構(gòu)圖

后面，我們會(huì)逐漸過渡到當(dāng)前大量使用的 Zebra 接入方式來訪問 TiDB，從而保持與訪問 MySQL 的方式一致，一方面減少業(yè)務(wù)改造的成本，另一方面盡量實(shí)現(xiàn)從 MySQL 到 TiDB 的透明遷移。

美團(tuán)目前使用 Mt-Falcon 平臺(tái)負(fù)責(zé)監(jiān)控報(bào)警，通過在 Mt-Falcon 上配置不同的插件，可以實(shí)現(xiàn)對(duì)多種組件的自定義監(jiān)控。另外也會(huì)結(jié)合 Puppet 識(shí)別不同用戶的權(quán)限、文件的下發(fā)。只要我們編寫好插件腳本、需要的文件，裝機(jī)和權(quán)限控制就可以完成了。監(jiān)控架構(gòu)如下圖所示：

圖 3 監(jiān)控架構(gòu)圖

而 TiDB 有豐富的監(jiān)控指標(biāo)，使用流行的 Prometheus + Grafana，一套集群有 700+ 的 Metric。從官方的架構(gòu)圖可以看出，每個(gè)組件會(huì)推送自己的 Metric 給 PushGateWay，Prometheus 會(huì)直接到 PushGateWay 去抓數(shù)據(jù)。

由于我們需要組件收斂，原生的 TiDB 每個(gè)集群一套 Prometheus 的方式不利于監(jiān)控的匯總、分析、配置，而報(bào)警已經(jīng)在 Mt-Falcon 上實(shí)現(xiàn)的比較好了，在 AlertManager 上再造一個(gè)也沒有必要。因此我們需要想辦法把監(jiān)控和報(bào)警匯總到 Mt-Falcon 上面，包括如下幾種方式：

方案一：修改源代碼，將 Metric 直接推送到 Falcon，由于 Metric 散落在代碼的不同位置，而且 TiDB 代碼迭代太快，把精力消耗在不停調(diào)整監(jiān)控埋點(diǎn)上不太合適。

方案二：在 PushGateWay 是匯總后的，可以直接抓取，但 PushGateWay 是個(gè)單點(diǎn)，不好維護(hù)。

方案三：通過各個(gè)組件（TiDB、PD、TiKV）的本地 API 直接抓取，優(yōu)點(diǎn)是組件宕機(jī)不會(huì)影響其他組件，實(shí)現(xiàn)也比較簡(jiǎn)單。

我們最終選擇了方案三。該方案的難點(diǎn)是需要把 Prometheus 的數(shù)據(jù)格式轉(zhuǎn)化為 Mt-Falcon 可識(shí)別的格式，因?yàn)?Prometheus 支持 Counter、Gauge、Histogram、Summary 四種數(shù)據(jù)類型，而 Mt-Falcon 只支持基本的 Counter 和 Gauge，同時(shí) Mt-Falcon 的計(jì)算表達(dá)式比較少，因此需要在監(jiān)控腳本中進(jìn)行轉(zhuǎn)換和計(jì)算。

TiDB 使用 Ansible 實(shí)現(xiàn)自動(dòng)化部署。迭代快，是 TiDB 的一個(gè)特點(diǎn)，有問題能快速進(jìn)行解決，但也造成 Ansible 工程、TiDB 版本更新過快，我們對(duì) Ansible 的改動(dòng)，也只會(huì)增加新的代碼，不會(huì)改動(dòng)已有的代碼。因此線上可能同時(shí)需要部署、維護(hù)多個(gè)版本的集群。如果每個(gè)集群一個(gè) Ansible 目錄，造成空間的浪費(fèi)。

我們采用的維護(hù)方式是，在中控機(jī)中，每個(gè)版本一個(gè) Ansible 目錄，每個(gè)版本中通過不同 inventory 文件來維護(hù)。這里需要跟 PingCAP 提出的是，Ansible 只考慮了單集群部署，大量部署會(huì)有些麻煩，像一些依賴的配置文件，都不能根據(jù)集群多帶帶配置（咨詢官方得知，PingCAP 目前正在基于 Cloud TiDB 打造一站式 HTAP 平臺(tái)，會(huì)提供批量部署、多租戶等功能，后續(xù)會(huì)比較好地解決這個(gè)問題）。

隨著線上集群數(shù)量的增加，打造運(yùn)維平臺(tái)提上了日程，而美團(tuán)對(duì) TiDB 和 MySQL 的使用方式基本相同，因此 MySQL 平臺(tái)上具有的大部分組件，TiDB 平臺(tái)也需要建設(shè)。典型的底層組件和方案：SQL 審核模塊、DTS、數(shù)據(jù)備份方案等。自動(dòng)化運(yùn)維平臺(tái)展示如下圖所示：

圖 4 自動(dòng)化運(yùn)維平臺(tái)展示圖

TiDB 是在線存儲(chǔ)體系中的一環(huán)，它同時(shí)也需要融入到公司現(xiàn)有的數(shù)據(jù)流中，因此需要一些工具來做銜接。PingCAP 官方標(biāo)配了相關(guān)的組件。

公司目前 MySQL 和 Hive 結(jié)合的比較重，而 TiDB 要代替 MySQL 的部分功能，需要解決 2 個(gè)問題：

MySQL to TiDB

MySQL 到 TiDB 的遷移，需要解決數(shù)據(jù)遷移以及增量的實(shí)時(shí)同步，也就是 DTS，Mydumper + Loader 解決存量數(shù)據(jù)的同步，官方提供了 DM 工具可以很好的解決增量同步問題。

MySQL 大量使用了自增 ID 作為主鍵。分庫分表 MySQL 合并到 TiDB 時(shí)，需要解決自增 ID 沖突的問題。這個(gè)通過在 TiDB 端去掉自增 ID 建立自己的唯一主鍵來解決。新版 DM 也提供分表合并過程主鍵自動(dòng)處理的功能。

Hive to TiDB & TiDB to Hive

Hive to TiDB 比較好解決，這體現(xiàn)了 TiDB 和 MySQL 高度兼容的好處，insert 語句可以不用調(diào)整，基于 Hive to MySQL 簡(jiǎn)單改造即可。

TiDB to Hive 則需要基于官方 Pump + Drainer 組件，Drainer 可以消費(fèi)到 Kafka、MySQL、TiDB，我們初步考慮用圖 5 中的方案通過使用 Drainer 的 Kafka 輸出模式同步到 Hive。

圖 5 TiDB to Hive 方案圖

對(duì)于初期上線的業(yè)務(wù)，我們比較謹(jǐn)慎，基本的原則是：離線業(yè)務(wù) -> 非核心業(yè)務(wù) -> 核心業(yè)務(wù)。TiDB 已經(jīng)發(fā)布兩年多，且前期經(jīng)歷了大量的測(cè)試，我們也深入了解了其它公司的測(cè)試和使用情況，可以預(yù)期的是 TiDB 上線會(huì)比較穩(wěn)定，但依然遇到了一些小問題。總體來看，在安全性、數(shù)據(jù)一致性等關(guān)鍵點(diǎn)上沒有出現(xiàn)問題。其他一些性能抖動(dòng)問題，參數(shù)調(diào)優(yōu)的問題，也都得到了快速妥善的解決。這里給 PingCAP 的同學(xué)點(diǎn)個(gè)大大的贊，問題響應(yīng)速度非常快，與我們美團(tuán)內(nèi)部研發(fā)的合作也非常融洽。

我們上線的最大的一個(gè)業(yè)務(wù)，每天有數(shù)百 G 的寫入量，在前期，我們也遇到了較多的問題。

業(yè)務(wù)場(chǎng)景：

穩(wěn)定的寫入，每個(gè)事務(wù)操作 100~200 行不等，每秒 6W 的數(shù)據(jù)寫入。

每天的寫入量超過 500G，以后會(huì)逐步提量到每天 3T。

每 15 分鐘的定時(shí)讀 Job，5000 QPS（高頻量?。?。

不定時(shí)的查詢（低頻量大）。?

之前使用 MySQL 作為存儲(chǔ)，但 MySQL 到達(dá)了容量和性能瓶頸，而業(yè)務(wù)的容量未來會(huì) 10 倍的增長(zhǎng)。初期調(diào)研測(cè)試了 ClickHouse，滿足了容量的需求，測(cè)試發(fā)現(xiàn)運(yùn)行低頻 SQL 沒有問題，但高頻 SQL 的大并發(fā)查詢無法滿足需求，只在 ClickHouse 跑全量的低頻 SQL 又會(huì) overkill，最終選擇使用 TiDB。

測(cè)試期間模擬寫入了一天的真實(shí)數(shù)據(jù)，非常穩(wěn)定，高頻低頻兩種查詢也都滿足需求，定向優(yōu)化后 OLAP 的 SQL 比 MySQL 性能提高四倍。但上線后，陸續(xù)發(fā)現(xiàn)了一些問題，典型的如下：

TiKV 底層有 2 個(gè) RocksDB 作為存儲(chǔ)。新寫的數(shù)據(jù)寫入 L0 層，當(dāng) RocksDB 的 L0 層數(shù)量達(dá)到一定數(shù)量，就會(huì)發(fā)生減速，更高則發(fā)生 Stall，用來自我保護(hù)。TiKV 的默認(rèn)配置：

level0-slowdown-writes-trigger = 20

level0-stop-writes-trigger = 36?

遇到過的，發(fā)生 L0 文件過多可能的原因有 2 個(gè)：

寫入量大，Compact 完不成。

Snapshot 一直創(chuàng)建不完，導(dǎo)致堆積的副本一下釋放，RocksDB-Raft 創(chuàng)建大量的 L0 文件，監(jiān)控展示如下圖所示：

圖 6 TiKV 發(fā)生 Write Stall 監(jiān)控展示圖

我們通過以下措施，解決了 Write Stall 的問題：

減緩 Raft Log Compact 頻率（增大 raft-log-gc-size-limit、raft-log-gc-count-limit）

加快 Snapshot 速度（整體性能、包括硬件性能）

max-sub-compactions 調(diào)整為 3

max-background-jobs 調(diào)整為 12

level 0 的 3 個(gè) Trigger 調(diào)整為 16、32、64

現(xiàn)在 TiDB 的 GC 對(duì)于每個(gè) kv-instance 是單線程的，當(dāng)業(yè)務(wù)刪除數(shù)據(jù)的量非常大時(shí)，會(huì)導(dǎo)致 GC 速度較慢，很可能 GC 的速度跟不上寫入。

目前可以通過增多 TiKV 個(gè)數(shù)來解決，長(zhǎng)期需要靠 GC 改為多線程執(zhí)行，官方對(duì)此已經(jīng)實(shí)現(xiàn)，即將發(fā)布。

業(yè)務(wù)上線初期，insert 的響應(yīng)時(shí)間 80 線（Duration 80 By Instance）在 20ms 左右，隨著運(yùn)行時(shí)間增加，發(fā)現(xiàn)響應(yīng)時(shí)間逐步增加到 200ms+。期間排查了多種可能原因，定位在由于 Region 數(shù)量快速上漲，Raftstore 里面要做的事情變多了，而它又是單線程工作，每個(gè) Region 定期都要 heartbeat，帶來了性能消耗。tikv-raft propose wait duration 指標(biāo)持續(xù)增長(zhǎng)。

解決問題的辦法：

臨時(shí)解決。

增加 Heartbeat 的周期，從 1s 改為 2s，效果比較明顯，監(jiān)控展示如下圖所示：

圖 7 insert 響應(yīng)時(shí)間優(yōu)化前后對(duì)比圖

徹底解決。

需要減少 Region 個(gè)數(shù)，Merge 掉空 Region，官方在 2.1 版本中已經(jīng)實(shí)現(xiàn)了 Region Merge 功能，我們?cè)谏?jí)到 2.1 后，得到了徹底解決。

另外，等待 Raftstore 改為多線程，能進(jìn)一步優(yōu)化。（官方回復(fù)相關(guān)開發(fā)已基本接近尾聲，將于 2.1 的下一個(gè)版本發(fā)布。）

DBA Truncate 一張大表后，發(fā)現(xiàn) 2 個(gè)現(xiàn)象，一是空間回收較慢，二是最終也沒有完全回收。

由于底層 RocksDB 的機(jī)制，很多數(shù)據(jù)落在 Level 6 上，有可能清不掉。這個(gè)需要打開 cdynamic-level-bytes 會(huì)優(yōu)化 Compaction 的策略，提高 Compact 回收空間的速度。

由于 Truncate 使用 delete_files_in_range 接口，發(fā)給 TiKV 去刪 SST 文件，這里只刪除不相交的部分，而之前判斷是否相交的粒度是 Region，因此導(dǎo)致了大量 SST 無法及時(shí)刪除掉。

考慮 Region 獨(dú)立 SST 可以解決交叉問題，但是隨之帶來的是磁盤占用問題和 Split 延時(shí)問題。

考慮使用 RocksDB 的 DeleteRange 接口，但需要等該接口穩(wěn)定。

目前最新的 2.1 版本優(yōu)化為直接使用 DeleteFilesInRange 接口刪除整個(gè)表占用的空間，然后清理少量殘留數(shù)據(jù)，目前已經(jīng)解決。

為了解決 region 過多的問題，我們?cè)谏?jí) 2.1 版本后，開啟了 region merge 功能，但是 TiDB 的響應(yīng)時(shí)間 80 線（Duration 80 By Instance）依然沒有恢復(fù)到當(dāng)初，保持在 50ms 左右，排查發(fā)現(xiàn) KV 層返回的響應(yīng)時(shí)間還很快，和最初接近，那么就定位了問題出現(xiàn)在 TiDB 層。研發(fā)人員和 PingCAP 定位在產(chǎn)生執(zhí)行計(jì)劃時(shí)行為和 2.0 版本不一致了，目前已經(jīng)優(yōu)化。

除了分析查詢量大的離線業(yè)務(wù)場(chǎng)景，美團(tuán)還有很多分庫分表的場(chǎng)景，雖然業(yè)界有很多分庫分表的方案，解決了單機(jī)性能、存儲(chǔ)瓶頸，但是對(duì)于業(yè)務(wù)還是有些不友好的地方：

業(yè)務(wù)無法友好的執(zhí)行分布式事務(wù)。

跨庫的查詢，需要在中間層上組合，是比較重的方案。

單庫如果容量不足，需要再次拆分，無論怎樣做，都很痛苦。

業(yè)務(wù)需要關(guān)注數(shù)據(jù)分布的規(guī)則，即使用了中間層，業(yè)務(wù)心里還是沒底。

因此很多分庫分表的業(yè)務(wù)，以及即將無法在單機(jī)承載而正在設(shè)計(jì)分庫分表方案的業(yè)務(wù)，主動(dòng)找到了我們，這和我們對(duì)于 TiDB 的定位是相符的。這些業(yè)務(wù)的特點(diǎn)是 SQL 語句小而頻繁，對(duì)一致性要求高，通常部分?jǐn)?shù)據(jù)有時(shí)間屬性。在測(cè)試及上線后也遇到了一些問題，不過目前基本都有了解決辦法。

業(yè)務(wù)偶爾報(bào)出 privilege check fail。

是由于業(yè)務(wù)在 JDBC 設(shè)置了 QueryTimeout，SQL 運(yùn)行超過這個(gè)時(shí)間，會(huì)發(fā)行一個(gè) kill query 命令，而 TiDB 執(zhí)行這個(gè)命令需要 Super 權(quán)限，業(yè)務(wù)是沒有權(quán)限的。其實(shí) kill 自己的查詢，并不需要額外的權(quán)限，目前已經(jīng)解決了這個(gè)問題：
https://github.com/pingcap/tidb/pull/7003，不再需要 Super 權(quán)限，已在 2.0.5 上線。

TiDB 的物理優(yōu)化階段需要依靠統(tǒng)計(jì)信息。在 2.0 版本統(tǒng)計(jì)信息的收集從手動(dòng)執(zhí)行，優(yōu)化為在達(dá)到一定條件時(shí)可以自動(dòng)觸發(fā)：

數(shù)據(jù)修改比例達(dá)到 tidb_auto_analyze_ratio。

表一分鐘沒有變更（目前版本已經(jīng)去掉這個(gè)條件）。

但是在沒有達(dá)到這些條件之前統(tǒng)計(jì)信息是不準(zhǔn)的，這樣就會(huì)導(dǎo)致物理優(yōu)化出現(xiàn)偏差，在測(cè)試階段（2.0 版本）就出現(xiàn)了這樣一個(gè)案例：業(yè)務(wù)數(shù)據(jù)是有時(shí)間屬性的，業(yè)務(wù)的查詢有 2 個(gè)條件，比如：時(shí)間+商家 ID，但每天上午統(tǒng)計(jì)信息可能不準(zhǔn)，當(dāng)天的數(shù)據(jù)已經(jīng)有了，但統(tǒng)計(jì)信息認(rèn)為沒有。這時(shí)優(yōu)化器就會(huì)建議使用時(shí)間列的索引，但實(shí)際上商家 ID 列的索引更優(yōu)化。這個(gè)問題可以通過增加 Hint 解決。

在 2.1 版本對(duì)統(tǒng)計(jì)信息和執(zhí)行計(jì)劃的計(jì)算做了大量的優(yōu)化，也穩(wěn)定了基于 Query Feedback 更新統(tǒng)計(jì)信息，也用于更新直方圖和 Count-Min Sketch，非常期待 2.1 的 GA。

經(jīng)過前期的測(cè)試、各方的溝通協(xié)調(diào)，以及近半年對(duì) TiDB 的使用，我們看好 TiDB 的發(fā)展，也對(duì)未來基于 TiDB 的合作充滿信心。

接下來，我們會(huì)加速推進(jìn) TiDB 在更多業(yè)務(wù)系統(tǒng)中的使用，同時(shí)也將 TiDB 納入了美團(tuán)新一代數(shù)據(jù)庫的戰(zhàn)略選型中。當(dāng)前，我們已經(jīng)全職投入了 3 位 DBA 同學(xué)和多位存儲(chǔ)計(jì)算專家，從底層的存儲(chǔ)，中間層的計(jì)算，業(yè)務(wù)層的接入，再到存儲(chǔ)方案的選型和布道，進(jìn)行全方位和更深入的合作。

長(zhǎng)期來看，結(jié)合美團(tuán)不斷增長(zhǎng)的業(yè)務(wù)規(guī)模，我們將與 PingCAP 官方合作打造更強(qiáng)大的生態(tài)體系：

Titan：Titan 是 TiDB 下一步比較大的動(dòng)作，也是我們非常期待的下一代存儲(chǔ)引擎，它對(duì)大 Value 支持會(huì)更友好，將解決我們單行大小受限，單機(jī) TiKV 最大支持存儲(chǔ)容量的問題，大大提升大規(guī)模部署的性價(jià)比。

Cloud TiDB （Based on Docker & K8s）：云計(jì)算大勢(shì)所趨，PingCAP 在這塊也布局比較早，今年 8 月份開源了 TiDB Operator，Cloud TiDB 不僅實(shí)現(xiàn)了數(shù)據(jù)庫的高度自動(dòng)化運(yùn)維，而且基于 Docker 硬件隔離，實(shí)現(xiàn)了數(shù)據(jù)庫比較完美的多租戶架構(gòu)。我們和官方同學(xué)溝通，目前他們的私有云方案在國內(nèi)也有重要體量的 POC，這也是美團(tuán)看重的一個(gè)方向。

TiDB HTAP Platform：PingCAP 在原有 TiDB Server 計(jì)算引擎的基礎(chǔ)上，還構(gòu)建 TiSpark 計(jì)算引擎，和他們官方溝通，他們?cè)谘邪l(fā)了一個(gè)基于列的存儲(chǔ)引擎，這樣就形成了下層行、列兩個(gè)存儲(chǔ)引擎、上層兩個(gè)計(jì)算引擎的完整混合數(shù)據(jù)庫（HTAP），這個(gè)架構(gòu)不僅大大的節(jié)省了核心業(yè)務(wù)數(shù)據(jù)在整個(gè)公司業(yè)務(wù)周期里的副本數(shù)量，還通過收斂技術(shù)棧，節(jié)省了大量的人力成本、技術(shù)成本、機(jī)器成本，同時(shí)還解決了困擾多年的 OLAP 的實(shí)效性。后面我們也會(huì)考慮將一些有實(shí)時(shí)、準(zhǔn)實(shí)時(shí)的分析查詢系統(tǒng)接入 TiDB。

圖 8 TiDB HTAP Platform 整體架構(gòu)圖

后續(xù)的物理備份方案，跨機(jī)房多寫等也是我們接下來逐步推進(jìn)的場(chǎng)景，總之，我們堅(jiān)信未來 TiDB 在美團(tuán)的使用場(chǎng)景會(huì)越來越多，發(fā)展也會(huì)越來越好。

目前，TiDB 在業(yè)務(wù)層面、技術(shù)合作層面都已經(jīng)在美團(tuán)揚(yáng)帆起航，美團(tuán)點(diǎn)評(píng)將攜手 PingCAP 開啟新一代數(shù)據(jù)庫深度實(shí)踐、探索之旅。后續(xù)，還有美團(tuán)點(diǎn)評(píng)架構(gòu)存儲(chǔ)團(tuán)隊(duì)針對(duì) TiDB 源碼研究和改進(jìn)的系列文章，敬請(qǐng)期待。

應(yīng)鋼，美團(tuán)點(diǎn)評(píng)研究員，數(shù)據(jù)庫專家。曾就職于百度、新浪、去哪兒網(wǎng)等，10年數(shù)據(jù)庫自動(dòng)化運(yùn)維開發(fā)、數(shù)據(jù)庫性能優(yōu)化、大規(guī)模數(shù)據(jù)庫集群技術(shù)保障和架構(gòu)優(yōu)化經(jīng)驗(yàn)。精通主流的SQL與NoSQL系統(tǒng)，現(xiàn)專注于公司業(yè)務(wù)在NewSQL領(lǐng)域的創(chuàng)新和落地。

李坤，2018年初加入美團(tuán)，美團(tuán)點(diǎn)評(píng)數(shù)據(jù)庫專家，多年基于MySQL、Hbase、Oracle的架構(gòu)設(shè)計(jì)和維護(hù)、自動(dòng)化開發(fā)經(jīng)驗(yàn)，目前主要負(fù)責(zé)分布式數(shù)據(jù)庫Blade的推動(dòng)和落地，以及平臺(tái)和周邊組件的建設(shè)

昌俊，美團(tuán)點(diǎn)評(píng)數(shù)據(jù)庫專家，曾就職于BOCO、去哪兒網(wǎng)，6年MySQL DBA從業(yè)經(jīng)歷，積累了豐富的數(shù)據(jù)庫架構(gòu)設(shè)計(jì)和性能優(yōu)化、自動(dòng)化開發(fā)經(jīng)驗(yàn)。目前專注于TiDB在美團(tuán)點(diǎn)評(píng)業(yè)務(wù)場(chǎng)景的改造和落地。