关系数据库与图数据库的比较

use*_*220 80 sql relational-database graph-databases

有人可以向我解释一个关系数据库(例如MySQL)与Neo4j等图形数据库相比的优缺点吗?

在SQL中,您有多个表,其中各种ID链接它们.然后你必须加入连接表.从新手的角度来看,为什么要将数据库设计为需要连接,而不是将连接从一开始显示为边缘,就像使用图形数据库一样.从概念上讲,对新手来说没有任何意义.据推测,这有一个非常技术但非概念性的原因?

dan*_*111 101

两种风格背后都有概念推理.维基百科关于关系模型图形数据库给出了很好的概述.

主要区别在于,在图形数据库中,关系存储在各个记录级别,而在关系数据库中,结构定义在更高级别(表定义).

这有重要的后果:

  • 在大量记录上操作时,关系数据库要快得多.在图形数据库中,每个记录都必须在查询期间单独检查,以便确定数据的结构,而这在关系数据库中是提前知道的.
  • 关系数据库使用较少的存储空间,因为它们不必存储所有这些关系.

如果关系中存在很多变化,那么仅在个人记录级别存储所有关系才有意义; 否则你只是一遍又一遍地重复相同的事情.这意味着图形数据库非常适合不规则,复杂的结构.但在现实世界中,大多数数据库需要定期的,相对简单的结构.这就是关系数据库占主导地位的原因.

  • 在其他情况下,在记录级别存储关系也是有意义的,因为它提供了无索引的邻接.也就是说,可以在没有索引查找的情况下执行图遍历,从而获得更好的性能.并且它不是重复,因为您存储的实际关系不同. (15认同)
  • 您说:"在图形数据库中,每个记录都必须在查询期间单独检查,以确定数据的结构".这是图数据库的通用属性,或者一般情况下或多或少是真的吗?OrientDb如何支持顶点和边的完整模式? (4认同)
  • 我强烈不同意这两点。有外键时,图形数据库总是更快。因为我们不需要联接操作。关系数据库必须将外键存储在许多表中。边缘和外键应占用相同的存储空间。 (3认同)
  • @cegprakash您是否还有一个文档,可以从中得出相同的结论? (3认同)

Jim*_*ber 93

图形和关系数据库之间的关键区别在于,关系数据库与集合一起工作,而图形数据库与路径一起工作.

对于RDBMS用户来说,这表现为意想不到且无益的方式.例如,当试图通过递归地加入关系数据库来模拟路径操作(例如,朋友的朋友)时,查询延迟随着内存使用而不可预测地和大规模地增长,更不用说它折磨SQL来表达那些类型的操作.更多数据意味着在基于集合的数据库中速度较慢,即使您可以通过明智的索引来延迟痛苦.

