Elasticsearch生产环境索引管理深刻剖析-搜索系统线上实战

时间 2019-11-08

标签 elasticsearch 生产环境索引管理深刻剖析搜索系统线上实战栏目日志分析繁體版

原文原文链接

本套技术专栏做者（秦凯新）专一于大数据及容器云核心技术解密，具有5年工业级IOT大数据云平台建设经验，可提供全栈的大数据+云原平生台咨询方案，请持续关注本套博客。QQ邮箱地址：1120746959@qq.com，若有任何学术交流，可随时联系。node

1. 索引管理

1.1 建立索引

用settings给这个索引在建立时能够添加一些设置，还有能够初始化一些type的mapping算法

curl -XPUT 'http://elasticsearch02:9200/twitter?pretty' -d '
  {
      "settings" : {
          "index" : {
              "number_of_shards" : 3, 
              "number_of_replicas" : 2 
          }
      },
      "mappings" : {
          "type1" : {
              "properties" : {
                  "field1" : { "type" : "text" }
              }
          }
      }
  }'
复制代码

1.2 索引建立返回消息的解释

默认状况下，索引建立命令会在每一个primary shard的副本开始进行复制之后，或者是请求超时之后，返回一个响应消息，相似下面这样的。shell
其中acknowledged代表了这个索引有没有建立成功，shards_acknowledged代表了每一个primary shard有没有足够数量的replica开始进行复制了。有可能这两个参数会为false，可是索引依然能够建立成功。由于这些参数仅仅是代表在请求超时以前，那两个行为有没有成功，也有可能请求超时了，在超时前都没成功，可是超时后在es server端仍是都执行了。json
若是acknoledged是false，那么就多是超时了，此时接受到响应消息的时候，cluster state都还没变动，没有加入新建立的index，可是也许以后仍是会建立这个index。若是shards_acknowledged是false，那么可能在primary shard进行副本copy以前，就timeout了，可是此时也许index建立成功了，并且cluster state已经加入了新建立的index。api
```
{
      "acknowledged": true,
      "shards_acknowledged": true
  }
复制代码
```

1.3 删除索引

删除索引中的一个type
curl -XDELETE 'http://elasticsearch02:9200/twitter?pretty'
复制代码

1.4 查询索引设置信息

curl -XGET 'http://elasticsearch02:9200/twitter?pretty'
复制代码

1.5 打开/关闭索引

若是关闭了一个索引以后，那么这个索引是不会带来任何的性能开销了，只要保留这个索引的元数据便可，而后对这个索引的读写操做都不会成功。一个关闭的索引能够接着再打开，打开之后会进行shard recovery过程。缓存

好比说你在作一些运维操做的时候，如今你要对某一个索引作一些配置，运维操做，修改一些设置，关闭索引，不容许写入，成功之后再打开索引数据结构

curl -XPOST 'http://elasticsearch02:9200/twitter/_close?pretty'
  curl -XPOST 'http://elasticsearch02:9200/twitter/_open?pretty'
  
  curl -XPUT 'http://elasticsearch02:9200/twitter/type1/1?pretty' -d '
  {
  	"field1": "1"
  }'
复制代码

1.6 压缩索引

shrink命令能够将一个已有的索引压缩成一个新的索引，同时primary shard会更少。app
primary shard由于涉及到document的hash路由问题，因此是不容许修改的。可是若是要减小index的primary shard，能够用shrink命令来压缩index。可是压缩后的shard数量必须能够被原来的shard数量整除。举例来讲，一个有8个primary shard的index能够被压缩成4个，2个，或者1个primary shard的index。运维
压缩索引，好比是要保留7天的数据，那么给了10个shard，可是如今需求变了，这个索引只要保留3天的数据就能够了，那么数据量变小了，就不须要10个shard了，就能够作shrink操做，5个shard。curl

shrink命令的工做流程以下：

（1）首先，它会建立一个跟source index的定义同样的target
       index，可是惟一的变化就是primary shard变成了指定的数量
  （2）接着它会将source index的segment file直接用hard-link的方式链接到
       target index的segment file，若是操做系统不支持hard-link，那么就会将
        source index的segment file都拷贝到target index的
        data dir中，会很耗时。若是用hard-link会很快
  （3）最后，会将target index进行shard recovery恢复
复制代码

