1.3萬億條資料查詢如何做到毫秒級響應？

作為中國最大的知識共享平臺，我們目前擁有 2.2 億註冊使用者，3000 萬個問題，網站答案超過 1.3 億。

隨著使用者群的增長，我們的應用程式的資料大小無法實現。我們的 Moneta 應用程式中儲存了大約 1.3 萬億行資料（儲存使用者已經閱讀過的帖子）。

由於每月累計產生大約 1000 億行資料且不斷增長，這一數字將在兩年內達到 3 萬億。在保持良好使用者體驗的同時，我們在擴充套件後端方面面臨嚴峻挑戰。

在這篇文章中，我將深入探討如何在如此大量的資料上保持毫秒級的查詢響應時間，以及 TiDB 是一個開源的 MySQL 相容的 NewSQL 混合事務/分析處理（ HTAP）資料庫，如何為我們提供支援獲得對我們資料的實時洞察。

我將介紹為什麼我們選擇 TiDB，我們如何使用它，我們學到了什麼，優秀實踐以及對未來的一些想法。 

我們的痛點

---

本節介紹了我們的 Moneta 應用程式的體系結構，我們嘗試構建的理想體系結構，以及資料庫可伸縮性作為我們的主要難點。

系統架構要求

知乎的 Post Feed 服務是一個關鍵系統，使用者可以透過該系統接收網站上釋出的內容。

後端的 Moneta 應用程式儲存使用者已閱讀的帖子，並在知乎的推薦頁面的帖子流中過濾掉這些帖子。

Moneta 應用程式具有以下特徵：

 ·  需要高可用性資料：Post Feed 是第一個出現的螢幕，它在推動使用者流量到知乎方面發揮著重要作用。

 ·  處理巨大的寫入資料：例如，在高峰時間每秒寫入超過 4 萬條記錄，記錄數量每天增加近 30 億條記錄。

 ·  長期儲存歷史資料：目前，系統中儲存了大約 1.3 萬億條記錄。隨著每月累積約 1000 億條記錄並且不斷增長，歷史資料將在大約兩年內達到 3 萬億條記錄。

 · 處理高吞吐量查詢：在高峰時間，系統處理平均每秒在 1200 萬個帖子上執行的查詢。

 · 將查詢的響應時間限制為 90 毫秒或更短：即使對於執行時間最長的長尾查詢，也會發生這種情況。

 · 容忍誤報：這意味著系統可以為使用者調出許多有趣的帖子，即使有些帖子被錯誤地過濾掉了。

考慮到上述事實，我們需要一個具有以下功能的應用程式架構：

 · 高可用性：當使用者開啟知乎的推薦頁面時，找到大量已經閱讀過的帖子是一種糟糕的使用者體驗。

 · 出色的系統效能：我們的應用具有高吞吐量和嚴格的響應時間要求。

 · 易於擴充套件：隨著業務的發展和應用程式的發展，我們希望我們的系統可以輕鬆擴充套件。

勘探

為了構建具有上述功能的理想架構，我們在之前的架構中整合了三個關鍵元件：

 · 代理：這會將使用者的請求轉發給可用節點，並確保系統的高可用性。

 · 快取：這暫時處理記憶體中的請求，因此我們並不總是需要處理資料庫中的請求。這可以提高系統效能。

 · 儲存：在使用 TiDB 之前，我們在獨立的 MySQL 上管理我們的業務資料。隨著資料量的激增，獨立的 MySQL 系統還不夠。

然後我們採用了 MySQL 分片和 Master High Availability Manager（ MHA）的解決方案，但是當每月有 1000 億條新記錄湧入我們的資料庫時，這個解決方案是不可取的。

MySQL Sharding 和 MHA 的缺點

MySQL 分片和 MHA 不是一個好的解決方案，因為 MySQL 分片和 MHA 都有它們的缺點。

MySQL 分片的缺點：

 · 應用程式程式碼變得複雜且難以維護。

 · 更改現有的分片鍵很麻煩。

 · 升級應用程式邏輯會影響應用程式的可用性。

MHA 的缺點：

 · 我們需要透過編寫指令碼或使用第三方工具來實現虛擬 IP（VIP）配置。

 · MHA 僅監視主資料庫。

 · 要配置 MHA，我們需要配置無密碼安全 Shell（ SSH）。這可能會導致潛在的安全風險。

 · MHA 不為從屬伺服器提供讀取負載平衡功能。

 · MHA 只能監視主伺服器（而不是從主伺服器）是否可用。

在我們發現 TiDB 並將資料從 MySQL 遷移到 TiDB 之前，資料庫可伸縮性仍然是整個系統的弱點。

什麼是 TiDB？

---

TiDB 平臺是一組元件，當它們一起使用時，它們將成為具有 HTAP 功能的 NewSQL 資料庫。

TiDB 平臺架構

