近期在优化索引时，我遇到了一些挑战。我们的环境是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 知识星球 

https://t.zsxq.com/10fKvwz0k

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

GET _cluster/stats

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

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

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

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

"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操作应该在业务低峰期进行。另外，如果频繁地更新或删除文档，可能需要调整索引策略或者数据模型以减少这种操作。

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

核心结果及释义如下：

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

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

"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 的性能。

"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 的性能。

"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 配置，比如，如果读操作非常多，可能需要在硬件或配置上进行优化以提高读取速度。

"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 来避免对缓存造成不必要的压力。

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

首先，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中，删除的文档不会立即被清除，而是在下次合并段时才被清除，这可能会占用额外的空间。

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

1）大量的数据操作

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

2）大量的并发查询

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

3）大量的数据段合并

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

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

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

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

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

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

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

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

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

在设计字段类型时，尽量使用更加精确的数据类型，避免不必要的文本字段，特别是对于一些hash值或者ID值，它们无需分词，直接用keyword类型存储即可。

如果必须要分词的话，合理选择分词器。例如，对于中文，ik_max_word可能会产生大量的词条，而ik_smart则更为节省资源。

对于大文本字段，可以考虑禁用倒排索引，或者只对部分关键内容做索引，避免索引过大。

Elasticsearch的每个shard都是一个完全的Lucene索引，拥有自己的数据结构和资源开销，所以shard的数量不应该过多。过多的shard会消耗大量的内存和CPU，降低查询性能。

单个shard的大小通常建议在20GB-40GB之间。过小的shard会增加开销，过大的shard在做recovery时会消耗更多的时间。

尽量避免一个查询涉及到太多的shard，这会增加查询时间和资源消耗。如果可能，尽量在一个index内部进行数据的切分和查询，而不是在多个index之间。

考虑使用index alias或者routing功能，减少不必要的shard查询。

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

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

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

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

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