1.3 萬億條數(shù)據(jù)查詢，如何做到毫秒級(jí)響應(yīng)？

來源：http://itindex.net

我們的痛點(diǎn)
本節(jié)介紹了我們的 Moneta 應(yīng)用程序的體系結(jié)構(gòu)，我們嘗試構(gòu)建的理想體系結(jié)構(gòu)，以及數(shù)據(jù)庫可伸縮性作為我們的主要難點(diǎn)。

系統(tǒng)架構(gòu)要求

容忍誤報(bào)： 這意味著系統(tǒng)可以為用戶調(diào)出許多有趣的帖子，即使有些帖子被錯(cuò)誤地過濾掉了。 
考慮到上述事實(shí)，我們需要一個(gè)具有以下功能的應(yīng)用程序架構(gòu)：

勘探

• 代理： 這會(huì)將用戶的請(qǐng)求轉(zhuǎn)發(fā)給可用節(jié)點(diǎn)，并確保系統(tǒng)的高可用性。
• 緩存： 這暫時(shí)處理內(nèi)存中的請(qǐng)求，因此我們并不總是需要處理數(shù)據(jù)庫中的請(qǐng)求。這可以提高系統(tǒng)性能。
• 存儲(chǔ)： 在使用 TiDB 之前，我們?cè)讵?dú)立的 MySQL 上管理我們的業(yè)務(wù)數(shù)據(jù)。隨著數(shù)據(jù)量的激增，獨(dú)立的 MySQL 系統(tǒng)還不夠。 然后我們采用了 MySQL 分片和 Master High Availability Manager（ MHA）的解決方案，但是當(dāng)每月有 1000 億條新記錄涌入我們的數(shù)據(jù)庫時(shí)，這個(gè)解決方案是不可取的。
  

MySQL Sharding 和 MHA 的缺點(diǎn)

MySQL 分片的缺點(diǎn)：

• 應(yīng)用程序代碼變得復(fù)雜且難以維護(hù)。
• 更改現(xiàn)有的分片鍵很麻煩。
• 升級(jí)應(yīng)用程序邏輯會(huì)影響應(yīng)用程序的可用性。

MHA 的缺點(diǎn)：

• 我們需要通過編寫腳本或使用第三方工具來實(shí)現(xiàn)虛擬 IP（VIP）配置。
• MHA 僅監(jiān)視主數(shù)據(jù)庫。
• 要配置 MHA，我們需要配置無密碼安全 Shell（ SSH）。這可能會(huì)導(dǎo)致潛在的安全風(fēng)險(xiǎn)。
• MHA 不為從屬服務(wù)器提供讀取負(fù)載平衡功能。

MHA 只能監(jiān)視主服務(wù)器（而不是從主服務(wù)器）是否可用。 
在我們發(fā)現(xiàn) TiDB 并將數(shù)據(jù)從 MySQL 遷移到 TiDB 之前，數(shù)據(jù)庫可伸縮性仍然是整個(gè)系統(tǒng)的弱點(diǎn)。

什么是 TiDB？
TiDB 平臺(tái)是一組組件，當(dāng)它們一起使用時(shí)，它們將成為具有 HTAP 功能的 NewSQL 數(shù)據(jù)庫。

TiDB 平臺(tái)架構(gòu) 

 在 TiDB 平臺(tái)內(nèi)部，主要組件如下：

• TiDB 服務(wù)器是一個(gè)無狀態(tài)的 SQL 層，它處理用戶的 SQL 查詢，訪問存儲(chǔ)層中的數(shù)據(jù)，并將相應(yīng)的結(jié)果返回給應(yīng)用程序。它與 MySQL 兼容并且位于 TiKV 之上。
• TiKV 服務(wù)器是數(shù)據(jù)持久存在的分布式事務(wù)鍵值存儲(chǔ)層。它使用 Raft 共識(shí)協(xié)議進(jìn)行復(fù)制，以確保強(qiáng)大的數(shù)據(jù)一致性和高可用性。
• TiSpark 集群也位于 TiKV 之上。它是一個(gè) Apache Spark 插件，可與 TiDB 平臺(tái)配合使用，支持商業(yè)智能（BI）分析師和數(shù)據(jù)科學(xué)家的復(fù)雜在線分析處理（OLAP）查詢。

放置驅(qū)動(dòng)程序（PD）服務(wù)器是由 etcd 支持的元數(shù)據(jù)集群，用于管理和調(diào)度 TiKV。 
除了這些主要組件之外，TiDB 還擁有一個(gè)工具生態(tài)系統(tǒng)，例如用于快速部署的  Ansible 腳本，用于從 MySQL 遷移的 Syncer 和 TiDB 數(shù)據(jù)遷移。
以及用于收集對(duì) TiDB 群集進(jìn)行的邏輯更改并提供增量備份的 TiDB Binlog。復(fù)制到下游（TiDB，Kafka 或 MySQL）。
TiDB 的主要功能包括：

