es搜索核心与实战Day07

es搜索核心与实战Day07

1.文档到分片的路由算法

• shard=hash(_rounting)%number_of_primary_shards

​ Hash算法确保文档均匀分散到分片中

​ 默认的_routing 值是文档id

​ 可以自行制定routing数值，例如用相同国家的商品，都分配到指定的shard

​ 设置Index Setting后，Primary数，不能随意修改的更本原因

更新一个文档

2.分片及其生命周期

a.倒排索引的不可变性

• 倒排索引采用Immutable Design，一旦生成，不可更改
• 不可变性，带来了的好处如下：

​ 1.无需考虑并发写文件的问题，避免了锁机制带来的性能问题

​ 2.一旦读入内核的文件系统缓存，便留在哪里。只要文件系统存有足够大的空间，大部分请求就会直接请求内存，不会命中磁盘，提升了很大的性能

​ 3.缓存容易生成和维护/数据可以被压缩

3.什么是Refresh

• 将Index buffer写入Segment的过程叫Refresh。Refresh不执行fsync操作
• Refresh频率：默认1秒发生一次，可通过index.refresh_interval配置。Refresh后，数据就可以被搜索到。这也是为什么Elasticsearch被称为近实时搜索
• 如果系统有大量的数据写入，那就会产生很多的Segment
• Index Buffer被占满时，会触发Refresh，默认值是JVM的10%

4.什么是Transaction Log

• Segment写入磁盘的过程相对耗时，借助文件系统缓存，Refresh时，先将Segment写入缓存以开放查询
• 为了保证数据不会丢失。所以在Index文档时，同时写入Transaction Log，高版本开始，Transaction Log默认落盘。每个分片有一个Transaction Log
• 在ES Refresh时，Index Buffer被清空，Transaction Log不会清空

5.什么是Flush

• ES Flush&Lucene Commit

​ 调用Refresh，Index Buffer清空并且Refresh

​ 调用fsync，将缓存中的Segments写入磁盘

​ 清空（删除）Transaction Log

​ 默认30分钟调用一次

​ Transaction Log满（默认512MB）

6.Merge

• Segment很多，需要被定期合并

​ 减少Segments/删除已经删除的文档

• ES和Lucene会自动进行Merge操作

​ POST my_index/_forcemerge

7.剖析分布式查询及相关性算分

1.Query阶段

• 用户发出搜索请求到ES节点。节点收到请求后，会以Coordinating节点的身份在6个主妇分片中随机选择3个分片，发送查询请求
• 被选中的分片执行查询，经行排序。然后，每个分片都会返回From+Size个排序后的文档Id和排序值给Coordinating节点

2.Fetch阶段

• Coordinating Node会将Query阶段，从每个分片获取的排序后的文档Id列表，重新进行排序。选取From到From+Size个文档的Id
• 以multi get请求的方式，到相应的分片获取详细的文档数据

3.Query Then Fetch潜在的问题

• 性能问题

​ 每个分片上需要查的文档个数=from+size

​ 最终协调点需要处理：number_of_shard*(from+size)

​ 深度分页

• 相关性算分

  每个分片都基于自己的分片上的数据经行相关度计算。这会导致打分偏离的情况，特别是数据很少时。相关性算分之间是相互独立。当文档总数很少的情况下，如果主分片大于1，主分片数越多，相关性算分会越不准

4.解决算分不准的方法

• 数据量不大的时候，可以将主分片数设置为1

​ 当数据量足够大时侯，只要保证文档均匀分散在各个分片上，结果一般就不会出现偏差

• 使用DFS Qurery Then Fetch

​ 搜索的URL中指定参数“_search？search_type=dfs_query_then_fetch”

​ 到每个分片把个分片的词频和文档频率进行搜集，然后完整的进行一次相关性算分，耗费更多的CPU和内存，执行性能低下，一般不建议使用

POST message/_doc
{
  "content":"good"
}

POST message/_doc
{
  "content":"good morning everyone"
}

POST message/_doc
{
  "content":"good morning"
}

POST message/_search
{
  "query": {
    "term": {
      "content": {
        "value": "good"
      }
    }
  }
}
DELETE message
PUT message
{
  "settings": {
    //20个分片算分一样
    "number_of_shards": 20
  }
}
GET message

POST message/_doc?routing=1
{
  "content":"good"
}
POST message/_doc?routing=2
{
  "content":"good morning"
}
POST message/_doc?routing=3
{
  "content":"good morning everyone"
}


POST message/_search
{
  "explain": true,
  "query": {
    "term": {
      "content": {
        "value": "good"
      }
    }
  }
}
//type  dfs_query_then_fetch
POST message/_search?search_type=dfs_query_then_fetch
{
 "query": {
    "term": {
      "content": {
        "value": "good"
  
  }
  }
}
}

8.排序及DocValues&Fielddata

1.排序

//单字段排序
POST /kibana_sample_data_ecommerce/_search
{
  "size":5,
  "query": {
    "match_all": {
      
    }
  },
  "sort": [
    {
      "order_date": {
        "order": "desc"
      }
    }
  ]
}
//多字段排序
POST /kibana_sample_data_ecommerce/_search
{
  "size":5,
  "query": {
    "match_all": {
      
    }
  },
  "sort": [
   {
     "order_date": {"order":"desc"}},
    {"_doc":{"order": "asc" }},
    {"_score":{"order": "desc"}}
  ]
}

//对text排序报错
POST /kibana_sample_data_ecommerce/_search
{
  "size":5,
  "query": {
    "match_all": {
      
    }
  },
  "sort": [
    {
      "customer_full_name": {
        "order": "desc"
      }
    }
  ]
}
//打开text的 fielddata
PUT kibana_sample_data_ecommerce/_mapping
{
  "properties":{
    "customer_full_name":{
     "type":"text",
     "fielddata":true,
     "fields":{
       "keyword":
       {
         "type":"keyword",
         "ignore_above":256
       }
     }
    }
  }
}

2.排序的过程

• 排序是针对字段原始内容进行的。倒排索引无法发挥作用
• 需要用到正排索引。通过文档Id和字段快速得到字段原始内容
• Elasticseach有两种实现方法

​ 1.Fielddata

​ 2.Dov Values（列式存储，对Text类型无效）

关闭Dov Values

• 默认启用，可以通过Mapping设置关闭

增加索引的速度/减少磁盘空间

• 如果重新打开，需要重建索引
• 什么时候需要关闭