午夜操大逼,影音先锋国产av,高清无码扣逼视频,欧美XXX黑人XYX性爽,播放欧美黄片。,苍井さくら在线一区二区,国产美女射精,三级网站在线看

Elasticsearch 是實(shí)現(xiàn)用戶無(wú)縫搜索體驗(yàn)的關(guān)鍵工具。它通過(guò)提供快速、準(zhǔn)確和相關(guān)的搜索結(jié)果，徹底改變了用戶與應(yīng)用程序的互動(dòng)方式。然而，要確保 Elasticsearch 部署達(dá)到最佳性能，就必須關(guān)注關(guān)鍵指標(biāo)，并對(duì)諸如索引、緩存、查詢、搜索以及存儲(chǔ)等各種組件進(jìn)行優(yōu)化。

在本博文中，我們將深入探討如何調(diào)整 Elasticsearch 以實(shí)現(xiàn)最佳性能和發(fā)揮最大潛能的最佳實(shí)踐與技巧，從優(yōu)化集群健康、搜索性能和索引，到精通緩存策略和存儲(chǔ)選項(xiàng)。無(wú)論你是經(jīng)驗(yàn)豐富的 Elasticsearch 專家，還是初涉此領(lǐng)域的新手，遵循一些最佳實(shí)踐以確保部署具備性能、可靠性和可擴(kuò)展性都至關(guān)重要。

1、通用優(yōu)化建議

1.1 使用合適的硬件

Elasticsearch是一個(gè)內(nèi)存密集型應(yīng)用程序，因此使用足夠內(nèi)存的硬件非常重要。此外，建議使用固態(tài)硬盤（SSD）作為存儲(chǔ)設(shè)備，因?yàn)樗鼈兛梢燥@著提高索引和搜索性能。

盡管 SSD 的 I/O 性能優(yōu)于傳統(tǒng)硬盤，但如果 Elasticsearch 集群中的節(jié)點(diǎn)數(shù)量較多，I/O 性能仍然可能成為瓶頸。為了保證性能，可以采取一些優(yōu)化措施，如使用 RAID 配置、合理的磁盤劃分和負(fù)載均衡等。

RAID級(jí)別	優(yōu)點(diǎn)	缺點(diǎn)	適用場(chǎng)景
RAID 0	高I/O性能，實(shí)現(xiàn)并行讀寫	無(wú)冗余，磁盤故障可能導(dǎo)致數(shù)據(jù)丟失	性能敏感型應(yīng)用，可接受數(shù)據(jù)恢復(fù)時(shí)間
RAID 1	數(shù)據(jù)冗余，磁盤故障時(shí)數(shù)據(jù)不丟失	寫入性能不如RAID 0	數(shù)據(jù)安全性和可靠性較高的應(yīng)用
RAID 5	數(shù)據(jù)冗余，一定程度的I/O性能優(yōu)勢(shì)	寫入性能不如RAID 0	需要在性能和數(shù)據(jù)安全性之間取得平衡的應(yīng)用
RAID 10	結(jié)合RAID 0和RAID 1的優(yōu)點(diǎn)，高I/O性能和數(shù)據(jù)冗余	需要更多磁盤，成本較高	既需要保證性能又需要保證數(shù)據(jù)安全性的應(yīng)用

1.2 規(guī)劃索引策略

Elasticsearch設(shè)計(jì)用于處理大量數(shù)據(jù)，但需要考慮如何索引這些數(shù)據(jù)。這包括需要多少分片和副本，數(shù)據(jù)將如何索引，以及如何處理更新和刪除。

分片數(shù)量

選擇合適數(shù)量的分片以實(shí)現(xiàn)水平擴(kuò)展和負(fù)載均衡。

默認(rèn)情況下，每個(gè)索引有 1 個(gè)主分片。根據(jù)數(shù)據(jù)量和節(jié)點(diǎn)數(shù)量調(diào)整分片數(shù)量。盡量避免使用過(guò)多分片，因?yàn)槊總€(gè)分片都需要額外的資源和開銷。

