elasticSearch5-原理解析

一：近实时搜索原理

 

先认识几个基本概念：

1、segment

es基本存储单元是shard，index分散在多个shard上。 而每个shard由多个段-segment组成，每次创建一个新Document(一条新数据)，就会归属于一个新的segment。 删除数据时，也不会直接删除当前segment，只是标记为已删除状态，后续在合适时机删除。

2、translog

操作日志，用来记录操作动作，防止数据丢失。 每个shard中对应一个translog文件。

3、commit

提交，意味着将多个segment，合并成新的更大的segment，并刷入磁盘。

4、refresh

es索引数据时，先是写入到内存buffer中，默认1s执行一次refresh操作，刷新到一个新的segment中，在segment中数据才具备被检索的结构，才能被查询。当写入segment后，会清空内存buffer。 所以近实时搜索通常指的是： 写入数据1s后才能被检索。

当然，可以改变默认时长（时长为-1代表关闭刷新）：

PUT /mytest/_settings 
{
  "refresh_interval": "20s"
}

或者直接调用refresh的api：

POST /_refresh    刷新所有索引

POST /mytest/_refresh     刷新某个索引

PUT /mytest/_doc/1?refresh=true      //刷新具体文档数据
{
  "test": "test"
}

5、flush

数据清洗，将内存缓冲区、segments中、translog等全部刷盘，成功后清空原数据和translog。

默认每30分钟执行一次，或者translog变大超过设定值后触发。

commit需要一个fsync同步操作来保证数据物理的被成功刷盘，假如每一个写操作都这样，那么性能会大大下降。 es在内存buffer与磁盘之间，引入了文件系统缓存。 refresh将数据刷到新的segment，这些segment其实是先存在于文件系统缓存，后续再刷盘。

整体流程：

 当es收到写请求后，数据暂时写入内存buffer，并添加translog。默认1s后，refresh数据到file system cache，并清空内存buffer。 30分钟后，执行flush刷数据到磁盘（tanslog大小超过设定阈值也会执行flush）。

分片默认会30分钟执行一次flush，也可手动调用api:

POST /mytest/_flush        刷新某一个索引

POST /_flush?wait_for_ongoin         刷新所有索引直到成功后返回

（手动调用flush情况很少，不过要关闭索引或者重启节点时，最好执行一下。因为es恢复索引或者重新打开索引时，它必须要先把translog里面的所有操作给恢复，所以也就是说translog越小，recovery恢复操作就越快）

上面说了数据的流程，现在看看translog是如何工作的？

当数据被refresh期间，新的操作日志会继续追加到translog，默认每次写请求（如 index, delete, update, bulk）都会刷盘。 这样会有很大的性能问题，所以如果能容忍5s内的数据丢失情况，还是使用每5s异步刷盘的方式。

配置如下：

PUT /mytest/_settings 
{
  "index.translog.durability": "async",
  "index.translog.sync_interval": "5s"
}

要保证完全可靠，还是使用默认配置：

PUT /mytest/_settings 
{
  "index.translog.durability": "request"
}

流程图： 

二： 段合并机制 

 在索引数据过程中，每一次的refresh都会创建新的segment，数量会越来越多，影响内存和CPU运行，查询也会在多个段中，影响性能。

所以，es会使用一定的策略，将segment不断的合并为更大的segment，最终被flush刷新到磁盘。

当然，合并会消耗大量IO和CPU，所以要对执行归并任务的线程作限速控制，默认是20MB，如果磁盘转速高，或者SSD等，可以适当调高：

PUT /_cluster/settings 
{ 
  "persistent" : 
  { 
    "indices.store.throttle.max_bytes_per_sec" : "100mb"
  } 
}

线程数也可以调整，比如为CPU核心数的一半：

index.merge.scheduler.max_thread_count

下面来看看合并是依据什么策略来执行的：

主要有以下几条：

index.merge.policy.floor_segment     默认 2MB ，小于这个大小的 segment ，优先被归并。

index.merge.policy.max_merge_at_once      默认一次最多归并 10 个 segment

index.merge.policy.max_merge_at_once_explicit       默认 optimize 时一次最多归并 30 个