• 水平可擴(kuò)展性。
• MySQL 兼容的語法。
• 具有強(qiáng)一致性的分布式事務(wù)。
• 云原生架構(gòu)。
• 使用 HTAP 進(jìn)行最小提取，轉(zhuǎn)換，加載（ ETL）。
• 容錯(cuò)和 Raft 恢復(fù)。
• 在線架構(gòu)更改。
  

我們?nèi)绾问褂?TiDB
在本節(jié)中，我將向您展示如何在 Moneta 的架構(gòu)中運(yùn)行 TiDB 以及 Moneta 應(yīng)用程序的性能指標(biāo)。

我們架構(gòu)中的 TiDB

知乎的 Moneta 應(yīng)用程序中的 TiDB 架構(gòu)

 我們?cè)谙到y(tǒng)中部署了 TiDB，Moneta 應(yīng)用程序的整體架構(gòu)變?yōu)椋?/span>

• 頂層：無狀態(tài)和可伸縮的客戶端 API 和代理。這些組件易于擴(kuò)展。
• 中間層： 軟狀態(tài)組件和分層 Redis 緩存作為主要部分。當(dāng)服務(wù)中斷時(shí)，這些組件可以通過恢復(fù)保存在 TiDB 群集中的數(shù)據(jù)來自我恢復(fù)服務(wù)。

底層： TiDB 集群存儲(chǔ)所有有狀態(tài)數(shù)據(jù)。它的組件高度可用，如果節(jié)點(diǎn)崩潰，它可以自我恢復(fù)其服務(wù)。 
在該系統(tǒng)中，所有組件都是可自我恢復(fù)的，整個(gè)系統(tǒng)具有全局故障監(jiān)視機(jī)制。然后，我們使用 Kubernetes 來協(xié)調(diào)整個(gè)系統(tǒng)，以確保整個(gè)服務(wù)的高可用性。

TiDB 的性能指標(biāo)

由于我們?cè)谏a(chǎn)環(huán)境中應(yīng)用了 TiDB，因此我們的系統(tǒng)具有高可用性和易于擴(kuò)展性，并且系統(tǒng)性能得到顯著改善。 例如，在 2019 年 6 月為 Moneta 應(yīng)用程序采用一組性能指標(biāo)。
在高峰時(shí)間每秒寫入 40,000 行數(shù)據(jù)：

每秒寫入的數(shù)據(jù)行（數(shù)千）

 在高峰時(shí)段每秒檢查 30,000 個(gè)查詢和 1200 萬個(gè)帖子：

每秒寫入的數(shù)據(jù)行（數(shù)千）

 第 99 百分位響應(yīng)時(shí)間約為 25 毫秒，第 999 百分位響應(yīng)時(shí)間約為 50 毫秒。實(shí)際上，平均響應(yīng)時(shí)間遠(yuǎn)遠(yuǎn)小于這些數(shù)字，即使對(duì)于需要穩(wěn)定響應(yīng)時(shí)間的長尾查詢也是如此。

第 99 百分位響應(yīng)時(shí)間

第 999 百分位響應(yīng)時(shí)間

我們學(xué)到了什么
我們遷移到 TiDB 并非順利，在這里，我們想分享一些經(jīng)驗(yàn)教訓(xùn)。 
更快地導(dǎo)入數(shù)據(jù) 我們使用 TiDB 數(shù)據(jù)遷移（DM）來收集 MySQL 增量 Binlog 文件，然后使用 TiDB Lightning 將數(shù)據(jù)快速導(dǎo)入 TiDB 集群。
令我們驚訝的是，將這 1.1 萬億條記錄導(dǎo)入 TiDB 只用了四天時(shí)間。如果我們邏輯地將數(shù)據(jù)寫入系統(tǒng)，可能需要一個(gè)月或更長時(shí)間。如果我們有更多的硬件資源，我們可以更快地導(dǎo)入數(shù)據(jù)。

減少查詢延遲

• 有些查詢對(duì)查詢延遲很敏感，有些則不然。我們部署了一個(gè)單獨(dú)的 TiDB 數(shù)據(jù)庫來處理對(duì)延遲敏感的查詢。（其他非延遲敏感的查詢?cè)诓煌?TiDB 數(shù)據(jù)庫中處理。） 這樣，大型查詢和對(duì)延遲敏感的查詢?cè)诓煌臄?shù)據(jù)庫中處理，前者的執(zhí)行不會(huì)影響后者。
• 對(duì)于沒有理想執(zhí)行計(jì)劃的查詢，我們編寫了 SQL 提示來幫助執(zhí)行引擎選擇最佳執(zhí)行計(jì)劃。

