不要将数据库中的“分库分表”理论盲目应用到 Elasticsearch

1、问题描述

近期在优化索引时，我遇到了一些挑战。我们的环境是7节点16*32G的机器，我在尝试内存优化。当前的文档总量为5亿，然而mapping设计和shard设计都出现了问题。每个节点上有480个shard，这是一个相当离谱的数量。

当我试图分析内存消耗的时候，遇到了更大的问题。尽管 fielddata、completion、segments、query_cache和translog占用的内存量可以计算出来，但是Heap的内存占用量达到了15G，让我困惑的是，剩下的内存究竟消耗在哪里呢？

sharding设计应该是参考了mysql的分表的思路，给一个 index 拆成了 300 个 index，比如 index_1,index_2...index_300。

我觉得这两个问题可能会导致内存的问题。

——来自：死磕Elasticsearch 知识星球 

2、问题拆解分析

同学给出了完整的 stats 分析结果数据。我们拆开一段一段解读看看以便复盘发现问题所在。如下内容来自于如下 ​​stats​​ 命令的返回结果。 

GET _cluster/stats

2.1 发现问题1：存在大量的删除或更新操作。

  "docs": {
      "count": 331681467,
      "deleted": 73434046
    },

删除文档的数量（deleted：73434046）相当高。这可能是因为当前业务场景在频繁地更新或删除文档，这样在 Elasticsearch 中会产生很多被标记为已删除的文档。

在 Elasticsearch 中，更新一个文档实际上是删除旧文档然后索引新文档。被删除的文档在一段时间内仍会占据空间，直到进行下一次 segment merge 时才会被真正删除。

如果应用有大量的删除或更新操作，可能会导致性能问题，因为 segment merge 是一个相对昂贵的操作。另外，过多的被删除的文档也会占用更多的存储空间。这种情况下，可以考虑调整数据模型或者索引策略。比如，避免过多的更新操作，或者使用 time-based indices（基于时间的索引）。在使用基于时间的索引时，可以定期（如每天）创建新的索引，删除老的索引，这样可以避免大量的删除操作。

2.2 发现问题2：存有大量已删除但未被清理的文档。

"segments": {
     "count": 3705,
     "memory_in_bytes": 43210351,
     "terms_memory_in_bytes": 34680393,
     "stored_fields_memory_in_bytes": 1870504,
     "term_vectors_memory_in_bytes": 0,
     "norms_memory_in_bytes": 1604160,
     "points_memory_in_bytes": 0,
     "doc_values_memory_in_bytes": 5055294,
     "index_writer_memory_in_bytes": 54801608,
     "version_map_memory_in_bytes": 211869,
     "fixed_bit_set_memory_in_bytes": 50741120,
     "max_unsafe_auto_id_timestamp": 1687046400930,
     "file_sizes": {}
   }

核心结果及释义如下：

潜在风险问题——fixed_bit_set_memory_in_bytes的值相对较高（50741120字节，约48.4MB）。这部分内存主要用于存储已删除文档的信息。在Elasticsearch中，当一个文档被删除或更新时，它的旧版本不会立即被物理删除，而是被标记为已删除，直到下一次段合并时才会被清除。这意味着索引中可能有大量已删除但未被清理的文档。

这种情况可能会降低查询性能并占用额外的存储空间。可以通过force merge操作来清理这些已删除的文档，但请注意，force merge是一个I/O密集型操作，可能会在执行期间影响集群性能。通常，force merge操作应该在业务低峰期进行。另外，如果频繁地更新或删除文档，可能需要调整索引策略或者数据模型以减少这种操作。

2.3 发现问题3：有大量的操作尚未被提交到 Lucene 索引

"translog": {
      "operations": 4171567,
      "size_in_bytes": 2854130582,
      "uncommitted_operations": 4171567,
      "uncommitted_size_in_bytes": 2854130582,
      "earliest_last_modified_age": 0
    },

核心结果及释义如下：

潜在风险问题——这可能会在系统崩溃时导致数据恢复时间变长，因为需要重新执行这些操作以恢复到最新的状态。

虽然这可能不会对正在运行的集群造成太大的影响，但是在某些情况下，例如节点宕机或集群恢复，可能会影响Elasticsearch的性能和数据恢复速度。因此，通常建议定期将Translog的数据提交到Lucene索引以保持其大小在合理范围内。

2.4 发现问题4：集群所在的操作系统的内存使用率非常高

"os": {
    "timestamp": 1687165428228,
    "cpu": {
      "percent": 13,
      "load_average": {
        "1m": 2.11,
        "5m": 1.68,
        "15m": 1.75
      }
    },
    "mem": {
      "total_in_bytes": 32822083584,
      "free_in_bytes": 260890624,
      "used_in_bytes": 32561192960,
      "free_percent": 1,
      "used_percent": 99
    },
    "swap": {
      "total_in_bytes": 0,
      "free_in_bytes": 0,
      "used_in_bytes": 0
    },
    "cgroup": {
      "cpuacct": {
        "control_group": "/user.slice",
        "usage_nanos": 15187558135108329
      },
      "cpu": {
        "control_group": "/user.slice",
        "cfs_period_micros": 100000,
        "cfs_quota_micros": -1,
        "stat": {
          "number_of_elapsed_periods": 0,
          "number_of_times_throttled": 0,
          "time_throttled_nanos": 0
        }
      },
      "memory": {
        "control_group": "/",
        "limit_in_bytes": "9223372036854771712",
        "usage_in_bytes": "31734857728"
      }
    }
  }, 

