使用 Hadoop 进行导入操作并使用 Solr 提供 Web 界面是否有意义？

Question

我正在考虑将大量数据实时导入 Lucene 索引的需求。这将包含各种格式的文件（Doc、Docx、Pdf 等）。

数据将作为批量压缩文件导入，因此需要将它们解压缩并索引到单个文件中，并以某种方式与整个文件批量相关。

我仍在试图弄清楚如何实现这一点，但我认为我可以使用 Hadoop 进行处理并导入到 lucene。然后我可以将 Solr 用作 Web 界面。

因为 Solr 已经可以处理数据，我是不是把事情复杂化了？由于导入的 CPU 负载非常高（由于预处理），我认为无论实现如何，我都需要将导入和随意搜索分开。

问：“请定义大量数据和实时性”

“大量”数据是每年（或更多）10 亿封电子邮件，平均大小为 1K，附件从 1K 到 20 Megs 不等，少量数据从 20 Megs 到 200 Megs 不等。这些通常是上面提到的需要索引的附件。

实时意味着它支持在准备好导入后 30 分钟或更短时间内进行搜索。

SLA：

我想为搜索操作提供 15 秒或更短的搜索 SLA。

Answer 1

如果您需要实时（或近乎实时）完成处理，那么 Hadoop 可能不是您的最佳选择。

Solr 已经处理了文件处理和索引的所有方面。我会首先坚持使用仅限 Solr 的解决方案。 Solr 允许您扩展到多台机器，因此如果您发现由于处理导致 CPU 负载过高，那么您可以轻松添加更多机器来处理负载。

Answer 2

我建议您使用Solr Replication 来减轻负载，方法是在一台机器上建立索引并从其他机器上检索。 Hadoop 不适合实时处理。

Answer 3

每年 10 亿个文档意味着每秒大约 32 个文档均匀分布。

您可以在单独的机器上运行文本提取并将可索引文本发送到 Solr。我想，在这个规模上，你已经选择了多核 Solr。因此，您可以将可索引内容发送到不同的核心。这应该会加快索引速度。

我已经完成了 1 亿范围内的小型结构化文档的索引，而在单个内核上没有太多麻烦。您应该能够使用单个 solr 实例扩展到 1 亿个文档。 （文本提取服务可以使用另一台机器。）

在Hathi Trust's blog 上阅读有关各种挑战和解决方案的大规模搜索。他们使用 Lucene/Solr。