Elasticsearch Index模塊

1. Index Setting（索引設置）

每一個索引均可以設置索引級別。可選值有：

• static ：只能在索引建立的時候，或者在一個關閉的索引上設置
• dynamic：能夠動態設置

1.1. Static index settings（靜態索引設置）

• index.number_of_shards ：一個索引應該有的主分片（primary shards）數。默認是5。並且，只能在索引建立的時候設置。（注意，每一個索引的主分片數不能超過1024。固然，這個設置也是能夠改的，經過在集羣的每一個節點機器上設置系統屬性來更改，例如：export ES_JAVA_OPTS="-Des.index.max_number_of_shards=128"）
• index.shard.check_on_startup ：分片在打開前是否要檢查是否有壞損。默認是false。
• index.routing_partition_size ：自定義的路由值能夠路由到的分片數。默認是1。

1.2. Dynamic index settings（動態索引設置）

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java高級交流：854630135，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。

• index.number_of_replicas ：每一個主分片所擁有的副本數，默認是1。
• index.auto_expand_replicas ：根據集羣中數據節點的數量自動擴展副本的數量。默認false。
• index.refresh_interval ：多久執行一次刷新操做，使得最近的索引更改對搜索可見。默認是1秒。設置爲-1表示禁止刷新。
• index.max_result_window ：在這個索引下檢索的 from + size 的最大值。默認是10000。（PS：也就是說最多能夠一次返回10000條）

2. Analysis

索引分析模塊是一個可配置的分析器註冊表，可用於將字符串字段轉換爲如下各個場景中的Term：

• 添加到反向索引（ inverted index）以使文檔可搜索
• 用於高級查詢，如match查詢

（PS：簡而言之，

第1、分析器用於將一個字符串轉成一個一個的Term；

第2、這些Term能夠被添加到反向索引中，以使得該文檔能夠經過這個Term被檢索到；

第3、這些Term還能夠高級查詢，好比match查詢）

3. Merge（合併）

在Elasticsearch中，一個分片就是一個Lucene索引，並且一個Lucene索引被分解成多個段（segments）。段是索引中存儲索引數據的內部存儲元素，而且是不可變的。較小的段按期合併到較大的段中，以控制索引大小。

合併調度程序（ConcurrentMergeScheduler）在須要時控制合併操做的執行。合併在單獨的線程中運行，當達到最大線程數時，將等待進一步的合併，直到合併線程可用爲止。

支持下列參數：

• index.merge.scheduler.max_thread_count ：在單個碎片上，一次合併的最大線程數。默認是 Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java高級交流：854630135，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。

4. Slow log（慢日誌）

4.1. Search Slow Log（查詢慢日誌）

分片級慢查詢日誌，容許將慢查詢記錄到專用的日誌文件中

能夠在執行query階段和fetch階段設置閾值，例如：

 

上面全部的設置項都是動態設置的，並且是按索引設置的。（PS：也就是說，是針對某一個索引設置的）

默認狀況下，是禁用狀態（設置爲-1）

級別（warn, info, debug, trace）能夠控制哪些日誌級別的日誌將會被記錄

注意，日誌記錄是在分片級別範圍內完成的，這意味着只有在特定的分片中執行搜索請求的慢日誌纔會被記錄。

日誌文件配置默認在log4j2.properties

4.2. Index Slow Log（索引慢日誌）

和前面的慢查詢日誌相似，索引慢日誌文件名後綴爲_index_indexing_slowlog.log

日誌和閾值配置與慢查詢相似，並且默認日誌文件配置也是在log4j2.properties

下面是一個例子：

 

5. Store（存儲）

5.1. 文件存儲類型

不一樣的文件系統有不一樣的存儲類型。默認狀況下，Elasticsearch將根據操做環境選擇最佳實現。

可選的存儲類型有：

• fs ：默認實現，取決於操做系統
• simplefs ：對應Lucene SimpleFsDirectory
• niofs ：對應Lucene NIOFSDirectory
• mmapfs ：對應Lucene MMapDirectory

能夠改變這種設置，經過在config/elasticsearch.yml中添加以下配置，例如：

index.store.type: niofs

上面的設置對全部的索引都生效。你也能夠在索引建立的時候針對某一個特定的索引進行設置，例如：

curl -X PUT "localhost:9200/my_index" -H 'Content-Type: application/json' -d' { "settings": { "index.store.type": "niofs" } } '

5.2. 預加載數據到文件系統緩存

默認狀況下，Elasticsearch徹底依賴於操做系統的文件系統緩存來緩存I/O操做。能夠設置index.store.preload來告訴操做系統在打開時將熱點索引文件的內容加載到內存中。這個選項接受一個逗號分隔的文件擴展列表：擴展名在列表中的全部文件將在打開時預加載。這對於提升索引的搜索性能很是有用，特別是在主機操做系統重啓時，由於這會致使文件系統緩存被丟棄。可是請注意，這可能會減慢索引的打開速度，由於只有在將數據加載到物理內存以後，索引纔會可用。

靜態設置的話能夠這樣設置：

index.store.preload: ["nvd", "dvd"]

或者在索引建立的時候設置：