我們使用低精度時(shí)間戳 Oracle（ TSO）和預(yù)處理語句來減少網(wǎng)絡(luò)往返。 
評(píng)估資源
在我們嘗試 TiDB 之前，我們沒有分析我們需要多少硬件資源來支持 MySQL 端的相同數(shù)據(jù)量。 
為了降低維護(hù)成本，我們?cè)趩沃鳈C(jī) - 單從機(jī)拓?fù)渲胁渴鹆?MySQL。相反，在 TiDB 中實(shí)現(xiàn)的 Raft 協(xié)議至少需要三個(gè)副本。
因此，我們需要更多的硬件資源來支持 TiDB 中的業(yè)務(wù)數(shù)據(jù)，我們需要提前準(zhǔn)備機(jī)器資源。
一旦我們的數(shù)據(jù)中心設(shè)置正確，我們就可以快速完成對(duì) TiDB 的評(píng)估。

對(duì) TiDB 3.0 的期望
在知乎，反垃圾郵件和 Moneta 應(yīng)用程序的架構(gòu)相同。我們?cè)谟糜谏a(chǎn)數(shù)據(jù)的反垃圾郵件應(yīng)用程序中嘗試了 TiDB 3.0（TiDB 3.0.0-rc.1 和 TiDB 3.0.0-rc.2）的候選版本中的 Titan 和 Table Partition。
①Titan 縮短了延遲
反垃圾郵件應(yīng)用程序一直受到嚴(yán)重的查詢和寫入延遲折磨。
我們聽說 TiDB 3.0 將引入 Titan，一種鍵值存儲(chǔ)引擎，用于在使用大值時(shí)減少  RocksDB（TiKV 中的底層存儲(chǔ)引擎）的寫入放大。 為了嘗試這個(gè)功能，我們?cè)?TiDB 3.0.0-rc.2 發(fā)布后啟用了 Titan。
下圖分別顯示了與 RocksDB 和 Titan 相比的寫入和查詢延遲：

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

 統(tǒng)計(jì)數(shù)據(jù)顯示，在我們啟用 Titan 后，寫入和查詢延遲都急劇下降。這真是太驚人了！當(dāng)我們看到統(tǒng)計(jì)數(shù)據(jù)時(shí)，我們無法相信自己的眼睛。
②表分區(qū)改進(jìn)了查詢性能
我們還在反垃圾郵件應(yīng)用程序中使用了 TiDB 3.0 的表分區(qū)功能。使用此功能，我們可以按時(shí)將表分成多個(gè)分區(qū)。
當(dāng)查詢到來時(shí)，它將在覆蓋目標(biāo)時(shí)間范圍的分區(qū)上執(zhí)行。這大大提高了我們的查詢性能。
讓我們考慮一下如果我們將來在 Moneta 和反垃圾郵件應(yīng)用程序中實(shí)施 TiDB 3.0 會(huì)發(fā)生什么。
③Moneta 應(yīng)用程序中的 TiDB 3.0
TiDB 3.0 具有諸如 gRPC 中的批處理消息，多線程 Raftstore，SQL 計(jì)劃管理和 TiFlash 等功能。我們相信這些將為 Moneta 應(yīng)用增添光彩。

④gRPC 和多線程 Raftstore 中的批處理消息

⑤SQL 計(jì)劃管理

⑥TiFlash

⑦反垃圾郵件應(yīng)用程序中的 TiDB 3.0

下一步是什么
TiDB 是一個(gè)與 MySQL 兼容的數(shù)據(jù)庫，因此我們可以像使用 MySQL 一樣使用它。
由于 TiDB 的橫向可擴(kuò)展性，現(xiàn)在我們可以自由擴(kuò)展我們的數(shù)據(jù)庫，即使我們有超過一萬億的記錄來應(yīng)對(duì)。
到目前為止，我們已經(jīng)在我們的應(yīng)用程序中使用了相當(dāng)多的開源軟件。我們還學(xué)到了很多關(guān)于使用 TiDB 處理系統(tǒng)問題的知識(shí)。
我們決定參與開發(fā)開源工具，并參與社區(qū)的長期發(fā)展。基于我們與 PingCAP 的共同努力，TiDB 將變得更加強(qiáng)大。

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場，如有問題，請(qǐng)聯(lián)系我們，謝謝！