TiDB功能

TiDB的核心功能包括彈性水平可伸縮性，具有ACID保證的分散式事務，高可用性以及實時事務資料的實時分析。讓我們來看看這些功能背後的平臺架構。TiDB平臺具有以下元件：

• TiDB：與Go相容的無狀態SQL層，內置於Go。

• TiKV：一個分散式事務鍵值儲存，用Rust構建。（TiKV最近成為雲原生計算基金會專案。）

• TiSpark：一個Apache Spark外掛，連線到TiKV或專門的柱狀儲存引擎（我們正在努力...繼續關注）。

• 放置驅動程式（PD）：由Etcd提供支援的元資料叢集，用於管理和計劃TiKV。

TiKV是基礎層。這是所有資料被保留，自動分割槽為較小的塊（我們稱之為“區域”），並通過執行Raft共識協議自動複製並強烈一致的地方。

TiDB中的無狀態SQL層可以處理100％的聯機事務處理（OLTP）工作負載和80％的常見，臨時，聯機分析處理（OLAP）工作負載。這個無狀態SQL層展示了定期的效能改進（參見我們最新的TPC-H基準測試），利用TiKV的分散式特性，通過協處理器層執行並行處理，同時將部分查詢推送到不同的TiKV節點。

對於更復雜的OLAP工作負載，例如用於培訓機器學習模型或實時商業智慧收集的迭代分析，第二個無狀態SQL層-TiSpark-報告職責，也直接從TiKV繪製資料。TiDB說MySQL，TiSpark暴露了Spark SQL。

TiDB平臺架構

TiDB架構

您可能已經注意到，整個TiDB平臺都是模組化的 - 所有元件都是獨立的程式碼庫，並且鬆散耦合。您可以將整個TiDB平臺部署為一個完整的軟體包（大多數使用者都可以），或者根據您的需要將其部分部署。這種模組化架構為使用者提供了最大的靈活性，並符合雲原生架構的標準。根據CNCF的官方定義，雲原生技術是“能夠實現彈性，可管理和可觀察的鬆耦合系統”。

作為TiDB使用者，您可以擴充套件無狀態SQL伺服器或TiSpark層（即您的計算資源），或者獨立於擴充套件TiKV（即您的儲存容量），允許您充分利用您正在消耗的資源以適應您的工作負載。您幾乎可以將TiDB無狀態SQL伺服器視為位於TiKV之上的微服務，TiKV是一個持久儲存資料的有狀態應用程式。這種設計使隔離錯誤更容易，滾動升級和維護更快，破壞性更小。

對這些TiDB優勢的權衡是部署和監控的一些額外的複雜性 - 只需要跟蹤更多的部分。然而，隨著Kubernetes的興起和CoreOS開創的運營商模式，部署和管理TiDB簡單，直接，並且越來越自動化。Kubernetes的開源TiDB運算子允許您在任何雲環境（公共，私有或混合）中部署，擴充套件，升級和維護TiDB。TiDB預設安裝Prometheus和Grafana，因此監控“開箱即用”。（請參閱我們的TiDB操作員教程。）

最終，技術資產的靈活可擴充套件性對於業務成功至關重要。這是成為下一個Facebook和下一個Friendster之間的區別。TiDB模組化和Kubernetes編排允許您為資料庫服務帶來靈活的可伸縮性。

最後，讓我們看一下TiDB的三個主要用例：MySQL可伸縮性，HTAP實時分析和統一資料儲存。

監控TiDB部署的示例Grafana儀表板

TiDB用例：MySQL可伸縮性

因為TiDB說MySQL - 它相容MySQL執行緒協議和MyDumper和MyLoader等MySQL生態系統工具 - 它非常適合那些無法擴充套件的MySQL使用者。需要明確的是，TiDB不是MySQL的替代品; 相反，它補充了MySQL。MySQL作為單例項資料庫仍然是一個很好的選擇，因此如果您的資料大小或工作量很小，請堅持使用MySQL。但如果您對這些問題感到頭疼：

• 考慮如何複製，遷移或擴充套件資料庫以獲得額外容量

• 尋找優化現有儲存容量的方法

• 關注慢查詢效能

• 研究中介軟體擴充套件解決方案或實施手動分片策略

然後，現在是開始考慮使用像TiDB這樣的分散式SQL資料庫的合適時機，它可以為您解決所有這些問題。MySQL分片解決方案的缺點是Mobike是世界上最大的無碼頭自行車共享平臺之一，它採用了TiDB（閱讀Mobike案例研究）。Mobike在200個城市運營著900萬輛智慧自行車，為2億使用者提供服務，因此不難想象其團隊在MySQL方面遇到的擴充套件瓶頸。Mobike通過部署TiDB和MySQL以及PingCAP的企業工具套件（包括Syncer）來解決其對彈性可擴充套件性的需求，後者自動將MySQL主伺服器與TiDB叢集同步。

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內部的資料可以比以前更有創造性地使用。

Yiguo.com是一個為500萬用戶提供服務的大型新鮮農產品交付平臺，它在TiDB上執行Apache Spark（閱讀Yiguo.com案例研究）以加速複雜查詢。通過從SQL Server升級其基礎架構並利用TiDB加強其現有的MySQL部署，Yiguo.com可以在中國最大的網上購物日光棍節那天全天候以高效能運行復雜的連線，以獲得洞察力並實時做出決策。

TiDB用例：統一資料儲存

作為分散式模組化HTAP資料庫，TiDB旨在橫向和靈活地擴充套件計算和儲存容量，以適應不同的工作負載，同時還可作為“單一事實來源”。通過在鍵值之上提供可擴充套件的SQL服務在商店中，TiDB旨在顯著降低與維護基礎架構堆疊中的資料管理層相關的人力和技術成本。

對於世界上最大的食品配送平臺之一Ele.me來說，統一資料儲存是採用TiDB和TiKV的關鍵原因之一（閱讀Ele.me案例研究））。以前，Ele.me的資料分散在許多不同的資料庫中--MongoDB，MySQL，Cassandra，Redis。最終，由於運營和維護成本增加，這種臨時堆疊變得難以維持。現在，來自大約2.6億使用者的Ele.me的80％實時流量由單個TiKV部署提供服務。這個TiKV叢集橫跨四個資料中心，每個資料中心都有100多個節點，可儲存數十TB的資料 - 始終可用，始終可用。