潮人地東莞seo博客小編下面跟大家分享關于seo優化技術：如何看待這種快照秒收方式-讓Elasticsearch飛起來（性能優化實踐干貨）等問題，希望seo專員在做seo優化的過程中有所幫助，內容僅供參考。
讓Elasticsearch飛起來-性能優化實踐干貨
0、題記
Elasticsearch性能優化的最終目的:用戶體驗酷。
關于酷的定義——著名產品人梁寧曾經說過：“當人們滿意時，他們的狀態被稱為快樂。如果人們不滿意，他們就會感到不舒服，并開始尋求。如果這個人能在尋找中立即得到滿足，這種感覺就很酷了！”。
Elasticsearch的爽點是:快、準、全！
seo博客相關推薦閱讀：seo技術博客分享：網站有那幾種地方需要優化，如何做
阿里巴巴、騰訊、JD.COM、攜程、滴滴、58等都對Elasticsearch的性能優化做了很多深入的實踐總結，都是很好的參考。本文以Elasticsearch的酷點為基礎，對性能優化進行了探討。
1、集群規劃優化實踐1.1基于目標數據量規劃集群
在業務初期，經常被問到的問題需要幾個節點的集群，內存和CPU需要多少，SSD需要多少？
最重要的考慮因素是：您的目標存儲數據量是多少？針對目標數據量可以反推多少節點。
1.2留出容量Buffer
注：Elasticsearch有三條警戒水位線，磁盤利用率達到85%、90%、95%。
不同的警戒水位線會有不同的應急策略。
在這一點上，應規劃磁盤容量選擇。控制在85%以下是合理的。
當然，也可以通過配置進行調整。
1.3ES集群各節點盡量不要與其他業務功能重用一臺機器。
除非內存很大。
例如，ES安裝在普通服務器上 Mysql redis，業務數據量大后，必然會出現內存不足等問題。
1.4磁盤盡量選擇SSDD
考慮到成本原因，Elasticsearch的官方文件必須推薦SSD。需要結合業務場景，
如果業務對寫入和檢索速率有較高的速率要求，建議使用SSD磁盤。
在阿里的業務場景中，SSD磁盤的速率是機械硬盤的5倍。
但因商業場景而異。
1.5內存配置合理
官方建議：堆內存的大小是官方建議：Min(32GB，機器內存大小/2)。
Medcl和wood大叔都明確表示，不需要設置32/31GB那么大，建議:熱數據設置:26GB，冷數據:31GB。
整體內存大小沒有具體要求，但內容越大，檢索性能越好。
經驗值供參考：每天200GB 在增量數據的業務場景中，服務器至少需要64GB內存。
除JVM外，還要有足夠的預留內存，否則OOM往往會出現。
1.6CPU核數不要太小
CPU核數與ESThreadpol有關。它與寫入和檢索性能有關。
建議：16核 。
1.7超大量業務場景，可考慮跨集群檢索
除非業務量級很大，比如滴滴和攜程的PB 業務場景，否則基本不需要跨集群檢索。
1.8集群節點數不需要奇數
ES內部維護集群通信不是基于zookeeper的分發部署機制，所以不需要奇數。
但是discovery.zen.minimum_master_nodes的值應設置為：候選主節點的數量/2 1、能有效避免腦裂。
1.9節點類型優化分配
集群節點數：<=3，建議：所有節點的master：true，data：true。既是主節點也是路由節點。集群節點數：>3.根據業務場景的需要，建議Master節點和協調/路由節點逐步獨立。
1.10建議冷熱數據分離
物理上提高了熱數據存儲SSD和普通歷史數據存儲機械磁盤的檢索效率。
2、索引優化實踐
Mysql等關系數據庫要分庫、分表。Elasticserach也要充分考慮。
2.1設置多少個索引？
建議根據業務場景進行存儲。
不同渠道類型的數據應分為索引存儲。例如：知乎采集信息存儲到知乎索引；APP采集信息存儲到APP索引。
2.2設置多少分片？
建議根據數據量進行測量。
經驗值：建議每片尺寸不超過30GB。
2.3分片數設置？
建議根據集群節點的數量規模，建議>=集群節點的數量。
5個節點的集群，5個分片比較合理。
注：除非reindex操作，否則不能修改分片數。
2.4副本數設置？
除非你對系統的健壯性有很高的要求，比如銀行系統。可以考慮兩份以上。
否則，一個副本就足夠了。
注：可通過配置隨時修改副本數。
2.5不要在一個索引下創建多個type
即便你是5.考慮到未來版本升級等后續可擴展性，X版本。
建議:一個索引對應一個type。
6.默認對應_xxdoc，5.x您直接對應type統一為doc。
2.6根據日期規劃索引索引
隨著業務量的增加，單一索引與數據量激增的矛盾突出。
按日期規劃索引是必然選擇。
好處1：歷史數據可以在幾秒鐘內刪除。非常適合歷史索引delete。注：如果索引需要使用delete_by_query force_merge操作慢，刪除不徹底。
好處2：便于冷熱數據的單獨管理，檢索近幾天的數據，直接物理指定相應日期的索引，速度快！
操作參考：模板使用 使用rolloverAPI。
2.7必須使用別名
與mysql不同，ES更改索引名稱。使用別名是一個相對靈活的選擇。
3、優化實踐的數據模型3.1不要使用默認的Mapping
默認Mapping的字段類型由系統自動識別。其中，string類型默認分為兩種類型：text和keyword。如果您的業務不需要單詞分割和搜索，只需要準確匹配，只設置為keyword。
根據業務需要選擇合適的類型，有利于節省空間，提高精度，如浮點型的選擇。
3.2Mapping各字段的選擇流程3.3選擇合理的分詞器
常見的開源中文分詞器包括：ik分詞器、ansj分詞器、hanlp分詞器、結巴分詞器、海量分詞器、“elasticsearch最全分詞器比較及使用方法”搜索可查看比較效果。
如果選擇ik，建議使用ik_max_word。因為粗粒度的分詞結果基本上包括細粒度ik_smart的結果。
3.4date、long、還是keyword
根據業務需要，如果需要根據時間軸進行分析，則必須進行date類型；
如果只需要秒返回，建議使用常州網站seo優化推廣優化keyword。
4、數據寫入優化實踐4.1要不要秒級響應？
Elasticsearch近實時的本質是：最快1s寫入的數據可以查詢。
如果refresh_interval設置為1s，必然會產生大量的segment，影響檢索性能。
因此，可以將非實時場景調大，設置為30s甚至-1。
4.2減少副本，提高寫入性能。
寫入前，副本數設置為0，
寫入后，將副本數設置為原始值。
4.3能量批量不單條寫入
批量接口為bulk，批量尺寸應與隊列尺寸相結合，而隊列尺寸、線程池尺寸、機器cpu核數。
4.4禁用swap
在Linux系統中，通過運行以下命令暫時禁用交換：
sudoswapofff-a
5、實戰檢索聚合優化5.1禁用wildcard模糊匹配
達到TB的數據量級 甚至更高之后，wildcard在多字段組合的情況下很容易卡死，甚至導致集群節點崩潰停機。
后果不堪設想。
替代方案：
方案1:對于精度要求高的方案:兩套分詞器、standard和ik的組合，使用match_phrase進行檢索。
方案二:對于精度要求低的替代方案:建議通過match_phrase和slop查詢ik分詞。
5.2使用match匹配極小概率的概率
顯然，中文match匹配的結果是不準確的。短語匹配將用于大型商業場景。”match_phrase"。
match_phrase結合合理的分詞詞典和詞庫，會使搜索結果更加準確，避免噪音數據。
5.3結合業務場景，大量使用filter過濾器
filter緩存機制無疑會使檢索更快，而不需要使用計算相關評分的場景。
例如：過濾郵編號。
5.4控制返回字段和結果
和mysql查詢一樣，在業務開發中，select*操作幾乎是不必要的。
同理，在ES中，_sourc崇義seo網站優化e返回所有字段也是不必要的。
通過_source控制字段的返回，只返回與業務相關的字段。
網頁文本content，網頁快照html_content類似字段的批量返回，可能是業務設計缺陷。
顯然，摘要字段應提前寫入，而不是在截取處理之前查詢content。
5.5分頁深度查詢和遍歷
使用分頁查詢：from size;
遍歷使用：scroll；
并行遍歷使用：scroll slice。
考慮集合業務的選擇和使用。
5.6合理設置聚合Size
聚合結果是不準確的。除非你把size設置為2的32次冪-1，否則聚合結果是取每個片段的topsize元素后綜合排序的值。
實際業務場景需要注意準確的反饋結果。
盡量不要獲得全聚合結果——從業務層面獲得Topn聚合結果值是非常合理的。因為排名靠后的結果值意義不大。
合理實現5.7聚合分頁
當顯示聚合結果時，聚合后分頁必然會面臨問題，ES官員不支持聚合后分頁，因為性能原因。
若需要聚合后分頁，則需要自開發實現。包括但不限于:
方案一:每次取聚合結果，獲取內存中分頁返回。
方案二：scrolll結合scrollafter集合redis實現。
6、業務優化
讓Elasticsearch做它擅長的事情，顯然，它更擅長基于倒排索引進行搜索。
建議Elasticsearch更有效地檢索：
1)要做好“前戲”
在寫入ES之前的ETL階段，將字段提取、傾向分析、分類/聚類、相關性判斷放在ETL階段；
2)“睡衣”產品經理
基于各種奇妙的業務場景，產品經理可能會提出各種不合理的需求。
作為一名技術人員，我們應該“通知理性”，向產品經理解釋搜索引擎的原理，Elasticsearch的原理，什么可以做，什么真正的“妾不能做”。
7、小結
在實際的業務發展中，公司一般要求馬不吃草，想馬快跑。
Elasticsearch開發也是如此，硬件資源不足（cpu、幾乎沒有辦法提高內存和磁盤的性能。
除了檢索聚合，讓Elasticsearch做N多相關和不相關的工作，然后得出結論，“Elastic太慢了，沒有想象的那么快”。
類似的場景也出現在你的腦海里嗎？
提供相對NB的硬件資源，做好各種前期準seo網站關鍵詞優化乚品達備，讓Elasticsearch輕裝上陣，相信你的Elasticsearch也會飛起來！
以上是潮人地東莞seo博客跟大家分享關于seo優化技術：如何看待這種快照秒收方式-讓Elasticsearch飛起來（性能優化實踐干貨）等問題，希望能對大家有所幫助，若有不足之處，請諒解，我們大家可以一起討論關于網站seo優化排名的技巧，一起學習，以上內容僅供參考。
