Elasticsearch最佳索引大小

"x节点集群的最佳索引大小是什么"的问题取决于以下几点:

你店里的普通文件有多大？

您的查询是什么样的,您是否正在进行大量的分面/排序？

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

索引数据时,是否存储= true set？(你不应该)

您正在做其他事情,例如父/子或内存密集的嵌套文档吗？

您是重度还是轻度索引？

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

在您的情况下,它不是关于索引大小,而是关于为您的案例分配适当数量的内存.此外,我认为你根据当前的使用和存储模式找到了自己的最佳尺寸,而没有真正询问.

也就是说,上面的项目列表只是我在试图判断应该为JVM分配多少内存时应该使用的一些内容.

一般来说,你应该总是至少留出50%的操作系统,而不要超过32GB(我永远不会超过29GB).除此之外,我不会说有一条硬性规则.在您的情况下,您可能会发现存在分配更多空间的空间,或者您可能发现您分配了太多.

例如,假设您有一个面向的字段,该字段是一个long数组.

让我们说最长的阵列有300个成员,你正在查看2M文档.JVM将首先分配300*2000000*8(java长度为8个字节).如果该空间量超过JVM大小,则每次都会获得一个OOM.

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

例如,也许你可以使用short或int.也许你不需要所有300名成员,但你真的只关心三个人的分面.只存储那三个,300个长列表会转到另一个字段(你永远不会反对).

通常,策略是依赖于用例的,需要一些思考和预测,以了解如何使用搜索集群.弹性搜索最大的好处之一就是你可以在大约五分钟内启动并运行,但我发现这会导致弹性搜索管理一切的错觉.它管理很多,但这仍然不能从良好的系统管理中解脱出来.