一，讀寫底層原理
Elasticsearch寫人數據的過程
1）客戶端選擇一個node發送請求過去，這個node就是coordinating node（協調節點）
2）coordinating node，對document進行路由，將請求轉發給對應的node（有primary shard）
3）實際的node上的primary shard處理請求，然后將數據同步到replica node
4）coordinating node，如果發現primary node和所有replica node都搞定之后，就返回響應結果給客戶端
Elasticsearch讀取數據的過程
1）客戶端發送請求到任意一個node，成為coordinate node
2）coordinate node對document進行路由，將請求轉發到對應的node，此時會使用round-robin隨機輪詢算法，在primary shard以及其所有replica中隨機選擇一個，讓讀請求負載均衡
3）接收請求的node返回document給coordinate node
4）coordinate node返回document給客戶端
1.寫入document時，每個document會自動分配一個全局唯一的id即doc id，同時也是根據doc id進行hash路由到對應的primary shard上。也可以手動指定doc id，比如用訂單id，用戶id。
2.讀取document時，你可以通過doc id來查詢，然后會根據doc id進行hash，判斷出來當時把doc id分配到了哪個shard上面去，從那個shard去查詢
Elasticsearch搜索數據過程
es最強大的是做全文檢索
1）客戶端發送請求到一個coordinate node
2）協調節點將搜索請求轉發到所有的shard對應的primary shard或replica shard也可以
3）query phase：每個shard將自己的搜索結果（其實就是一些doc id），返回給協調節點，由協調節點進行數據的合并、排序、分頁等操作，產出最終結果
4）fetch phase：接著由協調節點，根據doc id去各個節點上拉取實際的document數據，最終返回給客戶端
搜索的底層原理：倒排索引
Elasticsearch寫數據的底層原理
1）先寫入buffer，在buffer里的時候數據是搜索不到的；同時將數據寫入translog日志文件。
2）如果buffer快滿了，或者到一定時間，就會將buffer數據refresh到一個新的segment file中，但是此時數據不是直接進入segment file的磁盤文件的，而是先進入os cache的。這個過程就是refresh。
每隔1秒鐘，es將buffer中的數據寫入一個新的segment file，每秒鐘會產生一個新的磁盤文件，segment file，這個segment file中就存儲最近1秒內buffer中寫入的數據。
但是如果buffer里面此時沒有數據，那當然不會執行refresh操作咯，每秒創建換一個空的segment file，如果buffer里面有數據，默認1秒鐘執行一次refresh操作，刷入一個新的segment file中。
操作系統里面，磁盤文件其實都有一個東西，叫做os cache，操作系統緩存，就是說數據寫入磁盤文件之前，會先進入os cache，先進入操作系統級別的一個內存緩存中去。
只要buffer中的數據被refresh操作，刷入os cache中，就代表這個數據就可以被搜索到了。
為什么叫es是準實時的？NRT，near real-time，準實時。默認是每隔1秒refresh一次的，所以es是準實時的，因為寫入的數據1秒之后才能被看到。
可以通過es的restful api或者java api，手動執行一次refresh操作，就是手動將buffer中的數據刷入os cache中，讓數據立馬就可以被搜索到。
只要數據被輸入os cache中，buffer就會被清空了，因為不需要保留buffer了，數據在translog里面已經持久化到磁盤去一份了
二，性能調優
系統層面的調優
系統層面的調優主要是內存的設定與避免交換內存。
ES 安裝后默認設置的堆內存是 1GB，這很明顯是不夠的，那么接下來就會有一個問題出現：我們要設置多少內存給 ES 呢？
其實這是要看我們集群節點的內存大小，還取決于我們是否在服務器節點上還是否要部署其他服務。
如果內存相對很大，如 64G 及以上，并且不在 ES 集群上部署其他服務，那么建議 ES 內存可以設置為 31G-32G，因為這里有一個 32G 性能瓶頸問題，直白的說就是即使你給了 ES 集群大于 32G 的內存，其性能也不一定會更加優良，甚至會不如設置為 31G-32G 時候的性能。
設置 ES 集群內存的時候，還有一點就是確保堆內存最小值（Xms）與最大值（Xmx）的大小是相同的，防止程序在運行時改變堆內存大小，這是一個很耗系統資源的過程。
禁止swap，一旦允許內存與磁盤的交換，會引起致命的性能問題。
swap空間是一塊磁盤空間，操作系統使用這塊空間保存從內存中換出的操作系統不常用page數據，這樣可以分配出更多的內存做page cache。這樣通常會提升系統的吞吐量和IO性能，但同樣會產生很多問題。頁面頻繁換入換出會產生IO讀寫、操作系統中斷，這些都很影響系統的性能。這個值越大操作系統就會更加積極的使用swap空間。
通過： 在elasticsearch.yml 中 bootstrap.memory_lock: true， 以保持JVM鎖定內存，保證ES的性能。
分片與副本
分片 (shard)：ES 是一個分布式的搜索引擎, 索引通常都會分解成不同部分, 分布在不同節點的部分數據就是分片。ES 自動管理和組織分片, 并在必要的時候對分片數據進行再平衡分配, 所以用戶基本上不用擔心分片的處理細節。創建索引時默認的分片數為 5 個，并且一旦創建不能更改。
副本 (replica)：ES 默認創建一份副本，就是說在 5 個主分片的基礎上，每個主分片都相應的有一個副本分片。額外的副本有利有弊，有副本可以有更強的故障恢復能力，但也占了相應副本倍數的磁盤空間。
那我們在創建索引的時候，應該創建多少個分片與副本數呢？
對于副本數，比較好確定，可以根據我們集群節點的多少與我們的存儲空間決定，我們的集群服務器多，并且有足夠大多存儲空間，可以多設置副本數，一般是 1-3 個副本數，如果集群服務器相對較少并且存儲空間沒有那么寬松，則可以只設定一份副本以保證容災（副本數可以動態調整）。
對于分片數，是比較難確定的。因為一個索引分片數一旦確定，就不能更改，所以我們在創建索引前，要充分的考慮到，以后我們創建的索引所存儲的數據量，否則創建了不合適的分片數，會對我們的性能造成很大的影響。
對于分片數的大小，業界一致認為分片數的多少與內存掛鉤，認為 1GB 堆內存對應 20-25 個分片，而一個分片的大小不要超過 50G，這樣的配置有助于集群的健康。但是我個人認為這樣的配置方法過于死板，我個人在調優 ES 集群的過程中，根據總數據量的大小，設定了相應的分片，保證每一個分片的大小沒有超過 50G（大概在 40G 左右），但是相比之前的分片數查詢起來，效果并不明顯。之后又嘗試了增加分片數，發現分片數增多之后，查詢速度有了明顯的提升，每一個分片的數據量控制在 10G 左右。
查詢大量小分片使得每個分片處理數據速度更快了，那是不是分片數越多，我們的查詢就越快，ES 性能就越好呢？其實也不是，因為在查詢過程中，有一個分片合并的過程，如果分片數不斷的增加，合并的時間則會增加，而且隨著更多的任務需要按順序排隊和處理，更多的小分片不一定要比查詢較小數量的更大的分片更快。如果有多個并發查詢，則有很多小碎片也會降低查詢吞吐量。
如果現在你的場景是分片數不合適了，但是又不知道如何調整，那么有一個好的解決方法就是按照時間創建索引，然后進行通配查詢。如果每天的數據量很大，則可以按天創建索引，如果是一個月積累起來導致數據量很大，則可以一個月創建一個索引。如果要對現有索引進行重新分片，則需要重建索引，
對于每個index的shard數量，可以根據數據總量、寫入壓力、節點數量等綜合考量后設定，然后根據數據增長狀態定期檢測下shard數量是否合理。
騰訊云CES技術團隊的推薦方案是：
對于數據量較小（100GB以下）的index，往往寫入壓力查詢壓力相對較低，一般設置3~5個shard，number_of_replicas設置為1即可（也就是一主一從，共兩副本） 。
對于數據量較大（100GB以上）的index：
一般把單個shard的數據量控制在（20GB~50GB）
讓index壓力分攤至多個節點：可通過index.routing.allocation.total_shards_per_node參數，強制限定一個節點上該index的shard數量，讓shard盡量分配到不同節點上
綜合考慮整個index的shard數量，如果shard數量（不包括副本）超過50個，就很可能引發拒絕率上升的問題，此時可考慮把該index拆分為多個獨立的index，分攤數據量，同時配合routing使用，降低每個查詢需要訪問的shard數量。
下面我會介紹一些 ES 關鍵參數的調優。
有很多場景是，我們的 ES 集群占用了多大的 cpu 使用率，該如何調節呢。cpu 使用率高，有可能是寫入導致的，也有可能是查詢導致的，那要怎么查看呢？
可以先通過 GET _nodes/{node}/hot_threads 查看線程棧，查看是哪個線程占用 cpu 高，如果是 elasticsearch[{node}][search][T#10] 則是查詢導致的，如果是 elasticsearch[{node}][bulk][T#1] 則是數據寫入導致的。
在實際調優中，cpu 使用率很高，使用固態硬盤（Solid State Disk）替代機械硬盤。SSD 與機械磁盤相比，具有高效的讀寫速度和穩定性。如果不是 SSD，建議把 index.merge.scheduler.max_thread_count: 1 索引 merge 最大線程數設置為 1 個，該參數可以有效調節寫入的性能。因為在存儲介質上并發寫，由于尋址的原因，寫入性能不會提升，只會降低。
還有幾個重要參數可以進行設置，各位同學可以視自己的集群情況與數據情況而定。
index.refresh_interval：這個參數的意思是數據寫入后幾秒可以被搜索到，默認是 1s。每次索引的 refresh 會產生一個新的 lucene 段, 這會導致頻繁的合并行為，如果業務需求對實時性要求沒那么高，可以將此參數調大，實際調優告訴我，該參數確實很給力，cpu 使用率直線下降。
indices.memory.index_buffer_size：如果我們要進行非常重的高并發寫入操作，那么最好將 indices.memory.index_buffer_size 調大一些，index buffer 的大小是所有的 shard 公用的，對于每個 shard 來說，最多給 512mb，因為再大性能就沒什么提升了。ES 會將這個設置作為每個 shard 共享的 index buffer，那些特別活躍的 shard 會更多的使用這個 buffer。默認這個參數的值是 10%，也就是 jvm heap 的 10%。
translog：ES 為了保證數據不丟失，每次 index、bulk、delete、update 完成的時候，一定會觸發刷新 translog 到磁盤上。在提高數據安全性的同時當然也降低了一點性能。如果你不在意這點可能性，還是希望性能優先，可以設置如下參數：
"index.translog": {
"sync_interval": "120s", #sync間隔調高
"durability": "async", # 異步更新
"flush_threshold_size":"1g" #log文件大小
}
這樣設定的意思是開啟異步寫入磁盤，并設定寫入的時間間隔與大小，有助于寫入性能的提升。
replica數目
為了讓創建的es index在每臺datanode上均勻分布，同一個datanode上同一個index的shard數目不應超過3個。
計算公式: (number_of_shard * (1+number_of_replicas)) < 3*number_of_datanodes
每臺機器上分配的shard數目
"index.routing.allocation.total_shards_per_node": "2
磁盤緩存相關參數
vm.dirty_background_ratio 這個參數指定了當文件系統緩存臟頁數量達到系統內存百分之多少時（如5%）就會觸發pdflush/flush/kdmflush等后臺回寫進程運行，將一定緩存的臟頁異步地刷入外存；
vm.dirty_ratio
該參數則指定了當文件系統緩存臟頁數量達到系統內存百分之多少時（如10%），系統不得不開始處理緩存臟頁（因為此時臟頁數量已經比較多，為了避免數據丟失需要將一定臟頁刷入外存）；在此過程中很多應用進程可能會因為系統轉而處理文件IO而阻塞。
把該參數適當調小，原理通（1）類似。如果cached的臟數據所占比例（這里是占MemTotal的比例）超過這個設置，系統會停止所有的應用層的IO寫操作，等待刷完數據后恢復IO。所以萬一觸發了系統的這個操作，對于用戶來說影響非常大的。
sysctl -w vm.dirty_ratio=10
sysctl -w vm.dirty_background_ratio=5
為了將設置永久保存，將上述配置項寫入/etc/sysctl.conf文件中
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
merge相關參數
"index.merge.policy.floor_segment": "100mb",
"index.merge.scheduler.max_thread_count": "1",
"index.merge.policy.min_merge_size": "10mb"
還有一些超時參數的設置：
discovery.zen.ping_timeout 判斷 master 選舉過程中，發現其他 node 存活的超時設置
discovery.zen.fd.ping_interval 節點被 ping 的頻率，檢測節點是否存活
discovery.zen.fd.ping_timeout 節點存活響應的時間，默認為 30s，如果網絡可能存在隱患，可以適當調大
discovery.zen.fd.ping_retries ping 失敗/超時多少導致節點被視為失敗，默認為 3
Linux系統參數配置
文件句柄
Linux中，每個進程默認打開的最大文件句柄數是1000,對于服務器進程來說，顯然太小，通過修改/etc/security/limits.conf來增大打開最大句柄數
* - nofile 65535
讀優化
①避免大結果集和深翻
在上一篇講到了集群中的查詢流程，例如，要查詢從 from 開始的 size 條數據，則需要在每個分片中查詢打分排名在前面的 from+size 條數據。
協同節點將收集到的n×(from+size)條數據聚合，再進行一次排序，然后從 from+size 開始返回 size 條數據。
當 from、size 或者 n 中有一個值很大的時候，需要參加排序的數量也會增長，這樣的查詢會消耗很多 CPU 資源，從而導致效率的降低。
為了提升查詢效率，ES 提供了 Scroll 和 Scroll-Scan 這兩種查詢模式。
Scroll：是為檢索大量的結果而設計的。例如，我們需要查詢 1～100 頁的數據，每頁 100 條數據。
如果使用 Search 查詢：每次都需要在每個分片上查詢得分最高的 from+100 條數據，然后協同節點把收集到的 n×(from+100)條數據聚合起來再進行一次排序。
每次返回 from+1 開始的 100 條數據，并且要重復執行 100 次。
如果使用 Scroll 查詢：在各個分片上查詢 10000 條數據，協同節點聚合 n×10000 條數據進行合并、排序，并將排名前 10000 的結果快照起來。這樣做的好處是減少了查詢和排序的次數。
其他建議
插入索引自動生成 id：當寫入端使用特定的 id 將數據寫入 ES 時，ES 會檢查對應的索引下是否存在相同的 id，這個操作會隨著文檔數量的增加使消耗越來越大，所以如果業務上沒有硬性需求建議使用 ES 自動生成的 id，加快寫入速率。
避免稀疏索引：索引稀疏之后，會導致索引文件增大。ES 的 keyword，數組類型采用 doc_values 結構，即使字段是空值，每個文檔也會占用一定的空間，所以稀疏索引會造成磁盤增大，導致查詢和寫入效率降低。
參數調優
index.merge.scheduler.max_thread_count:1 # 索引 merge 最大線程數
indices.memory.index_buffer_size:30% # 內存
index.translog.durability:async # 這個可以異步寫硬盤，增大寫的速度
index.translog.sync_interval:120s #translog 間隔時間
discovery.zen.ping_timeout:120s # 心跳超時時間
discovery.zen.fd.ping_interval:120s # 節點檢測時間
discovery.zen.fd.ping_timeout:120s #ping 超時時間
discovery.zen.fd.ping_retries:6 # 心跳重試次數
thread_pool.bulk.size:20 # 寫入線程個數 由于我們查詢線程都是在代碼里設定好的，我這里只調節了寫入的線程數
thread_pool.bulk.queue_size:1000 # 寫入線程隊列大小
index.refresh_interval:300s #index 刷新間隔
bootstrap.memory_lock: true#以保持JVM鎖定內存，保證ES的性能。
關于重建索引
在重建索引之前，首先要考慮一下重建索引的必要性，因為重建索引是非常耗時的。
ES 的 reindex api 不會去嘗試設置目標索引，不會復制源索引的設置，所以我們應該在運行_reindex 操作之前設置目標索引，包括設置映射（mapping），分片，副本等。
第一步，和創建普通索引一樣創建新索引。當數據量很大的時候，需要設置刷新時間間隔，把 refresh_intervals 設置為-1，即不刷新,number_of_replicas 副本數設置為 0（因為副本數可以動態調整，這樣有助于提升速度）。
{
"settings": {
"number_of_shards": "50",
"number_of_replicas": "0",
"index": { "refresh_interval": "-1" }
}
"mappings":
{
}
}
第二步，調用 reindex 接口，建議加上 wait_for_completion=false 的參數條件，這樣 reindex 將直接返回 taskId。
POST _reindex?wait_for_completion=false { "source": { "index": "old_index", //原有索引
"size": 5000 //一個批次處理的數據量
}, "dest": { "index": "new_index", //目標索引
}
}
第三步，等待。可以通過 GET _tasks?detailed=true&actions=*reindex 來查詢重建的進度。如果要取消 task 則調用_tasks/node_id:task_id/_cancel。
第四步，刪除舊索引，釋放磁盤空間。重建索引的時候，在參數里加上上一次重建索引的時間戳，直白的說就是，比如我們的數據是 100G，這時候我們重建索引了，但是這個 100G 在增加，那么我們重建索引的時候，需要記錄好重建索引的時間戳，記錄時間戳的目的是下一次重建索引跑任務的時候不用全部重建，只需要在此時間戳之后的重建就可以，如此迭代，直到新老索引數據量基本一致，把數據流向切換到新索引的名字。
POST /_reindex
{
"conflicts": "proceed", //意思是沖突以舊索引為準，直接跳過沖突，否則會拋出異常，停止task
"source": { "index": "old_index" //舊索引
"query": { "constant_score" :
{ "filter" : {
"range" : { "data_update_time" :
{ "gte" : 123456789 //reindex開始時刻前的毫秒時間戳
}
}
}
}
}
},
"dest": { "index": "new_index", //新索引
"version_type": "external" //以舊索引的數據為準
}
}