若是要shrink index，那么这个index必须先被标记为read only，并且这个index的每一个shard的某一个copy，能够是primary或者是replica，都必须被复制到一个节点上去。
默认状况下，index的每一个shard有可能在不一样机器上的，好比说，index有5个shard，shard0和shard1在机器1上，shard二、shard3在机器2上，shard4在机器3上。如今还得把shard0，shard1，shard2，shard3，shard4所有拷贝到一个同一个机器上去，可是能够是shard0的replica shard。并且每一个primary shard都必须存在。能够经过下面的命令来完成。其中index.routing.allocation.require._name必须是某个node的名称，这个都是能够本身设置的。
```
curl -XPUT 'http://elasticsearch02:9200/twitter/_settings?pretty' -d '
  {
    "settings": {
      "index.routing.allocation.require._name": "node-elasticsearch-02", 
      "index.blocks.write": true 
    }
  }'
复制代码
```
这个命令会花费一点时间将source index每一个shard的一个copy都复制到指定的node上去，能够经过GET _cat/recovery?v命令来追踪这个过程的进度。
等上面的shard copy relocate过程结束以后，就能够shrink一个index，用下面的命令便可：
```
POST my_source_index/_shrink/my_target_inde
复制代码
```
若是target index被添加进了cluster state以后，这个命令就会当即返回，不是等待shrink过程完成以后才返回的。固然还能够用下面的命令来shrink的时候修改target index的设置，在settings里就能够设置target index的primary shard的数量。
```
curl -XPOST 'http://elasticsearch02:9200/twitter/_shrink/twitter_shrinked?pretty' -d '
  {
    "settings": {
      "index.number_of_replicas": 1,
      "index.number_of_shards": 1, 
      "index.codec": "best_compression" 
    }
  }'
复制代码
```
是须要监控整个shrink的过程的，用GET _cat/recovery?v便可。

1.7 rollover index建立新索引

rollover命令能够将一个alias重置到一个新的索引上去，若是已经存在的index被认为太大或者数据太旧了。这个命令能够接收一个alias名称，还有一系列的condition。
若是索引知足了condition，那么就会建立一个新的index，同时alias会指向那个新的index。好比下面的命令。举例来讲，有一个logs-0000001索引，给了一个别名是logs_write，接着发起了一个rollover的命令，若是logs_write别名以前指向的那个index，也就是logs-0000001，建立了超过7天，或者里面的document已经超过了1000个了，而后就会建立一个logs-000002的索引，同时logs_write别名会指向新的索引。
这个命令实际上是颇有用的，特别是针对这种用户访问行为日志的数据，或者是一些联机事务系统的数据的进入，你能够写一个shell脚本，天天0:00的时候就执行如下rollover命令，此时就判断，若是说以前的索引已经存在了超过1天了，那么此时就建立一个新的索引出来，同时将别名指向新的索引。自动去滚动建立新的索引，保持每一个索引就只有一个小时，一天，七天，三天，一周，一个月。

相似用es来作日志平台，就可能分布式电商平台，可能订单系统的日志，单独的一个索引，要求的是保留最近3天的日志就能够了。交易系统的日志，是单独的一个索引，要求的是保留最近30天的日志。

curl -XPUT 'http://elasticsearch02:9200/logs-000001?pretty' -d ' 
  {
    "aliases": {
      "logs_write": {}
    }
  }'
  
  # Add > 1000 documents to logs-000001
  
  curl -XPUT 'http://elasticsearch02:9200/logs-000001/data/1?pretty' -d '
  {
  	"userid": 1,
  	"page": 1
  }'
  
  curl -XPUT 'http://elasticsearch02:9200/logs-000001/data/2?pretty' -d '
  {
  	"userid": 2,
  	"page": 2
  }'
  
  curl -XPUT 'http://elasticsearch02:9200/logs-000001/data/3?pretty' -d '
  {
  	"userid": 3,
  	"page": 3
  }'
  
  curl -XPOST 'http://elasticsearch02:9200/logs_write/_rollover?pretty' -d ' 
  {
    "conditions": {
      "max_age":   "1d",
      "max_docs":  3
    }
  }'
  
  {
    "acknowledged": true,
    "shards_acknowledged": true,
    "old_index": "logs-000001",
    "new_index": "logs-000002",
    "rolled_over": true, 
    "dry_run": false, 
    "conditions": { 
      "[max_age: 7d]": false,
      "[max_docs: 1000]": true
    }
  }
