分散式資料庫 TiDB 是如何結合 OLTP 和 OLAP 的？
公眾號/AI前線
作者｜Kevin Xu
譯者｜劉嘉洋
編輯｜DebraAI 前線導讀：NewSQL 混合事務分析、MySQL 相容、水平可擴充套件資料庫的架構和用例。
更多幹貨內容請關注微信公眾號“AI 前線”（ID：ai-front）
TiDB 是一款開源、雲原生、MySQL 相容的分散式資料庫，可以處理混合事務和分析處理（HTAP）工作負載。它是“NEWSQL”關係資料庫的一員，被設計為方便大規模部署。也許有人想知道，“Ti”代表了鈦。
PingCAP 在三年半前才開始搭建 TiDB，但是這個產品已經擁有了 15000 次 GitHub 點贊，200 名貢獻者，7200 次提交，2000 個分支以及 300 名生產使用者。最近 TiDB 獲得了 InfoWorld Bossie Award 2018 資料儲存和分析領域最佳開源專案獎。
在這篇文章中，我將介紹 TiDB 設計的核心功能和架構，覆蓋資料庫的三個主要用例，並預覽了 PingCAP 即將推出的多雲 TiDB 即服務和 TiDB 學術版。
TiDB 功能
TiDB 的核心功能包括彈性的水平可擴充套件性，有 ACID 保證的分散式事務，高可用性以及實時交易資料額分析。讓我們來看一下這些功能背後隱藏的平臺架構。TiDB 平臺有以下這些元件：
- TiDB：無狀態 SQL 層，可以相容 MySQL，用 Go 語言開發。
- TiKV：分散式事務鍵值儲存，用 Rust 語言開發。（TiKV 最近成為了雲原生計算基金會專案）
- TiSpark：Apache Spark 外掛，連線到 TiKV 或者專門的柱狀儲存引擎（我們還在研究的部分，請持續關注）。
- Placement Driver（PD）：Etcd 提供的元資料叢集，管理並排程 TiKV。
TiKV 是基礎層。這是所有資料持久化的地方，自動分成小的塊（我們稱為“區域”），並通過執行 Raft 一致性協議自動複製並保持強一致。和 Placement Driver（PD）一起，TiKV 可以複製節點、資料中心和地理位置的資料。它還可以動態地去除形成的熱點，並拆分或合併區域，以提升效能和儲存使用率。我們在 TiKV 中實現了基於範圍的切片，而不是基於雜湊的切片，因為從一開始，我們的目標就是支援全功能的關係型資料庫。因此 TiKV 也支援不同型別的掃描操作：表掃描、索引掃描等等。
TiDB 中的無狀態 SQL 層用來負責所有的的線上交易處理（OLTP）工作和 80% 的常規線上分析處理（OLAP）。這樣的設計提升了常規效能（參考我們最新的 TPC-H 基準測試 https://github.com/pingcap/docs/blob/master/benchmark/tpch-v2.md） ，這個無狀態 SQL 層使用 TiKV 的分散式設計，通過協處理器層將部分查詢下放到不同 TiKV 節點進行並行處理。
對於更復雜的 OLAP 工作，比如說訓練機器學習模型的迭代分析或實時業務智慧採集，是由第二個無狀態 SQL 層 TiSpark 負責的，也是直接從 TiKV 獲得資料。TiDB 相容 MySQL，而 TiSpark 相容 Spark SQL。
TiDB 平臺架構
TiDB 架構
你可能已經注意到，整個 TiDB 平臺是模組化的，所有的元件都有單獨的程式碼庫，並且是鬆耦合的。你可以將整個 TiDB 平臺部署為一個完整的包（大多數使用者都是這麼做的）或是根據你的需要部署其中的一部分。這樣的模組化的架構給使用者提供了最大的靈活度，並符合雲原生架構標準。根據 CNCF 的官方定義，雲原生技術是“有彈性的、可管理的和可觀察的鬆耦合系統”。
作為 TiDB 的使用者，你可以擴充套件你的無狀態 SQL 伺服器或 TiSpark 層（也就是你的計算資源），或者是單獨擴充套件 TiKV（也就是你的儲存容量），允許你充分利用消耗的大部分資源，更好地滿足你的工作負載。你幾乎可以將 TiDB 無狀態 SQL 服務認為是在 TiKV 之上的微服務，它是持久化資料的有狀態應用程式。這個設計有利於隔離缺陷，更快地滾動升級和維護，而破壞性更小。
TiDB 這些優勢的代價是額外的部署和監視複雜性，有更多需要追蹤的部分。然而，隨著 Kubernetes 的興起以及 CoreOS 推動的 Operator 模式，部署和管理 TiDB 是簡單、直接並且日益自動化的。開源的 TiDB Operator for Kubernetes（https://www.infoworld.com/article/3297700/kubernetes/introducing-the-kubernetes-operator-for-tidb.html） 可以幫助你在任何雲環境下（公有、私有或混合）部署、擴充套件、升級和維護 TiDB。TiDB 預設安裝 Prometheus 和 Grafana，所以可以立即進行監視。（檢視我們的 TiDB Operator 教程 https://www.infoworld.com/article/3297700/kubernetes/introducing-the-kubernetes-operator-for-tidb.html）
靈活的技術資產擴充套件性是業務成功與否的最終關鍵。這就是你會成為下一個 Facebook 還是下一個 Friendster 的區別。TiDB 模組化和 Kubernetes 的加入可以給你的資料庫服務帶來靈活的擴充套件性。
最後，讓我們來看一下 TiDB 的三個主要用例：MySQL 擴充套件性、HTAP 實時分析和統一資料儲存。
示例 Grafana 儀表板監視 TiDB 部署
TiDB 用例：MySQL 擴充套件性
由於 TiDB 相容 MySQL，它同時相容 MySQL 連線協議和 MySQL 生態系統工具，比如 MyDumper 和 MyLoader，對於 MySQL 使用者來說，這是解決問題的自然選擇。我們需要清楚，TiDB 並非要取代 MySQL，相反，它是 MySQL 的補充。MySQL 仍然是很好的單例項資料庫選擇，所以如果你的資料大小或工作負載不大，那請繼續使用 MySQL。但如果你還在頭疼這些問題：
- 考慮如何複製、遷移或擴充套件資料庫得到更多容量
- 尋找優化現有儲存容量的方法
- 查詢效能慢
- 研究中介軟體擴充套件解決方案或實施手動分片策略
那麼請開始考慮使用像 TiDB 這樣的分散式 SQL 資料庫吧，它可以幫你解決你關心的所有問題。MySQL 分片的缺陷讓世界最大的單車共享平臺之一 Mobike 選擇使用 TiDB（閱讀 Mobike 案例 https://www.pingcap.com/success-stories/tidb-in-mobike/） 。Mobike 在 200 個城市擁有 9 百萬單車，服務於 2 億名使用者，因此不難想象團隊使用 MySQL 時候會遇到的擴充套件瓶頸。Mobike 通過在 MySQL 之外部署 TiDB，以及 PingCAP 的企業級工具套件，包括可以自動將 MySQL 主機和 TiDB 叢集同步的 Syncer，解決了彈性擴充套件需求。
TiDB 和其他 MySQL 相容資料庫之間最主要的區別在於 TiDB 的分散式架構。MySQL 技術已經存在了 23 年了，它從來沒有打算涉足於分散式領域。比如說，不像 TiDB，MySQL 不能產生查詢計劃，將部分查詢下放到多臺機器中同時進行並行處理。TiDB 的 SQL 解析器、基於成本的優化器和協處理器層從頭開始構建的，利用了分散式資料庫的計算資源和並行性，因此 MySQL 使用者可以從中獲得更多功能。
TiDB 用例：HTAP 實時分析
HTAP（混合事務和分析處理）是 Gartner 在 2014 年提出的一個術語，描述打破事務和分析資料工作之間隔閡的資料庫架構。目標是給企業實時分析，這樣就可以作出實時決策。其他行業分析公司有描述這個架構的專門術語：451 Research 的 HOAP（混合操作分析處理），Forrester 的 Translytical 以及 IDC 的 ATP（分析事務處理）。
正如我們討論的，TiDB 通過解耦計算層和儲存層，並使用不同的無狀態 SQL 引擎（TiDB 和 TiSpark）來做不同的分析任務，打破了 OLTP 和 OLAP 之間的隔閡。這兩個引擎都連線到同一個持久資料儲存（TiKV），讓系統自然擁有實時分析和決策的能力。複雜的 ETL 過程被簡單化，”t+1”延遲不復存在，TiDB 中儲存的資料可以更有創造力地進行使用。
服務於 5 百萬使用者的大型生鮮產品運送平臺 Yiguo.com 在 TiDB 之上執行 Apache Spark（閱讀 Yiguo.com 案例 https://www.datanami.com/2018/02/22/hybrid-database-capturing-perishable-insights-yiguo/） 來加速複雜的查詢。通過從 SQL Server 升級其基礎設施，並通過部署 TiDB 到其現有的 MySQL，Yiguo.com 可以高效能地在中國最大的線上購物節雙 11 運行復雜的連線運算，進行實時決策。
TiDB 用例：統一資料儲存
分散式、模組化、HTAP 資料庫 TiDB 被設計為可以水平地擴充套件計算和儲存容量，靈活地適應不同的工作負載，同時還是“唯一可信來源”。通過在鍵值儲存之上提供可擴充套件的 SQL 服務，TiDB 旨在動態地降低基礎設施棧中維護資料管理層的人力和技術成本。
對於世界上最大的食物配送平臺之一 Ele.me 來說，想要統一資料儲存是採用 TiDB 和 TiKV 的關鍵原因之一（閱讀 Ele.me 的案例 https://www.pingcap.com/success-stories/tidb-in-eleme/） 。之前，Ele.me 的資料分散在不同的資料庫中，包括 MongoDB、MySQL、Cassandra 和 Redis。最終，這個臨時堆疊不再可用，因為操作和維護成本不斷增加。現在 Ele.me 2 億 6 千萬使用者的 80% 操作在單個 TiKV 部署下服務。這個 TiKV 叢集跨越了 4 個數據中心，每個都有 100 多個節點，儲存了十幾個 TB 的資料，這些資料總是存在，一直可用。
多雲 TiDB 即服務和 TiDB Academy
自 PingCAP 開始搭建 TiDB 已經超過了 3 年，該資料庫在各種情況下都進行了測試。現在，超過 300 家公司都在使用 TiDB 滿足他們的 OLTP/OLAP、資料庫擴充套件性、實時分析和統一儲存的需求。然而，TiDB 的路線圖上還有許多目標。
其中一個是全面管理的多雲 TiDB 即服務，可以在各種雲設定下使用，包括公有、私有和混合。PingCAP 正在開發企業級、全託管、基於 Kubernetes 的 TiDB，並將在今年年底釋出第一個版本。如果你想要更早地使用，請在這裡註冊。
PingCAP 開發的另一個專案是 TiDB Academy，這是自己制定進度的實踐課程，幫助資料庫管理員、devops 以及系統架構師理解 TiDB 的架構、設計選擇、長處和短板。第一個課程“給 MySQL DBA 的分散式資料庫 TiDB”正在招生。你可以在這裡註冊（https://pingcap.com/tidb-cloud/）。
如果你想快速瞭解 TiDB，請參閱我們的 TiDB 快速入門指南（https://www.pingcap.com/docs/QUICKSTART/）。
Kevin Xu (twitter: @kevinsxu) 是 PingCAP 全球策略和運營的總經理，特別負責雲產品管理和策略。
檢視英文原文：
https://www.infoworld.com/article/3313327/database/how-tidb-combines-oltp-and-olap-in-a-distributed-database.html