正如Dan1111暗示的那样,大多数图形数据库都没有遭受这种联合痛苦,因为它们在基本层面上表达了关系.也就是说,关系在物理上存在于磁盘上,它们被命名,定向,并且可以自己用属性修饰(这称为属性图模型,请参阅:https://github.com/tinkerpop/blueprints/wiki/Property-Graph - 模型).这意味着如果您选择,您可以查看磁盘上的关系并查看它们如何"加入"实体.因此,关系是图数据库中的第一类实体,并且在语义上远远强于在关系存储中在运行时实现的那些隐含关系.

那你为什么要关心?有两个原因:

  1. 图形数据库比连接数据的关系数据库快得多 - 这是底层模型的优势.这样做的结果是,图形数据库中的查询延迟与您在查询中选择探索的图形的数量成正比,并且与存储的数据量不成比例,从而解除了连接炸弹的影响.
  2. 图形数据库使建模和查询更加愉快,这意味着更快的开发和更少的WTF时刻.例如,在Neo4j的Cypher查询语言中表达典型社交网络的朋友朋友就是MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

  • 这种比较似乎有点偏颇.缺点怎么样? (49认同)
  • 这需要一个_massive_警告:这个人是Neo Technology的"首席科学家",他制作了Neo4J图形数据库. (30认同)
  • 一点?在我的诚实意见中太偏颇了.看起来像"这是一个好产品!买这个"广告给我充其量! (6认同)
  • 任意搜索怎么样...给我过去 90 天内在 walmart 购物的所有 35 岁到 55 岁的用户。 (6认同)
  • "因此,关系是图数据库中的第一类实体".在关系数据库中通常也是如此:实体被映射到关系中的元组,许多关系也是如此.您为一对多关系描述的区别是否经常合并为实体关系? (3认同)
  • 这个答案存在巨大的利益冲突。-1 (2认同)

Wal*_*tty 18

Dan1111已经给出了一个标记为正确的答案.其他几点值得一提.

首先,在几乎每个图形数据库的实现中,记录都是"固定的",因为有一些未知数量的指针指向其当前位置的记录.这意味着,如果不在旧位置留下转发地址或打破未知数量的指针,则无法将记录拖放到新位置.

从理论上讲,人们可以立即对所有记录进行洗牌,并找到一种方法来定位和修复所有指针.在实践中,这是一个在大型图形数据库上可能需要数周时间的操作,在此期间数据库必须停止运行.这是不可行的.

相比之下,在关系数据库中,记录可以在相当大的范围内重新调整,唯一需要做的就是重建受影响的任何索引.这是一个相当大的操作,但远不及图形数据库的等效操作.

值得注意的第二点是,万维网可以被视为一个巨大的图形数据库.网页包含超链接和超链接引用,以及其他网页.引用是通过URL,其功能类似于指针.

当网页移动到不同的URL而不在旧URL上留下转发地址时,将会破坏未知数量的超链接.这些断开的链接然后引起可怕的"错误404:页面未找到"消息,这打断了这么多冲浪者的乐趣.

  • 只有大多数图形数据库具有不允许断开链接的完整性规则. (4认同)

Uli*_*hke 6

使用关系数据库,我们可以使用外键和自连接来建模和查询图形.仅仅因为RDBMS'包含关系这个词并不意味着他们善于处理关系.RDBMS中的关系一词源于关系代数而非关系.在RDBMS中,关系本身并不作为对象存在.它需要显式地表示为外键,或者隐式地表示为链接表中的值(当使用通用/通用建模方法时).数据集之间的链接存储在数据本身中.

我们在关系数据库中增加搜索深度越多,我们需要执行的自连接越多,查询性能就越高.我们在层次结构中越深入,我们需要连接的表就越多,查询得到的速度就越慢.数学上,成本在关系数据库中呈指数级增长.换句话说,我们的查询和关系越复杂,我们就越能从图形与关系数据库中受益.导航图形时,我们在图形数据库中没有性能问题.这是因为图形数据库将关系存储为单独的对象.但是,优越的读取性能是以较慢的写入为代价的.

在某些情况下,更改图形数据库中的数据模型比在RDBMS中更容易,例如在RDBMS中,如果我将表关系从1:n更改为m:n我需要应用具有潜在停机时间的DDL.

另一方面,RDBMS在其他方面具有优势,例如聚合数据或对数据进行带时间戳的版本控制.

我在关于数据仓库的图形数据库的博客文章中讨论了一些其他优缺点

  • “RDBMS 中的关系一词源于关系代数”——有点像。“而不是来自关系。”——不是 FK 意义上的关系,而是关系,因为关系代数和 RDBMS 中的关系来自代表关系/关联的表意义上的关系。由于误解关系模型的方法,FK 被错误地称为关系。FK 不需要已知或存在即可记录或查询。他们是为了诚信。查询的必要和充分条件是了解(基础或查询结果)表所代表的关系/关联。 (2认同)

Moh*_*ari 5

虽然关系模型可以轻松表示图模型中包含的数据,但我们在实践中面临两个\n重大问题:

\n\n
    \n
  1. SQL 缺乏轻松执行图遍历的语法,尤其是\n深度未知或无界的遍历。例如,\n使用 SQL 确定朋友的朋友很容易,但解决 \xe2\x80\x9c 分离度\xe2\x80\x9d 问题却很难。
  2. \n
  3. 当我们遍历图表时,性能会迅速下降。每个级别的遍历都会显着增加查询响应时间。
  4. \n
\n\n

参考:下一代数据库

\n

  • 递归 SQL 解决了这两个问题。Postgres、SQL Server、Oracle,现在甚至 MySQL 都支持递归查询。 (2认同)