复制代码

这个过程常见于网站用户行为日志数据，好比按天来自动切分索引，写个脚本定时去执行rollover，就会自动不断建立新的索引，可是别名永远是一个，对于外部的使用者来讲，用的都是最新数据的索引。
举一个简单的例子，这块是怎么玩儿的，好比说用es作网站的实时用户行为分析，要求的是一个索引只要保留当日的数据就能够了，那么就能够用这个rollover的策略，确保每一个索引都是包含当日的最新数据的。老的数据，就变成别的索引了，此时能够写一个shell脚本，删除旧的数据，这样的话，es里就保留当前最新的数据就能够了。也能够根据你的需求，就保留最近7天的数据，可是最新一天的数据在一个索引中，供分析查询使用。
默认状况下，若是已经存在的那个索引是用-符号加上一个数字结尾的，好比说logs-000001，那么新索引的名称就会是自动给那个数字加1，好比logs-000002，自动就是给一个6位的数字，并且会自动补零。可是咱们也能够本身指定要的新的索引名称，好比下面这样：
```
POST /my_alias/_rollover/my_new_index_name
  {
    "conditions": {
      "max_age":   "7d",
      "max_docs":  1000
    }
  }
复制代码
```
能够将rollover命令和date日期结合起来使用，好比下面的例子，先建立了一个logs-2016.10.31-1格式的索引。接着每次若是成功rollover了，那么若是是在当天rollover了屡次，那就是当天的日期，末尾的数字递增。若是是隔天才rollover，会自动变动日期，同时维护末尾的数字序号。
```
PUT /%3Clogs-%7Bnow%2Fd%7D-1%3E 
  {
    "aliases": {
      "logs_write": {}
    }
  }
  
  PUT logs_write/log/1
  {
    "message": "a dummy log"
  }
  
  POST logs_write/_refresh
  
  # Wait for a day to pass
  
  POST /logs_write/_rollover 
  {
    "conditions": {
      "max_docs":   "1"
    }
  }
复制代码
```

固然，还能够在rollover的时候，给新的index进行新的设置：

POST /logs_write/_rollover
  {
    "conditions" : {
      "max_age": "7d",
      "max_docs": 1000
    },
    "settings": {
      "index.number_of_shards": 2
    }
  }
复制代码

1.8 mapping管理

put mapping命令可让咱们给一个已有的索引添加一个新的type，或者修改一个type，好比给某个type加一些字段。

下面这个命令是在建立索引的时候，直接跟着建立一个type：

curl -XPUT 'http://elasticsearch02:9200/twitter?pretty' -d ' 
  {
    "mappings": {
      "tweet": {
        "properties": {
          "message": {
            "type": "text"
          }
        }
      }
    }
  }'
复制代码

下面这个命令是给一个已有的索引添加一个type：

curl -XPUT 'http://elasticsearch02:9200/twitter/_mapping/user?pretty' -d ' 
  {
    "properties": {
      "name": {
        "type": "text"
      }
    }
  }'
复制代码

下面这个命令是给一个已有的type添加一个field：

curl -XPUT 'http://elasticsearch02:9200/twitter/_mapping/tweet?pretty' -d '
  {
    "properties": {
      "user_name": {
        "type": "text"
      }
    }
  }'

  curl -XGET 'http://elasticsearch02:9200/twitter/_mapping/tweet?pretty'，上面这行命令能够查看某个type的
  mapping映射信息
  
  curl -XGET 'http://elasticsearch02:9200/twitter/_mapping/tweet/field/message?pretty'，这行命令能够看某个
  type的某个field的映射信息
复制代码

1.9 索引别名管理

curl -XPOST 'http://elasticsearch02:9200/_aliases?pretty' -d '
    {
        "actions" : [
            { "add" : { "index" : "twitter", "alias" : "twitter_prod" } }
        ]
    }'
    
    curl -XPOST 'http://elasticsearch02:9200/_aliases?pretty' -d '
    {
        "actions" : [
            { "remove" : { "index" : "twitter", "alias" : "twitter_prod" } }
        ]
    }'
    
    POST /_aliases
    {
        "actions" : [
            { "remove" : { "index" : "test1", "alias" : "alias1" } },
            { "add" : { "index" : "test2", "alias" : "alias1" } }
        ]
    }
    
    POST /_aliases
    {
        "actions" : [
            { "add" : { "indices" : ["test1", "test2"], "alias" : "alias1" } }
        ]
    }
