Elasticsearch-21.文档分布式存储和分片及其生命周期和剖析分布式查询及相关性评分

Elasticsearch

文档分布式存储

文档存储在分片上

• 文档会存储在具体的某个主分片和副本分片上:例如文档1，会存储在PO和RO分片.上

• 文档到分片的映射算法

  • 确保文档能均匀分布在所用分片.上，充分利用硬件资源，避免部分机器空闲，部分机器繁忙
  • 潜在的算法

    • 随机/ Round Robin。当查询文档1,分片数很多，需要多次查询才可能查到文档1

    • 维护文档到分片的映射关系，当文档数据:量大的时候，维护成本高

    • 实时计算，通过文档1,自动算出，需要去那个分片.上获取文档

文档到分片的路由算法

• shard = hash(_ routing) % number of .primary_ _shards
  • Hash算法确保文档均匀分散到分片中
  • 默认的_ _routing 值是文档id
  • 可以自行制定routing数值， 例如用相同国家的商品，都分配到指定的shard
  • 设置Index Settings后，Primary 数，不能随意修改的根本原因

更新一个文档

删除一个文档

本节知识点回顾

1. 可以通过设置Index Settings, 控制数据的分片
2. Primary Shard的值不能修改，修改需要重新Index。默认值是5，从7开始，默认值改为1
3. 索引写入数据后，Replica 的值可以修改。增加副本，可提高大并发下的读取性能
4. 通过控制集群的节点数，设置Primary Shard数，实现水平扩展

分片及其生命周期

分片的内部原理

• 什么是ES的分片
  - ES中最小的工作单元/是一个Lucene的Index
• 一些问题:
  • 为什么ES的搜索是近实时的(1秒后被搜到)
  • ES如何保证在断电时数据也不会丢失
  • 为什么删除文档，并不会立刻释放空间

倒排索引不可变性

• 倒排索引采 用Immutable Design，一旦生成，不可更改

• 不可变性， 带来了的好处如下:

  • 无需考虑并发写文件的问题，避免了锁机制带来的性能问题
  • 旦读入内核的文件系统缓存，便留在哪里。只要文件系统存有足够的空间，大部分请求就会直接请求内存，不会命中磁盘，提升了很大的性能缓存容易生成和维护/数据可以被压缩

• 不可变更性，带来了的挑战:如果需要让一个新的文档可以被搜索，需要重建整个索引。

Lucene Index

什么是Refresh

什么是Transaction Log

什么是Flush

Merge

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

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

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

  • POST my_ index/ forcemerge

知识点回顾

• Shard 和Lucene Index
  • Index Buffer / Segment / Transaction Log
• Refresh & Flush
• Merge

剖析分布式查询及相关性评分

分布式搜索的运行机制

• Elasticsearch 的搜索，会分两阶段进行
  • 第一阶段一 Query
  • 第二阶段- Fetch .
• Query- -then-Fetch

Query阶段

Fetch阶段

Query Then Fetch 潜在的问题

• 性能问题

  • 每个分片，上需要查的文档个数= from + size
  • 最终协调节点需要处理: number_ of shard * ( from+size )
  • 深度分页

• 相关性算分

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

解决算分不准的方法

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

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

• 使用 DFS Query Then Fetch

  • 搜索的URL 中指定参数“search?search_ type=dfs query _then. _fetch”

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

相关性算分问题Demo

• 写入 3条记录“Good”/“Good morning”/“good morning everyone’
• 使用1个主分 片测试，Good 应该排在第一，Good DF数值应该是3
• 和20 个主分片，测试
• 当多个个主分片时，3个文档的算分都-样。可 以通过Explain API进行分析
• 在3个主分片上 执行DFS Query Then Fetch,结果和一个分片上一致

Demo

DELETE message
PUT message
{
  "settings": {
    "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": {
    "match_all": {}
  }
}


POST message/_search
{
  "explain": true,
  "query": {
    "term": {
      "content": {
        "value": "good"
      }
    }
  }
}


POST message/_search?search_type=dfs_query_then_fetch
{

  "query": {
    "term": {
      "content": {
        "value": "good"
      }
    }
  }
}

本节知识点回顾

• 学习了 分布式搜索Query then Fetch的机制
  • Why/How
• Query Then Fetch带来的潜在问题
  • 深度分页: 使用Search After
  • 算分不准:设置1个主分片/数据量大时，只需要保证文档平均分布/ DFS Query then Fetch