我們將更多地討論使用 Elasticsearch 的最佳實(shí)踐。這些做法是一般性建議，可以應(yīng)用于任何用例。 讓我們開(kāi)始吧。

Bulk Requests

批量 API 使得在單個(gè) API 調(diào)用中執(zhí)行許多索引/刪除操作成為可能。 這可以大大增加索引速度。 每個(gè)子請(qǐng)求都是獨(dú)立執(zhí)行的，因此一個(gè)子請(qǐng)求的失敗不會(huì)影響其他子請(qǐng)求的成功。 如果任何請(qǐng)求失敗，頂級(jí)錯(cuò)誤標(biāo)志設(shè)置為 true，錯(cuò)誤詳細(xì)信息將在相關(guān)請(qǐng)求下報(bào)告。

索引數(shù)據(jù)的多線(xiàn)程客戶(hù)端

發(fā)送批量請(qǐng)求的單個(gè)線(xiàn)程不太可能最大化 Elasticsearch 集群的索引容量。 為了使用集群的所有資源，你應(yīng)該從多個(gè)線(xiàn)程或進(jìn)程發(fā)送數(shù)據(jù)。 除了更好地利用集群的資源之外，這應(yīng)該有助于降低每次 fsync 的成本。 索引數(shù)據(jù)和事務(wù)日志都會(huì)定期刷新到磁盤(pán)。 多線(xiàn)程數(shù)據(jù)越多，同步到磁盤(pán)的數(shù)據(jù)越多，減少I(mǎi)/O，提高性能。

index.refresh_interval

默認(rèn)情況下，Elasticsearch 每秒定期刷新索引，但僅限于在過(guò)去 30 秒內(nèi)收到一個(gè)或更多搜索請(qǐng)求的索引。如果你沒(méi)有搜索流量或搜索流量很少（例如，每一次搜索請(qǐng)求少于一個(gè)），這是最佳配置 5 分鐘）并希望優(yōu)化索引速度。 此行為旨在在不執(zhí)行搜索的默認(rèn)情況下自動(dòng)優(yōu)化批量索引。 為了選擇退出此行為，請(qǐng)明確設(shè)置刷新間隔。 另一方面，如果你的索引遇到常規(guī)搜索請(qǐng)求，則此默認(rèn)行為意味著 Elasticsearch 將每 1 秒刷新一次你的索引。 如果你有能力增加文檔被索引和文檔變?yōu)榭伤阉髦g的時(shí)間量，將 index.refresh_interval 增加到一個(gè)更大的值，例如 30s，可能有助于提高索引速度，同時(shí)也允許有一定的搜索行為。如果你在索引的時(shí)候，完全不考慮有搜索數(shù)據(jù)的可能，你可以直接把這個(gè)刷新間隔設(shè)置為 -1。

自動(dòng)生成 IDs

當(dāng)索引一個(gè)具有顯式 id 的文檔時(shí)，Elasticsearch 需要檢查同一個(gè)分片中是否已經(jīng)存在具有相同 id 的文檔，這是一個(gè)代價(jià)高昂的操作，并且隨著索引的增長(zhǎng)而變得更加昂貴。 通過(guò)使用自動(dòng)生成的 ID，ElasticSearch 可以跳過(guò)此檢查，從而加快索引速度。

index.translog.sync_interval

這個(gè)參數(shù)決定了 translog 被 fsync 到磁盤(pán)并提交的頻率，與寫(xiě)操作無(wú)關(guān)。 默認(rèn)為 5 秒。 不允許小于 100 毫秒的值。

index.translog.flush_threshold_size

Translog 存儲(chǔ)所有尚未安全地持久化在 Lucene 中的操作（即，不是 Lucene 提交點(diǎn)的一部分）。 盡管這些操作可用于讀取，但如果分片停止且必須恢復(fù)，則需要重放這些操作。 此設(shè)置控制這些操作的最大總大小，以防止恢復(fù)時(shí)間過(guò)長(zhǎng)。 一旦達(dá)到最大大小，就會(huì)發(fā)生刷新，生成一個(gè)新的 Lucene 提交點(diǎn)。 默認(rèn)為 512 MB。

大文件