复制代码

索引别名，仍是挺有用的，主要是什么呢，就是说，能够将一个索引别名底层挂载多个索引，好比说7天的数据
索引别名经常和以前讲解的那个rollover结合起来，咱们为了性能和管理方便，天天的数据都rollover出来一个索引，可是在对数据分析的时候，多是这样子的，有一个索引access-log，指向了当日最新的数据，用来计算实时数据的; 有一个索引access-log-7days，指向了7天的7个索引，可让咱们进行一些周数据的统计和分析。

1.10 index settings管理

常常可能要对index作一些settings的调整，经常和以前的index open和close结合起来

curl -XPUT 'http://elasticsearch02:9200/twitter/_settings?pretty' -d '
  {
      "index" : {
          "number_of_replicas" : 1
      }
  }'
  
  curl -XGET 'http://elasticsearch02:9200/twitter/_settings?pretty'
复制代码

1.11 index template管理

能够定义一些index template，这样template会自动应用到新建立的索引上去。template中能够包含settings和mappings，还能够包含一个pattern，决定了template会被应用到哪些index上。并且template仅仅在index建立的时候会被应用，修改template，是不会对已有的index产生影响的。

curl -XPUT 'http://elasticsearch02:9200/_template/template_access_log?pretty' -d '
  {
    "template": "access-log-*",
    "settings": {
      "number_of_shards": 2
    },
    "mappings": {
      "log": {
        "_source": {
          "enabled": false
        },
        "properties": {
          "host_name": {
            "type": "keyword"
          },
          "created_at": {
            "type": "date",
            "format": "EEE MMM dd HH:mm:ss Z YYYY"
          }
        }
      }
    },
    "aliases" : {
        "access-log" : {}
    }
  }'
  
  curl -XDELETE 'http://elasticsearch02:9200/_template/template_access_log?pretty'
  curl -XGET 'http://elasticsearch02:9200/_template/template_access_log?pretty'
  curl -XPUT 'http://elasticsearch02:9200/access-log-01?pretty'
  curl -XGET 'http://elasticsearch02:9200/access-log-01?pretty'
复制代码

index template，多是这样子的，就是你可能会常常建立不一样的索引，好比说商品，分红了多种，每一个商品种类的数据都很大，可能就是说，一个商品种类一个索引，可是每一个商品索引的设置是差很少的，因此干脆能够搞一个商品索引模板，而后每次新建一个商品种类索引，直接绑定到模板，引用相关的设置

2 索引统计

indice stat对index上发生的不一样类型的操做都提供了统计。这个api提供了index level的统计信息，不过大多数统计信息也能够从node level获取。这里包括了doc数量，index size，segment的内存使用量，merge，flush，refresh，translog等底层机制的统计信息。
```
curl -XGET 'http://elasticsearch02:9200/twitter/_stats?pretty'
复制代码
```

2.1 segment 统计

查看low level的lucene的segment信息，能够用来查看shard和index的更多的信息，包括一些优化信息，由于delete而浪费的数据空间等等。

curl -XGET 'http://elasticsearch02:9200/twitter/_segments?pretty'
  
  {
      ...
          "_3": {
              "generation": 3,
              "num_docs": 1121,
              "deleted_docs": 53,
              "size_in_bytes": 228288,
              "memory_in_bytes": 3211,
              "committed": true,
              "search": true,
              "version": "4.6",
              "compound": true
          }
      ...
  }
复制代码

