database - 在大型数据库中达到性能和可伸缩性之间的适当平衡

Question

我正在尝试确定众多数据库模型中的哪一个最能支持概率记录比较。具体来说，我有大约 2000 万份由各种属性(名称、类型、作者、所有者等)定义的文档。文本属性在数据集中占主导地位，但仍然有大量图像。相对于性能而言，读取操作是最关键的，但我预计每周将插入大约 20,000 个新文档。幸运的是，插入速度根本不重要，我很乐意将传入文档排队以进行受控处理。

数据库查询通常采用以下形式:

• 查找包含至少五个引用军人的句子的文档
• 在给定用户 A 的整个评论历史的情况下，预测用户 A 是否会对用户 B 撰写的特定文档发表评论
• 通过比较词汇、词序、句子结构和概念流来预测文档 X 的作者

我的第一个想法是使用一个简单的 document store喜欢，喜欢MongoDB ，因为每个文档不一定包含相同的数据。但是，复杂的查询会有效地将其降级​​为文件系统包装器，因为我无法构建产生我想要的结果的查询。因此，这种方法使我不得不遍历整个数据库并分别处理每个文件。尽管文档存储可以很好地横向扩展，但这里并没有体现出优势。

这让我意识到我的粒度不是在文档级别，而是实体关系级别。因此，graph databases似乎是合乎逻辑的选择，因为它们有助于将句子中的每个词与下一个词、下一段、当前段落、词性等相关联。图形数据库限制数据复制，提高统计聚类的速度，并横向扩展等事物。不幸的是，确保对您的查询的明确答案仍然需要遍历整个图。即使如此，索引仍将有助于提高性能。

我还评估了关系数据库的使用，如果设计得当(即避免不必要的规范化)，它们会非常高效。关系数据库擅长查找用户 A 创作的所有文档，但在结构比较(涉及昂贵的连接)方面失败。关系数据库还可以有效地执行约束(主键、外键、唯一性等)——这是一些 NoSQL 解决方案难以完成的任务。

在考虑了上面列出的要求之后，是否有任何数据库模型结合了关系模型的“精确性”(viz.，领域的有效耗尽)和图的灵 active 数据库？

Answer 1

这不是一个真正的答案，只是一个讨论。

你说的数据库是一个大型数据库。您没有提及文档的性质，但报纸文章通常在 2-3k 范围内，因此您谈论的是数百 GB 的原始数据。

如果查询性能是一个问题，那么您正在谈论的是一个庞大且相当昂贵的系统。

您的要求也相当复杂，而且不太可能是开箱即用的。我会想到一个混合系统。将文档元数据存储在关系数据库系统中，因此您可以通过简单的查询快速访问它们。您可以将文档本身作为 blob 存储在数据库中。

您的一些要求可以通过关系数据库上的文本插件来满足。因此，使用倒排索引技术进行简单搜索是可行的。这会处理您的三个场景中的第一个。

另外两个更具挑战性。第三个(“预测作者”)可能可以通过一个并行系统来处理，该系统存储作者信息，在加载文档时从文档中汇总。然后是使用简单的统计分析(朴素贝叶斯，任何人？)将文档与作者进行比较的问题。

中间的部分比较棘手，但它建议使用另一个组件来管理文档评论。根据音量，这可能很容易也可能很难。

最后，要求有多大变化？你真的知道系统应该做什么吗？或者，一旦启动并运行，功能会完全不同吗？