在 TiDB 平臺內部，主要元件如下：

 · TiDB 伺服器是一個無狀態的 SQL 層，它處理使用者的 SQL 查詢，訪問儲存層中的資料，並將相應的結果返回給應用程式。它與 MySQL 相容並且位於 TiKV 之上。

 · TiKV 伺服器是資料持久存在的分散式事務鍵值儲存層。它使用 Raft 共識協議進行復制，以確保強大的資料一致性和高可用性。

 · TiSpark 叢集也位於 TiKV 之上。它是一個 Apache Spark 外掛，可與 TiDB 平臺配合使用，支援商業智慧（BI）分析師和資料科學家的複雜線上分析處理（OLAP）查詢。

 · 放置驅動程式（PD）伺服器是由 etcd 支援的後設資料叢集，用於管理和排程 TiKV。

除了這些主要元件之外，TiDB 還擁有一個工具生態系統，例如用於快速部署的  Ansible 指令碼，用於從 MySQL 遷移的 Syncer 和 TiDB 資料遷移。

以及用於收集對 TiDB 群集進行的邏輯更改並提供增量備份的 TiDB Binlog。複製到下游（TiDB，Kafka 或 MySQL）。

TiDB 的主要功能包括：

 · 水平可擴充套件性。

 · MySQL 相容的語法。

 · 具有強一致性的分散式事務。

 · 雲原生架構。

 · 使用 HTAP 進行最小提取，轉換，載入（ ETL）。

 · 容錯和 Raft 恢復。

 · 線上架構更改。

我們如何使用 TiDB

---

在本節中，我將向您展示如何在 Moneta 的架構中執行 TiDB 以及 Moneta 應用程式的效能指標。

我們架構中的 TiDB

知乎的 Moneta 應用程式中的 TiDB 架構

我們在系統中部署了 TiDB，Moneta 應用程式的整體架構變為：

 · 頂層：無狀態和可伸縮的客戶端 API 和代理。這些元件易於擴充套件。

 · 中間層：軟狀態元件和分層 Redis 快取作為主要部分。當服務中斷時，這些元件可以透過恢復儲存在 TiDB 群集中的資料來自我恢復服務。

 · 底層：TiDB 叢集儲存所有有狀態資料。它的元件高度可用，如果節點崩潰，它可以自我恢復其服務。

在該系統中，所有元件都是可自我恢復的，整個系統具有全域性故障監視機制。然後，我們使用 Kubernetes 來協調整個系統，以確保整個服務的高可用性。

TiDB 的效能指標

由於我們在生產環境中應用了 TiDB，因此我們的系統具有高可用性和易於擴充套件性，並且系統效能得到顯著改善。例如，在 2019 年 6 月為 Moneta 應用程式採用一組效能指標。

在高峰時間每秒寫入 40,000 行資料：

每秒寫入的資料行（數千）

在高峰時段每秒檢查 30,000 個查詢和 1200 萬個帖子：

每秒寫入的資料行（數千）

第 99 百分位響應時間約為 25 毫秒，第 999 百分位響應時間約為 50 毫秒。實際上，平均響應時間遠遠小於這些數字，即使對於需要穩定響應時間的長尾查詢也是如此。

第 99 百分位響應時間

第 999 百分位響應時間

我們學到了什麼

---

我們遷移到 TiDB 並非順利，在這裡，我們想分享一些經驗教訓。

更快地匯入資料

我們使用 TiDB 資料遷移（DM）來收集 MySQL 增量 Binlog 檔案，然後使用 TiDB Lightning 將資料快速匯入 TiDB 叢集。

令我們驚訝的是，將這 1.1 萬億條記錄匯入 TiDB 只用了四天時間。如果我們邏輯地將資料寫入系統，可能需要一個月或更長時間。如果我們有更多的硬體資源，我們可以更快地匯入資料。

減少查詢延遲

完成遷移後，我們測試了少量的讀取流量。當 Moneta 應用程式首次上線時，我們發現查詢延遲不符合我們的要求。為解決延遲問題，我們與 PingCap 工程師合作調整系統效能。

在此過程中，我們積累了寶貴的資料和資料處理知識：

有些查詢對查詢延遲很敏感，有些則不然。我們部署了一個單獨的 TiDB 資料庫來處理對延遲敏感的查詢。（其他非延遲敏感的查詢在不同的 TiDB 資料庫中處理。）

這樣，大型查詢和對延遲敏感的查詢在不同的資料庫中處理，前者的執行不會影響後者。

對於沒有理想執行計劃的查詢，我們編寫了 SQL 提示來幫助執行引擎選擇最佳執行計劃。

我們使用低精度時間戳 Oracle（ TSO）和預處理語句來減少網路往返。

評估資源

在我們嘗試 TiDB 之前，我們沒有分析我們需要多少硬體資源來支援 MySQL 端的相同資料量。

為了降低維護成本，我們在單主機 - 單從機拓撲中部署了 MySQL。相反，在 TiDB 中實現的 Raft 協議至少需要三個副本。

因此，我們需要更多的硬體資源來支援 TiDB 中的業務資料，我們需要提前準備機器資源。

