ElasticSearch讀寫原理及性能調優

ES寫入/查詢原理

1. Elasticsearch寫入數據流程

1. 客戶端隨機選擇一個ES集群中的節點，發送POST/PUT請求，被選擇的節點為協調節點（coordinating node）
2. 協調節點查詢集群狀態信息並計算路由，將請求發送到真正處理請求的節點（primary shard所在的節點）
3. 包含primary shard的節點處理寫入請求，並將數據同步到包含replica shard的節點
4. coordinating node收到包含primary shard的節點的相應信息，將最終結果返回給Client端

2. Elasticsearch讀取數據流程

1. 客戶端隨機選擇一個ES集群中的節點，發送GET請求，被選擇的節點為協調節點（coordinating node）
2. 協調節點查詢集群狀態信息並使用round-robin隨機輪詢算法計算出去此次請求的節點，將請求發送到真正處理請求的節點（主分片節點和副本節點隨機分配）
3. 處理讀請求的節點將數據返回給協調節點
4. 協調節點會把文檔信息返回給Client

3. Elasticsearch檢索數據流程

1. 客戶端發送請求到一個協調節點
2. 協調節點將搜索請求轉發到所有的shard對應的primary shard或replica shard也可以
3. 每個shard將自己的搜索結果（其實就是一些doc id），返回給協調節點，由協調節點進行數據的合並、排序、分頁等操作，產出最終結果
4. 接着由協調節點，根據doc id去各個節點上拉取實際的document數據，最終返回給客戶端

這里需要注意，分頁查詢，當from特別大時會造成大量無用數據返回到協調節點，謹慎使用。

4. 數據索引底層原理

1. 先寫入buffer，在buffer里的時候數據是搜索不到的；同時將數據寫入translog日志文件。
2. 如果buffer到達閾值，或者到一定時間，ES會將buffer中的數據refresh到一個新的segment file中，但是此時數據不是直接進入segment file的磁盤文件的，而是先進入os cache的。這個過程就是refresh。

　　每隔1秒鍾，es就會將buffer中的數據寫入到一個新的segment file，因此每秒鍾產生一個新的磁盤文件（segment file），這個segment file中就存儲最近1秒內buffer中寫入的數據。如果buffer里面此時沒有數據，就不會執行refresh操作；如果buffer里面有數據，默認1秒鍾執行一次refresh操作，刷入一個新的segment file中。

操作系統里面存在操作系統緩存（os cache），數據寫入磁盤文件之前會先進入os cache，先進入操作系統級別的一個內存緩存中。只要buffer中的數據被refresh到os cache中，數據就可以被檢索到了。

可以通過es的restful api或者java api，手動執行一次refresh操作，就是手動將buffer中的數據刷入os cache中，讓數據立馬就可以被搜索到。只要數據被輸入os cache中，buffer就會被清空了，因為不需要保留buffer了，數據在translog里面已經持久化到磁盤去一份了

性能調優

1.系統層面

        系統層面的調優主要是內存的設定與避免交換內存。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的性能。

2.分片及副本層面

　　ES 是一個分布式的搜索引擎, 索引通常都會分解成不同部分, 分布在不同節點的部分數據就是分片。ES 自動管理和組織分片, 並在必要的時候對分片數據進行再平衡分配, 所以用戶基本上不用擔心分片的處理細節。創建索引時默認的分片數為 5 個，並且一旦創建不能更改。

ES 默認創建一份副本，就是說在 5 個主分片的基礎上，每個主分片都相應的有一個副本分片。額外的副本有利有弊，有副本可以有更強的故障恢復能力，但也占了相應副本倍數的磁盤空間。

對於副本數，比較好確定，可以根據我們集群節點的多少與我們的存儲空間決定，我們的集群服務器多，並且有足夠大多存儲空間，可以多設置副本數，一般是 1-3 個副本數，如果集群服務器相對較少並且存儲空間沒有那么寬松，則可以只設定一份副本以保證容災（副本數可以動態調整）。

對於分片數，是比較難確定的。因為一個索引分片數一旦確定，就不能更改，所以我們在創建索引前，要充分的考慮到，以后我們創建的索引所存儲的數據量，否則創建了不合適的分片數，會對我們的性能造成很大的影響。

查詢大量小分片使得每個分片處理數據速度更快了，那是不是分片數越多，我們的查詢就越快，ES 性能就越好呢？其實也不是，因為在查詢過程中，有一個分片合並的過程，如果分片數不斷的增加，合並的時間則會增加，而且隨着更多的任務需要按順序排隊和處理，更多的小分片不一定要比查詢較小數量的更大的分片更快。如果有多個並發查詢，則有很多小碎片也會降低查詢吞吐量。

如果現在你的場景是分片數不合適了，但是又不知道如何調整，那么有一個好的解決方法就是按照時間創建索引，然后進行通配查詢。如果每天的數據量很大，則可以按天創建索引，如果是一個月積累起來導致數據量很大，則可以一個月創建一個索引。如果要對現有索引進行重新分片，則需要重建索引，對於每個index的shard數量，可以根據數據總量、寫入壓力、節點數量等綜合考量后設定，然后根據數據增長狀態定期檢測下shard數量是否合理。

