如何在大型非文本数据集中进行搜索？

Question

在我正在处理的一个项目中，客户有一个旧且庞大（几TB）的关系型数据库。各种查询非常缓慢，没有时间去修复/重构架构。我已经确定了需要优化的常见查询集合。这个集合被划分为两部分：全文和元数据查询。

我的计划是从他们的数据库中提取数据，并将其分区到两个不同的存储系统中，每个系统针对特定查询集合进行优化。

对于全文搜索，Solr是最合适的引擎。它的分片和复制功能使其非常适合解决其中一半的问题。

对于元数据查询，我还不确定该采取什么路线。目前，我考虑使用一个极度去规范化的模式的关系型数据库，该模式代表“权威”RDBMS中的特定数据子集。然而，我的客户担心这样的子系统缺乏分片和复制以及设置这些功能的困难/复杂程度，与Solr相比，后者已经包含了这些功能。在这种情况下，元数据采用整数、日期、布尔值、位和字符串（最大长度为10个字符）的形式。

是否有具有内置分片和复制功能的数据库存储系统，可能特别适用于查询上述元数据？也许有一些非关系型数据库解决方案提供了良好的查询引擎？

请指点迷津。

Solr也可以用于元数据，但元数据是易变的。因此，我需要经常提交索引以保证搜索性能。这会导致搜索速度迅速下降。

- Newbie

---

啊，你不想在Solr中进行元数据查询的原因是什么呢？它完全能够处理所有其他数据类型。 - Femi

Solr可以用于元数据，但是元数据是易变的。因此，我需要经常提交索引。这会导致搜索速度相当快地降低。嗯，也许一些可以缓解这个问题的索引管理策略可以产生期望的结果？我会考虑一下的。 - Newbie

啊，我原本以为数据库大部分是历史和静态的，不会快速变化。你现在开始进入分布式搜索领域了：我预计你将不得不在其他解决方案的基础上自己编写索引管理（或者如果你有预算的话，可以付钱让别人为你编写 :)) - Femi

元数据有多少数据？ - Charles Lambert

@Charles，问题很好，元数据的大小大约在几百GB左右，存储不到1TB。粗略地说，任何时候都是500GB-1000GB。这种特殊情况是由于我打算实施某种档案保管政策，以区分实时搜索和基于作业的搜索（例如：您的搜索将花费一些时间进行处理，请几分钟后回来查看结果）。在这个问题的背景下，当然，我是在处理近实时的用例。 - Newbie

Answer 1

RavenDB:

• 它内置Lucene，可用于全文搜索。
• 它可以进行复制。
• 它支持分片。
• 它有一个HTTP API，因此您原则上可以从任何平台使用它。

缺点：它是AGPL许可证。根据您的开发/服务器环境，您可能认为在.NET上运行是一个缺点。此外，我不知道除.NET之外的其他平台的客户端状态。

Solandra:

• 集成了Solr和Cassandra
• Solr管理全文搜索
• Cassandra管理复制和分片

缺点：尚未发布。

ElasticSearch:

• 它内置了Lucene用于全文搜索。
• 它可以进行复制。
• 它支持分片。
• 它有一个HTTP API，因此您原则上可以从任何平台使用它。

ElasticSearch看起来与RavenDB相似，但它似乎强调全文搜索，而RavenDB则强调成为通用的NoSQL数据库。

- Mauricio Scheffer

---

这些数据库是否自动管理Lucene索引（在后台）？（例如，索引碎片化是否仍然需要编写代码来解决） 如果这些数据库的搜索依赖于Lucene，那么我是否最好拥有两个不同的Solr部署，以满足我的两种查询需求？ 就额外价值而言，我有点困惑为什么要使用您推荐的数据库，而不是我最终仍将使用的Solr。感谢您的帮助！ - Newbie

@新手：我对这两个数据库都没有第一手的经验（不过我有Solr的经验），但它们声称对近实时搜索（你的最后一个要求）有很好的支持。 - Mauricio Scheffer

@新手：添加了ElasticSearch，它还声称可以进行准实时搜索。 - Mauricio Scheffer

@新手；RavenDb在后台工作进程中处理其Lucene索引，这提供了“最终一致性”的概念，这意味着它们可能过时，但仍然提供结果。但是，您可以编写Map/Reduce索引，并使用名为Live projections的功能将数据映射到子集中，然后将该数据投影到索引中，并从多个文档类型中组合数据。 - Mikael Östberg

Answer 2

使用MongoDB作为您的元数据存储器：

• 内置分片
• 内置复制
• 故障转移和高可用性
• 简单的查询引擎，适用于大多数常见情况

然而，缺点是无法执行联接操作。在数据去规范化时要聪明，以避免这种情况。

- alan

---

据我所知，MongoDB不包括全文搜索，这是OP的要求之一！ - Mauricio Scheffer

他已经想出了解决方案的全文本部分，他正在寻找一个单独的系统来搜索元数据。 - alan

集成是一项不容易的任务... 我建议的引擎都提供了这两种功能，集成。 - Mauricio Scheffer

Answer 3

我相信您已经意识到，在频繁更新的系统中，无法获得快速的查询时间。要在关系型数据库管理系统上实现分片，您需要找到一些关键点来拆分记录并填充多个数据库。然后，您可以同时查询它们以地图减少方式获取和处理数据。这将使您能够随着数据的增长而增加机器的数量，并可能使您能够提高操作的速度。从快速的谷歌搜索结果来看，MongoDB和Hadoop都提供此地图/减少功能，但我对两者都不熟悉。

生成复杂的长时间运行报告是很常见的。但是，当报告完成生成时通常会附带电子邮件通知。这是与人类接口的良好推送通知格式。此外，如果这些报告按周期性方式（例如每周、每月等）预期，则仍可以在这些报告准备就绪时使用电子邮件通知，唯一的区别是自动生成的启动时间。

- Charles Lambert

---

又有一个忍者点了踩。请留下评论，让我知道为什么会收到它。 - Charles Lambert

Answer 4

如果您使用elasticsearch，您可以将元数据作为JSON文档的额外键简单地添加进去：

{
    "message": ... your full text,
    "date": "2009-11-15T14:12:12",
    ...
}

然后您可以同时使用两种搜索。否则，如果您仍然想采用两个系统的方法，monogoDB 是一个文档存储器，具有自动分片功能，并具有一些相当先进的查询机制（字段、MapReduce、用于快速查询的索引）。

- Bashwork