一旦我們的資料中心設定正確，我們就可以快速完成對 TiDB 的評估。

對 TiDB 3.0 的期望

---

在知乎，反垃圾郵件和 Moneta 應用程式的架構相同。我們在用於生產資料的反垃圾郵件應用程式中嘗試了 TiDB 3.0（TiDB 3.0.0-rc.1 和 TiDB 3.0.0-rc.2）的候選版本中的 Titan 和 Table Partition。 

①Titan 縮短了延遲

反垃圾郵件應用程式一直受到嚴重的查詢和寫入延遲折磨。

我們聽說 TiDB 3.0 將引入 Titan，一種鍵值儲存引擎，用於在使用大值時減少  RocksDB（TiKV 中的底層儲存引擎）的寫入放大。為了嘗試這個功能，我們在 TiDB 3.0.0-rc.2 釋出後啟用了 Titan。

下圖分別顯示了與 RocksDB 和 Titan 相比的寫入和查詢延遲：

在 RocksDB 和 Titan 中編寫和查詢延遲

統計資料顯示，在我們啟用 Titan 後，寫入和查詢延遲都急劇下降。這真是太驚人了！當我們看到統計資料時，我們無法相信自己的眼睛。

②表分割槽改進了查詢效能

我們還在反垃圾郵件應用程式中使用了 TiDB 3.0 的表分割槽功能。使用此功能，我們可以按時將表分成多個分割槽。

當查詢到來時，它將在覆蓋目標時間範圍的分割槽上執行。這大大提高了我們的查詢效能。

讓我們考慮一下如果我們將來在 Moneta 和反垃圾郵件應用程式中實施 TiDB 3.0 會發生什麼。

③Moneta 應用程式中的 TiDB 3.0

TiDB 3.0 具有諸如 gRPC 中的批處理訊息，多執行緒 Raftstore，SQL 計劃管理和 TiFlash 等功能。我們相信這些將為 Moneta 應用增添光彩。

④gRPC 和多執行緒 Raftstore 中的批處理訊息

Moneta 的寫入吞吐量超過每秒 4 萬次交易（TPS），TiDB 3.0 可以批次傳送和接收 Raft 訊息，並且可以在多個執行緒中處理 Region Raft 邏輯。我們相信這些功能將顯著提高我們系統的併發能力。

⑤SQL 計劃管理

如上所述，我們編寫了大量 SQL 提示，以使查詢最佳化器選擇最佳執行計劃。

TiDB 3.0 新增了一個 SQL 計劃管理功能，可以直接在 TiDB 伺服器中將查詢繫結到特定的執行計劃。使用此功能，我們不需要修改查詢文字以注入提示。

⑥TiFlash

在 TiDB DevCon 2019 上，我第一次聽說 TiFlash 是 TiDB 的擴充套件分析引擎。

它使用面向列的儲存技術來實現高資料壓縮率，並在資料複製中應用擴充套件的 Raft 一致性演算法以確保資料安全性。

由於我們擁有高寫入吞吐量的海量資料，因此我們無法每天使用 ETL 將資料複製到 Hadoop 進行分析。但是對於 TiFlash，我們樂觀地認為我們可以輕鬆分析我們龐大的資料量。

⑦反垃圾郵件應用程式中的 TiDB 3.0

與 Moneta 應用程式的巨大歷史資料大小相比，反垃圾郵件應用程式具有更高的寫入吞吐量。

但是，它僅查詢過去 48 小時記憶體儲的資料。在此應用程式中，資料每天增加 80 億條記錄和 1.5 TB。

由於 TiDB 3.0 可以批次傳送和接收 Raft 訊息，並且它可以在多個執行緒中處理 Region Raft 邏輯，因此我們可以用更少的節點管理應用程式。

以前，我們使用了七個物理節點，但現在我們只需要五個。即使我們使用商用硬體，這些功能也可提升效能。

下一步是什麼

---

TiDB 是一個與 MySQL 相容的資料庫，因此我們可以像使用 MySQL 一樣使用它。

由於 TiDB 的橫向可擴充套件性，現在我們可以自由擴充套件我們的資料庫，即使我們有超過一萬億的記錄來應對。 

到目前為止，我們已經在我們的應用程式中使用了相當多的開源軟體。我們還學到了很多關於使用 TiDB 處理系統問題的知識。

我們決定參與開發開源工具，並參與社群的長期發展。基於我們與 PingCAP 的共同努力，TiDB 將變得更加強大。

作者：孫曉光

簡介：知乎搜尋後端負責人，目前承擔知乎搜尋後端架構設計以及工程團隊的管理工作。曾多年從事私有云相關產品開發工作，關注雲原生技術，TiKV 專案 Committer。

出處：

原文連結：

另：想了解更多Tidb資料庫的知識與用法，歡迎關注墨天輪“Tidb專欄”（地址：），此外，墨天輪開放了很多資料庫專欄，如 GaussDB、PolarDB、OceanBase、TDSQL、GoldenDB 等眾多資料庫專欄，歡迎關注學習！