elasticsearch效能優化

elasticsearch查詢依賴作業系統的頁面快取記憶體（file system cache），因此除了需要給elasticsearch的jvm分配足夠的記憶體以外，還需要給頁快取預留記憶體。

例如單機32g記憶體，給jvm配置16g記憶體後，剩餘16g預留記憶體不需要額外配置，也不要讓其他程序占用這些記憶體。預留的16g記憶體會在elasticsearch讀取硬碟時自動分配給頁快取，如下圖中的buff/cache欄。

如果資金足夠，不要讓單節點的資料量超過分配給頁快取的記憶體大小。如果頁快取的預留記憶體超過當前節點的資料量，那麼該節點的查詢操作均在記憶體中執行，極大提高了elasticsearch的響應速度。

對於資料量較大的場景下，熱資料儲存於ssd而普通歷史資料儲存機械磁碟。甚至對於日誌這類資料，在elasticsearch中只儲存需要頻繁使用的熱資料，極少使用的冷資料可以從elasticsearch中移除而以其他的形式儲存，減少elasticsearch的查詢聚合壓力。

例如使用elasticsearch儲存日誌，可以以日期名稱作為index名，每天以乙個新的index儲存當天的日誌資料。對於超過3個月或者半年的日誌，直接刪除index，而把這些冷資料儲存到檔案中封存。

elasticsearch每個index預設建立5個shard資料分片，當建立乙個新文件時，該文件儲存到的分片通過以下公式計算：

shard = hash(routing) % number_of_primary_shards

routing是乙個可變值，預設是文件的_id。因此文件會均勻分布到建立的shard分片上。

當使用者對文件進行非id的查詢時，由於文件可能存放在任意乙個shard分片上，所以需要對每乙個shard分片進行乙個查詢後，再對所有shard分片返回的查詢結果進行聚合。該過程將浪費大量的網路資源、cpu資源和io資源。

使用者可以通過指定routing將相同routing的文件存放到同乙個shard分片上，那麼當通過routing查詢文件時，通過routing可以直接定位到乙個shard分片，而不需要對每乙個shard分片請求，節約了大量的資源。

routing需要針對業務場景而確定，例如在租戶模式下，絕大多數操作都是對租戶下的資料進行增刪改查，很少有跨租戶的操作。該業務場景就可以用租戶id作為routing。