indexing - Elasticsearch 最佳索引大小

Question

我有一个 3 节点集群，每个节点有 4g ES_HEAP_SIZE。当索引大小在 4GB 左右时没有问题，但是当索引大小超过 10GB 时，经常会出现 Java 堆空间异常和 Unavailableshard 异常。当我减小索引大小时，问题就消失了。因此我的问题是；这种 3 节点 Elasticsearch 集群的最佳索引大小是多少？

Answer 1

“x 节点集群的最佳索引大小是多少”这个问题取决于以下几点:

1. 您商店中的平均文档有多大？

2. 您的查询是什么样的，是否进行了大量分面/排序？

3. 每台机器上的总内存是多少？这些节点是在不同的机器上还是在同一台机器上？

4. 当你索引数据时，你是否设置了store=true？ (你不应该)

5. 您是否正在做任何其他事情，例如内存密集型的父/子文档或嵌套文档？

6. 你的索引是重度还是轻度？

7. 您商店中的文件总数是多少？

在您的情况下，它与索引大小无关，更多的是为您的情况分配适当数量的内存。此外，我认为您没有真正询问就根据当前的使用和存储模式找到了自己的最佳尺寸。

也就是说，上面的项目列表只是我头脑中的一些事情，您在尝试衡量应该分配给 JVM 的内存量时应该使用这些事情。

一般来说，您应该始终将至少 50% 的空间留给操作系统，并且永远不要超过 32GB(我从来不会超过 29GB)。除此之外，我不会说有硬性规定。在您的情况下，您可能会发现有空间可以分配更多，或者您可能会发现您分配了太多。

例如，假设您有一个要分面的字段，该字段是一个长整型数组。

假设最长的此类数组有 300 个成员，而您正在查看 2M 的文档。 JVM 将首先分配 300*2000000*8(8 个字节用于 java long)。如果该空间量超过您的 JVM 大小，您每次都会遇到 OOM。

这里的解决方案是 A.) 创建第四个节点 B.) 分配更多内存 C.) 重新考虑您的索引/存储策略或 D.) 重新考虑您的分面策略。

例如，也许您可​​以使用 short 或 int。也许您不需要全部 300 个成员，但您实际上只关心三个用于分面。仅存储这三个，然后 300 的长列表转到另一个字段(您永远不会反对)。

通常该策略取决于用例，并且需要对您将如何使用搜索集群进行一些思考和预测。 elasticsearch 最棒的事情之一是您可以在大约五分钟内启动并运行，但我发现这导致了一种错觉，即 elasticsearch 管理着一切。它管理很多，但这仍然不能免除良好的系统管理。