我正在评估一些使用开源技术为分析应用程序供电的不同选项。其中一个选择是使用ElasticSearch，虽然我还没有找到任何使用它进行大规模分析实施的公司的例子，因此我的问题在这里。
对于1B-10B点的数据集，ElasticSearch会有哪些限制（如果有的话，或者可能会有什么？）？例如，在拥有Google Analytics等功能集时，可以使用它。
答案 0 :(得分：4)
这是一个似乎对大量数据进行分析的用户 - https://digitalgov.gov/2015/01/07/elk - 以及他们所做的事情的描述，包括缺点。
使用Elasticsearch，对于像您一样开放式问题的问题没有黑白答案。记录的数量并不是一切：我们谈论了多少磁盘空间，有多少节点，多少索引，每个分片的数量，您需要什么样的分析，硬件规格等等。有两件事是肯定的您提到的数据：您需要专用的主节点，更重要的是良好的客户端节点，根据查询和并发搜索计数，您将需要更多或更少的。
在Elasticsearch 5中，客户端节点称为协调节点，但它具有相同的角色。 我能想到的一个限制是这种协调节点的堆/ RAM内存。 Elasticsearch节点的堆不应该设置为值更大由于JVM的垃圾收集周期较长（清理内存较大，需要的时间更长，节点更无法使用），因此大于~30GB 。在GC期间，该JVM上没有其他任何运行。所以你可能受到内存大小的限制。
我说你很可能需要协调节点，因为大量聚合（可能是分析平台中最常用的功能）将在查询的最后阶段使用cpu和内存，它会收集所有分片的结果参与并执行最终的排序和聚合。因此，它需要比普通数据节点更多的内存，仅用于聚合。
我怀疑单个聚合将使用如此多GB的内存，但如果使用的查询/聚合是以鲁莽的方式构建的话理论上可以使用它。取决于并发搜索的数量他们使用了多少内存可能需要更多或更少的协调节点，以便GC周期不是很频繁。
底线：我认为这是可能的，但需要一些常识（请参阅我对鲁莽聚合的评论）以及一些尽可能接近现实的关于负载的估算。
答案 1 :(得分：1)
Google Analytics专业人员：
Google Analytics Cons：
ElasticSearch专业人士：
ElasticSearch缺点：