幾個(gè)月前，我致力于提高“完整”索引器的性能。我覺得這種改進(jìn)足以分享這個(gè)故事。完整索引器是 Box 從頭開始創(chuàng)建搜索索引的過程，從 hbase 表中讀取我們所有的文檔并將文檔插入到 Solr 索引中。

我們根據(jù) id 對(duì)索引文檔進(jìn)行分片，同樣的文檔 id 也被用作 hbase 表中的 key。我們的 Solr 分片公式是 id % number_of_shards。mapreduce 作業(yè)掃描 hbase 表，通過上述分片公式計(jì)算每個(gè)文件的目標(biāo)分片，并將每個(gè)文檔插入相應(yīng)的 solr 分片中。這是在過去幾年中為我們提供良好服務(wù)的初始模型的示意圖：

所有 mapreduce 作業(yè)都與所有分片對(duì)話，因?yàn)槊總€(gè)分片的數(shù)據(jù)分布在所有 hbase 區(qū)域中。該作業(yè)是僅地圖作業(yè)，沒有減少作業(yè)。hbase 表掃描以及更新請(qǐng)求都在映射器中完成。

在每個(gè)映射器中，都有一個(gè)批處理作業(yè)的共享隊(duì)列；和一個(gè) http 客戶端共享池，它們從隊(duì)列中獲取作業(yè)并將其發(fā)送到相應(yīng)的分片。每個(gè)單獨(dú)的文檔都不會(huì)直接插入到隊(duì)列中。相反，需要在同一個(gè)分片上索引的文檔在插入隊(duì)列之前會(huì)一起批處理（當(dāng)前默認(rèn)值為 10）。隊(duì)列是有界的，當(dāng)它已滿時(shí)，文檔生產(chǎn)者必須等待才能掃描更多行。

如果所有 Solr 分片繼續(xù)以一致且一致的速度*攝取文檔，則該系統(tǒng)以穩(wěn)定的速度運(yùn)行。但是，Solr 時(shí)不時(shí)地會(huì)將內(nèi)存中的結(jié)構(gòu)刷新到文件中，這種 I/O 可能會(huì)導(dǎo)致一些索引操作暫時(shí)變慢。在這個(gè)階段，集群不提供查詢服務(wù)，所以這不是問題。

如果分片的總數(shù)為 n，并且給定分片的間歇性慢索引速率的概率為 p，則：

• P（至少 n 個(gè)分片中的一個(gè)很慢）= P（恰好一個(gè)分片很慢）+ P（正好兩個(gè)分片很慢）+ ... + P（所有 n 個(gè)分片都很慢）

要么

• P（至少一個(gè)分片很慢）= 1 - P（沒有一個(gè)分片很慢）

• P（n 個(gè)分片中至少有 1 個(gè)很慢）= 1 — (1-p)?

如果我們假設(shè)對(duì)于給定的時(shí)間間隔 p = 0.01，這是 P 的圖表（集群中至少有一個(gè)分片很慢）：

這意味著要在更多分片上獲得良好的索引性能，我們需要隔離一個(gè)分片的瓶頸，以免影響其他分片的索引。我的第一個(gè)嘗試是增加工作人員池，這樣如果一些工作人員由于速度慢而被卡在一個(gè)分片上，那么其余工作人員可以繼續(xù)處理隊(duì)列。這有所幫助，但仍然有可能讓所有或許多工人在選擇工作時(shí)陷入困境，這些工作會(huì)間歇性地進(jìn)入緩慢的分片。在這種情況下，文檔生產(chǎn)者線程將不會(huì)創(chuàng)建新文檔，因?yàn)殛?duì)列已滿，并且所有工作人員都無法繼續(xù)進(jìn)行，因?yàn)樗麄冋诘却徛墓ぷ魍瓿?。在我的第二次嘗試中，我為每個(gè)分片（在每個(gè)映射器上）創(chuàng)建了單獨(dú)的隊(duì)列和工作人員，這確保了如果一些分片很慢，那么其余分片不必閑置，因?yàn)樗麄兊墓ぷ魅藛T將繼續(xù)閱讀隊(duì)列中的作業(yè)并將它們發(fā)送以進(jìn)行索引。最終，正在呼吸的碎片將再次開始更快地索引，而其他一些碎片可能會(huì)開始緩慢響應(yīng)等等。這極大地改善了系統(tǒng)的總流量。