_3，是segment的名称，这个名称跟这个segment files的文件名有关系，一个segment的全部文件都是用这个名称开头的
generation：每次新生成一个segment，就会递增一个数值，segment名称也就是这个数值
num_docs：在这个segment中存储的没有被删除的document的数量 deleted_docs：在这个segment中存储的被删除的document数量，这个数值是无所谓的，由于每次segment merge的时候都会删除这些document
size_in_bytes：这个segment占用的磁盘空间
memory_in_bytes：segment须要将一些数据缓存在内存中，这样搜索性能才能更高，这个数值就是segment占用的内存的空间大小
committed：segment是否被sync到磁盘上去了，commit/sync的segment能够确保数据不会丢失，可是即便这个值是false也没关系，由于数据同时被存储在了translog里面，es进程重启的时候，是能够重放translog中的日志来恢复数据的
search：这个segment能不被搜索，若是是false的话，可能这个segment已经被sync到磁盘上，可是尚未进行refresh，因此不能被搜索
version：lucene的版本号
compound：若是是true的话，意味着lucene将这个segment全部的文件都merge成了一个文件，进而能够节省file descriptor的消耗

2.2 shard存储信息统计

查询索引shard copy的存储信息，能够看到哪些节点上有哪些shard copy，shard copy的allocation id，每一个shard copy的惟一标识，包括打开索引的时候遇到的报错。默认状况下，会显示至少有一个未分配的copy的shard，若是cluster health是yellow，会显示至少有一个未分配的replica的shard，当cluster health是red，会显示有未分配的primary的shard。可是用status=green能够看到每一个shard的信息。

curl -XGET 'http://elasticsearch02:9200/twitter/_shard_stores?pretty'
  curl -XGET 'http://elasticsearch02:9200/twitter/_shard_stores?status=green&pretty'

  {
      ...
     "0": { 
          "stores": [ 
              {
                  "sPa3OgxLSYGvQ4oPs-Tajw": { 
                      "name": "node_t0",
                      "transport_address": "local[1]",
                      "attributes": {
                          "mode": "local"
                      }
                  },
                  "allocation_id": "2iNySv_OQVePRX-yaRH_lQ", 
                  "legacy_version": 42, 
                  "allocation" : "primary" | "replica" | "unused", 
                  "store_exception": ... 
              },
              ...
          ]
     },
      ...
  }
复制代码

0：shard id
stores：shard的每一个copy的store信息
sPa3OgxLSYGvQ4oPs-Tajw：node id，持有一个copy的node信息
allocationi_id：copy的allocationid
allocation：shard copy的角色

2.4 clear cache

curl -XPOST 'http://elasticsearch02:9200/twitter/_cache/clear?pretty'，这个命令能够清空全部的缓存
复制代码

2.5 flush

flush API可让咱们去强制flush多个索引，索引flush之后，就会释放掉这个索引占用的内存，由于会将os cache里的数据强制fsync到磁盘上去，同时还会清理掉translog中的日志。默认状况下，es会不定时自动触发flush操做，以便于及时清理掉内存。POST twitter/_flush，这条命令便可。
flush命令能够接受下面两个参数，wait_if_going，若是设置为true，那么flush api会等到flush操做执行完之后再返回，即便须要等待其余的flush操做先完成。默认的值是false，这样的话，若是有其余flush操做在执行，就会报错；force，若是没有必要flush的话，是不会强制一个flush
```
curl -XPOST 'http://elasticsearch02:9200/twitter/_flush?pretty'
复制代码
```

2.6 refresh

refresh用来显式的刷新一个index，这样可让这个refresh以前执行的全部操做，都处于可见的状态。POST twitter/_refresh
```
curl -XPOST 'http://elasticsearch02:9200/twitter/_refresh?pretty'
复制代码
```

2.7 force merge

force merge API能够强制合并多个索引文件，能够将一个shard对应的lucene index的多个segment file都合并起来，能够减小segment file的数量。POST /twitter/_forcemerge。
```
curl -XPOST 'http://elasticsearch02:9200/twitter/_forcemerge?pretty'
复制代码
```

3 短路器

es有不少的断路器，也就是circuit breaker，能够用来阻止各类操做致使OOM内存溢出。每一个断路器都有一个限制，就是最多可使用多少内存。此外，还有一个父断路器指定了全部断路器最多可使用多少内存。

父短路器

indices.breaker.total.limit，能够配置父短路器的最大内存限制，默认是jvm heap内存的70%
fielddata短路器

field data短路器能够估算每个field的全部数据被加载到内存中，须要耗费多大的内存。这个短路器能够组织field data加载到jvm内存时发生OOM问题。默认的值是jvm heap的60%。indices.breaker.fielddata.limit，能够用这个参数来配置。indices.breaker.fielddata.overhead，能够配置估算因子，估算出来的值会乘以这个估算因子，留一些buffer，默认是1.03。
request circuit breaker

