mongodb - 图形数据库与文档数据库与三重存储

Question

这是一个有点抽象和笼统的问题。我对不同方法的固有(以及特定于实现的)属性感兴趣，以通过大量内部引用(类似图形)和大量属性(类似 JSON)来持久化非结构化数据。

• 由于图是树的超集，您可以将图 DB(例如 Neo4j)视为文档 DB(例如 MongoDB)的超集。也就是说，图形数据库提供了文档数据库的所有功能，另外还允许循环或具有 native 指针类型，因此您不必手动取消引用外键/ID。那么，当您向对象/资源添加更多引用时，您是否会遇到一些转折点，您最好使用图形数据库，但以前使用文档存储更好？文档 DB 是否有优势(存储空间、性能？)还是应该始终使用图形 DB，以防将来需要更多引用？

• 同样，图 DB 和三元存储(例如 RDF 存储)如何比较？图 DB(其中节点和边具有属性)似乎是简单三元组的超集。那么对于什么问题(如果有的话)执行三元存储实际上更好，比如 Neo4j？ (RDF 存储的一个优点是有一种标准化的查询语言 - SPARQL - 尽管似乎有很多人不喜欢 SPARQL，因此将其称为缺点。)

我想我的问题是:图模型(带有属性)似乎能够巧妙地表达各种数据，当你进入现实时有什么问题？我想图形数据库的捕获是性能，所以我很想看到一些数字或经验法则，了解加载、查询和修改数据以及内存和持久存储要求时会出现什么样的减速(与文档相比)和三重商店)。水平可扩展性又如何？我的印象是那里的竞争环境很公平。

您认为具有可表达性的图有可能成为没有超大数据的项目的新默认存储模型，还是我们注定要十年 Polyglot Persistence与 RDBMS、JSON 存储和 Graph DB 并存，必须与更多胶水代码集成？

Answer 1

我不确定我是否同意很多人不喜欢 SPARQL 的观点。 SPARQL 1.0 确实有一些缺点，但它很好地解决了它的设计目的，新的迭代 SPARQL 1.1 在此基础上添加了许多人们期望在原始规范中看到的 SQL 构造，包括子查询、聚合& 更新语义。我认为它是标准的，并且您可以期望在每个三元组存储中看到相同的解析和语义，而不是 SQL 方言，这是一个不错的功能。

我还声称所有三元存储都是图形数据库；您可以将属性放在 RDF 中的特定边上，尽管不如使用 Neo4j 的那么好。但是三元存储具有真正的查询语言的优势，一种 w3c 标准数据表示，可以轻松地将您的数据带到另一个三元存储，并且对于许多三元存储，能够执行基于 OWL 的推理。

我对大多数图形数据库的可扩展性一无所知，但一般来说，商业 RDF 数据库的可扩展性很好。所有这些都可以扩展到数十亿个三元组，可以处理大量用例。尽管他们处理规模的方式因供应商而异，以扩大或横向扩展、集群等。您还将看到完全不同的内存和硬件要求，以匹配每个供应商的实现。对我来说，我倾向于直接使用 EC2 实例，通常是 2XL 或 4XL，安装一个足够大的 EBS 来保存数据，我已经准备好了。

此外，一些三元存储与 Lucene 或类似技术集成以提供数据的倒排索引，现在许多存储开始包含地理空间和时间索引。这些是非常有用的功能，我不确定它们在 Neo4j 之类的东西中是否可用。

话虽如此，它们的扩展性不如关系数据库，只是不够成熟。但是，当您拥有“真实”数量的数据时，您也不会被搞砸。当然，三元存储的优势之一是推理，大规模执行是很棘手的，但这也是创建各种 OWL 配置文件的主要原因。但是如果你不提前考虑，你可以把自己画到一个角落里。

我认为图形数据库，特别是三元存储，可以很好地匹配许多正在构建的应用程序，但我不认为这意味着一切都应该用它们来完成。像其他任何东西一样，它们是具有优点和缺点的工具，因此您必须根据您的应用程序做出正确的选择。但如今，它们可能总是值得至少考虑一下。