Lucene +自定义集群解决方案上的ElasticSearch开销

Question

我有工作的经验，在这个项目中，全文搜索速度是通过用Lucene + Hazelcast替代ElasticSearch来提高的。

Lucene + Hazelcast上的ElasticSearch开销可能是什么原因？在相同的资源条件下，哪个ElasticSearch可能会导致经济增长大幅放缓？

为Lucene + Hazelcast提供了论据

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

我的考虑

1. 哪种间接费用？如我所知，您可以通过内部TCP而不是REST黑ElasticSearch与他通信。还有其他间接费用吗？它们只是关于复制(您可以关闭初始负载复制)吗？还是关于索引自动合并？也许，由于ElasticSearch试图自动合并索引，并使它们变得如此大，以致于不支持FS缓存？
2. 为什么Lucene更灵活？AFAIK，ElasticSearch具有所有相同的索引以及其他特性，如父-子对象或嵌套对象。因为这不是这个项目的案例。(请参见索引/查询模式)

Lucene + Hazelcast索引/查询模式：

1. 在HDFS中，有100到10.000个巨大的字符串文件压缩为AVRO (概括地说是千兆字节，甚至是in的数据)。您应该以这种方式对它们进行索引，以便找到包含特定字符串的所有文件。
2. 向每个集群节点提交使用Hazelcast的索引任务
3. 每个索引任务都使用IndexWriter为仅使用本地文件系统的每个节点编写单独的索引。意味着每个AVRO文件将形成每个节点的一个索引。每个文件行都是一个单独的StringField。
4. 在所有节点上完成索引之后，索引永远不会更改。意味着不再有写负载了。索引的数量等于文件的数量。文件相当大，而且它们的数量并不高-因此没有索引的合并。
5. 使用简单的术语查询搜索，指定可能存在数据的所有索引的路径。

Answer 1

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

• 未来项目需要以更多的方式探索数据
• 特性丰富聚集API
• 支持索引使用火花/蜂巢等-非常容易做到，我们可以有效地使用数据的预处理。
• 基于需求的复制自动缩放/调整#

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