【技術分享】《深入理解Elasticsearch》讀書筆記
題記
由於之前已經梳理過Elasticsearch基礎概念且在專案中實戰過Elasticsearch的增刪改查、聚類、排序等相關操作,對Elasticsearch算是有了一定的認知。但是,仍然對於一些底層的原理認知模糊,特買來《深入理解Elasticsearch》過了一遍,第一章到第四章偏應用,跟著敲一遍程式碼基本就能理解原理,第五章到第九章偏理論。現將書中一些細節知識點結合官網文件梳理如下。
第五章 分散式索引架構
如何選擇合適的分片和副本數?
- 目的:規劃索引及配置,適應應用的變化。
- 正確認知:分片數索引建立後不可以修改,副本數索引建立後可以通過API隨時修改。
- 多副本的缺點:額外副本佔據了額外的儲存空間,構建索引副本的開銷也隨之增大。
- 同時要注意:如果不建立副本,當主分片發生問題時,可能會造成資料的丟失。
- 配置參考:最理想的分片數量應該依賴於節點的數量。
- 參考公式:所需的最大節點數 = 分片數 *(副本數+1)
舉例:你計劃5個分片和1個副本,那麼所需要的最大的節點數為:5*(1+1)=10個節點。
可不可以基於時間構建索引?
- 目的:選擇感興趣的索引上進行查詢,歷史索引(時間比較久)的定期刪除。
- 正確操作方法:通過名稱為logs_2017_01, logs_2017_02,…..logs_2017_12來構建索引。
第六章 底層索引控制
什麼是段?
Elasticsearch中的每個分片包含多個segment(段),每一個segment都是一個倒排索引;在查詢的時,會把所有的segment查詢結果彙總歸併為最終的分片查詢結果返回。
在建立索引的時候,ES會把文件資訊寫到記憶體bugffer中(為了安全,也一起寫到translog),定時(可配置)把資料寫到segment快取小檔案中,然後重新整理查詢,使剛寫入的segment可查。
雖然寫入的segment可查詢,但是還沒有持久化到磁碟上。因此,還是會存在丟失的可能性的。所以,ES會執行flush操作,把segment持久化到磁碟上並清除translog的資料(因為這個時候,資料已經寫到磁碟上,不再需要了)。
參考連結什麼是段合併?
由於自動重新整理流程每秒會建立一個新的段,這樣會導致短時間內的段數量暴增。而段數目太多會帶來較大的麻煩。
- 消耗資源:每一個段都會消耗檔案控制程式碼、記憶體和cpu執行週期;
- 搜尋變慢:每個搜尋請求都必須輪流檢查每個段,所以段越多,搜尋也就越慢。
ES通過在後臺進行段合併來解決這個問題。小的段被合併到大的段,然後這些大的段再被合併到更大的段。
段合併做了什麼?
段合併的時候會將那些舊的已刪除文件從檔案系統中清除。
被刪除的文件(或被更新文件的舊版本)不會被拷貝到新的大段中。
啟動段合併不需要你做任何事。進行索引和搜尋時會自動進行。
- 當索引的時候,重新整理(refresh)操作會建立新的段並將段開啟以供搜尋使用。
- 合併程式選擇一小部分大小相似的段,並且在後臺將它們合併到更大的段中。這並不會中斷索引和搜尋。
為什麼要進行段合併?
- 索引段的個數越多,搜尋效能越低並且消耗更多的記憶體;
- 索引段是不可變的,你並不能物理上從中刪除資訊。(可以物理上刪除document,但只是做了刪除標記,物理上並沒有刪除)
- 當段合併時,這些被標記為刪除的文件並沒有被拷貝至新的索引段中,這樣,減少了最終的索引段中的document數目。
段合併的好處是什麼?
- 減少索引段的數量並提高檢索速度;
- 減少索引的容量(文件數)——段合併會移除被標記為已刪除的那些文件。
段合併可能帶來的問題?
- 磁碟IO操作的代價;
- 速度慢的系統中,段合併會顯著影響效能。
第七章 管理Elasticsearch
有了副本機制為什麼還需要叢集備份?
Elasticsearch 副本提供了高可靠性;它們讓你可以容忍零星的節點丟失而不會中斷服務。
但是,副本並不提供對災難性故障的保護。對這種情況,你需要的是對叢集真正的備份——在某些東西確實出問題的時候有一個完整的拷貝。
叢集如何備份?
使用 snapshot API備份你的叢集。
它會拿到你叢集裡當前的狀態和資料然後儲存到一個共享倉庫裡。這個備份過程是”智慧”的。
ES5.6叢集備份官網參考
叢集備份分類?
完整備份——你的第一個快照會是一個資料的完整拷貝。
增量備份——所有後續的快照會保留的是已存快照和新資料之間的差異。隨著你不時的對資料進行快照,備份也在增量的新增和刪除。這意味著後續備份會相當快速,因為它們只傳輸很小的資料量。
叢集可以備份到哪裡?
要使用這個功能,你必須首先建立一個儲存資料的倉庫。有多個倉庫型別可以供你選擇:
- 共享檔案系統,比如 NAS
- HDFS (Hadoop叢集分散式檔案系統)
備份如何操作API?
PUT _snapshot/my_backup
{
"type": "fs",
"settings": {
"location": "/mount/backups/my_backup"
}
}
注意:共享檔案系統路徑必須確保叢集所有節點都可以訪問到。
##第八章 提高效能
>####什麼情況下會出現堆記憶體洩漏?
>>如果沒有足夠的堆記憶體來供你的應用在堆上建立新物件,JVM會丟擲一個OutOfMemeory異常,這是一個記憶體出了問題的跡象,要麼是沒有足夠的記憶體給它,要麼是有記憶體洩漏,導致沒有釋放不再使用的物件。
>####推薦的效能測試工具?
>>- JMeter
- ab(Apache基準測試工具)
>####ES需要優化的原因?
>>- 硬體問題——如機械硬碟和固態硬碟;
- 不良的資料結構;
- 糟糕的查詢設計——如wildcard模糊匹配很長的字串。
>####後臺什麼在執行導致CPU飆升?如何排查?
>>熱點執行緒APi能向你提供查詢問題根源所必需的資訊。
GET /_nodes/hot_threads?pretty
>####如何擴充套件叢集?
>>- 垂直擴充套件
向Elasticsearch叢集新增更多的資源。
制約因素如:JVM最大支援31GB實體記憶體。
- 水平擴充套件
索引多分片、多副本,叢集中分散處理之。
優點:降低執行叢集的成本。
版本升級後(如5.X升級到6.0),確保服務仍然可用。
>####叢集架構設計考慮因素?
>>當你在設計架構、決定節點數量、有多少個索引以及每個索引的分片數量時,你需要把能接受的出現故障的節點數量考慮進去。
>>當然了,你還需要考慮效能,只不過冗餘和高可用應該是進行擴充套件時的一個因子。
>####大規模叢集節點角色如何設定?
>>為了有一個完全容錯和高可用的叢集,我們應該區分節點,為每個節點一個設計好的角色,角色分類如下:
- 路由節點或查詢聚合節點;
傳送子查詢到其他節點,收集和合並結果,以及響應發出查詢的客戶端。
node.master: false
node.data: false
- 資料節點
node.master: false
node.data: true
- 候選主節點
node.master: true
node.data: false
http.enabled: false
>>候選主節點禁用Http協議是為了避免意外地在這些節點上進行查詢。這樣候選主節點相比於資料節點和路由節點可以使用更少的資源,可以確保它們僅僅被用來處理和主節點相關的工作。
>####高負載場景Elasticsearch優化的常規建議?
>>這裡是建議,不是準則。
- 選擇正確的儲存,如:選擇預設的default儲存型別。
- 按需設定重新整理頻率
索引重新整理頻率定義:文件需要多長時間才能出現在搜尋結果中。
- 正確認知:
重新整理頻率越短,查詢越慢,且索引文件的吞吐率越低。
預設重新整理頻率:1s重新整理一次。
無限的增加重新整理時間是沒有意義的,因為超過一定的值(取決於你的資料負載和資料量)之後,效能提升變得微乎其微。
- 執行緒池優化
執行緒池優化的必要場景:你看到節點正在填充佇列並且仍然有計算能力剩餘,且這些計算能力可以被指定用於處理待處理的任務。
- 調整合並過程
index.merge.policy.mery_factory低於預設值10,會導致更少的段,更低的RAM消耗,更快的查詢速度和更慢的索引速度;
若大於10,導致索引由更多的分段組成,更高的RAM消耗,更慢的查詢速度和更快的索引速度。
- 合理資料分佈
高索引量的使用場景:把索引分散到多個分片上來降低伺服器CPU和I/O子系統的壓力。
>>如果你的節點無法處理查詢帶來的負載,你可以增加更多的ES節點,並增加副本的數量,於是主分片的物理拷貝會部署到新增節點上。這樣會使得文件索引慢一些,但是會給你同時處理更多查詢的能力。
>###高負載、高查詢頻率場景的建議
>>- 啟動過濾器快取和分片查詢快取
過濾器快取配置:indices.cache.filter.size
分片查詢快取配置:indices.cache.query.enable
- 優化查詢語句結構
書本中的過濾器已不再使用5.X以及更高版本。
但,依然可以優化查詢語句,返回核對查詢同樣語句返回時間,進行權衡優化。
- 使用路由
有著相同路由值的資料都會儲存到相同的分片上。
- 並行查詢
建議資料平均分配,多個節點可以有相同的負載。
- 欄位資料快取和斷路
當使用聚合和排序等欄位資料快取相關操作時,遇到了記憶體相關的問題(記憶體洩漏或者GC停頓),可以考慮使用 doc value。
- 控制size和shard_size
主要針對聚合操作。
增加size和shard_size能使得聚合結果更準確,代價是:更多的網路開銷和記憶體使用;
減少size和shard_size能使得聚合不那麼精確,代價是:網路開銷小和記憶體使用率低。
>####高負載、高索引吞吐量場景
>>- 批量索引
批量索引代替逐個索引文件。
- doc values和索引速度的取捨
一方面:我們只關心更高的索引速度和更大的索引吞吐量,可以考慮不適用doc values。
另一方面:如果有大量的資料,為了使用聚合和排序功能而不產生記憶體相關問題,唯一選擇——使用 doc values。
- 控制文件欄位
方式一:_source 控制欄位輸出;
方式二:禁用_all。
減少文件的大小和其內文字欄位的數量會讓索引稍快一些。
- 索引的結構和副本
1) 主分片部署到所有的節點上,以便:並行的索引文件,加快索引的速度。
2)過多的副本導致索引速度下降。
- 調整預寫日誌。
- 儲存優化
1)資金充足,建議購買SSD——原因:速度優勢明顯;
2)資金不足,考慮ES使用多個資料路徑。
3)不要使用共享或者遠端的檔案系統儲存索引——原因:速度慢,整體效能下降。
- 索引期間的記憶體快取
建議給每個索引期間生效的分片分配512MB記憶體。
indices.memeory.index_buffer_size是設定節點的,而不是分片。
##小結
>書中基於ES1.X版本的一些優化細節,可能在5.X、6.X甚至更高版本中有所不同,需要根據實戰需要、並結合最新官網文件更新相關知識。
作者:銘毅天下 文章轉載自http://blog.csdn.net/laoyang360
##加入釘釘技術討論群
<p style="text-align:center"><img src="https://yqfile.alicdn.com/fd66fe6dfb293dc9cd7e02122200196dd063f45e.jpeg" width = "200" height = "248" alt="dingQR"></p>
阿里雲Elasticsearch已正式釋出啦,Elastic開源官方聯合開發,整合5.5.3商業版本XPack功能,歡迎開通使用。
相關文章
- 《深入分析JavaWeb技術內幕》之讀書筆記(篇三)JavaWeb筆記
- 《深入淺出MyBatis--技術原理與實戰》讀書筆記MyBatis筆記
- 《深入理解Java虛擬機器》讀書筆記Java虛擬機筆記
- [原創]京東技術解密讀書筆記解密筆記
- 深入理解java虛擬機器——讀書筆記1Java虛擬機筆記
- 深入探索Android熱修復技術原理讀書筆記 —— 熱修復技術介紹Android筆記
- 深入探索Android熱修復技術原理讀書筆記 —— 程式碼熱修復技術Android筆記
- 深入探索Android熱修復技術原理讀書筆記 —— 資源熱修復技術Android筆記
- 「理解Unix程式」讀書筆記筆記
- 閱讀《深入理解ES6》書籍,筆記整理(上)筆記
- 讀書筆記-大型網站技術架構筆記網站架構
- 《淘寶技術這十年》讀書筆記筆記
- 《資料探勘概念與技術》讀書筆記筆記
- 『淘寶十年技術路』讀書筆記筆記
- 《大型網站技術架構》讀書筆記網站架構筆記
- 深入淺出node讀書筆記筆記
- 《深入淺出MySQL》讀書筆記MySql筆記
- 《快速閱讀術》讀書筆記筆記
- 《深入理解java虛擬機器》讀書筆記1(走近java)Java虛擬機筆記
- 深入理解JVM讀書筆記四: (早期)編譯器優化JVM筆記編譯優化
- 《深入分析Java Web技術內幕》讀書筆記 - 第1章 深入Web請求過程JavaWeb筆記
- 《現代通訊網路技術》讀書筆記筆記
- 深入淺出Nodejs讀書筆記NodeJS筆記
- 《深入剖析Tomcat》讀書筆記(一)Tomcat筆記
- 《深入剖析Tomcat》讀書筆記(二)Tomcat筆記
- JVM資料區域與垃圾收集<深入理解JVM讀書筆記>JVM筆記
- 【Laravel】Laravel 框架關鍵技術解析·讀書筆記(二)Laravel框架筆記
- 《深入理解ES6》筆記——導讀筆記
- 深入理解JVM讀書筆記二: 垃圾收集器與記憶體分配策略JVM筆記記憶體
- 《深入核心的敏捷開發》讀書筆記(2)敏捷筆記
- 《深入淺出MFC》讀書筆記(一,二) (轉)筆記
- 深入理解JVM讀書筆記五: Java記憶體模型與Volatile關鍵字JVM筆記Java記憶體模型
- 深入理解JVM讀書筆記三: 虛擬機器類載入機制JVM筆記虛擬機
- 讀書筆記:從Lucene到Elasticsearch:全文檢索實戰筆記Elasticsearch
- 讀書筆記...筆記
- 讀書筆記筆記
- 《Web前端黑客技術解密》讀書筆記(第三、四、五章)Web前端黑客解密筆記
- Mysql技術內幕InnoDB儲存引擎讀書筆記--《四》表MySql儲存引擎筆記