這是具有較舊并發(fā)模型的 39 臺(tái)主機(jī)的圖表。該作業(yè)在運(yùn)行三天后崩潰。即使在崩潰之前，它的表現(xiàn)也不一致。此外，分片的平均索引速度低于我們過去看到的總分片較少的情況。

這是在具有新并發(fā)模型的同一組主機(jī)上執(zhí)行的相同工作，它的性能要好得多且更一致：

y 軸上的單位是每秒讀取次數(shù)。它增加了一倍多。Box 擁有近 500 億份文檔**，通過改進(jìn)，完整索引器能夠在不到兩天的時(shí)間內(nèi)完成此索引階段。
但是，這種新模型也有其缺點(diǎn)，例如：

• 此模型在針對(duì)同一分片的工作人員之間沒有通信。因此，當(dāng)一個(gè)分片響應(yīng)緩慢時(shí)，來自其他并行運(yùn)行的映射器的工作人員繼續(xù)向它發(fā)送請(qǐng)求（并且失敗，然后重試），即使一個(gè)或多個(gè)工作人員（在其他映射器中）已經(jīng)確定該分片很慢。

• 由于每個(gè)映射器為每個(gè)分片分配一個(gè)固定長度的隊(duì)列，因此設(shè)計(jì)不會(huì)擴(kuò)展到超過一定數(shù)量的分片；因?yàn)殛?duì)列的內(nèi)存需求將超過映射器的堆大小。

更具可擴(kuò)展性的模型將涉及映射器和 Solr 分片之間的隊(duì)列。并且應(yīng)該有特定于分片的客戶端，它們可能運(yùn)行在分片的主機(jī)上，它將從隊(duì)列中讀取分片的文檔并發(fā)送到 Solr 進(jìn)行索引（通過 REST API 或 SolrJ）。
* Hbase 表掃描和文檔生成器不是我們的瓶頸，因此我在這里只提到 Solr 索引性能。

本文	https://architect.pub/solr-improving-performance-batch-indexing
討論：知識(shí)星球【首席架構(gòu)師圈】或者加微信小號(hào)【cea_csa_cto】或者加QQ群【792862318】
公眾號(hào)	【jiagoushipro】 【超級(jí)架構(gòu)師】 精彩圖文詳解架構(gòu)方法論，架構(gòu)實(shí)踐，技術(shù)原理，技術(shù)趨勢。 我們在等你，趕快掃描關(guān)注吧。
微信小號(hào)	【cea_csa_cto】 50000人社區(qū)，討論：企業(yè)架構(gòu)，云計(jì)算，大數(shù)據(jù)，數(shù)據(jù)科學(xué)，物聯(lián)網(wǎng)，人工智能，安全，全棧開發(fā)，DevOps，數(shù)字化.
QQ群	【792862318】深度交流企業(yè)架構(gòu)，業(yè)務(wù)架構(gòu)，應(yīng)用架構(gòu)，數(shù)據(jù)架構(gòu)，技術(shù)架構(gòu)，集成架構(gòu)，安全架構(gòu)。以及大數(shù)據(jù)，云計(jì)算，物聯(lián)網(wǎng)，人工智能等各種新興技術(shù)。 加QQ群，有珍貴的報(bào)告和干貨資料分享。
視頻號(hào)	【超級(jí)架構(gòu)師】 1分鐘快速了解架構(gòu)相關(guān)的基本概念，模型，方法，經(jīng)驗(yàn)。 每天1分鐘，架構(gòu)心中熟。
知識(shí)星球	向大咖提問，近距離接觸，或者獲得私密資料分享。
喜馬拉雅	路上或者車上了解最新黑科技資訊，架構(gòu)心得。	【智能時(shí)刻，架構(gòu)君和你聊黑科技】
知識(shí)星球	認(rèn)識(shí)更多朋友，職場和技術(shù)閑聊。	知識(shí)星球【職場和技術(shù)】
微博	【智能時(shí)刻】	智能時(shí)刻
嗶哩嗶哩	【超級(jí)架構(gòu)師】
抖音	【cea_cio】超級(jí)架構(gòu)師
快手	【cea_cio_cto】超級(jí)架構(gòu)師
小紅書	【cea_csa_cto】超級(jí)架構(gòu)師

謝謝大家關(guān)注，轉(zhuǎn)發(fā)，點(diǎn)贊和點(diǎn)在看。文章來源地址http://www.zghlxwxcb.cn/news/detail-554560.html