題記

由于之前已經梳理過Elasticsearch基礎概念且在項目中實戰過Elasticsearch的增刪改查、聚類、排序等相關操作，對ES算是有了一定的認知。

但是，仍然對于一些底層的原理認知模糊，特買來《深入理解Elasticsearch》過了一遍，將書中一些細節知識點結合官網文檔梳理如下。

1——4章偏應用，跟著敲一遍代碼基本就能理解原理。?
5——9章偏理論一些。?

第5章 分布式索引架構

1、如何選擇合適的分片和副本數？

目的：規劃索引及配置，適應應用的變化。

正確認知：分片數索引創建后不可以修改，副本數索引創建后可以通過API隨時修改。

多副本的缺點：額外副本占據了額外的存儲空間，構建索引副本的開銷也隨之增大。

同時要注意：如果不創建副本，當主分片發生問題時，可能會造成數據的丟失。

配置參考：最理想的分片數量應該依賴于節點的數量。

參考公式：所需的最大節點數 = 分片數 *（副本數+1）?
舉例：你計劃5個分片和1個副本，那么所需要的最大的節點數為：5*（1+1）=10個節點。

2、可不可以基于時間構建索引？

目的：選擇感興趣的索引上進行查詢，歷史索引（時間比較久）的定期刪除。?
正確操作方法：通過名稱為logs_2017_01, logs_2017_02,…..logs_2017_12來構建索引。

第6章 底層索引控制

1、什么是段？

Elasticsearch中的每個分片包含多個segment（段），每一個segment都是一個倒排索引；在查詢的時，會把所有的segment查詢結果匯總歸并為最終的分片查詢結果返回。

在創建索引的時候，ES會把文檔信息寫到內存bugffer中（為了安全，也一起寫到translog），定時（可配置）把數據寫到segment緩存小文件中，然后刷新查詢，使剛寫入的segment可查。

雖然寫入的segment可查詢，但是還沒有持久化到磁盤上。因此，還是會存在丟失的可能性的。所以，ES會執行flush操作，把segment持久化到磁盤上并清除translog的數據（因為這個時候，數據已經寫到磁盤上，不再需要了）。?
參考：http://t.cn/RjKOMv1

2、什么是段合并？

由于自動刷新流程每秒會創建一個新的段，這樣會導致短時間內的段數量暴增。而段數目太多會帶來較大的麻煩。

1）消耗資源：每一個段都會消耗文件句柄、內存和cpu運行周期；?
2）搜索變慢：每個搜索請求都必須輪流檢查每個段；所以段越多，搜索也就越慢。

ES通過在后臺進行段合并來解決這個問題。小的段被合并到大的段，然后這些大的段再被合并到更大的段。

3、段合并做了什么？

段合并的時候會將那些舊的已刪除文檔從文件系統中清除。?
被刪除的文檔（或被更新文檔的舊版本）不會被拷貝到新的大段中。

啟動段合并不需要你做任何事。進行索引和搜索時會自動進行。?
1）當索引的時候，刷新（refresh）操作會創建新的段并將段打開以供搜索使用。?
2） 合并進程選擇一小部分大小相似的段，并且在后臺將它們合并到更大的段中。這并不會中斷索引和搜索。

4、為什么要進行段合并？

1）索引段的個數越多，搜索性能越低并且消耗更多的內存；?
2）索引段是不可變的，你并不能物理上從中刪除信息。（可以物理上刪除document，但只是做了刪除標記，物理上并沒有刪除）?
3）當段合并時，這些被標記為刪除的文檔并沒有被拷貝至新的索引段中，這樣，減少了最終的索引段中的document數目。

5、段合并的好處是什么？

1）減少索引段的數量并提高檢索速度；?
2）減少索引的容量（文檔數）——段合并會移除被標記為已刪除的那些文檔。

6、段合并可能帶來的問題？

1）磁盤IO操作的代價；?
2）速度慢的系統中，段合并會顯著影響性能。