副本數(shù)量

增加副本數(shù)量以提高搜索性能和系統(tǒng)容錯(cuò)能力，但要辯證看，后文會(huì)詳細(xì)解讀。

默認(rèn)情況下，每個(gè)分片有 1 個(gè)副本。根據(jù)負(fù)載和可用性需求調(diào)整副本數(shù)量。

數(shù)據(jù)索引策略

使用基于時(shí)間的索引生命周期管理策略（ILM）以提高查詢性能和降低資源消耗。例如，為每天、每周或每月的數(shù)據(jù)創(chuàng)建一個(gè)新索引。

選擇合適的字段類型和分析器。優(yōu)化映射以減少存儲(chǔ)空間和提高查詢性能。

使用 Index Templates 自動(dòng)應(yīng)用映射和設(shè)置。

更新和刪除處理

使用 Update API 更新文檔，避免刪除和重新索引整個(gè)文檔。

合理使用 Elasticsearch 的版本控制特性。

考慮使用 Index Lifecycle Management (ILM) 自動(dòng)管理索引的生命周期。根據(jù)具體業(yè)務(wù)需求和場(chǎng)景，靈活調(diào)整上述建議以優(yōu)化 Elasticsearch 集群性能。

1.3 優(yōu)化查詢

Elasticsearch是一個(gè)功能強(qiáng)大的搜索引擎，但要確保查詢性能優(yōu)化。這包括盡可能使用過(guò)濾器而不是查詢，并使用分頁(yè)限制返回結(jié)果的數(shù)量。

使用過(guò)濾器而不是查詢:

提高查詢速度：過(guò)濾器不計(jì)算相關(guān)性得分。
結(jié)果可被緩存：相同過(guò)濾條件直接獲取結(jié)果。

使用分頁(yè)限制返回結(jié)果數(shù)量:

降低計(jì)算和傳輸負(fù)擔(dān)：提高查詢性能。
注意深度分頁(yè)可能導(dǎo)致性能問(wèn)題：考慮使用 search_after 參數(shù)。

優(yōu)化查詢性能有助于降低響應(yīng)時(shí)間、提高吞吐量并確保集群在高負(fù)載下保持穩(wěn)定。

1.4 保持Elasticsearch版本更新

Elasticsearch 是一個(gè)活躍的項(xiàng)目，定期發(fā)布新版本以修復(fù)錯(cuò)誤并提供新功能。保持版本更新至關(guān)重要，以利用這些改進(jìn)并避免已知問(wèn)題。

1.5 監(jiān)控集群

Elasticsearch 提供了各種監(jiān)控工具，如Elasticsearch Head、Kibana monitoring（優(yōu)先推薦）插件，可用于監(jiān)控集群的健康和性能。需要密切關(guān)注磁盤使用情況、CPU和內(nèi)存使用情況以及搜索請(qǐng)求的數(shù)量。

在通用最佳實(shí)踐的基礎(chǔ)上，我們將深入探討索引、查詢和搜索、擴(kuò)展、性能和監(jiān)控等具體領(lǐng)域。

2、寫入（索引化）優(yōu)化建議

2.1 使用批量請(qǐng)求

Elasticsearch的批量API允許在單個(gè)API調(diào)用中執(zhí)行多個(gè)索引/刪除操作。這大大提高了索引速度。如果請(qǐng)求中的一個(gè)失敗，頂層錯(cuò)誤標(biāo)志將設(shè)置為true，并在相關(guān)請(qǐng)求下報(bào)告錯(cuò)誤詳細(xì)信息。

使用 Elasticsearch 的批量 API 的原因：

提高性能

減少網(wǎng)絡(luò)開銷和連接建立時(shí)間，提高索引速度。

減少資源消耗

降低服務(wù)器和客戶端資源消耗，提高系統(tǒng)效率和吞吐量。

錯(cuò)誤處理

靈活且可控的錯(cuò)誤處理方式，即使部分操作失敗，其他操作仍可繼續(xù)執(zhí)行。