大型文檔會(huì)給網(wǎng)絡(luò)、內(nèi)存使用和磁盤(pán)帶來(lái)更多壓力。 索引大型文檔可以使用一定數(shù)量的內(nèi)存，該內(nèi)存量是文檔原始大小的倍數(shù)。 鄰近搜索（例如短語(yǔ)查詢(xún)）和突出顯示也變得更加昂貴，因?yàn)樗鼈兊某杀局苯尤Q于原始文檔的大小。

顯式設(shè)置索引映射

Elasticsearch 可以動(dòng)態(tài)創(chuàng)建映射，但它可能不適合所有場(chǎng)景。 例如，Elasticsearch 5.x 中默認(rèn)的字符串字段映射都是 “keyword” 和 “text” 類(lèi)型。 在很多情況下是不必要的。

Index Mapping — Nested Types

與父文檔中的字段相比，對(duì)嵌套字段的查詢(xún)速度較慢。 匹配嵌套字段的檢索增加了額外的減速。 一旦更新包含嵌套字段的文檔的任何字段，無(wú)論是否更新嵌套字段，所有底層 Lucene 文檔（父文檔及其所有嵌套子文檔）都需要標(biāo)記為已刪除和重寫(xiě)。 除了減慢我們的更新速度之外，這樣的操作還會(huì)產(chǎn)生垃圾，以便稍后通過(guò)段合并進(jìn)行清理。

Index Mapping

禁用 _all 字段將所有其他字段的值連接到一個(gè)字符串中。 它比其他字段需要更多的 CPU 和磁盤(pán)空間。 大多數(shù)用例不需要 _all 字段。 你可以使用 copy_to 參數(shù)連接多個(gè)字段。 _all 字段在 Elasticsearch 6.0 及更高版本中默認(rèn)禁用。 要禁用早期版本中的 _all 字段，請(qǐng)將 enabled 設(shè)置為 false。

使用索引模板

索引模板定義分片數(shù)量、副本和映射等設(shè)置，你可以在創(chuàng)建新索引時(shí)自動(dòng)應(yīng)用這些設(shè)置。 Elasticsearch 根據(jù)與索引名稱(chēng)匹配的索引模式將模板應(yīng)用于新索引。

使用副本實(shí)現(xiàn)可擴(kuò)展性和彈性

Elasticsearch 旨在始終可用并根據(jù)你的需求進(jìn)行擴(kuò)展。 它通過(guò)自身的分布式設(shè)計(jì)來(lái)做到這一點(diǎn)。 你可以向集群添加節(jié)點(diǎn)以增加容量，Elasticsearch 會(huì)自動(dòng)將你的數(shù)據(jù)和查詢(xún)負(fù)載分布到所有可用節(jié)點(diǎn)上。 為了使 Elasticsearch 具有高可用性，其索引需要具備適當(dāng)?shù)娜蒎e(cuò)能力。 這可以使用副本分片來(lái)實(shí)現(xiàn)。 副本分片是主分片的副本。 副本提供數(shù)據(jù)的冗余副本，以防止硬件故障并增加處理讀取請(qǐng)求（如搜索或檢索文檔）的能力。

分片大小

分片是幕后的 Lucene 索引，它使用文件句柄、內(nèi)存和 CPU 周期。 ES 中索引的默認(rèn)分片策略是 5 個(gè)主分片和一個(gè)副本。 選擇多個(gè)分片的目的是在集群中的所有數(shù)據(jù)節(jié)點(diǎn)上均勻分布一個(gè)索引。 但是，這些碎片不應(yīng)該太大或太多。 一個(gè)好的經(jīng)驗(yàn)法則是嘗試將分片大小保持在 10–50 GB 之間。 大分片會(huì)使 Elasticsearch 難以從故障中恢復(fù)，但由于每個(gè)分片都使用一定量的 CPU 和內(nèi)存，因此擁有太多小分片會(huì)導(dǎo)致性能問(wèn)題和內(nèi)存不足錯(cuò)誤。

在多個(gè)數(shù)據(jù)節(jié)點(diǎn)中保持索引的分片數(shù)，這些節(jié)點(diǎn)具有相同的大小并跨節(jié)點(diǎn)分布

