公司數據存儲用的最多的就是ES了,大概每天會產生1T的數據,這個數據量還是挺大的,公司用的ES集羣有12個節點,後期可能還要擴展,於是便看些博客再結合自己工作,總結了一些ES的調優
第一部分:調優索引速度
1、使用批量請求批量請求將產生比單文檔索引請求好得多的性能。
爲了知道批量請求的最佳大小,您應該在具有單個分片的單個節點上運行基準測試。
首先嚐試索引100個文件,然後是200,然後是400,等等。當索引速度開始穩定時,您知道您達到了數據批量請求的最佳大小。
請注意,如果羣集請求太大,可能會使羣集受到內存壓力,因此建議避免超出每個請求幾十兆字節,即使較大的請求看起來效果更好。
-
發送端使用多worker/多線程向es發送數據 發送批量請求的單個線程不太可能將Elasticsearch羣集的索引容量最大化。
爲了使用集羣的所有資源,您應該從多個線程或進程發送數據。除了更好地利用集羣的資源,這應該有助於降低每個fsync的成本。
請確保注意TOO_MANY_REQUESTS(429)響應代碼(Java客戶端的EsRejectedExecutionException),這是Elasticsearch告訴您無法跟上當前索引速率的方式。
發生這種情況時,應該再次嘗試暫停索引,理想情況下使用隨機指數回退。
與批量調整大小請求類似,只有測試才能確定最佳的worker數量。這可以通過逐漸增加工作者數量來測試,直到集羣上的I / O或CPU飽和。
-
調大 refresh interval 默認的index.refresh_interval是1s,這迫使Elasticsearch每秒創建一個新的分段。增加這個價值(比如說30s)將允許更大的部分flush並減少未來的合併壓力。
-
加載大量數據時禁用refresh和replicas 如果您需要一次加載大量數據,則應該將index.refresh_interval設置爲-1並將index.number_of_replicas設置爲0來禁用刷新。
這會暫時使您的索引處於危險之中,因爲任何分片的丟失都將導致數據 丟失,但是同時索引將會更快,因爲文檔只被索引一次。
初始加載完成後,您可以將index.refresh_interval和index.number_of_replicas設置回其原始值。
-
設置參數,禁止OS將es進程swap出去 您應該確保操作系統不會swapping out the java進程,通過禁止swap
-
爲filesystem cache分配一半的物理內存 文件系統緩存將用於緩衝I / O操作。您應該確保將運行Elasticsearch的計算機的內存至少減少到文件系統緩存的一半。
-
使用自動生成的id(auto-generated ids) 索引具有顯式id的文檔時,Elasticsearch需要檢查具有相同id的文檔是否已經存在於相同的分片中,這是昂貴的操作,並且隨着索引增長而變得更加昂貴。通過使用自動生成的ID,Elasticsearch可以跳過這個檢查,這使索引更快。
-
買更好的硬件,搜索一般是I/O 密集的,此時,你需要
-
爲filesystem cache分配更多的內存
-
使用SSD硬盤
-
使用local storage(不要使用NFS、SMB 等remote filesystem)
-
亞馬遜的 彈性塊存儲(Elastic Block Storage)也是極好的,當然,和local storage比起來,它還是要慢點 如果你的搜索是 CPU-密集的,買好的CPU吧
-
-
加大 indexing buffer size
如果你的節點只做大量的索引,確保index.memory.index_buffer_size足夠大,每個分區最多可以提供512 MB的索引緩衝區,而且索引的性能通常不會提高。
Elasticsearch採用該設置(java堆的一個百分比或絕對字節大小),並將其用作所有活動分片的共享緩衝區。非常活躍的碎片自然會使用這個緩衝區,而不是執行輕量級索引的碎片。
默認值是10%,通常很多:例如,如果你給JVM 10GB的內存,它會給索引緩衝區1GB,這足以承載兩個索引很重的分片。
-
禁用_field_names字段 _field_names字段引入了一些索引時間開銷,所以如果您不需要運行存在查詢,您可能需要禁用它。
-
剩下的,再去看看 “調優 磁盤使用”吧 ,中有許多磁盤使用策略也提高了索引速度。
第二部分-調優搜索速度
1、filesystem cache越大越好 爲了使得搜索速度更快, es嚴重依賴filesystem cache
一般來說,需要至少一半的 可用內存作爲filesystem cache,這樣es可以在物理內存中 保有 索引的熱點區域(hot regions of the index)
2、用更好的硬件 搜索一般是I/O bound的,此時,你需要
- 爲filesystem cache分配更多的內存
- 使用SSD硬盤
- 使用local storage(不要使用NFS、SMB 等remote filesystem)
- 亞馬遜的 彈性塊存儲(Elastic Block Storage)也是極好的,當然,和local storage比起來,它還是要慢點 如果你的搜索是 CPU-bound,買好的CPU吧
3、文檔模型(document modeling) 文檔需要使用合適的類型,從而使得 search-time operations 消耗更少的資源。咋作呢?
答:避免 join操作。具體是指 a.nested 會使得查詢慢 好幾倍 b.parent-child關係 更是使得查詢慢幾百倍 如果 無需join 能解決問題,則查詢速度會快很多
4、預索引 數據 根據“搜索數據最常用的方式”來最優化索引數據的方式
舉個例子:所有文檔都有price字段,大部分query 在 fixed ranges 上運行 range aggregation。你可以把給定範圍的數據 預先索引下。然後,使用 terms aggregation
5、Mappings(能用 keyword 最好了) 數字類型的數據,並不意味着一定非得使用numeric類型的字段。
一般來說,存儲標識符的 字段(書號ISBN、或來自數據庫的 標識一條記錄的 數字),使用keyword更好(integer,long 不好哦)
6、避免運行腳本 一般來說,腳本應該避免。如果他們是絕對需要的,你應該使用painless和expressions引擎。
7、搜索rounded 日期 日期字段上使用now,一般來說不會被緩存。但,rounded date則可以利用上query cache rounded到分鐘等
8、強制merge只讀的index 只讀的index可以從“merge成 一個單獨的 大segment”中收益
9、預熱 全局序數(global ordinals)。全局序數用於在keyword字段上運行terms aggregations。es不知道哪些fields將用於/不用於 term aggregation。
因此全局序數在需要時才加載進內存,但可以在mapping type上,定義 eager_global_ordinals==true。這樣,refresh時就會加載 全局序數
10、預熱 filesystem cache 機器重啓時,filesystem cache就被清空。
OS將index的熱點區域(hot regions of the index)加載進filesystem cache是需要花費一段時間的。設置 index.store.preload 可以告知OS 這些文件需要提早加載進入內存
11、使用索引排序來加速連接 索引排序對於以較慢的索引爲代價來加快連接速度非常有用。在索引分類文檔中閱讀更多關於它的信息。
12、使用preference來優化高速緩存利用率 有多個緩存可以幫助提高搜索性能,例如文件系統緩存,請求緩存或查詢緩存。
然而,所有這些緩存都維護在節點級別,這意味着如果連續運行兩次相同的請求,則有一個或多個副本,並使用循環(默認路由算法),那麼這兩個請求將轉到不同的分片副本,阻止節點級別的緩存幫助。
由於搜索應用程序的用戶一個接一個地運行類似的請求是常見的,例如爲了分析索引的較窄的子集,使用標識當前用戶或會話的優選值可以幫助優化高速緩存的使用。
13、副本可能有助於吞吐量,但不會一直存在 除了提高彈性外,副本可以幫助提高吞吐量。例如,如果您有單個分片索引和三個節點,則需要將副本數設置爲2,以便共有3個分片副本,以便使用所有節點。
現在假設你有一個2-shards索引和兩個節點。
在一種情況下,副本的數量是0,這意味着每個節點擁有一個分片。在第二種情況下,副本的數量是1,這意味着每個節點都有兩個碎片。
哪個設置在搜索性能方面表現最好?通常情況下,每個節點的碎片數少的設置將會更好。
原因在於它將可用文件系統緩存的份額提高到了每個碎片,而文件系統緩存可能是Elasticsearch的1號性能因子。
同時,要注意,沒有副本的設置在發生單個節點故障的情況下會出現故障,因此在吞吐量和可用性之間進行權衡。
那麼複製品的數量是多少?如果您有一個具有num_nodes節點的羣集,那麼num_primaries總共是主分片,如果您希望能夠一次處理max_failures節點故障,那麼正確的副本數是max(max_failures,ceil(num_nodes / num_primaries) - 1)。
14、打開自適應副本選擇 當存在多個數據副本時,elasticsearch可以使用一組稱爲自適應副本選擇的標準,根據包含分片的每個副本的節點的響應時間,服務時間和隊列大小來選擇數據的最佳副本。這可以提高查詢吞吐量並減少搜索量大的應用程序的延遲。
第三部分:通用的一些建議
1、不要 返回大的結果集。es設計來作爲搜索引擎,它非常擅長返回匹配query的top n文檔。
但如“返回滿足某個query的 所有文檔”等數據庫領域的工作,並不是es最擅長的領域。如果你確實需要返回所有文檔,你可以使用Scroll API
2、避免大的doc。即單個doc小了會更好 given that(考慮到) http.max_context_length默認==100MB,es拒絕索引操作100MB的文檔。
當然你可以提高這個限制,但Lucene本身也有限制的,其爲2GB 即使不考慮上面的限制,大的doc 會給 network/memory/disk帶來更大的壓力;
- a.任何搜索請求,都需要獲取 _id 字段,由於filesystem cache工作方式。即使它不請求 _source字段,獲取大doc _id 字段消耗更大
- b.索引大doc時消耗內存會是 doc本身大小 的好幾倍
- c.大doc的 proximity search, highlighting 也更加昂貴。它們的消耗直接取決於doc本身的大小
3、避免 稀疏
- a.不相關數據 不要 放入同一個索引
- b.一般化文檔結構(Normalize document structures)
- c.避免類型
- d.在 稀疏 字段上,禁用 norms & doc_values 屬性
稀疏爲什麼不好?
Lucene背後的數據結構更擅長處理緊湊的數據text類型的字段,norms默認開啓;numerics, date, ip, keyword,doc_values默認開啓 Lucene內部使用 integer的doc_id來標識文檔 和 內部API交互。
舉個例子:使用match查詢時生成doc_id的迭代器,這些doc_id被用於獲取它們的norm,以便計算score。
當前的實現是每個doc中保留一個byte用於存儲norm值。獲取norm值其實就是讀取doc_id位置處的一個字節 這非常高效,Lucene通過此值可以快速訪問任何一個doc的norm值;
但給定一個doc,即使某個field沒有值,仍需要爲此doc的此field保留一個字節 doc_values也有同樣的問題。2.0之前的fielddata被現在的doc_values所替代了。
稀疏性最明顯的影響是 對存儲的需求(任何doc的每個field,都需要一個byte)
但是稀疏性對索引速度和查詢速度也是有影響的,因爲即使doc並沒有某些字段值,但索引時依然需要寫這些字段
查詢時需要skip這些字段的值 某個索引中擁有少量稀疏字段,這完全沒有問題。但這不應該成爲常態
稀疏性影響最大的是 norms&doc_values ,但,倒排索引(用於索引 text以及keyword字段),二維點(用於索引geo_point字段)也會受到較小的影響
如何避免稀疏呢?
1、不相關數據 不要 放入同一個索引 給個tip:索引小(即:doc的個數較少),則,primary shard也要少
2、一般化文檔結構(Normalize document structures)
3、避免類型(Avoid mapping type) 同一個index,最好就一個mapping type 在同一個index下面,使用不同的mapping type來存儲數據
這聽起來不錯,但其實不好。given that(考慮到)每一個mapping type會把數據存入 同一個index,因此,多個不同mapping type,各個的field又互不相同,這同樣帶來了稀疏性 問題
4、在稀疏字段上,禁用 norms & doc_values 屬性
a.norms用於計算score,無需score,則可以禁用它(所有filtering字段,都可以禁用norms)
b.doc_vlaues用於sort&aggregations,無需這兩個,則可以禁用它 但是,不要輕率的做出決定,因爲 norms&doc_values無法修改。只能reindex
祕訣1:混合 精確查詢和提取詞幹(mixing exact search with stemming) 對於搜索應用,提取詞幹(stemming)都是必須的。
例如:查詢 skiing時,ski和skis都是期望的結果 但,如果用戶就是要查詢skiing呢?
解決方法是:使用multi-field。同一份內容,以兩種不同的方式來索引存儲 query.simple_query_string.quote_field_suffix,竟然是 查詢完全匹配的
祕訣2:獲取一致性的打分 score不能重現 同一個請求,連續運行2次,但,兩次返回的文檔順序不一致。這是相當壞的用戶體驗
如果存在 replica,則就可能發生這種事,這是因爲:search時,replication group中的shard是按round-robin方式來選擇的
因此兩次運行同樣的請求,請求如果打到 replication group中的不同shard,則兩次得分就可能不一致
那問題來了,“你不是整天說 primary和replica是in-sync的,是完全一致的”嘛,爲啥打到“in-sync的,完全一致的shard”卻算出不同的得分?
原因就是標註爲“已刪除”的文檔。如你所知,doc更新或刪除時,舊doc並不刪除,而是標註爲“已刪除”,只有等到 舊doc所在的segment被merge時,“已刪除”的doc纔會從磁盤刪除掉
索引統計(index statistic)是打分時非常重要的一部分,但由於 deleted doc 的存在,在同一個shard的不同copy(即:各個replica)上計算出的索引統計並不一致
個人理解:a. 所謂索引統計應該就是df,即 doc_freq b. 索引統計是基於shard來計算的
-
搜索時,“已刪除”的doc 當然是 永遠不會 出現在 結果集中的
-
索引統計時,for practical reasons,“已刪除”doc 依然是統計在內的
假設,shard A0 剛剛完成了一次較大的segment merge,然後移除了很多“已刪除”doc,shard A1 尚未執行 segment merge,因此 A1 依然存在那些“已刪除”doc
於是:兩次請求打到 A0 和 A1 時,兩者的 索引統計 是顯著不同的
如何規避 score不能重現 的問題?
使用 preference 查詢參數 發出搜索請求時候,用 標識字符串 來標識用戶,將 標識字符串 作爲查詢請求的preference參數。
這確保多次執行同一個請求時候,給定用戶的請求總是達到同一個shard,因此得分會更爲一致(當然,即使同一個shard,兩次請求 跨了 segment merge,則依然會得分不一致)
這個方式還有另外一個優點,當兩個doc得分一致時,則默認按着doc的 內部Lucene doc id 來排序(注意:這並不是es中的 _id 或 _uid)。
但是呢,shard的不同copy間,同一個doc的 內部Lucene doc id 可能並不相同。因此,如果總是達到同一個shard,則,具有相同得分的兩個doc,其順序是一致的
score錯了 score錯了(Relevancy looks wrong) 如果你發現
-
具有相同內容的文檔,其得分不同
-
完全匹配 的查詢 並沒有排在第一位 這可能都是由 sharding 引起的
-
默認情況下,搜索文檔時,每個shard自己計算出自己的得分。
-
索引統計 又是打分時一個非常重要的因素。
如果每個shard的 索引統計相似,則 搜索工作的很好 文檔是平分到每個primary shard的,因此 索引統計 會非常相似,打分也會按着預期工作。
但萬事都有個但是:
-
索引時使用了 routing(文檔不能平分到每個primary shard 啦)
-
查詢多個索引
-
索引中文檔的個數 非常少 這會導致:參與查詢的各個shard,各自的 索引統計 並不相似(而,索引統計對 最終的得分 又影響巨大),於是 打分出錯了(relevancy looks wrong)
那如何繞過 score錯了(Relevancy looks wrong)?
如果數據集較小,則,只使用一個primary shard(es默認是5個),這樣兩次查詢 索引統計 不會變化,因而得分也就一致啦
另一種方式是,將search_type設置爲:dfs_query_then_fetech(默認是query_then_fetch) dfs_query_then_fetch的作用是
-
向 所有相關shard 發出請求,要求 所有相關shard 返回針對當前查詢的 索引統計
-
然後,coordinating node 將 merge這些 索引統計,從而得到 merged statistics
-
coordinating node 要求所有相關shard 執行 query phase,於是發出請求,這時,也帶上 merged statistics。
這樣執行query的shard將使用全局的索引統計。大部分情況下,要求 所有相關shard 返回針對當前查詢的 索引統計,這是非常cheap的。
但如果查詢中包含非常大量的 字段/term查詢,或者有 fuzzy查詢,此時,獲取 索引統計 可能並不cheap,因爲爲了得到索引統計 可能 term dictionary 中 所有的term都需要被查詢一遍