ElasticSearch偶爾查詢不到資料

現象：每次insert之後，立刻查詢es的資料是有可能查不到的，因為es從記憶體寫到磁碟需要時間

原因：es預設每1s執行一次refresh，因此文件實時性被提高到1s，這也是es被稱為近實時的原因

解決方法：寫的時候指定資料重新整理策略，request().setRefreshPolicy(RefreshPolicy.IMMEDIATE);

　　列舉org.elasticsearch.action.support.WriteRequest.RefreshPolicy定義了三種策略：

/**
 * Don't refresh after this request. The default.
 
 
*/
NONE,
/**
 * Force a refresh as part of this request. This refresh policy does not scale for high indexing or search throughput but is useful
 * to present a consistent view to for indices with very low traffic. And it is wonderful for tests!
 */
IMMEDIATE,
/**
 * Leave this request open until a refresh has made the contents of this request visible to search. This refresh policy is
 * compatible with high indexing and search throughput but it causes the request to wait to reply until a refresh occurs.
 
 
*/
WAIT_UNTIL; 

每次查詢最大10000條

通過資料的查閱,發現預設值是10000,如果要查詢大於10000條,我們就需要修改es的max_result_window預設值

解決方法：我們在建立索引的時候 設定："index.max_result_window": "10000", 這個值預設一萬，我們可以改成自己想要的值

也可以使用ES的Scroll滾動查詢

ES效能優化

1. 因為ES不能改變分片數量，所以建立索引的時候要指定好分片數量

ES 預設為一個索引建立 5 個主分片, 並分別為每個分片建立一個副本分片。

解決辦法：合理的分片數量可以提高寫入效能和穩定性。

　　分片數可以理解為MySQL中的分庫分表

　　ES查詢主要分為兩類：單ID查詢以及分頁查詢。

　　分片數越大，叢集橫向擴容規模也更大，根據分片路由的單ID查詢吞吐量也能大大提升，但聚合的分頁查詢效能則將降低；

　　分片數越小，叢集橫向擴容規模也更小，單ID的查詢效能也會下降，但分頁查詢的效能將會提升。

2、避免深分頁查詢ES叢集的分頁查詢支援from和size引數，

　　查詢的時候，每個分片必須構造一個長度為from+size的優先佇列，

　　然後回傳到閘道器節點，閘道器節點再對這些優先佇列進行排序找到正確的size個文件。

　　假設在一個有6個主分片的索引中，from為10000，size為10，每個分片必須產生10010個結果，

　　在閘道器節點中匯聚合併60060個結果，最終找到符合要求的10個文件。

　　由此可見，當from足夠大的時候，就算不發生OOM，也會影響到CPU和頻寬等，從而影響到整個叢集的效能。

　　所以應該避免深分頁查詢，儘量不去使用。

解決辦法：也可以使用ES的Scroll滾動查詢