Elasticsearch杂记

分片

• 主分片，用以解决数据水平扩展的问题。通过主分片，可以将数据分布到集群内的所有节点之上。

  • 一个分片是一个运行的Lucene的实例
  • 主分片数在索引创建时指定，后续不允许修改，除非Reindex

• 副本，用以解决数据高可用的问题。分片是主分片的拷贝

  • 副本分片数，可以动态调整
  • 增加副本数，还可以在一定程度上提高服务的可用性（读取的吞吐）

如何设计分片数

• 当分片数 > 节点数时

  • 一旦集群中有新的数据节点加入，分片就可以自动进行分配
  • 分片在重新分配时，系统不会有downtime

• 多分片的好处：一个索引如果分布在不同节点，多个节点可以并行执行

  • 查询可以并行执行
  • 数据写入可以分散到多个机器

分片过所带来的副作用

• Shard是ElasticSearch实现集群水平扩展的最小单位

• 过多设置分片数会带来一些潜在的问题

  • 每个分片是一个Lucene的索引，会使用机器的资源。过多的分片会导致额外的性能开销

    • Lucene Indices / File descriptors / RAM / CPU
    • 每次搜索的请求，需要从每个分片上获取数据
    • 分片的Meta信息由Master节点维护。过多，会增加管理的负担。经验值，控制分片总数在10W以内

分片的设定

• 对于生产环境中分片的设定，需要提前做好容量规划

  • 分片数设置过小

    • 导致后续无法增加节点实现水平扩展
    • 单个分片的数据量太大，导致重新分配耗时

  • 分片数设置过大，7.0开始，默认主分片设置成1，解决了over-sharding的问题

    • 影响搜索结果的相关性打分，影响统计结果的准确性
    • 单个节点上过多的分片，会导致资源浪费，同时也会影响性能

如何确定主分片数

• 从存储的物理角度看

  • 日志类应用，单个分片不要大于50GB
  • 搜索类应用，单个分片不要超过20GB

• 为什么要控制分片存储大小

  • 提高Update的性能
  • Merge时，减少所需的资源
  • 丢失节点后，具备更快的恢复速度 / 便于分片在集群内Rebalancing

如何确定副本分片数

• 副本是主分片的拷贝

  • 提高系统可用性：相应查询请求，防止数据丢失
  • 需要占用和主分片一样的资源

• 对性能的影响

  • 副本会降低数据的索引速度：有几份副本就会有几倍的CPU资源消耗在索引上

  • 会减缓对主分片的查询压力，但是会消耗同样的内存资源

    • 如果机器资源充分，提高副本数，可以提高整体的查询QPS

倒排索引不可变性

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

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

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

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

刷新的本质：写入数据由内存 buffer 写入到内存段中，以保证搜索可见

将文档插入 Elasticsearch 时，它们会被写入缓冲区中，然后在刷新时定期从该缓冲区刷新到段中。刷新频率由 refresh_interval 参数控制，默认每1秒发生一次。也就是说，新插入的文档在刷新到段（内存中）之前，是不能被搜索到的。

关于是否需要实时刷新

• 如果新插入的数据需要近乎实时的搜索功能，则需要频繁刷新
• 如果对最新数据的检索没有实时性要求，则应增加刷新间隔，以提高数据写入的效率，从而应释放资源辅助提高查询性能

关于刷新频率对查询性能的影响

• 由于每刷新一次都会生成一个Lucene段，刷新频率越小就意味着同样时间间隔，生成的段越多
• 每个段都要消耗句柄和内存
• 每次查询请求都需要轮询每个段，轮询完毕后再对结果进行合并
• 也就意味着：refresh_interval越小，产生的段越多，搜索反而会越慢；反过来说，加大refresh_interval，会相对提升索引性能

什么是段

• 一个集群包含1个或多个节点
• 一个节点包含1个或多个索引
• 一个索引：类似MySQL中的数据库
• 每个索引都是一个Lucene索引实例，可以将其视作一个独立的搜索引擎，它能够对Elasticsearch集群中的数据子集进行索引并处理相关查询
• 每个分片包含多个segment（段），每一个segment都是一个倒排索引

在查询的时候，会把所有的segment查询结果汇总归并为最终的分片查询结果返回

为什么段是不可变的？

• 在lucene中，为了实现高索引速度，故使用了segment分段架构存储
• 一批写入数据保存在一个段中，其中每个段是磁盘中的单个文件
• 由于两次写入之间的文件操作非常繁重，因此将一个段设为不可变的，以便所有后续写入都转到New段

什么是段合并？

由于自动刷新流程每秒会创建一个新的段（由动态配置参数：refresh_interval决定），这样会导致短时间内的段数量暴增。
而段数据太多会带来较大的麻烦

• 消耗资源：每一个段都会消耗文件句柄、内存和CPU运行周期
• 搜索变慢：每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢

Elasticsearch通过在后台进行段合并来解决这个问题：小的段被合并到大的段，然后这些大的段再被合并到更大的段。

段合并做了什么？

段合并的时候会将那些旧的已删除文档从文件系统中消除，
被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中，
启动段合并不需要你做任何事，进行索引和搜索时会自动进行。

为什么要进行段合并？

• 索引段的个数越多，搜索性能越低并且消耗更多的内存
• 索引段是不可变的，你不能物理上从中删除信息

可以物理上删除document，但只是做了删除标记，物理上并没有删除

• 当段合并的时候，这些被标记位删除的文档并没有被拷贝至新的索引段中，这样减少了最终的索引段中的document数目。

段合并的好处是什么？

• 减少索引段的数量并提高检索速度
• 减少索引的容量（文档数）

原因：段合并会移除被标记为已删除的那些文档

段合并可能带来的问题

• 磁盘IO操作的代价
• 速度慢的系统中，段合并会显著影响性能

重建索引

使用场景

• 一般在以下几种情况时，我们需要重建索引

  • 索引的Mappings发生变更：字段类型更改，分词器及字典更新
  • 索引的Settings发生变更：索引的主分片数发生改变
  • 集群内，集群间需要做数据迁移

• Elasticsearch的内置提供的API

  • Update By Query：在现有索引重建
  • Reindex：在其他索引上重建索引

性能优化

https://elastic.blog.csdn.net/article/details/97695931

分片大小

• 如果分片给索引的分片太多，则Lucene分段会很小，从而导致开销增加。当同时进行多个查询，许多小分片也会降低查询吞吐量
• 分片太大会导致搜索性能下降和故障恢复时间更长

数据动态持续写入场景

Index Sorting

注意：索引排序机制是6.X版本才有的特性
在Elasticsearch中创建索引时，可以配置每个分片中的分段的排序方式。默认情况下，Lucene不会应用任何排序。index.sort.*定义应使用哪些字段对每个Segment内的文档进行排序

面试题

一旦创建索引后，为什么无法更改索引的主分片数量？

如果我们要更改分片的数量，那么对于文档，运行路由公式的结果将发生变化。

假设：设置有 5 个分片时文档已存储在分片 A 上，因为那是当时路由公式的结果。

后面我们将主分片更改为7个，如果再尝试通过ID查找文档，则路由公式的结果可能会有所不同。

现在，即使文档实际上存储在Shard A上，该公式也可能会路由到ShardB。这意味着永远不会找到该文档。

以此可以得出：主分片创建后不能更改的结论。