使用批量 API 可實(shí)現(xiàn)高效的數(shù)據(jù)索引和刪除操作，同時(shí)提高系統(tǒng)的穩(wěn)定性和可靠性。

2.2 使用多線程客戶端索引數(shù)據(jù)

單個(gè)線程發(fā)送批量請(qǐng)求無(wú)法充分利用Elasticsearch集群的索引能力。

通過(guò)多線程或多進(jìn)程發(fā)送數(shù)據(jù)，將有助于利用集群的所有資源，降低每個(gè)fsync的成本，提高性能。

2.3 增加刷新間隔（index.refresh_interval）

Elasticsearch中默認(rèn)的刷新間隔為1秒，但如果搜索流量很小，可以增加此值以優(yōu)化索引速度。

2.4 使用自動(dòng)生成的ID

在索引具有顯式ID的文檔時(shí)，Elasticsearch需要檢查是否已經(jīng)存在具有相同ID的文檔，這是一項(xiàng)代價(jià)高昂的操作。

使用自動(dòng)生成的ID可以跳過(guò)此檢查，使索引更快。

2.5 index.translog.sync_interval

此設(shè)置控制translog何時(shí)提交到磁盤，無(wú)論寫操作如何。默認(rèn)值為5秒，但不允許使用小于100毫秒的值。

官方文檔地址：

https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-translog.html

2.6 避免大型文檔

大型文檔會(huì)給網(wǎng)絡(luò)、內(nèi)存使用和磁盤帶來(lái)壓力，導(dǎo)致索引速度緩慢，影響鄰近搜索和高亮顯示。

高亮處理推薦 fvh 高亮方式。

推薦閱讀：Elasticsearch大文件檢索性能提升20倍實(shí)踐（干貨）

2.7 顯式設(shè)置映射

Elasticsearch可以動(dòng)態(tài)創(chuàng)建映射，但并不適用于所有場(chǎng)景。顯式設(shè)置（strict）映射將有助于確保最佳性能。

顯式設(shè)置映射的優(yōu)勢(shì)：

準(zhǔn)確的字段類型

確保查詢和聚合操作正確性。

優(yōu)化存儲(chǔ)和性能

降低存儲(chǔ)空間，提高查詢性能。

避免不必要的映射更新

減少映射更新操作和性能開銷。

2.8 避免使用嵌套Nested類型

雖然嵌套類型在某些場(chǎng)景下很有用，但它們也帶來(lái)了一定的性能影響：

查詢速度較慢

與查詢非嵌套文檔中的普通字段相比，查詢嵌套字段速度較慢。

這是因?yàn)榍短鬃侄蔚牟樵冃枰獔?zhí)行額外的處理步驟，例如過(guò)濾器和關(guān)聯(lián)。這可能導(dǎo)致較低的查詢性能，特別是在處理大量數(shù)據(jù)時(shí)。

額外的減速

在檢索匹配嵌套字段的文檔時(shí)，Elasticsearch 需要對(duì)嵌套層文檔進(jìn)行關(guān)聯(lián)。這意味著它需要將嵌套文檔與其外層文檔匹配，以確定哪些文檔實(shí)際上包含匹配的嵌套字段。這個(gè)過(guò)程可能導(dǎo)致額外的性能開銷，尤其是在查詢結(jié)果集很大時(shí)。

為了避免嵌套類型帶來(lái)的性能影響，可以考慮使用以下方法：

扁平化數(shù)據(jù)結(jié)構(gòu)（俗成大寬表）：盡可能將嵌套字段轉(zhuǎn)換為扁平化的數(shù)據(jù)結(jié)構(gòu)，例如使用多個(gè)普通字段表示原本的嵌套字段。
使用關(guān)鍵詞類型（keyword類型）：對(duì)于具有固定集合值的字段，可以使用關(guān)鍵詞類型進(jìn)行索引，以提高查詢速度。
使用 join 類型（父子關(guān)聯(lián)類型）：在某些場(chǎng)景下，可以使用 join 類型替代嵌套類型。

