TiDB簡述

項目内使用的MySQL2Hive任務失敗，是由于數倉使用的TiDB新版元件BUG引起的，自此了解到了TiDB。恰逢美團技術團隊公衆号2018.11.22發了一篇文章新一代資料庫TiDB在美團的實踐，就花了點時間進一步了解了下TiDB。TiDB 是 PingCAP 公司（中國一家開源新型分布式資料庫公司 ）設計的開源分布式 HTAP (Hybrid Transactional and Analytical Processing) 資料庫，已在多家網際網路公司使用：美團、今日頭條、愛奇藝、餓了麼等大規模使用。

1 數倉為何要用TiDB

目前公司線上業務庫中的資料分析現有的架構會有如下問題：

• ​ 現有的業務資料量比較大，多源DB壓力大，不易優化，經常出現問題（如cpu滿載等）
• ​ Sqoop導入資料低效（1. Sqoop通過JDBC讀取資料 2. Sqoop的Mapreduce雖然是分布式的，但是Mysql的資料庫卻隻是單台，無法達到分布式的效果）
• ​ 中繼資料資訊不透明，使用者通過排程系統添加排程任務的時候，對業務庫的中繼資料不太了解，往往需要咨詢DBA
• ​ 資料導入過程中缺乏導入資訊的統計，如導入的資料量等
• ​ 資料的導入是T+1的模式，時效性不夠
• ​ 每次都全量導入到大資料叢集中，造成存儲，網絡等資源的浪費
• ​ 無法實作業務資料的OLTP分析，甚至跨多個庫的聯合分析

2 TiDB概述

官方文檔

2.1 簡介

TiDB 是 PingCAP 公司受 Google Spanner / F1 論文啟發設計的開源分布式 HTAP (Hybrid Transactional and Analytical Processing) 資料庫，結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 相容 MySQL，支援無限的水準擴充，具備強一緻性和高可用性。TiDB 的目标是為 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的解決方案。

TiDB 具備如下特性：

• 高度相容 MySQL

  大多數情況下，無需修改代碼即可從 MySQL 輕松遷移至 TiDB，分庫分表後的 MySQL 叢集亦可通過 TiDB 工具進行實時遷移。

• 水準彈性擴充

  通過簡單地增加新節點即可實作 TiDB 的水準擴充，按需擴充吞吐或存儲，輕松應對高并發、海量資料場景。

• 分布式事務

  TiDB 100% 支援标準的 ACID 事務。

• 真正金融級高可用

  相比于傳統主從 (M-S) 複制方案，基于 Raft 的多數派選舉協定可以提供金融級的 100% 資料強一緻性保證，且在不丢失大多數副本的前提下，可以實作故障的自動恢複 (auto-failover)，無需人工介入。

• 一站式 HTAP 解決方案

  TiDB 作為典型的 OLTP 行存資料庫，同時兼具強大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解決方案，一份存儲同時處理 OLTP & OLAP，無需傳統繁瑣的 ETL 過程。

• 雲原生 SQL 資料庫

  TiDB 是為雲而設計的資料庫，支援公有雲、私有雲和混合雲，使部署、配置和維護變得十分簡單。

TiDB 的設計目标是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更複雜的 OLAP 分析可以通過 TiSpark 項目來完成。

TiDB 對業務沒有任何侵入性，能優雅的替換傳統的資料庫中間件、資料庫分庫分表等 Sharding 方案。同時它也讓開發運維人員不用關注資料庫 Scale 的細節問題，專注于業務開發，極大的提升研發的生産力。

2.2 在網際網路公司的應用

2.2.1 今日頭條

吳镝：TiDB 在今日頭條的實踐

TiDB 主要應用在今日頭條核心 OLTP 系統 - 對象存儲系統的部分中繼資料存儲，支援頭條圖檔和視訊相關業務，比如抖音等。

TiDB 支撐着今日頭條 OLTP 系統裡資料流量最大、QPS 最高的場景：叢集容量 幾十T，資料量日增 5 億，日常 QPS 均值在 12W，峰值 20W 左右。

用 TiDB 之前，中繼資料是存在 MySQL 裡的一個 2.8TB 的SSD盤，因為增長的特别快，是以導緻磁盤不夠用，隻能用分庫分表的方案。