第7章 管理Elasticsearch

1、有了副本機制為什么還需要集群備份？

Elasticsearch 副本提供了高可靠性；它們讓你可以容忍零星的節點丟失而不會中斷服務。?
但是，副本并不提供對災難性故障的保護。對這種情況，你需要的是對集群真正的備份——在某些東西確實出問題的時候有一個完整的拷貝。

2、集群如何備份？

使用 snapshot API備份你的集群。?
它會拿到你集群里當前的狀態和數據然后保存到一個共享倉庫里。這個備份過程是”智能”的。?
ES5.6集群備份官網參考：?http://t.cn/RjKEH9G

3、集群備份分類？

完整備份——你的第一個快照會是一個數據的完整拷貝。?
增量備份——所有后續的快照會保留的是已存快照和新數據之間的差異。隨著你不時的對數據進行快照，備份也在增量的添加和刪除。這意味著后續備份會相當快速，因為它們只傳輸很小的數據量。

4、集群可以備份到哪里？

要使用這個功能，你必須首先創建一個保存數據的倉庫。有多個倉庫類型可以供你選擇：

• 共享文件系統，比如 NAS
• Amazon S3：亞馬遜Web云服務
• HDFS (Hadoop集群分布式文件系統)
• Azure Cloud：微軟云平臺

5、備份操作API？

PUT _snapshot/my_backup {"type": "fs","settings": {"location": "/mount/backups/my_backup"} }

• 1
• 2
• 3
• 4
• 5
• 6
• 7

注意：共享文件系統路徑必須確保集群所有節點都可以訪問到。

第8章 提高性能

1、什么情況下會出現堆內存泄漏？

如果沒有足夠的堆內存來供你的應用在堆上創建新對象，JVM會拋出一個OutOfMemeory異常，這是一個內存出了問題的跡象，要么是沒有足夠的內存給它，要么是有內存泄漏，導致沒有釋放不再使用的對象。

2、推薦的性能測試工具？

1）JMeter?
2）ab（Apache基準測試工具）

3、ES需要優化的原因？

1）硬件問題——如機械硬盤和固態硬盤；?
2）不良的數據結構；?
3）糟糕的查詢設計——如wildcard模糊匹配很長的字符串。

4、后臺什么在運行導致CPU飆升？如何排查？

熱點線程APi能向你提供查找問題根源所必需的信息。?
GET /_nodes/hot_threads?pretty

5、如何擴展集群？

1）垂直擴展?
向Elasticsearch集群添加更多的資源。?
制約因素——如：JVM最大支持31GB物理內存。

2）水平擴展?
索引多分片、多副本，集群中分散處理之。

優點：降低運行集群的成本。?
版本升級后（如5.X升級到6.0），確保服務仍然可用。

6、集群架構設計考慮因素？

當你在設計架構、決定節點數量、有多少個索引以及每個索引的分片數量時，你需要把能接受的出現故障的節點數量考慮進去。

當然了，你還需要考慮性能，只不過冗余和高可用應該是進行擴展時的一個因子。

7、大規模集群節點角色如何設定？

為了有一個完全容錯和高可用的集群，我們應該區分節點，為每個節點一個設計好的角色，角色分類如下：?
1）路由節點或查詢聚合節點；?
發送子查詢到其他節點，收集和合并結果，以及響應發出查詢的客戶端。

node.master: false node.data: false

• 1
• 2

2）數據節點；

node.master: false node.data: true

• 1
• 2

3）候選主節點。

node.master: true node.data: false http.enabled: false

• 1
• 2
• 3

候選主節點禁用Http協議是為了避免意外地在這些節點上進行查詢。這樣候選主節點相比于數據節點和路由節點可以使用更少的資源，可以確保它們僅僅被用來處理和主節點相關的工作。

8、高負載場景Elasticsearch優化的常規建議？