核心结果及释义如下：

潜在风险问题——Elasticsearch 集群所在的操作系统(OS)的内存使用率非常高（"used_percent": 99），可用内存非常低（"free_percent": 1）。这可能会导致性能问题，因为系统可能不得不频繁地使用磁盘进行交换操作，这会大大降低性能。

建议尽快采取措施释放内存或增加更多的内存，以提高 Elasticsearch 的性能。

2.5 发现问题5：堆内存使用率相当高

"jvm": {
    "timestamp": 1687165428234,
    "uptime_in_millis": 5988052030,
    "mem": {
      "heap_used_in_bytes": 16480235136,
      "heap_used_percent": 76,
      "heap_committed_in_bytes": 21474836480,
      "heap_max_in_bytes": 21474836480,
      "non_heap_used_in_bytes": 309785016,
      "non_heap_committed_in_bytes": 354152448,
      "pools": {
        "young": {
          "used_in_bytes": 8967421952,
          "max_in_bytes": 0,
          "peak_used_in_bytes": 12968787968,
          "peak_max_in_bytes": 0
        },
        "old": {
          "used_in_bytes": 7479258752,
          "max_in_bytes": 21474836480,
          "peak_used_in_bytes": 11748245496,
          "peak_max_in_bytes": 21474836480
        },
        "survivor": {
          "used_in_bytes": 33554432,
          "max_in_bytes": 0,
          "peak_used_in_bytes": 1610612736,
          "peak_max_in_bytes": 0
        }
      }
    },
    "threads": {
      "count": 268,
      "peak_count": 314
    },
    "gc": {
      "collectors": {
        "young": {
          "collection_count": 434416,
          "collection_time_in_millis": 18999559
        },
        "old": {
          "collection_count": 0,
          "collection_time_in_millis": 0
        }
      }
    },

核心结果及释义如下：

潜在风险问题——堆内存使用率相当高（"heap_used_percent": 76）。虽然这个值可能不会立即导致问题，但如果索引负载增加，或者有更多的查询，可能会使内存压力增加，导致更频繁的垃圾收集，从而影响性能。

建议监控这些值的变化，并在需要时调整 JVM 的内存设置，以保持 Elasticsearch 的性能。

2.6 发现问题6：读操作比写操作多很多

"io_stats": {
      "devices": [
        {
          "device_name": "dm-0",
          "operations": 5250539512,
          "read_operations": 4478787246,
          "write_operations": 771752266,
          "read_kilobytes": 129711481927,
          "write_kilobytes": 23684659984
        }
      ],
      "total": {
        "operations": 5250539512,
        "read_operations": 4478787246,
        "write_operations": 771752266,
        "read_kilobytes": 129711481927,
        "write_kilobytes": 23684659984
      }
    }
  }

核心结果及释义如下：

潜在风险问题——上述内容显示了 Elasticsearch 集群的 I/O 操作统计信息。看起来读操作比写操作多很多，但这并不一定是问题，这完全取决于应用程序使用 Elasticsearch 的方式。如果当前业务场景主要是查询数据，那么这个读取操作的数量就可以解释了。

可以根据这些信息来调整 Elasticsearch 的 I/O 配置，比如，如果读操作非常多，可能需要在硬件或配置上进行优化以提高读取速度。

2.7 发现问题6：缓存命中率低

"query_cache": {
    "memory_size_in_bytes": 422629063,
    "total_count": 18178614894,
    "hit_count": 4107645935,
    "miss_count": 14070968959,
    "cache_size": 405975,
    "cache_count": 16870486,
    "evictions": 16464511
  }

核心结果及释义如下：

潜在风险问题——查询缓存命中率似乎有些低，这可能意味着当前业务查询有很大的多样性，或者缓存设置不够理想。

建议：如果想提高查询缓存的效率，可能需要调整查询缓存的大小，或者看看是否有一些查询可以做些修改以适应缓存。此外，一些不需要缓存的查询，可以明确地在查询中设置 ——"cache": false 来避免对缓存造成不必要的压力。

3、问题总结

我们从响应中得到了一些显著的内存相关统计信息：操作系统级别的内存使用非常高，只剩下1%的总内存空闲。如果内存使用继续上升，可能会导致性能问题或崩溃。

• JVM内存使用

首先，JVM的堆内存使用了76%，接近80%的警戒线。如果内存使用超过80%，将会触发更频繁的垃圾收集，可能会对性能产生影响。同时，“young”内存池的使用超过了其“max”值，这也可能是一个需要进一步调查的问题。

• 操作系统内存使用

​操作系统的内存使用很高，仅剩1%的空闲内存，这可能会导致系统性能降低，甚至导致进程被操作系统杀死以释放内存。

