萬億條數據查詢如何做到毫秒級響應？

知乎，在古典中文中意為“你知道嗎？”，它是中國的 Quora，一個問答網站，其中各種問題由用戶社區創建，回答，編輯和組織。作為中國最大的知識共享平臺，我們目前擁有 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?的缺點

應用程序代碼變得復雜且難以維護。

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

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

我們需要通過編寫腳本或使用第三方工具來實現虛擬 IP（VIP）配置。

MHA 僅監視主數據庫。

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

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

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

什么是 TiDB？

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

TiDB 服務器是一個無狀態的 SQL 層，它處理用戶的 SQL 查詢，訪問存儲層中的數據，并將相應的結果返回給應用程序。它與 MySQL 兼容并且位于 TiKV 之上。

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

TiSpark 集群也位于 TiKV 之上。它是一個 Apache Spark 插件，可與 TiDB 平臺配合使用，支持商業智能（BI）分析師和數據科學家的復雜在線分析處理（OLAP）查詢。

放置驅動程序（PD）服務器是由 etcd 支持的元數據集群，用于管理和調度 TiKV。

水平可擴展性。

MySQL 兼容的語法。

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

云原生架構。

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

容錯和 Raft 恢復。

在線架構更改。

我們如何使用 TiDB

我們架構中的 TiDB

頂層：無狀態和可伸縮的客戶端 API 和代理。這些組件易于擴展。

中間層：軟狀態組件和分層 Redis 緩存作為主要部分。當服務中斷時，這些組件可以通過恢復保存在 TiDB 群集中的數據來自我恢復服務。

底層：TiDB 集群存儲所有有狀態數據。它的組件高度可用，如果節點崩潰，它可以自我恢復其服務。

TiDB 的性能指標

在高峰時間每秒寫入 40,000 行數據：

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

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

第 99 百分位響應時間

我們學到了什么

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

更快地導入數據

減少查詢延遲

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

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

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

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

評估資源

對?TiDB 3.0 的期望

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

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

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

下一步是什么

出處：http://itindex.net/

本文轉載自微信公眾號朱小廝的博客

MySQL 存儲 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。