這里是建議，不是準則。?
（1）選擇正確的存儲?
如：選擇默認的default存儲類型。

（2）按需設定刷新頻率?
索引刷新頻率定義：文檔需要多長時間才能出現在搜索結果中。?
正確認知：?
1）刷新頻率越短，查詢越慢，且索引文檔的吞吐率越低。?
2）默認刷新頻率：1s刷新一次。?
3）無限的增加刷新時間是沒有意義的，因為超過一定的值（取決于你的數據負載和數據量）之后，性能提升變得微乎其微。

（3）線程池優化?
線程池優化的必要場景：你看到節點正在填充隊列并且仍然有計算能力剩余，且這些計算能力可以被指定用于處理待處理的任務。

（4）調整合并過程?
index.merge.policy.mery_factory低于默認值10，會導致更少的段，更低的RAM消耗，更快的查詢速度和更慢的索引速度；?
若大于10，導致索引由更多的分段組成，更高的RAM消耗，更慢的查詢速度和更快的索引速度。

（5）合理數據分布?
高索引量的使用場景：把索引分散到多個分片上來降低服務器CPU和I/O子系統的壓力。

如果你的節點無法處理查詢帶來的負載，你可以增加更多的ES節點，并增加副本的數量，于是主分片的物理拷貝會部署到新增節點上。這樣會使得文檔索引慢一些，但是會給你同時處理更多查詢的能力。

9.高負載、高查詢頻率場景的建議

（1）啟動過濾器緩存和分片查詢緩存?
過濾器緩存配置：indices.cache.filter.size?
分片查詢緩存配置：indices.cache.query.enable

（2）優化查詢語句結構?
書本中的過濾器已不再使用5.X以及更高版本。?
但，依然可以優化查詢語句，返回核對查詢同樣語句返回時間，進行權衡優化。

（3）使用路由?
有著相同路由值的數據都會保存到相同的分片上。

（4）并行查詢?
建議數據平均分配，多個節點可以有相同的負載。

（5）字段數據緩存和斷路?
當使用聚合和排序等字段數據緩存相關操作時，遇到了內存相關的問題（內存泄漏或者GC停頓），可以考慮使用 doc value。

（6）控制size和shard_size?
主要針對聚合操作。?
增加size和shard_size能使得聚合結果更準確，代價是：更多的網絡開銷和內存使用；?
減少size和shard_size能使得聚合不那么精確，代價是：網絡開銷小和內存使用率低。

10、高負載、高索引吞吐量場景

（1）批量索引?
批量索引代替逐個索引文檔。

（2）doc values和索引速度的取舍?
一方面：我們只關心更高的索引速度和更大的索引吞吐量，可以考慮不適用doc values。?
另一方面：如果有大量的數據，為了使用聚合和排序功能而不產生內存相關問題，唯一選擇——使用 doc values。

（3）控制文檔字段?
方式一：_source 控制字段輸出；?
方式二：禁用_all。?
減少文檔的大小和其內文本字段的數量會讓索引稍快一些。

（4）索引的結構和副本?
1）主分片部署到所有的節點上，以便：并行的索引文檔，加快索引的速度。?
2）過多的副本導致索引速度下降。

（5）調整預寫日志。

（6）存儲優化?
1）資金充足，建議購買SSD——原因：速度優勢明顯；?
2）資金不足，考慮ES使用多個數據路徑。?
3）不要使用共享或者遠程的文件系統保存索引——原因：速度慢，整體性能下降。

（7）索引期間的內存緩存?
建議給每個索引期間生效的分片分配512MB內存。?
indices.memeory.index_buffer_size是設置節點的，而不是分片。

小結

書中基于ES1.X版本的一些優化細節，可能在5.X、6.X甚至更高版本中有所不同，需要根據實戰需要、并結合最新官網文檔更新相關知識。?
ES仍然有很長的路要走，堅持、加油！

總結

以上是生活随笔為你收集整理的《深入理解Elasticsearch》读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。