java - ElasticSearch 开销超过 Lucene + 自定义集群解决方案

Question

我曾参与过一个项目，其中通过用 Lucene + Hazelcast 替换 ElasticSearch 提高了全文搜索速度。

ElasticSearch 开销超过 Lucene + Hazelcast 的原因可能是什么？哪些 ElasticSearch 配置可能会导致相同资源的速度显着下降？

为 Lucene + Hazelcast 提供参数

1. ElasticSearch 的开销比 Lucene 大
2. Lucene 在索引方面比 ElasticSearch 更灵活

我的考虑

1. 哪些间接费用？据我所知，您可以破解 ElasticSearch 以通过内部 TCP API 而不是 REST 与他通信。还有其他开销吗？它们是否仅与复制有关(您可以关闭初始加载复制)？或者关于索引自动合并？可能是由于 ElasticSearch 试图自动合并索引并使它们太大以至于无法容纳 FS 缓存？
2. 为什么 Lucene API 更灵活？据我所知，ElasticSearch 具有所有相同的索引以及附加功能，如父子或嵌套对象。因为这不是这个项目的案例。 (参见索引/查询模式)

Lucene + Hazelcast 索引/查询模式:

1. 您有 100-10.000 个巨大的字符串文件在 HDFS 中压缩为 AVRO(总计 GB 甚至 TB 的数据)。您应该以这种方式对它们进行索引，以便您可以找到包含特定字符串的所有文件。
2. 使用Hazelcast向每个集群节点提交索引任务
3. 每个索引任务都使用 IndexWriter 为每个仅使用本地文件系统的节点编写单独的索引。意味着每个 AVRO 文件都会为每个节点形成一个索引。每个文件行都是一个单独的 StringField
4. 在所有节点上完成索引之后——索引永远不会改变。意味着不再有写入有效载荷。索引的数量等于文件的数量。文件很大，但数量不是很多 - 所以没有合并索引。
5. 使用简单的 Term 查询进行搜索，指定可能存在数据的所有索引的路径。

Answer 1

我在这种情况下使用 ES 的原因是

• 项目 future 需要以更多方式探索数据

• 功能丰富的聚合 API

• 支持使用 Spark/Hive 等建立索引 - 非常容易做到，我们可以高效地使用数据预处理。

• Auto Scaling/根据需求调整复制数量

当然，不需要维护代码库来完成所有这些工作。如果您可以从最后添加一些对灵 active 的期望，那么这个线程将是一个很好的讨论。