request circuit breaker会阻止每一个请求对应的一些数据结构形成OOM，好比一个聚合请求可能会用jvm内存来作一些汇总计算。indices.breaker.request.limit，最大是jvm heap的60%。indices.breaker.request.overhead，估算因子，默认是1.
in flight request circuit breaker

flight request circuit breaker能够限制当前全部进来的transport或http层的请求超出一个节点的内存总量，这个内存的使用量就是请求本身自己的长度。network.breaker.inflight_requests.limit，默认是jvm heap的100%。network.breaker.inflight_requests.overhead，估算因子，默认是1.
script compilation circuit breaker

这个短路器能够阻止一段时间内的inline script编译的数量。script.max_compilations_per_minute，默认是1分钟编译15个。

4 缓存优化

fielddata cache
在对field进行排序或者聚合的时候，会用到这个cache。这个cache会将全部的field value加载到内存里来，这样能够加速排序或者聚合的性能。可是每一个field的field data cache的构建是很成本很高昂的，所以建议给机器提供充足的内存来保持fielddata cache。
```
indices.fielddata.cache.size，这个参数能够控制这个cache的大小，能够是30%这种相对大小，或者是12GB这种绝对大小，默认是没有限制的。
复制代码
```
实际上是对分词后的field进行排序或者聚合的时候，才会使用fielddata这种jvm内存数据结构。若是是对普通的未分词的field进行排序或者聚合，其实默认是用的doc value数据结构，是在os cache中缓存的。
query cache
用来缓存query的结果，每一个node都有一个query cache，使用的是LRU策略，会自动清理数据。可是query cache仅仅会对那些filter后的数据进行缓存，对search后的数据是不会进行缓存的。若是只是要根据一些field进行等值的查询或过滤，那么用filter操做，性能会比较好，query cache
```
indices.queries.cache.size，控制query cache的大小，默认是jvm heap的10%。
复制代码
```
index buffer
用来存储最新索引的的document。若是这个buffer满了以后，document就会被写入一个segment file，可是此时实际上是写入os cache中，没有用fsync同步到磁盘，这就是refresh过程，写入os cache中，就能够被搜索到了。而后flush以后，就fsync到了磁盘上。
```
indices.memory.index_buffer_size，控制index buffer的大小，默认是10%。
  indices.memory.min_index_buffer_size，buffer的最小大小，默认是48mb。
复制代码
```
index buffer，增删改document，数据先写入index buffer，写到磁盘文件里面去，不可见的，refresh刷入磁盘文件对应的os cache里面，还有translog一份数据
对于分布式的搜索请求，相关的shard都会去执行搜索操做，而后返回一份结果集给一个coordinate node，由那个coordinate node来执行最终的结果合并与计算。shard request cache会缓存每一个shard的local result。那么对于频繁请求的数据，就能够直接从cache中获取了。与query cache不一样的是，query cache只是针对filter的，可是shard request cache是针对全部search和聚合求的。
shard request cache
默认状况下，shard request cache仅仅会针对size=0的搜索来进行缓存，仅仅会缓存hits.total，聚合结果等等汇总结果，而不会缓存搜索出来的hits明细数据。cache是很智能的，若是cache对应的doc数据被refresh，也就是修改了，那么cache就会自动失效。若是cache满了的话，也会自动用LRU算法来清理掉cache中的数据。

能够手动来启用和禁用cache：

PUT /my_index
  {
    "settings": {
      "index.requests.cache.enable": false
    }
  }
  
  在每一个request中也能够手动启用或禁用cache：
  
  GET /my_index/_search?request_cache=true
  {
    "size": 0,
    "aggs": {
      "popular_colors": {
        "terms": {
          "field": "colors"
        }
      }
    }
  }
复制代码

可是默认对于size>0的request的结果是不会被cache的，即便在index设置中启用了request cache也不行。只有在请求的时候，手动加入reqeust cache参数，才能够对size>0的请求进行result cache。缓存用的key，是完整的请求json，所以每次请求即便json中改变了一点点，那么也没法复用上次请求的request cache结果。
```
indices.requests.cache.size，能够设置request cache大小，默认是1%
  GET /_stats/request_cache?human，监控request cache的使用
  若是是search，默认是不缓存的，除非你手动打开request_cache=true，在发送请求的时候
  若是是aggr，默认是缓存的，不手动打开request_cache=true，也会缓存聚合的结果
复制代码
```

