背景：es 深度分頁索引效率問題
1.常見深度分頁方式 from+size
es 預設採用的分頁方式是 from+ size 的形式，在深度分頁的情況下，這種使用方式效率是非常低的，比如
from = 5000, size=10000， es 需要在各個分片上匹配排序並得到5000*10000條有效資料，然後在結果集中取最後10000條
資料返回.
除了效率上的問題，還有乙個無法解決的問題是，es 目前支援最大的 skip 值是 max_result_window ，預設
為 10000。也就是當 from + size > max_result_window 時，es 將返回錯誤.
當然，我們可以採用緊急規避方案，就是調整 max_result_window 的值。
curl -xput "127.0.0.1:9200/custm/_settings" -d ' }'
然後這種方式只能暫時解決問題，當es 的使用越來越多，資料量越來越大，深度分頁的場景越來越複雜時，如何解決這種問題呢？
2.scroll 分頁方式
為了滿足深度分頁的場景，es 提供了 scroll 的方式進行分頁讀取。原理上是對某次查詢生成乙個游標 scroll_id ， 後續的查詢只需要根據這個游標去取資料，直到結果集中返回的 hits 欄位為空，就表示遍歷結束。
scroll_id 的生成可以理解為建立了乙個臨時的歷史快照，在此之後的增刪改查等操作不會影響到這個快照的結果。
1.先獲取第乙個 scroll_id，url 引數包括 /index/_type/ 和 scroll，scroll 字段指定了scroll_id 的有效生存期，以分鐘為單位，過期之後會被es 自動清理。
curl -xget 127.0.0.1:9200/db/info/_search?pretty&scroll=2m -d '}, "sort": ["_doc"]}'
curl -xget '127.0.0.1:9200/_search/scroll?scroll=1m&scroll_id=cxdferdgd45wesdfd35dfefdfx2znoza
刪除掉所有索引上的 scroll_id curl -xdelete 127.0.0.1:9200/_search/scroll/_all
刪掉指定的多個 srcoll_id curl -xdelete 127.0.0.1:9200/_search/scroll -d ''
3.search_after 的方式
上述的 scroll search 的方式，官方的建議並不是用於實時的請求，因為每乙個 scroll_id 不僅會占用大量的資源（特別是排序的請求），而且是生成的歷史快照，對於資料的變更不會反映到快照上。這種方式往往用於非實時處理大量資料的情況，比如要進行資料遷移或者索引變更之類的。那麼在實時情況下如果處理深度分頁的問題呢？es 給出了 search_after 的方式，這是在 >= 5.0 版本才提供的功能。
為了找到每一頁最後一條資料，每個文件必須有乙個全域性唯一值，這種分頁方式其實和目前 moa 記憶體中使用rbtree 分頁的原理一樣，官方推薦使用 _uid 作為全域性唯一值，其實使用業務層的 id 也可以。
第一頁的請求和正常的請求一樣
curl -xget 127.0.0.1:9200/db/info/_search
curl -xget 127.0.0.1:9200/order/info/_search
},"search_after": [1463533345, "2039488283-alt"],
"sort": [,]
}備註：參考： 這篇文章提到，使用search_after 方式時，必須要設定from=0。
search_after 深分頁
scroll 的方式，官方的建議不用於實時的請求（一般用於資料匯出），因為每乙個 scroll_id 不僅會占用大量的資源，而且會生成歷史快照，對於資料的變更不會反映到快照上。
為了找到每一頁最後一條資料，每個文件必須有乙個全域性唯一值，官方推薦使用 _uid 作為全域性唯一值，其實使用業務層的 id 也可以。
get test_dev/_search}]
}},
"size": 20,
"from": 0,
"sort": [
,"_id":
}]}
這裡我使用timestamp和_id作為唯一值排序。
我們在返回的最後一條資料裡拿到sort屬性的值傳入到search_after。
get test_dev/_search}]
}},
"size": 10,
"from": 0,
"search_after": [
1541495312521,
"d0xh6gybbtbwbqsp0j1a"
],"sort": [
,"_id":
}]}
elasticsearch配置詳解
elasticsearch的config資料夾裡面有兩個配置檔案 elasticsearch.yml和logging.yml，第乙個是es的基本配置檔案，第二個是日誌配置檔案，es也是使用log4j來記錄日誌的，所以logging.yml裡的設定按普通log4j配置檔案來設定就行了。下面主要講解下e...
誰在使用Elasticsearch
github github使用elasticsearch搜尋20tb的資料，包括13億的檔案和1300億行的 這個不用介紹了吧，碼農們都懂的，github在2013年1月公升級了他們的 搜尋，由solr轉為elasticsearch，目前集群規模為26個索引儲存節點和8個客戶端節點 負責處理搜尋請求...
elasticsearch配置說明
elasticsearch.yml是elasticsearch主要的配置檔案，所有的配置都在這個檔案裡完成，一般情況下，預設的配置已經可以比較好地執行乙個集群了，但你也可以對其進行微調。在環境變數中的引數可以用來作為配置引數的值，比如配置檔案裡舉的乙個例子為 node.rack 再比如 等。下面對其...