通過(guò)模板設(shè)置主分片計(jì)數(shù)，將每個(gè)主分片的最大容量設(shè)定為 50GB（日志分析）或最大 30GB（搜索用例）。數(shù)據(jù)節(jié)點(diǎn)之間的分片分配將根據(jù) 2 個(gè)重要規(guī)則進(jìn)行。

相同索引的主分片和副本分片不會(huì)分配在同一個(gè)數(shù)據(jù)節(jié)點(diǎn)上。

根據(jù)節(jié)點(diǎn)上可用的分片數(shù)量或均衡集群中所有節(jié)點(diǎn)中每個(gè)索引的分片數(shù)量，將分片放置在節(jié)點(diǎn)上。 另請(qǐng)注意，可能會(huì)有較大的分片分配給某些節(jié)點(diǎn)而較小的分片分配給其他節(jié)點(diǎn)。 建議索引的分片數(shù)（主+副本）應(yīng)該是數(shù)據(jù)節(jié)點(diǎn)數(shù)的倍數(shù)。 比方說(shuō)，你有一個(gè) 4 節(jié)點(diǎn)的集群，索引的總分片（主 + 副本）應(yīng)該是 4 或 8 或 12 等。這確保數(shù)據(jù)在節(jié)點(diǎn)之間均勻分布。

索引生命周期管理

如果你要處理時(shí)間序列數(shù)據(jù)，則不想將所有內(nèi)容連續(xù)轉(zhuǎn)儲(chǔ)到單個(gè)索引中。 取而代之的是，你可以定期將數(shù)據(jù)滾動(dòng)到新索引，以防止數(shù)據(jù)過(guò)大而又緩慢又昂貴。 隨著索引的老化和查詢(xún)頻率的降低，你可能會(huì)將其轉(zhuǎn)移到價(jià)格較低的硬件上，并減少分片和副本的數(shù)量。

要在索引的生命周期內(nèi)自動(dòng)移動(dòng)索引，可以創(chuàng)建策略來(lái)定義隨著索引的老化對(duì)索引執(zhí)行的操作。 索引生命周期策略在與 Beats 數(shù)據(jù)發(fā)件人一起使用時(shí)特別有用，Beats 數(shù)據(jù)發(fā)件人不斷將運(yùn)營(yíng)數(shù)據(jù)（例如指標(biāo)和日志）發(fā)送到 Elasticsearch。 當(dāng)現(xiàn)有索引達(dá)到指定的大小或期限時(shí)，你可以自動(dòng)滾動(dòng)到新索引。 這樣可以確保所有索引具有相似的大小，而不是每日索引，其大小可以根 beats 數(shù)和發(fā)送的事件數(shù)而有所不同。

讓我們通過(guò)動(dòng)手操作場(chǎng)景跳入索引生命周期管理（Index cycle management: ILM）。 本文章將利用你可能不熟悉的ILM獨(dú)有的許多新概念。 我們先用一個(gè)示例來(lái)展示。本示例的目標(biāo)是建立一組索引，這些索引將封裝來(lái)自時(shí)間序列數(shù)據(jù)源的數(shù)據(jù)。 我們可以想象有一個(gè)像Filebeat這樣的系統(tǒng)，可以將文檔連續(xù)索引到我們的書(shū)寫(xiě)索引中。 我們希望在索引達(dá)到 50 GB，或文檔的數(shù)量超過(guò)10000，或已在30天前創(chuàng)建索引后對(duì)其進(jìn)行 rollover，然后在90天后刪除該索引。

按日期組織索引數(shù)據(jù)

對(duì)于大多數(shù)日志記錄或監(jiān)控用例，我們可以將索引組織為每天、每周或每月，然后我們可以得到一個(gè)指定日期范圍的索引列表。 Elasticsearch 只需要查詢(xún)較小的數(shù)據(jù)集而不是整個(gè)數(shù)據(jù)集。 此外，當(dāng)數(shù)據(jù)過(guò)期時(shí)，收縮/刪除舊索引也很容易。我們可以參考文章 “Elasticsearch：使用 ingest pipeline 來(lái)管理索引名稱(chēng)” 來(lái)管理索引名稱(chēng)。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-482638.html

到了這里，關(guān)于Elasticsearch：實(shí)用指南的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！