但請(qǐng)注意，join 類型也可能導(dǎo)致性能問(wèn)題，尤其是在需要頻繁修改文檔關(guān)系時(shí)。

3、查詢和搜索優(yōu)化建議

3.1 盡可能使用 filter 而不是 query

query 子句用于回答“這個(gè)文檔與這個(gè)子句的匹配程度如何？
filter（過(guò)濾器）子句用于回答“這個(gè)文檔是否與這個(gè)子句匹配？” Elasticsearch只需要回答“是”或“否”。它不需要為過(guò)濾器子句計(jì)算相關(guān)性得分，而且過(guò)濾器結(jié)果可以被緩存。

3.2 增加刷新間隔

增加刷新間隔有助于減少段數(shù)量，降低搜索的IO成本。

而且，一旦刷新發(fā)生并且數(shù)據(jù)發(fā)生變化，緩存就會(huì)失效。增加刷新間隔可以使Elasticsearch更有效地利用緩存。

3.3 辯證的看待增加副本數(shù)量對(duì)檢索性能的影響

直接給出企業(yè)級(jí)測(cè)試結(jié)論——副本數(shù)對(duì)檢索性能的影響非正相關(guān)。也就是說(shuō)：不是副本越多，檢索性能越高。

增加副本數(shù)量的優(yōu)勢(shì)：

負(fù)載均衡

分散查詢請(qǐng)求負(fù)載，實(shí)現(xiàn)負(fù)載均衡。

高可用性

提高集群的可用性和容錯(cuò)能力。

并行處理

加快查詢速度，提高吞吐量。

注意：增加副本數(shù)量會(huì)消耗額外的存儲(chǔ)空間和計(jì)算資源。需根據(jù)需求和資源限制權(quán)衡副本數(shù)量。

3.4 僅檢索必要字段

如果文檔很大，且僅需要幾個(gè)字段，請(qǐng)使用stored_fields僅檢索所需字段，而不是所有字段。

3.5 避免通配符查詢

通配符查詢可能會(huì)很慢且耗資源。最好盡量避免使用它們。

替代方案：Ngram分詞、設(shè)置 wildcard 數(shù)據(jù)類型。

Elasticsearch 警惕使用 wildcard 檢索！然后呢？

3.6 使用節(jié)點(diǎn)查詢緩存

過(guò)濾器上下文中使用的查詢結(jié)果將緩存在節(jié)點(diǎn)查詢緩存中，以便快速查找。

過(guò)濾器上下文查詢結(jié)果緩存的優(yōu)勢(shì)：

緩存命中率

過(guò)濾器查詢具有較高的緩存命中率，常在多個(gè)查詢中重復(fù)使用。

節(jié)省計(jì)算資源

緩存結(jié)果減少重復(fù)計(jì)算，節(jié)省資源。

提高查詢速度

緩存加速查詢，特別是復(fù)雜或數(shù)據(jù)量大的過(guò)濾器查詢。

并發(fā)查詢效果更好

節(jié)點(diǎn)查詢緩存在高并發(fā)場(chǎng)景下發(fā)揮作用，提高性能。

注意：需平衡緩存使用與內(nèi)存消耗。對(duì)于頻繁變更或低緩存命中率的查詢，緩存效果可能有限。

Elasticsearch 緩存深入詳解

3.7 使用分片查詢緩存

可以通過(guò)將“index.requests.cache.enable”設(shè)置為true來(lái)啟用分片查詢緩存。

設(shè)置參考如下：

      
        PUT?/my-index-000001
{
??"settings":?{
????"index.requests.cache.enable":?false
??}
}

官方文檔地址：

https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-request-cache.html

3.8 使用索引模板

索引模板可以幫助自動(dòng)將設(shè)置和映射應(yīng)用于新索引。

使用索引模板的優(yōu)勢(shì)：

一致性

確保新索引具有相同的設(shè)置和映射，實(shí)現(xiàn)集群一致性。

