es是乙個搜尋引擎，所以如果用這個搜尋引擎對大量的資料進行搜尋，並且返回搜尋結果中排在最前面的少數結果，是非常合適的。然而，如果要做成類似資料庫的東西，每次都進行大批量的查詢，是很不合適的。如果真的要做大批量結果的查詢，記得考慮用scroll api。
http.max_context_length的預設值是100mb，意味著你一次document寫入時，document的內容不能超過100mb，否則es就會拒絕寫入。也許你可以將這個引數設定的更大，從而讓你的超大的documdent可以寫入es，但是es底層的lucene引擎還是有乙個2gb的最大限制。
即使我們不考慮引擎層的限制，超大的document在實際生產環境中是很不好的。超大document會耗費更多的網路資源，記憶體資源和磁碟資源，甚至對那些不要求獲取_source的請求，也是一樣，因為es需要從_source中提取_id欄位，對於超大document這個獲取_id欄位的過程的資源開銷也是很大的。而將這種超大document寫入es也會使用大量的記憶體，占用記憶體空間的大小甚至會是documdent本身大小的數倍。近似匹配的搜尋，比如phrase query，以及高亮顯示，對超大document的資源開銷會更大，因為這些操作的效能開銷直接跟document的大小成正比。
因此對於超大document，我們需要考慮一下，我們到底需要其中的哪些部分。舉例來說，如果我們要對一些書進行搜尋，那麼我們並不需要將整本書的內容就放入es中吧。我們可以僅僅使用每一篇章或者乙個段落作為乙個document，然後給乙個field標識出來這些document屬於哪本書，這樣每個document的大小不就變小了麼。這就可以避免超大document導致的各種開銷，同時可以優化搜尋的體驗。比如說，如果乙個使用者要搜尋兩個單詞，foo和bar，如果在兩個不同的段落中分別匹配了乙個單詞，肯定匹配效果要比，乙個段落中匹配了兩個單詞，要差。
lucene的核心結構，跟稠密的資料配合起來，效能會更好，舉個例子，什麼叫稀疏的資料，什麼叫稠密的資料？比如有100個document，每個document都有20個field，20個field都有值，這就是稠密的資料。但是如果100個document，每個document的field都不一樣，有的document有2個field，有的document有50個field，這就是稀疏的資料。
原因就是，lucene在內部會通過doc id來唯一標識乙個document，這個doc id是integer型別，範圍在0到索引中含有的document數量之間。這些doc id是用來在lucene內部的api之間進行通訊的，比如說，對乙個term用乙個match query來進行搜尋，就會產生乙個doc id集合，然後這些doc id會用來獲取對應的norm值，以用來計算每個doc的相關度分數。而根據doc id查詢norm的過程，是通過每個document的每個field保留乙個位元組來進行的乙個演算法，這個過程叫做norm查詢，norm就是每個document的每個field保留的乙個位元組。對於每個doc id對應的那個norm值，可以通過讀取es乙個內建索引，叫做doc_id的索引，中的乙個位元組來獲取。這個過程是效能很高的，而且可以幫助lucene快速的定位到每個document的norm值，但是同時這樣的話document本身就不需要儲存這乙個位元組的norm值了。
在實際執行過程中，這就意味著，如果乙個索引有100個document，對於每個field，就需要100個位元組來儲存norm值，即使100個document中只有10個document含有某個field，但是對那個field來說，還是要100個位元組來儲存norm值。這就會對儲存產生更大的開銷，儲存空間被浪費的乙個問題，而且也會影響讀寫效能。
下面有一些避免稀疏資料的辦法：
（1）避免將沒有任何關聯性的資料寫入同乙個索引
我們必須避免將結構完全不一樣的資料寫入同乙個索引中，因為結構完全不一樣的資料，field是完全不一樣的，會導致index資料非常稀疏。最好將這種資料寫入不同的索引中，如果這種索引資料量比較少，那麼可以考慮給其很少的primary shard，比如1個，避免資源浪費。
（2）對document的結構進行規範化/標準化
即使我們真的要將不同型別的document寫入相同的索引中，還是有辦法可以避免稀疏性，那就是對不同型別的document進行標準化。比如說，如果所有的document都有乙個時間戳field，不過有的叫做timestamp，有的叫做creation_date，那麼可以將不同document的這個field重新命名為相同的字段，盡量讓documment的結構相同。另外乙個，就是比如有的document有乙個字段，叫做goods_type，但是有的document沒有這個字段，此時可以對沒有這個欄位的document，補充乙個goods_type給乙個預設值，比如default。
（3）避免使用多個types儲存不一樣結構的document
很多人會很喜歡在乙個index中放很多個types來儲存不同型別的資料。但是其實不是這樣的，最好不要這麼幹，如果你在乙個index中有多個type，但是這些type的資料結構不太一樣，那麼這些type實際上底層都是寫到這個索引中的，還是會導致稀疏性。如果多個type的結構不太一樣，最好放入不同的索引中，不要寫入乙個索引中。
（4）對稀疏的field禁用norms和doc_values
如果上面的步驟都沒法做，那麼只能對那種稀疏的field，禁止norms和doc_values欄位，因為這兩個欄位的儲存機制類似，都是每個field有乙個全量的儲存，對儲存浪費很大。如果乙個field不需要考慮其相關度分數，那麼可以禁用norms，如果不需要對乙個field進行排序或者聚合，那麼可以禁用doc_values欄位。
ElasticSearch 效能優化
getrace系統的所有搜尋都是用elasticsearch來做的，在使用elasticsearch的過程中碰到了一些問題，這裡記錄一下。一 在查詢呼叫鏈的時候。整體資料量大 每天60g 7 420g 但是結果集比較少 只有幾百行 的時候，查詢時間經常會超過1分鐘，慢的甚至需要5，6分鐘.優化1 經...
elasticsearch效能優化
elasticsearch查詢依賴作業系統的頁面快取記憶體 file system cache 因此除了需要給elasticsearch的jvm分配足夠的記憶體以外，還需要給頁快取預留記憶體。例如單機32g記憶體，給jvm配置16g記憶體後，剩餘16g預留記憶體不需要額外配置，也不要讓其他程序占用這...
ElasticSearch效能優化策略
一 伺服器部署演算法的基本思想 1 增加1 2臺伺服器，用於負載均衡節點 elasticsearch的配置檔案中有2個引數 node.master和node.data。這兩個參 數搭配使用時，能夠幫助提供伺服器效能。1.1 node.master false node.data true 該node...