elasticsearch如何設計索引

本文爲博客園作者所寫：一寸HUI，個人博客地址：https://www.cnblogs.com/zsql/

最近在做es相關的工作，所以記錄下自己的一些想法，可能很多方面不會很全面，但是基本都是經過驗證的。本文主要是圍繞着思考，從多個方面進行考慮，怎麼設計索引比較好，直接進入主題吧，本文的es版本爲elasticsearch7.8.1。

一、索引設計的重要性

　　首先索引創建後，索引的分片只能通過_split和_shrink接口對其進行成倍的增加和縮減，主要是因爲es的數據是通過_routing分配到各個分片上面的，所以本質上是不推薦去改變索引的分片數量的，因爲這樣都會對數據進行重新的移動。還有就是索引只能新增字段，不能對字段進行修改和刪除，缺乏靈活性，所以每次都只能通過_reindex重建索引了。還有就是一個分片的大小以及所以分片數量的多少嚴重影響到了索引的查詢和寫入性能。所以可想而知，設計一個好的索引能夠減少後期的運維管理和提高不少性能。所以前期對索引的設計是相當的重要的。

好的索引設計在整個集羣規劃中佔據舉足輕重的作用，索引的設計直接影響集羣設計的好壞和複雜度。
好的索引設計應該是充分結合業務場景的時間維度和空間維度，結合業務場景充分考量增、刪、改、查等全維度設計的。
好的索引設計是完全基於“設計先行，編碼在後”的原則，前期會花很長時間，爲的是後期工作更加順暢，避免不必要的返工

二、如何設計索引

　　在設計索引之前我們要明白索引有些什麼內容，明白索引的構成，比如索引的基本配置setting，映射mapping，還有重要的分片，副本，模板，索引的生命週期等。知道這些之後就可以有針對性的設計了。首先要結合公司的業務場景，數據量的大小，每天增量如何，數據的特點，會不會對歷史數據進行重新更新。數據存多久，是永久還是有一定的週期。數據需要準實時呢還是不需要準實時呢。所以清楚索引的構成和知道業務場景，才能夠結合起來做更好的設計。

2.1、考慮索引的公共基本配置

由於elasticsearch7.x不允許把索引級別的設置配置在elasticsearch.yml中，所以需要對每個索引進行單獨的配置，這樣的話就比較麻煩，所以可以把這些公共的配置配置在索引模板中，這樣就可以在新建索引的時候可以自動的設置到索引中，關於索引模板的操作可以看考：聊聊elasticsearch7.8的模板和動態映射

接下來看看一些常用索引級別的配置

"number_of_replicas": 1, #推薦副本數爲1
"max_result_window": 100000,
"refresh_interval": "30s", #這裏對實時性要求不高，可以增加該值提高寫入性能
"index.search.slowlog.threshold.query.warn": 10s,
"index.search.slowlog.threshold.query.info": 5s,
"index.search.slowlog.threshold.query.debug": 2s,
"index.search.slowlog.threshold.query.trace": 500ms,
"index.search.slowlog.threshold.fetch.warn": 1s,
"index.search.slowlog.threshold.fetch.info": 800ms,
"index.search.slowlog.threshold.fetch.debug": 500ms,
"index.search.slowlog.threshold.fetch.trace": 200ms,
"index.indexing.slowlog.threshold.index.warn": 10s,
"index.indexing.slowlog.threshold.index.info": 5s,
"index.indexing.slowlog.threshold.index.debug": 2s,
"index.indexing.slowlog.threshold.index.trace": 500ms
"dynamic": false #是否關閉動態字段映射，默認爲true，這裏選擇個人選擇禁用

當然索引的配置還有很多其他的，可以根據實際情況進行調整，這樣就可以把需要配置公共索引配置設計成索引模板：

PUT _index_template/template_index
{
    "index_patterns": [
        "index-*"
    ],
    "template": {
        "settings": {
            "number_of_replicas": 1,
            "max_result_window": 100000,
            "refresh_interval": "30s",
            "index.search.slowlog.threshold.query.warn": "10s",
            "index.search.slowlog.threshold.query.info": "5s",
            "index.search.slowlog.threshold.query.debug": "2s",
            "index.search.slowlog.threshold.query.trace": "500ms",
            "index.search.slowlog.threshold.fetch.warn": "1s",
            "index.search.slowlog.threshold.fetch.info": "800ms",
            "index.search.slowlog.threshold.fetch.debug": "500ms",
            "index.search.slowlog.threshold.fetch.trace": "200ms",
            "index.indexing.slowlog.threshold.index.warn": "10s",
            "index.indexing.slowlog.threshold.index.info": "5s",
            "index.indexing.slowlog.threshold.index.debug": "2s",
            "index.indexing.slowlog.threshold.index.trace": "500ms"
        },
        "mappings": {
            "dynamic": false
        }
    },
    "priority": 10
}

這樣新建index-開頭的索引的時候都會默認配置好如上的配置，這樣就是考慮到基本設置公共化

2.2、索引命名規範

