作者：Adrien Grand, Joe Gallo, Tyler Perkins
正如你們中的一些人已經(jīng)注意到的，Elasticsearch 8.6、8.7 和 8.8 在各種數(shù)據(jù)集上帶來了良好的索引加速，從簡單的關(guān)鍵字到繁重的 KNN 向量，以及攝取管道繁重的攝取工作負載。 攝取涉及許多組件 —— 運行攝取管道、反轉(zhuǎn)內(nèi)存中的數(shù)據(jù)、刷新段、合并段 —— 所有這些通常都需要不可忽略的時間。 對你來說幸運的是，我們在所有這些領(lǐng)域都進行了改進，從而實現(xiàn)了更快的端到端攝取速度。
例如，在我們的基準測試中，8.8 的攝取速度比 8.6 快 13%，該基準模擬了具有多個數(shù)據(jù)集、攝取管道等的實際日志記錄用例。 下圖顯示了在我們實施這些優(yōu)化期間，攝取率從約 22.5k 文檔/秒變?yōu)榧s 25.5k 文檔/秒。
本博客深入探討了一些有助于在 8.6、8.7 和 8.8 中實現(xiàn)攝取加速的更改。
更快地合并 kNN 向量
Elasticsearch 的 kNN 搜索的底層結(jié)構(gòu)是 Lucene 的分層可導(dǎo)航小世界 (HNSW) 圖。 該圖甚至可以在數(shù)百萬個向量上提供異?？焖俚?kNN 搜索。 然而，構(gòu)建圖表本身可能是一項昂貴的任務(wù)； 它需要在現(xiàn)有圖上執(zhí)行多次搜索、建立連接并更新當前的鄰居集。 在 Elasticsearch 8.8 之前，當合并段（segements）時，會創(chuàng)建一個全新的 HNSW 圖索引 - 這意味著來自每個段的每個向量都被單獨添加到一個完全空的圖中。 隨著段規(guī)模的擴大，其數(shù)量也會增加，而合并的成本可能會高得令人望而卻步。
在 Elasticsearch 8.8 中，Lucene 在合并 HNSW 圖方面做出了重大改進。 Lucene 智能地重用現(xiàn)有最大的 HNSW 圖。 因此，Lucene 不再像以前那樣從空圖開始，而是利用之前完成的所有工作來構(gòu)建現(xiàn)有的最大分段。 當合并較大的段，這一變化的影響非常顯著。 在我們自己的基準測試中，我們發(fā)現(xiàn)合并所用時間減少了 40% 以上，刷新吞吐量提高了一倍多。 這顯著減少了索引較大矢量數(shù)據(jù)集時集群所經(jīng)歷的負載。
優(yōu)化攝取管道
攝取管道（ingest pipelines）在索引文檔之前使用處理器對文檔執(zhí)行轉(zhuǎn)換 - 例如，設(shè)置或刪除字段、解析日期或 JSON 字符串等值，以及使用 IP 地址或其他數(shù)據(jù)豐富查找地理位置。 通過攝取管道，可以從日志文件發(fā)送文本行，并讓 Elasticsearch 完成繁重的工作，將該文本轉(zhuǎn)換為結(jié)構(gòu)化文檔。 我們的大多數(shù)開箱即用的集成（integrations）都使用攝取管道，使你能夠在幾分鐘內(nèi)解析和豐富新的數(shù)據(jù)源。
在 8.6 和 8.7 中，我們通過多種方式優(yōu)化了攝取管道和處理器：
- 我們已經(jīng)消除了單個文檔經(jīng)過多個管道處理的大部分開銷。
- 我們優(yōu)化了一些最常用的處理器：
- 使用 mustache 模板的 set 和 append 處理器現(xiàn)在可以更快地創(chuàng)建模板模型和執(zhí)行?mustache 模板。
- Date 處理器現(xiàn)在緩存其關(guān)聯(lián)的日期解析器。
- Geoip 處理器不再依賴反射（reflection）。
- 在 8.6.0 中，我們通過兩種方式優(yōu)化了無痛腳本，改進了腳本處理器和條件檢查。
- 此外，攝取處理的總體指標和統(tǒng)計數(shù)據(jù)比以前更準確：
- 正確考慮了管道執(zhí)行后序列化數(shù)據(jù)所花費的時間。
- 針對多個管道執(zhí)行的文檔僅計數(shù)一次。
- 最后，低級熱代碼的優(yōu)化減少了所有處理文檔的開銷，例如更快的集合交集、更快的元數(shù)據(jù)驗證和更快的自引用檢查。
結(jié)合所有這些改進，我們的每日安全集成基準的攝取管道性能提高了 45%，每日日志記錄集成基準的攝取管道性能提高了 35%。
我們預(yù)計這些加速能夠在升級到 8.7 或更新版本后，一些重要的攝入用例將會看到的改進。?
關(guān)鍵字和數(shù)字字段的優(yōu)化
我們有許多數(shù)據(jù)集，其中大多數(shù)字段都是簡單的數(shù)字和關(guān)鍵字字段，它們將自動受益于這些字段類型的改進。 兩項主要改進有助于索引這些字段類型：
- Elasticsearch 在適用時切換到 Lucene 的 IntField、LongField、FloatField 和 DoubleField（Lucene 9.5 中的新增功能）以及 Lucene 的 KeywordField（Lucene 9.6 中的新增功能）。 這些字段允許用戶在單個 Lucene 字段上啟用索引（indexing）和文檔值（doc values） - 否則您需要提供兩個字段：一個啟用索引，另一個啟用文檔值。 事實證明，這一旨在使 Lucene 更加用戶友好的更改也有助于提高索引率，超出了我們的預(yù)期！ 請參閱注釋 AH 和 AJ 以了解這些更改對 Lucene 夜間基準測試的影響。
- 簡單的關(guān)鍵字現(xiàn)在可以直接索引，而不是通過 TokenStream 抽象。 TokenStreams 通常是分析器的輸出，并公開術(shù)語、位置、偏移量和有效負載 - 為文本字段構(gòu)建倒排索引所需的所有信息。 為了保持一致性，還使用簡單關(guān)鍵字通過生成返回單個標記的 TokenStream 來進行索引。 現(xiàn)在，關(guān)鍵字值會直接被索引，而無需經(jīng)過 TokenStream 抽象。 請參閱注釋 AH 以了解此更改對 Lucene 的夜間基準測試的影響。
索引排序的優(yōu)化
索引排序是一項強大的功能，可以通過提前終止查詢或?qū)⒖赡芘c相同查詢匹配的文檔聚集在一起來加速查詢。 此外，索引排序是時間序列數(shù)據(jù)流基礎(chǔ)的一部分。 因此，我們花了一些時間來解決索引排序的一些索引時間瓶頸。 這使得我們的基準攝取加速了 12%，該基準攝取了按 @timestamp 降序排序的簡單 HTTP 日志數(shù)據(jù)集。
基于時間的數(shù)據(jù)的新合并策略
直到最近，Elasticsearch 一直依賴 Lucene 的默認合并策略：TieredMergePolicy。 這是一個非常明智的合并策略，它嘗試將段組織成指數(shù)大小的層，其中默認情況下每層有 10 個段。 它擅長計算廉價的合并、回收刪除等。 那么為什么要使用不同的合并策略呢？
時序數(shù)據(jù)的特殊之處在于它通常以近似@timestamp的順序?qū)懭?，因此通過后續(xù)刷新操作形成的段時間戳范圍通常是不會重疊的。對于在@timestamp字段上進行范圍查詢，這是一個有趣的屬性，因為許多段要么根本不與查詢范圍重疊，要么完全包含在查詢范圍內(nèi)，這是處理范圍查詢非常高效的兩種情況。不幸的是，段時間戳范圍不重疊的特性會被TieredMergePolicy破壞，因為它更樂意將不相鄰的段合并在一起。
所以有@timestamp日期類型字段的分片現(xiàn)在使用Lucene的LogByteSizeMergePolicy，它是TieredMergePolicy的前身. 兩者之間的一個關(guān)鍵區(qū)別是LogByteSizeMergePolicy只會合并相鄰的段，所以在假設(shè)數(shù)據(jù)以 @timestamp 順序?qū)懭氲那闆r下，這可以使得合并后段的@timestamp屬性繼續(xù)保持不會重疊。這個變化使得在EQL 基準測試中一些查詢速度加快了多達3倍，這些查詢需要按“@timestamp”順序遍歷事件的序列！
但這個屬性也有一個缺點，因為LogByteSizeMergePolicy在計算相等大小段的合并方面不如 TieredMergePolicy靈活，這是通過合并限制寫入放大的最佳方法。為了減輕這種不利影響，合并因子已從TieredMergePolicy的10提高到 32。雖然增加合并因子通常會使搜索速度變慢，但由于在相同的合并因子下， LogByteSizeMergePolicy比TieredMergePolicy會更積極地合并數(shù)據(jù)，并且保留段的@timestamp 范圍不重疊極大地幫助了時間戳字段的范圍查詢，通常對于時序數(shù)據(jù)最常用的就是根據(jù)時間戳進行過濾。
這就是對 8.6、8.7 和 8.8寫入性能提升的分析。我們會在后續(xù)多個小版本中帶來更多的加速優(yōu)化，敬請期待！
想要詳細了解每個版本中包含的內(nèi)容嗎？ 閱讀他們各自的發(fā)布博客以了解詳細信息：文章來源：http://www.zghlxwxcb.cn/news/detail-606672.html
- 8.6 release blog
- 8.7 release blog
- 8.8 release blog
- Elasticsearch 3rd Party Performance Report
原文：How we sped up data ingestion in Elasticsearch 8.6, 8.7, and 8.8 | Elastic Blog文章來源地址http://www.zghlxwxcb.cn/news/detail-606672.html
到了這里，關(guān)于我們?nèi)绾卧?Elasticsearch 8.6、8.7 和 8.8 中加速數(shù)據(jù)攝入的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