segment 。

index.merge.policy.max_merged_segment      默认 5 GB ，大于这个大小的 segment ，不用参与归 并， optimize 除外。

 optimize api：

optimize代表手动强制执行合并，它可以通过参数max_num_segments指定，把某个index在每个分片上的segments最终合并为几个（最小是1个），比如日志是按天创建索引存储，可以合并为一个segment，查询就会很快。

POST /logstash-2022-10/_optimize?max_num_segments=1

三：数据的写一致性如何保证

ES如何才能成功写入数据：

5.0版本以前，使用参数consistency来保证，consistency有三个值可选：

one：只要有一个primary shard是可用的即可

all：要求所有的primary shard和replica shard都是可用的

quorum：默认选项。满足可用的shard数量才可写入成功。  它的计算方式是：

quorum  =  int（（主分片总数 + 单个主分片的副本数）/ 2) + 1

5.0之后：

wait_for_active_shards:

指定多少个分片的数据都成功写入，才算成功。 默认是1，代表主分片成功即可（一条数据肯定只存在于一个主分片）。  最大值是 1+number_of_replicas，代表主分片和所有副本分片都成功。

timeout:

在多少时间内没有成功，就返回失败。 结合上面 ，只要在timeout时间内， wait_for_active_shards数满足都能成功（比如超时时间内，shard从不可用到可用，最终也会成功）。

 wait_for_active_shards可在索引的setting属性中全局设置，也可对某个document设置：

put /mytest/_doc/1?wait_for_active_shards=2&timeout=10s

{

"name" : "xiao mi"

}

四：query机制

es的SearchType有两个选项：

 query then fetch（默认方式）：搜索时分两步进行：

1、向所有的shard发出请求，各shard只返回文档id和排名相关信息（即文档的得分，该分值只是在当前shard中比较后统计出来的），然后在请求节点上，对所有返回的文档按分值重新排序，取前size个文档id。

2、拿着id去相关shard获取完整的document信息(数据)。

优点：size数量和用户要求的一致。

缺点：排序不准确，因为不是全局打分排序。

DFS  query then fetch：

在上面的步骤之前，多了一个DFS步骤： 先对所有的shard发送请求，把所有shard中的词频和文档频率等进行全局打分，再执行上面的操作。

优点：返回的size和排序都是准确的

缺点：性能会差一些。

五：写和读的流程

写操作：

客户端选择某一个node发送请求（如果是协调节点，从新路由到对应的node），由primary shard进行处理，并同步replica shard，当shard数满足wait_for_active_shards后返回成功。

读操作：

客户端选择某一个node发送请求（如果是协调节点，从新路由到相关node： 含有primary 或者 replica的都可以）。  根据上面SearchType执行query的机制。

六：DocValues

es的倒排索引， 可以根据条件很快定位到是哪个document（能拿到doc_id），如上图，但此时我们并不知道每个doc里面的具体内容是什么，如果需要做排序聚合等，我们不可能把所有doc的内容都查出来再做，那样性能会非常差，因此倒排索引不适合聚合排序（从上面的query机制我们知道，查询是先获取id和得分，排序后取出size个，最终根据id去对应的shard上获取完整的doc内容，所以在最终获取完整doc前，肯定要先做排序）。

如果在获取数据之前，有一种索引中可以知道doc的值，那就可以做排序了。DocValues就是这样的一种正排索引，它存的是doc与对应词项的关系：

在创建索引的mapping映射时，doc_values属性默认为true开启，也可以在不需要的字段中指定为false，则该字段不能用作聚合排序。

PUT /mytest
{
  "settings": {
    "number_of_shards": 3, 
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "name":{
        "type": "keyword",
        "doc_values": false
      },
      "age":{
        "type": "keyword"
      }
    }
  }
}

对于不需要聚合排序的字段，就禁用掉，减少索引成本。

DocValues与倒排索引是同时创建的，也是同样基于segment的操作，最终会序列化到磁盘。 

对于es来说，就是运用倒排索引搜索，并且用DocValues来实现聚合排序，所以es快。当然，对于快es在很多方面都做了细节的体现，比如filter查询就比普通的query快。

