日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
ElasticSearch使用規(guī)范Beta版

本文轉(zhuǎn)載自微信公眾號「Redis開發(fā)運(yùn)維實戰(zhàn)」，作者付磊。轉(zhuǎn)載本文請聯(lián)系Redis開發(fā)運(yùn)維實戰(zhàn)公眾號。  

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：國際域名空間、雅安服務(wù)器托管、營銷軟件、網(wǎng)站建設(shè)、臨海網(wǎng)站維護(hù)、網(wǎng)站推廣。

ElasticSearch除了在日志場景(監(jiān)控、數(shù)據(jù)分析、debug)等場景大量使用以外，最近一年多在很多核心上的線上業(yè)務(wù)(譬如電商業(yè)務(wù))大量使用，目前接近了5000個節(jié)點(diǎn)，目前在db-ranking(2020-11-24日)，ElasticSearch在search-engine中常年第一：

對于MySQL、Redis這類存儲緩存許多開發(fā)同學(xué)多有很強(qiáng)的最佳實踐，但對于ElasticSearch的使用經(jīng)驗相對模式。我個人經(jīng)驗是ElasticSearch非常便于開發(fā)(譬如支持dynamic mapping)但它相對脆弱：一方面是開發(fā)同學(xué)對于其重視程度不夠(譬如沒有自己制定mapping)、另一方面它本身的一些設(shè)計(例如聚合計算都在JVM完成)導(dǎo)致其相對脆弱。

為此我們提供一份關(guān)于ElasticSearch的開發(fā)規(guī)范幫助ElasticSearch使用者減少一些可能碰到的坑

一、容量規(guī)劃

1. 分片(shard)容量

  • 非日志型(搜索型、線上業(yè)務(wù)型)的shard容量在10~30GB(建議在10G)
  • 日志型的shard容量在30~100GB(建議30G)
  • 單個shard的文檔個數(shù)不能超過21億左右(Integer.MAX_VALUE - 128)

注：一個shard就是一個lucene分片，ES底層基于lucene實現(xiàn)。

2. 索引(index)數(shù)量

  • 大索引需要拆分：增強(qiáng)性能，風(fēng)險分散。

反例：一個10T的索引，例如按date查詢、name查詢

正例：index_name拆成多個index_name_${date}

正例：index_name按hash拆分index_name_{1,2,3,...100..}

 
 
 
 
    
  
  
  
  
  1. 提示：索引和shard數(shù)并不是越多越好，對于批量讀寫都會有性能下降，所以要綜合考慮性能和容量規(guī)劃，同時配合壓力測試，不存在真正的最優(yōu)解。 
    2.

3. 節(jié)點(diǎn)、分片、索引

一個節(jié)點(diǎn)管理的shard數(shù)不要超過200個

4. 示意圖

(1) 集群

(2) 節(jié)點(diǎn)：

(3) 索引：

(4) 分片(shard)

二、 索引mapping設(shè)計

大原則：不用默認(rèn)配置和動態(tài)mapping、數(shù)據(jù)用途(類型、分詞、存儲、排序)弄清，下面是一個標(biāo)準(zhǔn)mapping：

1. shard個數(shù)(number_of_shards)：

參考一

2. refresh頻率(refresh_interval)：

ES的定位是準(zhǔn)實時搜索引擎，該值默認(rèn)是1s，表示寫入后1秒后可被搜索到，所以這里的值取決于業(yè)務(wù)對實時性的要求，注意這里并不是越小越好，刷新頻率高也意味著對ES的開銷也大，通常業(yè)務(wù)類型在1-5s，日志型在30s-120s，如果集中導(dǎo)入數(shù)據(jù)可將其設(shè)置為-1，ES會自動完成數(shù)據(jù)刷新(注意完成后更改回來，否則后續(xù)會出現(xiàn)搜索不到數(shù)據(jù))

3. 使用別名(aliases)：不要過度依賴別名功能

正例：

  • 索引名：index_name_v1
  • 別名：index_name

未來重建index_name_v2索引，對于業(yè)務(wù)來說只需要換別名。

4. type個數(shù)

1個就夠了，從ES6開始只支持一個type，這個type比較雞肋，后面的版本可能會去掉。

如果一定用：針對已經(jīng)使用多個type的場景，一定要保證不同type下字段盡量保持一致，否則會加大數(shù)據(jù)稀疏性，存儲與查詢性能受影響

5. 慢日志(slowlog)：

一定要配置，默認(rèn)不記錄慢查詢，kcc提供了grafana、kibana查詢功能。

6. 副本(number_of_replicas)

1個就夠用，副本多寫入壓力不可忽視。極端情況下：譬如批量導(dǎo)入數(shù)據(jù)，可以將其調(diào)整為0.

7. 字段設(shè)計

(1) text和keyword的用途必須分清：分詞和關(guān)鍵詞(確定字段是否需要分詞)

(2) 確定字段是否需要獨(dú)立存儲

(3) 字段類型不支持修改，必須謹(jǐn)慎。

(4) 對不需要進(jìn)行聚合/排序的字段禁用doc_values

 
 
 
 
    
  
  
  
  
  1. text 類型作用：分詞，用于搜索。 
    2. 
  
  
  
  
  2.  適用于：email 內(nèi)容、某產(chǎn)品的描述等需要分詞全文檢索的字段； 
    3. 
  
  
  
  
  3.  不適用：排序或聚合（Significant Terms 聚合例外） 
    4. 
  
  
  
  
  4. keyword 類型：無需分詞、整段完整精確匹配。 
    5. 
  
  
  
  
  5.  適用于：email 地址、住址、狀態(tài)碼、分類 tags。 
    6.

