我正在评估使用开源技术为分析应用程序提供支持的几种不同选择。一种选择是使用ElasticSearch，尽管我无法找到公司将其用于大规模实现分析的任何示例，因此，我的问题在这里。
对于1B-10B点的数据集，ElasticSearch会有哪些限制(如果有的话，或者有可能吗？)？例如，具有类似Google Analytics(分析)的功能集。
最佳答案
这是一位似乎似乎对大量数据进行分析的用户-https://digitalgov.gov/2015/01/07/elk-加上他们所做的工作(包括缺点)的描述。
对于Elasticsearch，没有像您这样的开放式问题可以得到黑白答案。记录的数量并不是全部:我们在谈论多少磁盘空间，多少节点，多少索引，每个分片的数量，所需的分析类型，硬件规格等。您提到的数据:您需要专用的主节点，更重要的是好的客户端节点，根据查询和并发搜索数，您或多或少需要它们。
在Elasticsearch 5中，客户节点被称为协调节点，但它具有相同的作用。 我可以想到的一个限制是此类协调节点的堆/ RAM内存。 不应将Elasticsearch节点的堆的值设置为大于〜30GB 的值，这是因为JVM的垃圾回收周期更长(清理的内存更大，花费的时间更多，节点的更多无法使用)。在GC期间，该JVM上没有其他运行。因此，您可能会受到内存大小的限制。
我说过，您很可能需要协调节点，因为繁重的聚合(这可能是分析平台中最常用的功能)将在查询的最后阶段使用cpu和内存，在该阶段它将收集所有涉及的分片的结果并执行最后的排序和汇总。因此，与仅用于聚合的普通数据节点相比，它将需要更多的内存。
我怀疑单个聚合将使用那么多GB的内存，但是如果所使用的查询/聚合是以鲁ck的方式构建的，那么从理论上讲它是否可以使用它。 可能需要或多或少的协调节点，这取决于并发搜索的数量以及它们使用的内存量，因此GC周期不会非常频繁。
底线:我认为这是可能的，但是需要一些常识(请参阅我对鲁ck聚合的评论)，以及一些尽可能接近实际的负载估计。