优化并行查询的Elasticsearch

时间:2016-08-04 03:18:45

标签: elasticsearch apache-spark lucene full-text-search

我在AWS EMR中运行的20节点Elasticsearch集群上获得了大约3gb的索引。该索引有5个分片,并被复制4次。基础数据是书籍,但我将它们拆分为段落或行块,具体取决于格式,因此有大约2700万份文档。索引只需约5分钟。

我想在索引中搜索大约1500万个短语。

搜索逻辑是一个4层瀑布,一旦找到结果就停止:完全匹配=>模糊匹配,编辑距离为1 =>模糊匹配,编辑距离为2 =>部分短语匹配。我以这种方式将其分解,所以我可以通过一些质量测量来过滤匹配。

为了分发和执行搜索,我正在使用Spark。

我发现运行搜索的最快速度是每秒420个短语,这意味着整个任务需要10-12个小时。

我的问题是:是一个合理的搜索率?

如果我在一个分片上拥有整个索引并在每个节点上复制完整索引,我会获得更好的性能吗?或者我应该走另一个方向并增加分片级别?我怀疑这两个问题的答案将是“同时试试!”,从长远来看,我可能会这样做,但我有一个短期限期,我正在努力优化,所以我想知道是否有其他人有类似问题的经验。

我很乐意根据需要提供更多详细信息。

如果这不是关于主题的道歉 - 我没有找到关于Elasticsearch的这种用例的大量文档。

1 个答案:

答案 0 :(得分:2)

在20个节点上 3gb的数据是浪费资源。如果您有5分片索引,则仅从5个节点开始。哎呀,3gb是如此之小,你甚至可以让该索引只包含一个分片并在单个节点上运行。

您很幸运,只需5分钟即可为您的所有数据编制索引,因为您可以快速找到合适的群集大小来优化运行查询。从一个节点上的一个主分片(无副本)开始,然后添加一个副本和另一个节点等

然后重新开始使用两个主分片和两个节点,添加副本和节点等。

对于每个测试,测量它的速度,并且在某些时候(即在一两天内),您将找到最适合您的搜索要求的精确簇大小。

<强>更新

如果每个节点有32个CPU,则可以拥有一个节点和20个分片。在每次搜索期间,每个CPU都会愉快地处理一个分片,网络聊天会更少,以便聚合结果并且“应该”更快。我肯定会尝试一下。