簡(jiǎn)化操作

自動(dòng)應(yīng)用預(yù)定義的設(shè)置和映射，減少手動(dòng)配置。

易于擴(kuò)展

快速創(chuàng)建具有相同配置的新索引，便于集群擴(kuò)展。

版本控制和更新

實(shí)現(xiàn)模板版本控制，確保新索引使用最新配置。

4、性能優(yōu)化建議

4.1 活動(dòng)分片應(yīng)與CPU成比例

活動(dòng)分片=主分片+副本分片數(shù)之和。

活動(dòng)分片與 CPU 成比例的原因：

并行處理

更多活動(dòng)分片提高并行處理能力，加速查詢和索引請(qǐng)求。與 CPU 核心數(shù)成比例確保充分利用 CPU 資源。

避免資源競(jìng)爭(zhēng)

將活動(dòng)分片與 CPU 核心數(shù)成比例，避免多分片競(jìng)爭(zhēng)同一 CPU 核心，提高性能。

負(fù)載均衡

成比例的活動(dòng)分片數(shù)有助于在多節(jié)點(diǎn)間分散請(qǐng)求，避免單節(jié)點(diǎn)資源瓶頸。

性能優(yōu)化

與 CPU 核心數(shù)成比例的分片數(shù)根據(jù)可用計(jì)算資源為分片分配處理能力，優(yōu)化查詢和索引操作。

注意：實(shí)際部署需考慮其他因素，如內(nèi)存、磁盤和網(wǎng)絡(luò)資源等。

如前所述，為了提高寫入密集型用例的性能，應(yīng)將刷新間隔增加到較大的值（例如，30秒），并增加主分片以將寫請(qǐng)求分發(fā)到不同節(jié)點(diǎn)。對(duì)于讀取密集型用例，增加副本分片以在副本之間平衡查詢/搜索請(qǐng)求會(huì)有所幫助。

4.2 如果查詢具有日期范圍 filter 過(guò)濾器，請(qǐng)按日期組織數(shù)據(jù)。

對(duì)于日志或監(jiān)控場(chǎng)景，按每日、每周或每月組織索引并按指定日期范圍獲取索引列表可以提高性能。

Elasticsearch只需要查詢較小的數(shù)據(jù)集，而不是整個(gè)數(shù)據(jù)集，而且在數(shù)據(jù)過(guò)期時(shí)縮小/刪除舊索引會(huì)很容易。

負(fù)面案例：之前有客戶超大規(guī)模（100TB）以上的數(shù)據(jù)沒(méi)有日期格式字段或者出現(xiàn)字段格式不規(guī)范的問(wèn)題。

4.3 如果查詢具有過(guò)濾字段且其值可枚舉，則將數(shù)據(jù)分割成多個(gè)索引。

如果我們的查詢中包含可枚舉的過(guò)濾字段（例如，地區(qū)），則可以通過(guò)將數(shù)據(jù)分割成多個(gè)索引來(lái)提高查詢性能。

例如，如果數(shù)據(jù)包含來(lái)自美國(guó)、歐洲和其他地區(qū)的記錄，并且經(jīng)常使用“region”過(guò)濾查詢，那么可以將數(shù)據(jù)分割成三個(gè)索引，每個(gè)索引包含一組地區(qū)的數(shù)據(jù)。

這樣，當(dāng)執(zhí)行帶有過(guò)濾子句“region”的查詢時(shí)，Elasticsearch 只需要在包含該地區(qū)數(shù)據(jù)的索引中搜索，從而提高查詢性能。

5、擴(kuò)展建議

5.1 索引狀態(tài)管理

定義自定義管理策略以自動(dòng)執(zhí)行常規(guī)任務(wù)，并將其應(yīng)用于索引和索引模式。例如，可以定義一項(xiàng)策略，使索引在30天后進(jìn)入只讀狀態(tài)，然后在90天后將其刪除。

ILM（索引生命周期管理）是 Elasticsearch 的一項(xiàng)功能，可自動(dòng)化索引的管理和維護(hù)，具有以下好處：

