# 一些建議 原文鏈接 : [https://www.elastic.co/guide/en/elasticsearch/reference/5.3/general-recommendations.html](https://www.elastic.co/guide/en/elasticsearch/reference/5.3/general-recommendations.html) 譯文鏈接 : [一些建議](/pages/viewpage.action?pageId=10027109) 貢獻者 : @李堅，[ApacheCN](/display/~apachecn)，[Apache中文網](/display/~apachechina) ## 不要返回大的結果集 Elasticsearch被設計為一個搜索引擎，這使得它非常好地獲取與查詢匹配的頂級文檔。 但是，它對于落入數據庫域的工作負載并不好，例如檢索與特定查詢匹配的所有文檔。 如果需要這樣做，請確保使用Scroll API。 ## 避免大文件 假設默認_**http.max_context_length**_ 的設置為100MB，_Elasticsearch_ 將拒絕索引大于該值的任何文檔。 您可能會決定增加該特定設置，但是Lucene的限制約為2GB。 即使沒有考慮到硬限制，大型文件通常也不實用。即使搜索請求不需要 _source，大型文檔也會對網絡，內存使用和磁盤造成更大的壓力，因為在所有情況下，Elasticsearch 需要獲取文檔的_id，并且獲取此字段的成本將大于大文檔工作時占用的文件系統緩存。索引這個大文檔所占用的內存是一個普通文檔的乘數倍。鄰近搜索（例如短語查詢）和高亮顯示也變得花費更多系統資源，因為它們的花費的系統資源成本直接取決于原始文檔的大小。 重新考慮信息的單位應該是有用的。例如，您想要使書籍可搜索，并不意味著可搜索的這個文檔應該由整本書組成。使用章節甚至段落作為文檔可能是一個更好的辦法，然后在這些文檔中有一個屬性標識他們屬于哪本書。這不僅避免了大文件的問題，還使搜索體驗更好。例如，如果用戶搜索兩個單詞foo和bar，則不同章節中的匹配可能非常差，而同一段落中的匹配可能很好。 ## 避免稀疏 Elasticsearch 依賴于索引和存儲數據的 Lucene 后面的數據結構最適用于密集數據，比如，當所有文檔都有相同的字段的時候。對于啟用規范的字段（默認情況下為文本字段）或啟用了文檔值（默認情況下為數字，日期，IP和關鍵字）的情況尤其如此。 原因是 Lucene 內部標識了 documents（文檔）所謂的 doc_id，它們是在 0 和 documents（文檔）總數之間的一個整數。?這些 documents（文檔）用于Lucene的內部API之間的通信：例如，使用 match 查詢搜索 term 時會生成doc id的迭代器，然后使用這些 documents（文檔）來檢索規范的值以計算這些 documents（文檔）的得分。實現此規范查找的方法是為每個 documents（文檔）保留一個字節，然后通過讀取索引中的 doc_id 字節來檢索給定 documents（文檔）的 id 的取值集合。雖然這是非常有效的，并且可以幫助 Lucene 快速訪問每個 documents（文檔）的標準值，但這樣做的缺點是沒有值的文檔也需要一個字節的存儲空間。 實際上，這意味著如果一個索引具有M個文檔，則規范將需要每個字段M個字節的存儲空間，即使只出現在索引文檔的一小部分中的字段也是如此。雖然文檔取值稍微復雜一些，因為 doc值 有多種方式，但是可以根據字段的類型和字段存儲的實際數據進行編碼，問題是非常相似的。如果想了解 fielddata，在?_Elasticsearch_ 2.0 之前的版本使用，之后替換成了?doc values，同樣收到這個問題的影響，但是?fielddata 只是在內存占用上有影響，沒有明確的具體化到磁盤。 請注意，盡管稀疏性最顯著的影響是存儲要求，但它也對索引速度和搜索速度有影響，因為這些字節對于沒有字段的文檔仍然需要在索引時寫入并且在搜索時跳過。 索引中少數稀疏字段是完全正確的。 但請注意，如果稀疏性成為規則而不是異常，那么索引將不會如此有效。 這一部分主要集中在規范和 doc 值上，因為這些是影響最小兩大特征。稀疏性也影響反向索引的效率（用于索引 _text / keyword_ 字段）和維度點（用于索引 geo_point 和數字），但程度較小。 以下是一些可以幫助避免稀疏性的建議： ### 避免將不相關的數據放在同一個索引中 您應避免將具有完全不同結構的 _documents（文檔）_放入同一索引中，以避免稀疏。將這些文件放在不同的索引中往往更好，您也可以考慮為這些較小的索引提供更少的碎片，因為它們整體上將包含更少的文檔。 請注意，此建議不適用于您需要使用文檔之間的_parent / child_ 關系的情況，因為該功能僅在同一索引中的文檔支持。 ### 統一文檔結構 即使你真的需要將不同類型的文檔放在同一個索引中，也有機會減少稀疏性。 例如，如果索引中的所有文檔都有一個 timestamp 字段，但有些則將其稱為 timestamp，而另一些則將其稱為“create_date”，那么對它重命名，以便所有文檔具有相同數據的相同字段名稱。 ### 避免多類型（types） Types（類型）可能聽起來像是在單個索引中存儲多個租戶的好方法。 它們不是：給定類型將所有內容存儲在單個索引中，在單個索引中具有不同字段的多個類型也將由于如上所述的稀疏性而導致問題。 如果您的類型沒有非常相似的映射，您可能需要考慮將它們移動到專用索引。 ### 在稀疏字段上禁用** `norms`**?和 doc_values 如果上述的一些建議不適用你的情況，你需要檢查是否在稀疏字段確實需要 `norms` `和` `doc_values。如果在字段上不需要生成分數，則可以禁用 `norms`?，對于僅用于過濾的字段，這通常是正確的。對于既不用于排序也不用于聚合的字段，可以禁用doc_values。請注意，由于這些參數無法在實時索引中更改，因此您不要輕率做決定，因此如果您需要 ``norms`?`或 doc_values，則必須重建索引。`