　　這部分主要說下索引命名規範，包括別名，通過別名可以使得索引的操作變得更加靈活，一個索引可以有多個別名，當然一個別名可以配置多個索引，這樣的話就極大的增加了索引的的靈活性。在索引的命名上規定特殊字段開頭，同樣對其好進行權限控制，關於權限控制可以參考：elasticsearch7.8權限控制和規劃

必須嚴格按照如下命名格式：（否則將無法使用，因爲這裏設置了相關權限）；

索引命名規範：index-{行業}-{業務}-{版本}
別名命名規範：index-{行業}-{業務}

如果是索引拆分後（有多個索引），需要一個全局的讀的別名對所有拆分後的所有進行命名，和一個最新索引寫的別名（只對可更新的索引），如果這裏沒有描述清楚，請見2.5大索引的設計，兩個別名可規範如下：

讀別名：index-{行業}-{業務}-read
寫別名：index-{行業}-{業務}-insert

2.3、mapping的設計

mapping設置主要就是怎麼選擇數據類型，分詞等

中文分詞：推薦使用："analyzer": "ik_max_word" ，這樣可以更細粒度的進行中文分詞

設置字段的時候，務必過一下如下圖示的流程。根據實際業務需要，主要關注點：

數據類型選型；
是否需要檢索；
是否需要排序+聚合分析；
是否需要另行存儲

核心參數的含義，梳理如下

2.4、分片的設計

這個很重要，直接影響到後期的管理和性能。

Elasticsearch中的數據組織成索引。每一個索引由一個或多個分片組成。每個分片是Luncene索引的一個實例，你可以把實例理解成自管理的搜索引擎，用於在Elasticsearch集羣中對一部分數據進行索引和處理查詢。

分片設計原則

推薦每個分片的大小：20-40G，建議不超過30G，但是也會有特殊的情況，有些索引字段少，但是數據量大，這樣的話也可以增加一些分片數
確保每個節點的分片數量保持在低於每1GB堆內存對應集羣的分片在20-25之間。因此，具有30GB堆內存的節點最多可以有600-750個分片
每個索引的分片：一般爲節點數的1-3倍，假設我們有15個數據節點，則15*3*40G=1.8T，這樣一個索引最多設置真的大，如果超過了，就需要參考大索引的設計
分片數量儘量爲數據節點的倍數，這樣就可以使得數據進來均衡，但是數據量極少的索引，根據情況進行分片數量的設計

下面寫一個簡單的參考表（都可以根據實際情況進行調整，只是個人的建議）：

索引的大小	分片數量設置
0-20G	2
20-100G	8
100-400G	15
400-900G	30
900G-1.6T	45

如上設置是基於15個數據節點進行配置的，基本都給增量預留了一些空間，最好是根據實際情況進行設定，如果一個索引已經很大了，上面的配置不能滿足了的話需要對對索引進行拆分了，使用索引模板+Rollover+索引生命週期進行自動滾動，拆分索引。見2.5節

2.5、大索引的設計

　　當一個索引太大時就會有很多的風險，首先會影響性能，當分片數一定的情況下，數據越來越多，一個分片就會越來越大，就會違背了上面的設計原則，其次就是一個索引出問題，很難恢復，並且影響範圍廣，那如何對很大的索引進行設計呢。可以使用索引模板+Rollover+生命週期進行自動滾動創建索引，所有的索引都用一個別名進行讀，並且設置一個索引爲寫，這樣就能夠很好的拆分索引。先看看這麼設計的原理圖。

上面有三個索引，通過index_all索引進行檢索，是用index_latest保證只寫入到一個最新的索引中，每次索引滿足三個條件（文檔數，時間，索引大小）中的一個，就會自動的滾動生成新的索引。接下來做個實操，這樣更方面理解。

先來個官網，有興趣的可以參考：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/getting-started-index-lifecycle-management.html

主要分爲四個步驟：

創建索引生命週期的規則
創建索引模板並應用該生命週期
初始化一個索引
驗證

首先創建生命週期的規則，對於索引的生命週期可以參考：對Elasticsearch生命週期的思考，如果數據是定期存儲的，比如一些日誌，只保留最近30天，這樣的數據結合索引的生命週期可以自動的進行清理。我們首先創建一個策略policy_index，這裏是測試，所以把時間調至5分鐘，這些配置都應該根據實際情況進行設置。

PUT _ilm/policy/policy_index
{
  "policy": {
    "phases": {
      "hot": {                      
        "actions": {
          "rollover": {
            "max_size": "50GB",     
            "max_age": "5m"
          }
        }
      }
    }
  }
}

接下來設計索引模板，並且該策略應用進去。

PUT _index_template/policy_index_template
{
  "index_patterns": [
    "index-test-*"
  ],
  "template": {
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 1,
      "index.lifecycle.name": "policy_index", #配置策略
      "index.lifecycle.rollover_alias": "index-test-insert"
    },
    "aliases": {
      "index-test-read": {
        "is_write_index": false  #這個別名是用來讀的，不允許寫，否則會和寫的那個別名衝突
      }
    }
  }
}