curl -X PUT "localhost:9200/my_index" -H 'Content-Type: application/json' -d' { "settings": { "index.store.preload": ["nvd", "dvd"] } } '

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java高級交流：854630135，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。

默認值是一個空數組，意味着文件系統不會預加載任何數據。對於可搜索的索引，你可能想要把它們設置爲["nvd", "dvd"]，這將會使得norms和doc數據被預先加載到物理內存。不推薦把全部的文件都預加載到內存，一般可能更好的選擇是設置爲["nvd", "dvd", "tim", "doc", "dim"]，這樣的話將會預加載norms，doc values，terms dictionaries， postings lists 和 points

6. Translog（事物日誌）

對Lucene的更改只有在Lucene提交的時候纔會持久化到磁盤，這是一個相對昂貴的操做，所以不能再每次索引建立或者刪除之後就執行。若是進程退出或者硬件故障的話，那麼在兩次提交之間所作的更改將會被Lucece從索引中刪除。（PS：上一次提交之後到下一次提交以前這之間的更新會丟失）

若是每次更改之後當即執行Lucene提交，那麼這個開銷實在太大，所以每一個分片副本也都有一個事物日誌，它被叫作與之關聯的translog。全部的索引和刪除操做都是在內部Lucene索引處理以後，確認以前，被寫入到translog的。在崩潰的狀況下，當分片恢復時，能夠從translog中恢復最近的事務，這些事務已經被確認，可是尚未包含在上一次Lucene提交中。

Elasticsearch flush是執行Lucene提交併啓動新translog的過程。flush是在後臺自動執行的，以確保translog不會變得太大。（PS：由於若是translog很大，那麼恢復所須要的時間越長）。固然，咱們也能夠經過API手動執行刷新，儘管不多須要這樣作。

6.1. Translog設置

translog中的數據只有在fsync和提交時纔會被持久化到磁盤。在硬件失敗的狀況下，在translog提交以前的數據都會丟失。

默認狀況下，若是index.translog.durability被設置爲async的話，Elasticsearch每5秒鐘同步並提交一次translog。或者若是被設置爲request（默認）的話，每次index，delete，update，bulk請求時就同步一次translog。更準確地說，若是設置爲request, Elasticsearch只會在成功地在主分片和每一個已分配的副本分片上fsync並提交translog以後，纔會向客戶端報告index、delete、update、bulk成功。

能夠動態控制每一個索引的translog行爲：

• index.translog.sync_interval ：translog多久被同步到磁盤並提交一次。默認5秒。這個值不能小於100ms
• index.translog.durability ：是否在每次index，delete，update，bulk請求以後當即同步並提交translog。接受下列參數：
• request ：（默認）fsync and commit after every request。這就意味着，若是發生崩潰，那麼全部只要是已經確認的寫操做都已經被提交到磁盤。
• async ：在後臺每sync_interval時間進行一次fsync和commit。意味着若是發生崩潰，那麼全部在上一次自動提交之後的已確認的寫操做將會丟失。
• index.translog.flush_threshold_size ：當操做達到多大時執行刷新，默認512mb。也就是說，操做在translog中不斷累積，當達到這個閾值時，將會觸發刷新操做。
• index.translog.retention.size ：translog文件達到多大時執行執行刷新。默認512mb。
• index.translog.retention.age ：translog最長多久提交一次。默認12h。

6.2. 小結

一、只有在Lucene提交的時候，對Lucene所作的更改纔會持久化到磁盤，而這一操做開銷很大，於是不可能每次改變後就當即提交，而若是不是每次更改後當即提交的話，那麼在本次提交之後到下一次提早之前這之間的更改就有丟失的可能。爲了解決這種問題，每一個索引分片都有一個叫作「translog」的事物日誌，每次Lucene處理完之後，就向translog中寫日誌，最後確認本次更改。也就是說，translog是在Lucene內部處理完之後，確認請求以前寫的。

二、translog是爲了不頻繁Lucene提交所形成的大額開銷，同時又要儘可能減小數據丟失而採起的一種方案

三、Elasticsearch flush的時候會提交Lucene更改，同時開啓新的translog。flush是後臺自動進行的。默認30分鐘一次。

四、translog自己做爲文件也是須要fsync（同步）到磁盤的。經過translog選項設置，咱們能夠控制多久同步一次，或者當文件達到多大的時候同步，或者文件最長多久就必須同步。默認每次請求之後就當即同步。若是在同步以前發生崩潰，那麼上一次同步以後的寫操做也是會丟失的。

五、Lucene提交跟translog提交是兩回事，Lucene提交的時候translog確定會被提交

7. Segment（段）

向索引中插入文檔時，文檔首先被保存在內存緩存（in-memory buffer）中，同時將操做寫入到translog中，此時這條剛插入的文檔還不能被搜索到。默認1秒鐘refresh一次，refresh操做會將文件寫到操做系統的文件系統緩存中，並造成一個segment，refresh後文檔能夠被檢索到。

當flush的時候，全部segment被同步到磁盤，同時清空translog，而後生成一個新的translog

Lucene把每次生成的倒排索引叫作一個segment，也就是說一個segment就是一個倒排索引。（PS：能夠類比Oracle中段區塊的概念）

 

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加個人Java高級交流：854630135，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。