ElasticSearch 分析查询答案

【问题标题】：ElasticSearch Analytical queriesElasticSearch 分析查询
【发布时间】：2017-04-16 20:26:46
【问题描述】：

我正在评估使用开源技术为分析应用程序提供支持的几个不同选项。其中一个选项是使用 ElasticSearch，尽管我无法找到任何使用它进行大规模分析实施的公司的例子，因此我的问题在这里。

对于 1B-10B 点的数据集，ElasticSearch 会有哪些限制（如果有，或者可能吗？）？例如，拥有像 Google Analytics 这样的功能集。

【问题讨论】：

这是一位似乎对大量数据进行分析的用户 - digitalgov.gov/2015/01/07/elk - 加上他们所做的描述，包括缺点。
在 Elasticsearch 中，对于像您这样的开放式问题没有非黑即白的答案。记录的数量并不是一切：我们谈论多少磁盘空间、多少节点、多少索引、每个分片的数量、您需要什么样的分析、硬件规格等。有两件事可以确定。您提到的数据：您需要专用的主节点，更重要的是良好的客户端节点，根据查询和并发搜索计数，您将需要更多或更少的主节点。
在 Elasticsearch 5 中，客户端节点被称为协调节点，但它具有相同的角色。我能想到的一个限制是这种协调节点的堆/RAM 内存。由于 JVM 的垃圾收集周期较长（要清理的内存更大，需要更多时间，节点更不可用），因此 Elasticsearch 节点的堆不应设置为大于 ~30GB 的值。在 GC 期间，该 JVM 上没有其他任何东西运行。所以你可能会受到内存大小的限制。
我说您很可能需要协调节点，因为大量聚合（这可能是分析平台中最常用的功能）将在收集结果的final phase of a query 中使用 CPU 和内存从所有涉及的分片中提取并执行最终的排序和聚合。因此，与仅用于聚合的普通数据节点相比，它需要更多的内存。
我怀疑单个聚合会使用这么多 GB 的内存，但如果正在使用的查询/聚合是以鲁莽的方式构建的，它理论上可以使用它。根据有多少并发搜索以及它们使用多少内存，您可能需要更多或更少的协调节点，以便 GC 周期不是很频繁。底线：我认为这是可能的，但需要一些常识（请参阅我关于鲁莽聚合的评论）和一些尽可能接近现实的负载估计。

【解决方案1】：

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

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

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

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

我怀疑单个聚合是否会使用这么多 GB 的内存，但如果 使用的查询/聚合是以鲁莽的方式构建的，理论上它可以使用它。 取决于并发搜索的数量他们有多少内存以及它们使用了多少内存可能需要更多或更少的协调节点，这样 GC 周期就不会很频繁。

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

【讨论】：

【解决方案2】：

谷歌分析专家：

易于安装
可用于多种环境（例如网络、移动、其他）
自定义数据收集

谷歌分析缺点：

自定义报告受到限制
升级到高级版很昂贵
需要不断训练
将数据分割成更小的样本以处理大型采样问题

ElasticSearch 优点：

按设计分发
更容易水平扩展
擅长全文搜索
快速索引和查询

ElasticSearch 缺点：

不是关系型数据库，因此不能从外键约束之类的东西中受益
可能会影响数据一致性
没有内置的身份验证或授权系统

【讨论】：