簡(jiǎn)化索引管理：自動(dòng)化索引的生命周期管理，包括索引的創(chuàng)建、更新、刪除和存檔，減輕管理員的負(fù)擔(dān)。
提高性能：自動(dòng)優(yōu)化索引設(shè)置，包括調(diào)整分片大小、縮小索引和刪除過(guò)期數(shù)據(jù)等，有助于提高查詢性能和減少存儲(chǔ)空間的使用。
降低成本：自動(dòng)歸檔和刪除過(guò)期數(shù)據(jù)，降低存儲(chǔ)成本，減少管理員的工作量和時(shí)間成本。
更好的可擴(kuò)展性：根據(jù)需要自動(dòng)調(diào)整索引設(shè)置和存儲(chǔ)策略，使索引更好地適應(yīng)不斷增長(zhǎng)和變化的數(shù)據(jù)。

使用 ILM 可以讓索引管理變得更簡(jiǎn)單、更可靠。

干貨 | Elasticsearch 索引生命周期管理 ILM 實(shí)戰(zhàn)指南
Elasticsearch ILM 索引生命周期管理常見(jiàn)坑及避坑指南

5.2 快照生命周期管理

SLM（快照生命周期管理）是 Elasticsearch 的一項(xiàng)功能，可自動(dòng)化快照的管理和維護(hù)，具有以下好處：

簡(jiǎn)化快照管理：自動(dòng)化快照的生命周期管理，包括創(chuàng)建、管理、刪除和清理快照，減輕管理員的負(fù)擔(dān)。
提高效率：自動(dòng)化快照的創(chuàng)建、管理、刪除和清理，提高管理效率。
減少存儲(chǔ)成本：自動(dòng)刪除無(wú)用的快照，降低存儲(chǔ)成本。
更好的可擴(kuò)展性：根據(jù)需要自動(dòng)調(diào)整快照設(shè)置和存儲(chǔ)策略，使快照更好地適應(yīng)不斷增長(zhǎng)和變化的數(shù)據(jù)。

使用 SLM 可以讓快照管理變得更簡(jiǎn)單、更可靠，提高管理效率和降低存儲(chǔ)成本。

Elasticsearch 快照生命周期管理 (SLM) 實(shí)戰(zhàn)指南

5.3 用好監(jiān)控

為了監(jiān)視Elasticsearch集群的性能并檢測(cè)任何潛在問(wèn)題，應(yīng)該定期跟蹤以下指標(biāo)：

集群健康狀況節(jié)點(diǎn)和分片：監(jiān)控集群中節(jié)點(diǎn)的數(shù)量以及分片及其分布。
搜索性能：請(qǐng)求延遲和速率 - 跟蹤搜索請(qǐng)求的延遲以及每秒搜索請(qǐng)求的數(shù)量。
索引性能：刷新時(shí)間和合并時(shí)間 - 監(jiān)控刷新索引所需的時(shí)間以及合并段所需的時(shí)間。
節(jié)點(diǎn)利用率：線程池 - 監(jiān)控每個(gè)節(jié)點(diǎn)上線程池的使用情況，例如索引池。

6、小結(jié)

遵循這些最佳實(shí)踐，可以確保Elasticsearch部署性能高、可靠且可擴(kuò)展。

請(qǐng)記住，Elasticsearch是一個(gè)功能強(qiáng)大的搜索和分析引擎，可以快速并近乎實(shí)時(shí)地處理大量數(shù)據(jù)，但是要充分利用它，需要計(jì)劃、優(yōu)化和監(jiān)控部署。

以上建議僅供參考，實(shí)操環(huán)節(jié)以 Elasticsearch 官方文檔和自己集群的性能測(cè)試結(jié)論為準(zhǔn)。沒(méi)有普適的優(yōu)化建議，只有適合自己的優(yōu)化才是最好的優(yōu)化。

干貨 | Elasticsearch 8.X 性能優(yōu)化實(shí)戰(zhàn)