七：filter

 filter使用bitset机制和caching机制来提高搜索效率。

bitset：

先根据条件在倒排索引中查找字符串，获取到document list，然后根据list，对每个搜索的结果构建一个bitset（二进制数组），来表示哪些doc中存在（0表示不存在，1表示存在）。

如下：

  如果搜索date为2020-02-02，那么对该条件构建出来的bitset为： [0,1,1]表示在doc2和doc3中存在。

如果多个条件，那么就会构建多个bitset，然后先过滤稀疏的bitset（就是1比较少的数组），先过滤掉大多数数据，如再增加一个条件：

userId=4，创建的bitset为： [0,1,0]。那么会先过滤userId的bitset，再去和date的bitset一起过滤，最终返回doc2。

caching: 

有了bitset之后，最好还能将其缓存起来。 这样避免同一个条件每一次都去扫描索引，频繁创建bitset ，以便达到最佳性能。  什么情况下会缓存bitset呢？

1、在最近使用的256个filter中，如果某个filter超过一定的次数，它对应的bitset就会被缓存。 该次数不固定，使用越多越容易被缓存。

2、我们知道，一个document就对应一个segment，然后segment会逐步合并为更大的segment。   caching机制对于小的segment的情况是不缓存的，因为很快就会被合并。

小segment比如： document记录数少于1000，或者大小少于index总大小的3%。

3、当有写操作时，也会更新缓存。

filter比query快，就是因为它不要聚合排序，不需要去关系分值，只需要做简单的过滤，并使用了缓存。 

八：精准度控制

boost 

es搜索的时候，会根据词项在文档中的匹配度打分。我们可以通过boost来修改权重（默认是1），比如想要name中含有java的doc分高一点，排在前面：

GET /mytest/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "term": {
            "name": {
              "value": "java",
              "boost": 3
            }
          }
        },
        {
          "term": {
            "name": {
              "value": "elastic",
              "boost": 2
            }
          }
        },
        {
          "term": {
            "name": {
              "value": "mysql"
            }
          }
        }
      ]
    }
  }
}

dis_max

除了boost，有一种情况，如下：

GET /mytest/_search
{
  "query": {
    "bool": {
      "should": [
        {"match": {
          "title": "java solution"
          }
        },
        {
          "match": {
            "content": "java solution"
          }
        }
      ]
    }
  }
}

上面的查询，要求title中有java solution或者content中有java solution能被查出来，此时：

文档1可能在title和content字段都有java一词， 针对两个字段的得分分别是：1和1.3，那么文档1的得分为2.3。

文档2的title中一个词没匹配到，得分0， content中有java solution，完全匹配，得分1.5，文档2的得分为1.5。

然而，文档2更符合预期，但是它的分却比较低，查询不会被优先返回，这时候就需要使用dis_max： 不管有多少个字段匹配，取分值最高的字段得分，作为文档的得分。

GET /mytest/_search
{
  "query": {
    "dis_max": {
      "queries": [
        {
          "match": {
          "title": "java solution"
          }
        },
        {
          "match": {
            "content": "java solution"
          }
        }
      ]
    }
  }
}

九：deep paging性能问题 和 解决方案

深度分页问题：

es默认使用from+size的方式分页，类似于mysql的limit。 假如from：990 ，size：10， 那么es会所有shard上各取出1000条数据，返回给协调节点，然后从这1w条数据中根据分值找出最符合的10条（从之前的query流程知道，这里只是返回了文档id和score的值，但是数据量也很大了），假如查询更多，更深，量更大呢？显然性能是很差的！

es有个设置index.max_result_window，默认10000。 代表查询的数据，超过符合条件的第1w条，就不支持。 如果es性能好，可以根据业务需要改大。 当然了，也不是很推荐from+size的方式做深度查询。 这时候要从业务考虑，是不是真的需要查询很后面的数据。 如果确实需要，则要换分页方式：

深度分页方式：

scoll:

scoll分页分两步，第一步把所有初始化，把所有符合条件的数据缓存，形成快照。