Lucene +自定义群集解决方案

Question

我有一个项目工作经验，通过用Lucene + Hazelcast替换ElasticSearch来提高全文搜索速度。

与Lucene + Hazelcast相比，ElasticSearch开销可能是什么原因？哪些ElasticSearch配置可能导致使用相同资源显着减速？

为Lucene + Hazelcast

提供了参数

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

我的考虑因素

1. 哪些管理费用？据我所知，您可以通过内部TCP API而不是REST来破解ElasticSearch与他进行通信。还有其他开销吗？它们只是关于复制（您可以关闭初始加载复制）吗？或关于索引自动合并？也许是由于ElasticSearch试图自动合并索引并使它们变得如此之大，以至于它们没有FS缓存？
2. 为什么Lucene API更灵活？ AFAIK，ElasticSearch具有所有相同的索引以及父子或嵌套对象等附加功能。因为这不是这个项目的案例。 （请参阅索引/查询架构）

Lucene + Hazelcast索引/查询架构：

1. 你有100-10.000个巨大的字符串文件在HDFS中压缩为AVRO（总结千兆字节或甚至数TB的数据）。您应该以可以找到包含特定字符串的所有文件的方式对它们编制索引。
2. 使用Hazelcast向每个群集节点提交索引任务
3. 每个索引任务使用IndexWriter为每个仅使用本地文件系统的节点编写单独的索引。意味着每个AVRO文件将为每个节点形成一个索引。每个文件行都是单独的StringField
4. 在所有节点上完成索引后 - 索引永远不会更改。意味着不再有写入有效载荷。索引量等于文件量。文件非常大，而且数量不是很高 - 所以没有合并索引。
5. 使用简单的术语查询进行搜索，指定可能存在数据的所有索引的路径。

Answer 1

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

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

• 功能丰富的聚合API

• 支持使用Spark / Hive等进行索引 - 非常容易，我们可以有效地预处理数据。

• 根据需求自动调整/调整复制次数

当然，不保持代码库来完成所有这些。如果您可以从最终添加一些关于灵活性的期望，那么这个主题将是很好的讨论。