索引恢复

indices.recovery.max_bytes_per_sec，每秒能够恢复的数据量，默认是40mb
复制代码

5 索引管理高级特性

5.1 merge

es里的一个shard，就是一个lucene index，每一个lucene index都是由多个segment file组成的。segment file负责存储全部的document数据，并且segment file是不可变的。一些小的segment file会被merge成一个大的segment file，这样能够保证segment file数量不会膨胀太多，并且能够将删除的数据实际上作物理删除。merge过程会自动进行throttle限流，这样可让merge操做和节点上其余的操做都均衡使用硬件资源。

merge scheduler会控制merge的操做何时执行，merge操做会在一些独立的后台线程中执行，若是达到了最大的线程数量的话，那么merg操做就会等待有空闲的线程出来再去执行。

index.merge.scheduler.max_thread_count，这个参数能够控制每次merge操做的最大线程数量，
  默认的公式是Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))，
  对于SSD来讲，表现是很好的。可是若是咱们使用的是机械硬盘，建议将这个数量下降为1。
复制代码

5.2 translog

对lucene的磁盘持久化，能够经过一次lucene commit来提交，是一个很重的过程，因此是不可能在每次插入或者删除操做事后来执行的。因此在上一次提交和下一次提交之间的数据变动，都是在os cache中的，若是机器挂掉，可能致使数据丢失。为了不这种数据丢失，每一个shard都有一个transaction log，也就是translog，来写入write ahead log，预写日志。任何写入数据都会同时被写入translog。若是机器挂掉了，那么就能够重放translog中的日志来恢复shard中的数据。
一次es flush操做，都会执行一次lucene commit，将数据fsync到磁盘上去，同时清空translog文件。在后台会自动进行这个操做，来确保translog日志不会增加的太过于巨大，这样的话重放translog数据来恢复，才不会太慢。
```
index.translog.flush_threshold_size，这个参数能够设置os cache中数据达到多大的时候，要执行一次flush，默认是512mb。
复制代码
```

此外，默认状况下，es每隔5秒钟会在每一个增删改操做结束以后，对translog进行一次fsync操做，

可是要求index.translog.durability设置为async或者request（默认）。
  es只有在primary和每个replica shard的translog fsync以后，才会对增删改操做返回的状态中显示为success。

  index.translog.sync_interval：设置index.translog.durability=fsync操做时，translog被fsync到磁盘的频率，默认是5秒
  index.translog.durability：是否要在每次增删改操做以后，fsync translog。
  
  默认是request，每次写请求以后，都会fsync translog，这样的话，即便机器宕机，可是只要是返回success的操做，
  就意味着translog被fsync到磁盘了，就能够保证数据不丢失。
  
  async，在后台每隔必定时间来fsync translog，默认是5秒，机器宕机的时候，可能致使5秒的数据丢失，
  可能有5秒钟的数据，数据自己是停留在os cache中的，数据对应的translog也停留在os cache中，
  5秒才能将translog从os cache输入磁盘
复制代码

5.3 translog损坏怎么办

若是硬盘损坏，可能致使translog出现损坏，es会自动经过checksum来捕获到这个问题，此时es就会认为这个shard故障了，并且禁止将shard分配给这个node，同时会尝试从其余replica shard来恢复数据。若是没有replica数据的话，那么用户能够手动经过工具来恢复，使用elasticsearch-translog便可。要注意的是，elasticsaerch-translog工具不能在elasticsearch运行的时候来使用，不然咱们可能丢失数据。
```
bin/elasticsearch-translog truncate -d /var/lib/elasticsearchdata/nodes/0/indices/P45vf_YQRhqjfwLMUvSqDw/0/translog/
  
  Checking existing translog files
复制代码
```

6 总结

生产部署还有不少工做要作，本文从初级思路切入，进行了问题的整合。

本套技术专栏做者（秦凯新）专一于大数据及容器云核心技术解密，具有5年工业级IOT大数据云平台建设经验，可提供全栈的大数据+云原平生台咨询方案，请持续关注本套博客。QQ邮箱地址：1120746959@qq.com，若有任何学术交流，可随时联系

秦凯新