我正在评估使用开源技术为分析应用程序提供动力的几个不同选项。其中一个选项是使用 ElasticSearch，尽管我还没有找到任何公司使用它进行大规模实现分析的例子，因此我的问题在这里。
对于 1B-10B 点的数据集，ElasticSearch 有什么限制(如果有的话，或者可能吗？)？例如，拥有像 Google Analytics 这样的功能集。
最佳答案
这是一位似乎对大量数据进行分析的用户 - https://digitalgov.gov/2015/01/07/elk - 加上对他们所做工作的描述，包括缺点。
对于像您这样开放式的问题，使用 Elasticsearch 没有非黑即白的答案。记录的数量不是一切:我们谈论的是多少磁盘空间、多少节点、多少索引、每个分片的数量、您需要什么样的分析、硬件规范等。有两件事是确定的您提到的数据:您需要专用的主节点，更重要的是良好的客户端节点，并且根据查询和并发搜索计数，您将需要更多或更少的节点。
在 Elasticsearch 5 中，客户端节点 称为协调节点，但它具有相同的作用。 我能想到的一个限制是此类协调节点的堆/RAM 内存。Elasticsearch 节点的堆不应设置为大于~的值30GB 由于 JVM 的垃圾收集周期较长(需要清理的内存越大，花费的时间越多，节点越不可用)。在 GC 期间，该 JVM 上没有其他任何东西运行。因此，您可能会受到内存大小的限制。
我说过您很可能需要协调节点，因为繁重的聚合(这可能是分析平台中最常用的功能)将在查询的最后阶段使用 CPU 和内存，从所有分片收集结果参与并执行最终的排序和聚合。因此，它将需要比仅用于聚合的普通数据节点更多的内存。
我怀疑单个聚合是否会使用这么多 GB 的内存，但如果正在使用的查询/聚合是以鲁莽的方式构建的，理论上它可以使用它。取决于并发搜索的数量它们使用了多少内存，您可能需要更多或更少的协调节点，这样 GC 周期就不会很频繁。
底线:我认为这是可能的，但需要一些常识(请参阅我关于鲁莽聚合的评论)和一些尽可能接近现实的负载估计。
关于ElasticSearch 分析查询，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40923529/