首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >图DBs与文档DBs与Triplestore

图DBs与文档DBs与Triplestore
EN

Stack Overflow用户
提问于 2012-08-20 18:32:02
回答 3查看 8.2K关注 0票数 32

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

  • 因为图是树的超集,所以可以将图DBs (例如Neo4j)看作文档DB的超集(例如MongoDB)。也就是说,图DB提供文档DB的所有功能,另外还允许循环或具有本机指针类型,这样就不必手动取消引用外键/ is。那么,在添加更多对对象/资源的引用时,是否存在这样的临界点:使用图形DB更好,但以前使用文档存储更好?文档DBs (存储空间、性能)是否有优势?还是应该一直使用图DB,以防将来需要更多的引用?
  • 类似地,图DBs和triplestore(例如RDF存储)比较如何?图DB(节点和边具有属性)似乎是简单三层集的一个超集。那么,Neo4j说,对于哪些问题(如果有的话),执行triplestores实际上更好呢?( RDF商店的一个优点是,有一种标准化的查询语言-- SPARQL -尽管似乎有很多人不喜欢SPARQL,因此称它为劣势。)

我想我的问题是:图形模型(带有属性)似乎能够很好地表达各种数据,当你进入现实时,什么是陷阱呢?我认为图形DBs的问题在于性能,所以我希望看到一些数字或经验法则,说明在加载、查询和修改数据以及内存和持久存储需求(与文档和三重存储相比)时会出现什么样的减速。此外,水平可伸缩性如何?我得到的印象是,那里的竞争环境相当公平。

您是否认为,对于没有超大型数据的项目来说,具有表示性的图形是否会成为新的默认存储模型,或者我们是否注定要使用关系数据库管理系统、JSON存储和图形数据库来实现十年的多标记持久性,而这些数据库必须与更多的粘合代码集成?

EN

回答 3

Stack Overflow用户

发布于 2012-08-20 19:37:53

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

我还声明所有三重存储都是图形数据库;您可以在RDF中将属性放在特定的边缘上,尽管不如w/ Neo4j那么好。但是三重存储具有真正的查询语言的优势,这是一种w3c标准数据表示,它使得将数据带到另一个三层存储库变得非常简单,对于许多三重存储来说,它具有基于OWL进行推理的能力。

我对大多数图形数据库的可伸缩性一无所知,但总的来说,商业RDF数据库的扩展性相当好。所有这些都可以扩展到数十亿的三元组,这将处理大量的用例。尽管它们处理规模的方式因厂商而异,但wrt在扩展或扩展、集群等方面有很大差异。您还将看到匹配每个实现的不同的mem &硬件需求。对我来说,我倾向于抓取一个EC2实例,通常是一个2XL或4XL,挂载一个足够大的EBS来保存数据,而且我已经做得很好了。

此外,一些三重存储集成了Lucene或类似的技术来提供对数据的反向索引,许多现在开始包括地理、空间和时间索引。这些都是非常有用的特性,我不确定它们在像Neo4j这样的东西中是否可用。

尽管如此,它们不会像关系数据库那样扩展,它们只是不够成熟。但是,当你有“真实”数量的数据时,你也不会被搞砸。当然,三元组商店的优点之一是推理,但这也是创建各种OWL配置文件的主要原因。但是如果你不提前思考的话,你可以把自己画在角落里。

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

票数 12
EN

Stack Overflow用户

发布于 2013-02-22 15:00:23

只是对amk答案的一个小更正: Tinkerpop还包含一个用于ArangoDB的适配器,参见https://github.com/triAGENS/blueprints-arangodb-graph/wiki/Gremlin。因此,您可以在ArangoDB中使用Gremlin查询。

通常,像ArangoDB或OrientDB这样的多模型数据库允许您使用文档数据库的所有优点(无模式、索引)以及图形结构。顶点或边缘只是一个文档,就像文档数据库中的那样。您可以拥有任意数量的属性,甚至是嵌入的文档。可以在这些文档上定义散列、范围、全文或geo索引。或者,您可以忘记文档结构,使用Gremlin或某些遍历语言调用底层图,将文档视为顶点和边。

至于“我们是否注定要坚持”的问题:与文档/图形数据库问题无关,我相信RDBMS还会持续一段时间。因此,这个问题的答案是:“是的,这很可能”。

票数 11
EN

Stack Overflow用户

发布于 2012-08-21 09:26:13

图数据库有一个特殊的标准-- 小叮当,包括Gremlin (命令式)查询语言,除了ArangoDB以外的所有东西都支持它。

为了进一步混水摸鱼,还有混合文档-图形数据库、OrientDB和ArangoDB。

我认为,在图形数据库中使用边缘存储子关系与在文档数据库中作为嵌入对象存储子关系的一个主要区别是,对于前者,可以廉价地将子对象转移到另一个父级,而不会在两个不同位置的两个位置出现子关系。

票数 6
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/12043086

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档