前瞻性（非回顾性）搜索的数据库解决方案

Question

假设我们需要创建一个系统，该系统使用大量、实时的文档数据流，并在这些文档可用时将这些文档与一组用户定义的搜索查询进行匹配。这是一项前瞻性的，而不是回顾性的搜索服务。什么是合适的持久性解决方案？

假设用户想要查看与其查询匹配的文档的实时提要（想想 Google 快讯），并且提要必须显示每个文档的某些元数据。让我们假设比赛的寿命是无限期的；即，系统将允许用户从创建特定查询时查看查询的所有匹配项。因此，流中的每个文档的元数据，以及文档与匹配该文档的用户查询之间的关联，都必须保存到数据库中。

让我们提出另一个要求，即用户希望能够对某些元数据进行分面：例如，用户希望仅查看元数据字段“结果类型”等于“博客”的特定查询的匹配文档并想要计算博客匹配的数量。

以下是一些假设的数字：

1. 数据流中每天有 200,000 个新文档。

   -每个文档的元数据都被持久化。

2. 1000 个用户，每个用户大约有 5 个搜索查询：用户搜索查询总数约为 5000 个。

   -这些查询是简单的布尔查询。

   -当每个新文档进入时，都会针对所有 5000 个查询对其进行处理，以查看哪些查询是匹配的。

3. 每个提要（每个用户查询一个提要）每分钟向用户刷新一次。换句话说，对于每个提要，每分钟都会向数据库查询最新的匹配页面。

向用户显示提要的速度至关重要。可扩展性和高可用性也很重要。

用户和查询之间的关系是相关的，查询和匹配文档之间的关系也是如此，但文档元数据本身只是键值对。所以我最初的想法是将关系数据保存在像 MySQL 这样的关系数据库中，将元数据保存在 NoSQL DB 中，但是在 NoSQL DB 中可以实现分面要求吗？此外，构建提要需要调用两个单独的数据存储，这会增加复杂性。或者也许将所有内容都推入 MySQL，但这将需要大量的连接和计数。如果我们将所有数据作为键值对存储在其他类型的数据存储中，我们将如何进行分面？对于匹配多个搜索查询的文档，会有大量冗余元数据。

什么样的数据库适合这种情况？我知道Twitter Storm 和雅虎的S4 等工具可以用来构建这样一个系统的整体架构，但考虑到数据存储、容量和查询/分面要求。

Answer 1

看看弹性搜索。它具有过滤器功能，可以将文档与已注册的查询进行匹配。 http://www.elasticsearch.org/blog/2011/02/08/percolator.html

Answer 2

考虑一下，这听起来像是一个事件处理任务，而不是常规的数据处理操作，因此可能值得研究 Complex Event Processing 系统 - 而不是在常规数据库上构建所有内容，使用处理在流入系统时查询传入的数据。有些商业系统可以达到速度和高可用性标准，但我还没有研究过可用的 OSS 选项（幸运的是，quora 上的人已经这样做了）。

Answer 3

首先，我不同意本。每天 20 万条新记录与一天 86,400 秒相比，所以我们说的是每秒 3 条记录。这不是惊天动地的，但它是一个值得尊重的新数据剪辑。

其次，我认为这是人们面临的真正问题。我不会说这个论坛不适合这个话题。

我认为问题的答案与支持的用户查询的复杂性和类型有很大关系。例如，如果查询由一堆二进制谓词组成，那么您可以从文档数据中提取特定规则，然后轻松应用这些规则。另一方面，如果查询包含对文档文本的复杂评分，那么您可能需要一个倒排索引与每个用户查询的评分算法配对。

我对这样一个系统的方法是将查询解析为可以从每个文档中确定的单个数据元素（我可以称之为“查询签名”，因为结果将包含满足查询所需的所有字段）。每次加载文档时都会创建此“查询签名”，然后可以使用它来满足查询。

添加新查询需要处理所有文档以分配新值。考虑到数据量，这可能需要更多的批处理任务。

SQL 是否合适取决于您需要从数据中提取的特征。这又取决于用户查询的性质。 SQL 可能就足够了。另一方面，您可能需要更复杂的工具，尤其是当您使用文本挖掘概念进行查询时。