來源：http://itindex.net
隨著用戶群的增長，我們的應用程序的數據大小無法實現。我們的 Moneta 應用程序中存儲了大約 1.3 萬億行數據（存儲用戶已經閱讀過的帖子）。
由于每月累計產生大約 1000 億行數據且不斷增長，這一數字將在兩年內達到 3 萬億。在保持良好用戶體驗的同時，我們在擴展后端方面面臨嚴峻挑戰(zhàn)。
在這篇文章中，我將深入探討如何在如此大量的數據上保持毫秒級的查詢響應時間，以及 TiDB 是一個開源的 MySQL 兼容的 NewSQL 混合事務/分析處理（ HTAP）數據庫，如何為我們提供支持獲得對我們數據的實時洞察。
我將介紹為什么我們選擇 TiDB，我們如何使用它，我們學到了什么，優(yōu)秀實踐以及對未來的一些想法。
我們的痛點
本節(jié)介紹了我們的 Moneta 應用程序的體系結構，我們嘗試構建的理想體系結構，以及數據庫可伸縮性作為我們的主要難點。
系統(tǒng)架構要求
后端的 Moneta 應用程序存儲用戶已閱讀的帖子，并在知乎的推薦頁面的帖子流中過濾掉這些帖子。
Moneta 應用程序具有以下特征：
- 需要高可用性數據： Post Feed 是第一個出現的屏幕，它在推動用戶流量到知乎方面發(fā)揮著重要作用。
- 處理巨大的寫入數據： 例如，在高峰時間每秒寫入超過 4 萬條記錄，記錄數量每天增加近 30 億條記錄。
- 長期存儲歷史數據：目前，系統(tǒng)中存儲了大約 1.3 萬億條記錄。隨著每月累積約 1000 億條記錄并且不斷增長，歷史數據將在大約兩年內達到 3 萬億條記錄。
- 處理高吞吐量查詢： 在高峰時間，系統(tǒng)處理平均每秒在 1200 萬個帖子上執(zhí)行的查詢。
- 將查詢的響應時間限制為 90 毫秒或更短： 即使對于執(zhí)行時間最長的長尾查詢，也會發(fā)生這種情況。
容忍誤報： 這意味著系統(tǒng)可以為用戶調出許多有趣的帖子，即使有些帖子被錯誤地過濾掉了。
考慮到上述事實，我們需要一個具有以下功能的應用程序架構：
- 高可用性： 當用戶打開知乎的推薦頁面時，找到大量已經閱讀過的帖子是一種糟糕的用戶體驗。
- 出色的系統(tǒng)性能： 我們的應用具有高吞吐量和嚴格的響應時間要求。
-
易于擴展： 隨著業(yè)務的發(fā)展和應用程序的發(fā)展，我們希望我們的系統(tǒng)可以輕松擴展。
勘探
為了構建具有上述功能的理想架構，我們在之前的架構中集成了三個關鍵組件：- 代理： 這會將用戶的請求轉發(fā)給可用節(jié)點，并確保系統(tǒng)的高可用性。
- 緩存： 這暫時處理內存中的請求，因此我們并不總是需要處理數據庫中的請求。這可以提高系統(tǒng)性能。
-
存儲： 在使用 TiDB 之前，我們在獨立的 MySQL 上管理我們的業(yè)務數據。隨著數據量的激增，獨立的 MySQL 系統(tǒng)還不夠。 然后我們采用了 MySQL 分片和 Master High Availability Manager（ MHA）的解決方案，但是當每月有 1000 億條新記錄涌入我們的數據庫時，這個解決方案是不可取的。
MySQL Sharding 和 MHA 的缺點
MySQL 分片和 MHA 不是一個好的解決方案，因為 MySQL 分片和 MHA 都有它們的缺點。MySQL 分片的缺點：
- 應用程序代碼變得復雜且難以維護。
- 更改現有的分片鍵很麻煩。
- 升級應用程序邏輯會影響應用程序的可用性。
MHA 的缺點：
- 我們需要通過編寫腳本或使用第三方工具來實現虛擬 IP（VIP）配置。
- MHA 僅監(jiān)視主數據庫。
- 要配置 MHA，我們需要配置無密碼安全 Shell（ SSH）。這可能會導致潛在的安全風險。
- MHA 不為從屬服務器提供讀取負載平衡功能。
MHA 只能監(jiān)視主服務器（而不是從主服務器）是否可用。
在我們發(fā)現 TiDB 并將數據從 MySQL 遷移到 TiDB 之前，數據庫可伸縮性仍然是整個系統(tǒng)的弱點。
什么是 TiDB？
TiDB 平臺是一組組件，當它們一起使用時，它們將成為具有 HTAP 功能的 NewSQL 數據庫。
TiDB 平臺架構
在 TiDB 平臺內部，主要組件如下：
- TiDB 服務器是一個無狀態(tài)的 SQL 層，它處理用戶的 SQL 查詢，訪問存儲層中的數據，并將相應的結果返回給應用程序。它與 MySQL 兼容并且位于 TiKV 之上。
- TiKV 服務器是數據持久存在的分布式事務鍵值存儲層。它使用 Raft 共識協議進行復制，以確保強大的數據一致性和高可用性。
- TiSpark 集群也位于 TiKV 之上。它是一個 Apache Spark 插件，可與 TiDB 平臺配合使用，支持商業(yè)智能（BI）分析師和數據科學家的復雜在線分析處理（OLAP）查詢。
放置驅動程序（PD）服務器是由 etcd 支持的元數據集群，用于管理和調度 TiKV。
除了這些主要組件之外，TiDB 還擁有一個工具生態(tài)系統(tǒng)，例如用于快速部署的 Ansible 腳本，用于從 MySQL 遷移的 Syncer 和 TiDB 數據遷移。
以及用于收集對 TiDB 群集進行的邏輯更改并提供增量備份的 TiDB Binlog。復制到下游（TiDB，Kafka 或 MySQL）。
TiDB 的主要功能包括：
- 水平可擴展性。
- MySQL 兼容的語法。
- 具有強一致性的分布式事務。
- 云原生架構。
- 使用 HTAP 進行最小提取，轉換，加載（ ETL）。
- 容錯和 Raft 恢復。
-
在線架構更改。
我們如何使用 TiDB
在本節(jié)中，我將向您展示如何在 Moneta 的架構中運行 TiDB 以及 Moneta 應用程序的性能指標。
我們架構中的 TiDB
知乎的 Moneta 應用程序中的 TiDB 架構
我們在系統(tǒng)中部署了 TiDB，Moneta 應用程序的整體架構變?yōu)椋?/span>
- 頂層：無狀態(tài)和可伸縮的客戶端 API 和代理。這些組件易于擴展。
- 中間層： 軟狀態(tài)組件和分層 Redis 緩存作為主要部分。當服務中斷時，這些組件可以通過恢復保存在 TiDB 群集中的數據來自我恢復服務。
底層： TiDB 集群存儲所有有狀態(tài)數據。它的組件高度可用，如果節(jié)點崩潰，它可以自我恢復其服務。
在該系統(tǒng)中，所有組件都是可自我恢復的，整個系統(tǒng)具有全局故障監(jiān)視機制。然后，我們使用 Kubernetes 來協調整個系統(tǒng)，以確保整個服務的高可用性。
TiDB 的性能指標
由于我們在生產環(huán)境中應用了 TiDB，因此我們的系統(tǒng)具有高可用性和易于擴展性，并且系統(tǒng)性能得到顯著改善。 例如，在 2019 年 6 月為 Moneta 應用程序采用一組性能指標。
在高峰時間每秒寫入 40,000 行數據：
每秒寫入的數據行（數千）
在高峰時段每秒檢查 30,000 個查詢和 1200 萬個帖子：
每秒寫入的數據行（數千）
第 99 百分位響應時間約為 25 毫秒，第 999 百分位響應時間約為 50 毫秒。實際上，平均響應時間遠遠小于這些數字，即使對于需要穩(wěn)定響應時間的長尾查詢也是如此。
第 99 百分位響應時間
第 999 百分位響應時間
我們學到了什么
我們遷移到 TiDB 并非順利，在這里，我們想分享一些經驗教訓。
更快地導入數據 我們使用 TiDB 數據遷移（DM）來收集 MySQL 增量 Binlog 文件，然后使用 TiDB Lightning 將數據快速導入 TiDB 集群。
令我們驚訝的是，將這 1.1 萬億條記錄導入 TiDB 只用了四天時間。如果我們邏輯地將數據寫入系統(tǒng)，可能需要一個月或更長時間。如果我們有更多的硬件資源，我們可以更快地導入數據。
減少查詢延遲
完成遷移后，我們測試了少量的讀取流量。當 Moneta 應用程序首次上線時，我們發(fā)現查詢延遲不符合我們的要求。為解決延遲問題，我們與 PingCap 工程師合作調整系統(tǒng)性能。在此過程中，我們積累了寶貴的數據和數據處理知識：
- 有些查詢對查詢延遲很敏感，有些則不然。我們部署了一個單獨的 TiDB 數據庫來處理對延遲敏感的查詢。（其他非延遲敏感的查詢在不同的 TiDB 數據庫中處理。） 這樣，大型查詢和對延遲敏感的查詢在不同的數據庫中處理，前者的執(zhí)行不會影響后者。
- 對于沒有理想執(zhí)行計劃的查詢，我們編寫了 SQL 提示來幫助執(zhí)行引擎選擇最佳執(zhí)行計劃。
我們使用低精度時間戳 Oracle（ TSO）和預處理語句來減少網絡往返。
評估資源
在我們嘗試 TiDB 之前，我們沒有分析我們需要多少硬件資源來支持 MySQL 端的相同數據量。
為了降低維護成本，我們在單主機 - 單從機拓撲中部署了 MySQL。相反，在 TiDB 中實現的 Raft 協議至少需要三個副本。
因此，我們需要更多的硬件資源來支持 TiDB 中的業(yè)務數據，我們需要提前準備機器資源。
一旦我們的數據中心設置正確，我們就可以快速完成對 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 發(fā)布后啟用了 Titan。
下圖分別顯示了與 RocksDB 和 Titan 相比的寫入和查詢延遲：
在 RocksDB 和 Titan 中編寫和查詢延遲
統(tǒng)計數據顯示，在我們啟用 Titan 后，寫入和查詢延遲都急劇下降。這真是太驚人了！當我們看到統(tǒng)計數據時，我們無法相信自己的眼睛。
②表分區(qū)改進了查詢性能
我們還在反垃圾郵件應用程序中使用了 TiDB 3.0 的表分區(qū)功能。使用此功能，我們可以按時將表分成多個分區(qū)。
當查詢到來時，它將在覆蓋目標時間范圍的分區(qū)上執(zhí)行。這大大提高了我們的查詢性能。
讓我們考慮一下如果我們將來在 Moneta 和反垃圾郵件應用程序中實施 TiDB 3.0 會發(fā)生什么。
③Moneta 應用程序中的 TiDB 3.0
TiDB 3.0 具有諸如 gRPC 中的批處理消息，多線程 Raftstore，SQL 計劃管理和 TiFlash 等功能。我們相信這些將為 Moneta 應用增添光彩。
④gRPC 和多線程 Raftstore 中的批處理消息
Moneta 的寫入吞吐量超過每秒 4 萬次交易（TPS），TiDB 3.0 可以批量發(fā)送和接收 Raft 消息，并且可以在多個線程中處理 Region Raft 邏輯。我們相信這些功能將顯著提高我們系統(tǒng)的并發(fā)能力⑤SQL 計劃管理
如上所述，我們編寫了大量 SQL 提示，以使查詢優(yōu)化器選擇最佳執(zhí)行計劃。TiDB 3.0 添加了一個 SQL 計劃管理功能，可以直接在 TiDB 服務器中將查詢綁定到特定的執(zhí)行計劃。使用此功能，我們不需要修改查詢文本以注入提示。
⑥TiFlash
在 TiDB DevCon 2019 上，我第一次聽說 TiFlash 是 TiDB 的擴展分析引擎。它使用面向列的存儲技術來實現高數據壓縮率，并在數據復制中應用擴展的 Raft 一致性算法以確保數據安全性。
由于我們擁有高寫入吞吐量的海量數據，因此我們無法每天使用 ETL 將數據復制到 Hadoop 進行分析。但是對于 TiFlash，我們樂觀地認為我們可以輕松分析我們龐大的數據量。
⑦反垃圾郵件應用程序中的 TiDB 3.0
與 Moneta 應用程序的巨大歷史數據大小相比，反垃圾郵件應用程序具有更高的寫入吞吐量。但是，它僅查詢過去 48 小時內存儲的數據。在此應用程序中，數據每天增加 80 億條記錄和 1.5 TB。
由于 TiDB 3.0 可以批量發(fā)送和接收 Raft 消息，并且它可以在多個線程中處理 Region Raft 邏輯，因此我們可以用更少的節(jié)點管理應用程序。
以前，我們使用了七個物理節(jié)點，但現在我們只需要五個。即使我們使用商用硬件，這些功能也可提升性能。
下一步是什么
TiDB 是一個與 MySQL 兼容的數據庫，因此我們可以像使用 MySQL 一樣使用它。
由于 TiDB 的橫向可擴展性，現在我們可以自由擴展我們的數據庫，即使我們有超過一萬億的記錄來應對。
到目前為止，我們已經在我們的應用程序中使用了相當多的開源軟件。我們還學到了很多關于使用 TiDB 處理系統(tǒng)問題的知識。
我們決定參與開發(fā)開源工具，并參與社區(qū)的長期發(fā)展?；谖覀兣c PingCAP 的共同努力，TiDB 將變得更加強大。
免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯系我們，謝謝！
下載文檔
