ElasticSearch Analytical查询

Question

我正在评估一些使用开源技术为分析应用程序供电的不同选项.其中一个选项是使用ElasticSearch,虽然我还没有找到任何使用它进行大规模分析实施的公司的例子,因此我的问题在这里.

对于1B-10B点的数据集,ElasticSearch会有哪些限制(如果有的话,或者可能会有什么？)？例如,拥有像Google Analytics这样的功能集.

Answer 1

这是一位似乎对大量数据进行分析的用户 - https://digitalgov.gov/2015/01/07/elk - 以及他们所做工作的描述，包括缺点。

对于像您这样的开放式问题，Elasticsearch 不存在非黑即白的答案。记录量并不代表一切：我们谈论的是多少磁盘空间、多少个节点、多少个索引、每个分片的数量、您需要什么样的分析、硬件规格等。从以下内容可以确定两件事：您提到的数据：您需要专用的主节点，更重要的是良好的客户端节点，并且根据查询和并发搜索计数，您将需要更多或更少的节点。

在 Elasticsearch 5 中，客户端节点称为协调节点，但它具有相同的角色。我能想到的一个限制是此类协调节点的堆/RAM 内存。Elasticsearch 节点的堆不应设置为大于 ~30GB 的值，因为 JVM 的垃圾收集周期较长（需要清理的内存更大，需要更多时间，节点更不可用）。在 GC 期间，该 JVM 上不会运行其他任何东西。所以你可能会受到内存大小的限制。

我说过，您很可能需要协调节点，因为大量聚合（可能是分析平台中最常用的功能）将在查询的最后阶段使用 CPU 和内存，在查询的最后阶段收集所有涉及的分片的结果并执行最后的排序和聚合。因此，它需要比仅用于聚合的普通数据节点更多的内存。

我怀疑单个聚合是否会使用这么多 GB 的内存，但如果所使用的查询/聚合是以鲁莽的方式构建的，那么理论上它可以使用它。根据并发搜索的数量以及它们使用的内存量，您可能需要更多或更少的协调节点，以便 GC 周期不会非常频繁。

底线：我认为这是可能的，但需要一些常识（请参阅我关于鲁莽聚合的评论）以及一些尽可能接近现实的负载估计。