(5) 不要在text做模糊搜索：

8. 設(shè)置合理的routing key(默認(rèn)是id)

id不均衡：集群容量和訪問不均衡，對于分布式存儲是致命的。

9. 關(guān)閉_all

ES6.0已經(jīng)去掉，對容量(索引過大)和性能(性能下降)都有影響。

10. 避免大寬表：

ES默認(rèn)最大1000，但建議不要超過100.

11. text類型的字段不要使用聚合查詢。

text類型fileddata會加大對內(nèi)存的占用，如果有需求使用，建議使用keyword

12.聚合查詢避免使用過多嵌套，

聚合查詢的中間結(jié)果和最終結(jié)果都會在內(nèi)存中進(jìn)行，嵌套過多，會導(dǎo)致內(nèi)存耗盡

比如以下聚合就嵌套了3層，country、city和salary的結(jié)果都會保存在內(nèi)存中，如果唯一值較多，就會導(dǎo)致內(nèi)存耗盡

 
 
 
 
    
  
  
  
  
  1. { 
    2. 
  
  
  
  
  2.     "aggs":{ 
    3. 
  
  
  
  
  3.         "country":{ 
    4. 
  
  
  
  
  4.             "terms":{ 
    5. 
  
  
  
  
  5.                 "filed":"country", 
    6. 
  
  
  
  
  6.                 "size":10 
    7. 
  
  
  
  
  7.             }, 
    8. 
  
  
  
  
  8.             "aggs":{ 
    9. 
  
  
  
  
  9.                 "city":{ 
    10. 
  
  
  
  
  10.                     "terms":{ 
    11. 
  
  
  
  
  11.                         "filed":"city", 
    12. 
  
  
  
  
  12.                         "size":20 
    13. 
  
  
  
  
  13.                     }, 
    14. 
  
  
  
  
  14.                     "aggs":{ 
    15. 
  
  
  
  
  15.                         "salary":{ 
    16. 
  
  
  
  
  16.                             "terms":{ 
    17. 
  
  
  
  
  17.                                 "filed":"salary", 
    18. 
  
  
  
  
  18.                                 "size":20 
    19. 
  
  
  
  
  19.                             } 
    20. 
  
  
  
  
  20.                         } 
    21. 
  
  
  
  
  21.                     } 
    22. 
  
  
  
  
  22.                 } 
    23. 
  
  
  
  
  23.             } 
    24. 
  
  
  
  
  24.         } 
    25. 
  
  
  
  
  25.     } 
    26. 
  
  
  
  
  26. } 
    27.

三、違規(guī)操作

1. 原則：不要忽略設(shè)計，快就是慢，壞的索引設(shè)計后患無窮.

2. 拒絕大聚合 ：ES計算都在JVM內(nèi)存中完成。

3. 拒絕模糊查詢：es一大殺手

 
 
 
 
    
  
  
  
  
  1. { 
    2. 
  
  
  
  
  2.     "query":{ 
    3. 
  
  
  
  
  3.         "wildcard":{ 
    4. 
  
  
  
  
  4.             "title.keyword":"*張三*" 
    5. 
  
  
  
  
  5.         } 
    6. 
  
  
  
  
  6.     } 
    7. 
  
  
  
  
  7. } 
    8.

4. 拒絕深度分頁

ES獲取數(shù)據(jù)時，每次默認(rèn)最多獲取10000條，獲取更多需要分頁，但存在深度分頁問題，一定不要使用from/Size方式，建議使用scroll或者searchAfter方式。scroll會把上一次查詢結(jié)果緩存一定時間(通過配置scroll=1m實現(xiàn))，所以在使用scroll時一定要保證search結(jié)果集不要太大。

5. 基數(shù)查詢

盡量不要用基數(shù)查詢?nèi)ゲ樵內(nèi)ブ睾蟮臄?shù)據(jù)量大小(kibana中界面上顯示是Unique Count，Distinct Count等)，即少用如下的查詢：

 
 
 
 
    
  
  
  
  
  1. "aggregations": { 
    2. 
  
  
  
  
  2.      "cardinality": { 
    3. 
  
  
  
  
  3.           "field": "userId" 
    4. 
  
  
  
  
  4.       } 
    5. 
  
  
  
  
  5.  } 
    6.

6. 禁止查詢 indexName-*

7. 避免使用script、update_by_query、delete_by_query，對線上性能影響較大。

四、常見問題

1. 一個索引的shard數(shù)一旦確定不能改變

2. ES不支持事務(wù)ACID特性。

3. reindex：

reindex可以實現(xiàn)索引的shard變更，但代價非常大：速度慢、對性能有影響，所以好的設(shè)計和規(guī)劃更重要

五、grafana使用規(guī)范

1.查詢范圍不要太大，建議在3h以內(nèi)

如下查詢7d，數(shù)據(jù)量巨大，嚴(yán)重影響集群查詢性能

2. 拒絕多層嵌套，不要超過2層

如下圖中進(jìn)行了4層嵌套，每層嵌套的結(jié)果都緩存在內(nèi)存中，導(dǎo)致內(nèi)存崩潰

3. 拒絕分時查詢

分位查詢相當(dāng)于一種分桶聚合方式，分的桶越多，帶來的CPU計算量越大

4. 拒絕TOP>100查詢

top查詢是在聚合的基礎(chǔ)上再進(jìn)行排序，如果top太大，cpu的計算量和耗費(fèi)的內(nèi)存都會導(dǎo)致查詢瓶頸

5. 拒絕正則匹配查詢


網(wǎng)頁名稱：ElasticSearch使用規(guī)范Beta版
文章分享：http://m.5511xx.com/article/cooppgh.html