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

本套技术专栏作者(秦凯新)专注于大数据及容器云核心技术解密,具备5年工业级IOT大数据云平台建设经验,可提供全栈的大数据+云原生平台咨询方案,请持续关注本套博客。QQ邮箱地址:[email protected],如有任何学术交流,可随时联系。

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的副本开始进行复制以后,或者是请求超时以后,返回一个响应消息,类似下面这样的。

  • 其中acknowledged表明了这个索引有没有创建成功,shards_acknowledged表明了每个primary shard有没有足够数量的replica开始进行复制了。有可能这两个参数会为false,但是索引依然可以创建成功。因为这些参数仅仅是表明在请求超时之前,那两个行为有没有成功,也有可能请求超时了,在超时前都没成功,但是超时后在es server端还是都执行了。

  • 如果acknoledged是false,那么就可能是超时了,此时接受到响应消息的时候,cluster state都还没变更,没有加入新创建的index,但是也许之后还是会创建这个index。如果shards_acknowledged是false,那么可能在primary shard进行副本copy之前,就timeout了,但是此时也许index创建成功了,而且cluster state已经加入了新创建的index。

      {
          "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会更少。

  • 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。

  • 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上,shard2、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邮箱地址:[email protected],如有任何学术交流,可随时联系

秦凯新

转载于:https://juejin.im/post/5d3dbb57f265da1b6a34dd2c

你可能感兴趣的:(运维,大数据,数据结构与算法)