假设我们需要创建一个系统，该系统使用大量实时的文档数据流，并在这些文档可用时将这些文档与一组用户定义的搜索查询进行匹配。这是一种前瞻性的，而不是回顾性的搜索服务。什么是适当的持久性解决方案？
假设用户希望查看与其查询匹配的文档的实时Feed（请参阅Google快讯），并且Feed必须为每个文档显示某些元数据。让我们假设比赛的无限期寿命;即，系统将允许用户从创建特定查询的时间开始查看查询的所有匹配。因此，流中的每个文档的元数据以及文档与匹配该文档的用户查询之间的关联必须保存到数据库中。
让我们提出另一个要求，即用户希望能够对某些元数据进行分析：例如，用户只想查看其元数据字段“结果类型”等于“博客”的特定查询的匹配文档。并希望计算博客数量。
以下是一些假设数字：
每天在数据流中有200,000个新文档。
- 每个文档的元数据都是持久的。
1000个用户，每个用户大约有5个搜索查询：大约5000个用户搜索查询。
- 这些查询是简单的布尔查询。
- 随着每个新文档的进入，它将针对所有5000个查询进行处理，以查看哪些查询匹配。
每个Feed（每个用户查询一个）每分钟刷新一次。换句话说，对于每个Feed，每分钟都会对数据库进行最新匹配页面的查询。
向用户显示Feed的速度至关重要。可扩展性和高可用性也是必不可少的。
用户和查询之间的关系是关系型的，查询和匹配文档之间的关系也是如此，但文档元数据本身只是键值对。所以我最初的想法是将关系数据保存在像MySQL这样的关系数据库和NoSQL数据库中的元数据中，但是可以在NoSQL DB中实现切面要求吗？此外，构建一个feed然后需要调用两个独立的数据存储，这是额外的复杂性。或者将所有内容都推送到MySQL中，但这需要大量的连接和计数。如果我们将所有数据作为键值对存储在其他类型的数据存储中，那么我们将如何进行分面处理？对于匹配多个搜索查询的文档，会有大量冗余元数据。
哪种数据库适合这种情况？我知道Twitter Storm和Yahoo S4等工具可以用来构建这样一个系统的整体架构，但考虑到数据存储，我想关注数据库。 ，数量和查询/分面要求。
答案 0 :(得分：0)
首先，我不同意本。每天200k新记录与一天86,400秒相比，所以我们说的是每秒三条记录。这不是惊天动地，但对于新数据来说这是一个值得尊敬的剪辑。
其次，我认为这是人们面临的真正问题。我不会说那个论坛不适合这个话题。
我认为问题的答案与支持的用户查询的复杂性和类型有很大关系。例如，如果查询由一堆二进制谓词组成，那么您可以从文档数据中提取特定规则，然后轻松应用规则。另一方面，如果查询包含对文档文本的复杂评分，那么您可能需要一个倒置索引与每个用户查询的评分算法配对。
我对这种系统的方法是将查询解析为可以从每个文档确定的单个数据元素（我可以称之为“查询签名”，因为结果将包含满足查询所需的所有字段）。每次加载文档时都会创建“查询签名”，然后可以使用它来满足查询。
添加新查询需要处理所有文档以分配新值。鉴于数据量，这可能需要更多的批处理任务。
SQL是否合适取决于您需要从数据中提取的功能。这又取决于用户查询的性质。 SQL就足够了。另一方面，您可能需要更复杂的工具，特别是如果您使用文本挖掘概念进行查询。
答案 1 :(得分：0)
考虑到这一点，它听起来像是一个事件处理任务，而不是一个常规的数据处理操作，因此可能值得调查Complex Event Processing系统 - 而不是使用一个系统在常规数据库上构建所有内容。在传入数据流入系统时处理对传入数据的查询。有商业系统可以达到速度和速度。高可用性标准，但我没有研究可用的OSS选项（幸运的是，quora上的人已经这样做了。）
答案 2 :(得分：0)
看看弹性搜索。它有一个过滤器功能，可以将文档与已注册的查询进行匹配。 http://www.elasticsearch.org/blog/2011/02/08/percolator.html