用的的分庫分表的方案是 MyCAT。但用這個方案的過程中遇到了一些問題。比如丢資料；再就是連接配接的問題，目前頭條做分片是大概固定分 100 個片。如果你的業務是需要分庫分表，那好，你這邊搞 101 個分片，這樣有些業務，他用了一個分片鍵，用分片鍵來做查詢，那可能中間件隻用一個連接配接就可以找到相關資料。但有些業務，确實有不帶分片鍵的請求。會導緻 select 語句過來的時候，下面會建 101 個對後端的連接配接，也就是說，因為有連接配接的限制，有一個沒有帶分片鍵的這種請求過來之後， MyCAT 可以啟 101 個連接配接到後面的每一個 MySQL 庫。那這樣的話，有時候我給它 5 萬個連接配接，他一下子就把一百萬用掉了。這樣會導緻，它在非分片鍵的 select 請求，它連接配接速度消耗非常快，經常在業務這邊會抛出說，連接配接數不夠。

目前平均值 QPS 在 12W，用了 3 個 TiDB，3 個 TiDB 總的連接配接數加起來大概 14K，然後 Latency 的 pct99 小于 60ms。這其實都屬于挺高峰時期的資料了。做活動的時候 QPS 會達到 20W。

在使用 TiDB 過程中，比較一下 TiDB 和 MySQL 的延時：

2.2.2 美團點評

美團點評攜手 PingCAP 開啟新一代資料庫深度實踐之旅

在美團，基于 MySQL 建構的傳統關系型資料庫服務已經難于支撐公司業務的爆發式增長，促使去探索更合理的資料存儲方案和實踐新的運維方式。随着近一兩年來分布式資料庫大放異彩，美團 DBA 團隊聯合架構存儲團隊，于 2018 年初啟動了分布式資料庫項目。

美團業務線衆多，根據業務特點及重要程度逐漸推進上線，到截稿為止，已經上線 10 個叢集，近 200 個實體節點，大部分是 OLTP 類型的應用，除了上線初期遇到了一些小問題，目前均已穩定運作。初期上線的叢集，已經分别服務于配送、出行、閃付、酒旅等業務。

除了分析查詢量大的離線業務場景，美團還有很多分庫分表的場景，雖然業界有很多分庫分表的方案，解決了單機性能、存儲瓶頸，但是對于業務還是有些不友好的地方：

• 業務無法友好的執行分布式事務。
• 跨庫的查詢，需要在中間層上組合，是比較重的方案。
• 單庫如果容量不足，需要再次拆分，無論怎樣做，都很痛苦。
• 業務需要關注資料分布的規則，即使用了中間層，業務心裡還是沒底。

2.2.3 愛奇藝

TiDB 在愛奇藝的應用及實踐

随着公司業務的快速發展，原來普遍使用的 MySQL 叢集遇到了很多瓶頸，比如單機 MySQL 執行個體支撐的資料量有限，隻能通過不停删除較舊的資料來維持資料庫的運轉。同時單表的資料行數不斷增大導緻查詢速度變慢。急需一種可擴充、高可用同時又相容 MySQL 通路方式的資料庫來支撐業務的高速發展。

從 2017 年年中開始調研 TiDB，并且在資料庫雲部門内部系統中使用了 TiDB 叢集。從今年 TiDB 推出 2.0 之後，TiDB 愈發成熟，穩定性與查詢效率都有很大提升。

在實踐過程中感受到 TiDB 解決的痛點主要是橫向擴充和高可用。單機資料庫支撐的資料量有限，如果采用分庫分表 + proxy 的方式，無論 proxy 是在用戶端還是服務端都增加了運維的成本。同時 proxy 的查詢效率在很多場景下不能滿足要求。另外，proxy 對事務的支援都比較弱，不能滿足資料強一緻性的要求。TiDB 可以直接替代 proxy+MySQL 的架構，服務高可用性、資料高可用性、橫向擴充性都由 TiDB 叢集完成，完美解決了資料量增量情況下出現的很多問題。而且，TiDB 在資料量越大的情況下性能表現得比 MySQL 越驚豔。

2.2.4 360

http://blog.csdn.net/dkjkls