騰訊雲CES技術團隊的推薦方案是：對於數據量較小（100GB以下）的index，往往寫入壓力查詢壓力相對較低，一般設置35個shard，number_of_replicas設置為1即可（也就是一主一從，共兩副本）。對於數據量較大（100GB以上）的index：一般把單個shard的數據量控制在（20GB50GB）讓index壓力分攤至多個節點：可通過
index.routing.allocation.total_shards_per_node參數，強制限定一個節點上該index的shard數量，讓shard盡量分配到不同節點上綜合考慮整個index的shard數量，如果shard數量（不包括副本）超過50個，就很可能引發拒絕率上升的問題，此時可考慮把該index拆分為多個獨立的index，分攤數據量，同時配合routing使用，降低每個查詢需要訪問的shard數量。

3.ES方面調優

　　確定集群CPU占用率高的原因，使用GET _nodes/{node}/hot_threads，如果結果為elasticsearch[{node}][search][T#10]則為查詢導致，如果結果為elasticsearch[{node}][bulk][T#1]，則為寫入導致

1. index.merge.scheduler.max_thread_count: 在實際調優中，cpu使用率很高，使用SSD替代機械硬盤。SSD與機械磁盤相比，具有高效的讀寫速度和穩定性。如果不是SSD，建議設置index.merge.scheduler.max_thread_count: 1，即索引merge最大線程數設置為1 個，該參數可以有效調節寫入的性能。因為在存儲介質上並發寫，由於尋址的原因，寫入性能不會提升，只會降低。當有多個磁盤時可以設置為對應的數量。
2. index.refresh_interval: 這個參數的意思是數據寫入后幾秒可以被搜索到，默認是 1s。每次索引的 refresh 會產生一個新的 lucene 段, 這會導致頻繁的合並行為，如果業務需求對實時性要求沒那么高，可以將此參數調大。
3. indices.memory.index_buffer_size: 如果我們要進行非常重的高並發寫入操作，那么最好將它調大一些，index buffer的大小是所有的shard公用的，對於每個 shard來說，最多給512MB，因為再大性能就沒什么提升了。ES會將這個設置作為每個shard共享的index buffer，那些特別活躍的shard會更多的使用這個 buffer。默認這個參數的值是10%，也就是jvm堆內存的10%。
4. translog: ES為了保證數據不丟失，每次index、bulk、delete、update完成的時候，一定會觸發刷新translog到磁盤上。在提高數據安全性的同時當然也降低了性能。如果你不在意這點可能性，還是希望性能優先，可以設置如下參數：

"index.translog": {
  "sync_interval": "120s",     #sync間隔調高
  "durability": "async",      # 異步更新
  "flush_threshold_size":"1g" #log文件大小
}

 

這樣設定的意思是開啟異步寫入磁盤，並設定寫入的時間間隔與大小，有助於寫入性能的提升。

1. 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
2. merge相關參數

"index.merge.policy.floor_segment": "100mb"
"index.merge.scheduler.max_thread_count": "1"
"index.merge.policy.min_merge_size": "10mb"

1. 超時參數

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

 

4.Linux層面相關調優

1. Linux中，每個進程默認打開的最大文件句柄數是1000，對於服務器進程來說，顯然太小，通過修改/etc/security/limits.conf來增大打開最大句柄數* - nofile 65535
2. vm.dirty_background_ratio: 這個參數指定了當文件系統緩存臟頁數量達到系統內存百分之多少時（如5%）就會觸發pdflush/flush/kdmflush等后台回寫進程運行，將一定緩存的臟頁異步地刷入外存；
3. vm.dirty_ratio: 該參數則指定了當文件系統緩存臟頁數量達到系統內存百分之多少時（如10%），系統不得不開始處理緩存臟頁（因為此時臟頁數量已經比較多，為了避免數據丟失需要將一定臟頁刷入外存）；在此過程中很多應用進程可能會因為系統轉而處理文件IO而阻塞。

把該參數適當調小。如果cached的臟數據所占比例（這里是占MemTotal的比例）超過這個設置，系統會停止所有的應用層的IO寫操作，等待刷完數據后恢復IO。所以萬一觸發了系統的這個操作，對於用戶來說影響非常大的。

sysctl -w vm.dirty_ratio=10
sysctl -w vm.dirty_background_ratio=5

可以修改/etc/sysctl.conf文件進行持久化。

ES使用建議

1.讀數據

避免大結果集合深翻，ES 提供了 Scroll 和 Scroll-Scan 這兩種查詢模式。

Scroll：是為檢索大量的結果而設計的。例如，我們需要查詢 1～100 頁的數據，每頁 100 條數據。

如果使用Search查詢：每次都需要在每個分片上查詢得分最高的 from+100 條數據，然后協同節點把收集到的 n×(from+100)條數據聚合起來再進行一次排序。

每次返回from+1開始的100條數據，並且要重復執行100次。

如果使用Scroll查詢：在各個分片上查詢10000條數據，協同節點聚合n×10000條數據進行合並、排序，並將排名前10000的結果快照起來。這樣做的好處是減少了查詢和排序的次數。

2.插入索引自動生成 id

當寫入端使用特定的 id 將數據寫入 ES 時，ES 會檢查對應的索引下是否存在相同的 id，這個操作會隨着文檔數量的增加使消耗越來越大，所以如果業務上沒有硬性需求建議使用 ES 自動生成的 id，加快寫入速率。

3.避免稀疏索引

索引稀疏之后，會導致索引文件增大。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的性能