• 索引压力

"Indexing_pressure.memory.total.combined_coordinating_and_primary_in_bytes"远远大于"indexing_pressure.memory.limit_in_bytes"，这表示索引操作产生的内存压力超过了预设的限制。这可能导致新的写入操作被拒绝，以防止内存耗尽。

• 索引失败

“indexing.index_failed”值为10253，这表示有一些索引操作失败。可能需要查看Elasticsearch的日志来确定失败的原因。

• 缓冲区使用

“buffer_pools.mapped.used_in_bytes”值很高，表示映射的文件缓冲区使用了很大的内存。这通常是由于大量的文件被打开并映射到内存中，可能是由于大量的读取操作或大量的小文件。

• 可能存在大量删除或更新操作

因为在Elasticsearch中，删除的文档不会立即被清除，而是在下次合并段时才被清除，这可能会占用额外的空间。

3.1 可能的原因

上述问题可能由以下几个原因引起：

• 1、大量的数据操作

频繁的索引、更新和删除操作可能会使Elasticsearch需要更多的内存来处理这些操作。

• 2、大量的并发查询

高并发查询会使Elasticsearch需要在短时间内处理大量请求，也可能导致内存使用上升。

• 3、大量的数据段合并

数据段合并需要消耗大量的计算和内存资源。

• 4、数据库分库分表理论直接迁移到 Elasticsearch

分片设置不合理，sharding（分片）设计应该是参考了 mysql 的分表的思路，给一个 index 拆成了300个 index。

解决这些问题通常需要结合监控数据和日志来确定具体原因，然后根据具体情况进行优化或扩容。

3.2 根因：MySQL 的分库分表理论不直接适用于 Elasticsearch

在进行深入分析之后，我发现主要问题出在mapping和sharding的设计上。

• 一开始，我们的mapping设计比较粗糙，甚至对一些hash也进行了分词。这导致了索引非常大，占用了大量的内存。
• 另外，我们在设计sharding时，参考了MySQL的分表思路，给一个index拆成了300个index，例如index_1, index_2...index_300。

这两个问题都可能导致内存问题。

• 一方面，mapping设计使索引很大，占用大量内存。
• 另一方面，一次查询可能会打开300个shard，每个shard都有自己的pool，这可能就是导致“buffer_pools.mapped.used_in_bytes”值较大的原因。比如进行分页查询时，每次打开300个shard或segment，那就意味着一次查询打开了6000个文档。

因此，优化的当务之急就是合并索引。当前的单分片应该是不到 2G，小的分片应该是几百兆，分片并不均匀。

我计算了一下，这些分片应该可以合并到8个分片（原来数百个）。这种优化应该能够显著减少内存的消耗，进一步提升Elasticsearch的性能。

4、小结

Elasticsearch的设计理念和关系型数据库（例如MySQL）的设计理念是有明显区别的。在关系型数据库中，分表是常见的处理大量数据的策略，但是在Elasticsearch中，过度分片会导致效率降低和内存占用过高。以下是一些深入的分析和后续开发人员的注意事项：

4.1 Mapping 的设计：

• 在设计字段类型时，尽量使用更加精确的数据类型，避免不必要的文本字段，特别是对于一些hash值或者ID值，它们无需分词，直接用keyword类型存储即可。
• 如果必须要分词的话，合理选择分词器。例如，对于中文，ik_max_word可能会产生大量的词条，而ik_smart则更为节省资源。
• 对于大文本字段，可以考虑禁用倒排索引，或者只对部分关键内容做索引，避免索引过大。

4.2 Sharding 分片的设计：

• Elasticsearch的每个shard都是一个完全的Lucene索引，拥有自己的数据结构和资源开销，所以shard的数量不应该过多。过多的shard会消耗大量的内存和CPU，降低查询性能。
• 单个shard的大小通常建议在20GB-40GB之间。过小的shard会增加开销，过大的shard在做recovery时会消耗更多的时间。
• 尽量避免一个查询涉及到太多的shard，这会增加查询时间和资源消耗。如果可能，尽量在一个index内部进行数据的切分和查询，而不是在多个index之间。
• 考虑使用index alias或者routing功能，减少不必要的shard查询。

4.3 后续开发人员的注意事项：

在构建和优化Elasticsearch数据模型时，我们必须深入理解其内在工作机制，并借鉴已有的最佳实践，而非简单地迁移关系型数据库的理论。

持续监控Elasticsearch的核心数据，如shard的数量、大小，以及CPU和内存的使用情况，是预防问题、提前发现和处理隐患的关键。

此外，我们需要定期进行性能测试，以了解系统的性能瓶颈和限制，并通过对不同shard数量和大小的性能变化的测试，找出最优的shard设计方案。

为了更好地使用和优化Elasticsearch，我们必须不断学习和保持对其新功能和最佳实践的关注。

遇到问题时，要充分利用Elasticsearch提供的各种分析工具，如_slow log_和_hot threads_，以准确找出问题的根源。这是我们向更高效、更稳定的Elasticsearch 服务迈进的关键步骤。

文章转载自公众号：铭毅天下Elasticsearch