Elasticsearch 写入、搜索原理

基本概念

• Shard（分片）：Elasticsearch 存储的基本单元，一个索引可以分为多个分片。每一个分片是一个 Lucene 索引
• Segment（段）：每个Lucene索引由多个段组成。每次创建一个新的文档时，会生成一个新的段，而不会修改已有的段。删除操作会标记文档为删除状态，而不是立即物理删除。
• Commit（提交）：在 Lucene 中，commit 操作意味着将段合并并写入磁盘。为了提高性能和实现近实时搜索，Elasticsearch 并不会频繁执行刷盘操作。
• Translog（事务日志）：新文档被索引时，文档首先写入内存缓冲区和 translog 文件。每个分片对应一个 translog 文件。
  • 文档索引过程：
    • 写入 Translog
    • 写入内存缓冲区（In Memory Buffer）
• Refresh（刷新）：在 Elasticsearch 中，_refresh 操作默认每秒执行一次，将内存缓冲区的数据写入文件系统缓冲区，使数据可被搜索。
• Flush（刷盘）： 将系统缓冲区中的数据写入磁盘，保证数据持久化。这是一个较重的 IO 操作。

Elasticsearch 配置选型

• 节点配置：

  • 数据节点：

    • 16 核心

    • 64 GB 内存

    • 2 TB SSD（一开始是高效云盘）

    • 专有主节点：

      • 4 核心
      • 16 GB 内存
      • 100 GB 磁盘

    • 协调节点：

      • 4 核心
      • 16 GB 内存

• JVM 内存配置：建议配置为物理内存的一半。

• 分片配置：每个索引的分片数 = 节点数 * 1.5

• 单个分片大小：

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

13个数据节点

3个专有主节点

5个协调节点

JVM内存配置原内存的一半

节点数 * 1.5（3） = 单个索引的分片数

补充说明

• 内存管理
  • Elasticsearch 的 JVM 内存管理非常重要，内存不足会导致性能问题甚至宕机
  • 通常建议将 JVM 堆内存设置为物理内存的一半，但不超过 32 GB
• 分片数量
  • 分片过多会导致资源浪费和管理复杂，分片过少可能会导致性能瓶颈
  • 使用 _shrink API 可以在不影响索引数据的情况下调整分片数量
• 近实时搜索
  • 默认的每秒 _refresh 操作使得 Elasticsearch 能够提示近实时搜索能力，但也可以通过调整刷新间隔来优化性能
• 磁盘 IO 性能
  • 使用 SSD 可以显著提高 Elasticsearch 的写入和搜索性能
  • 高效的磁盘 IO 对于密集型应用尤其重要