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

有人可以向我解释关系数据库(如MySQL)与graphics数据库(如Neo4j)相比的优缺点吗?

在SQL中,你有多个表与不同的ID链接它们。 那么你必须join连接表。 从一个新手的angular度来看,为什么要devise数据库来要求连接,而不是从一开始就像graphics数据库那样将连接明确地视为边缘。 从概念上讲,这对新手来说是没有意义的。 据推测,这有一个非常技术性但非概念性的原因?

实际上这两种风格背后都有概念推理。 维基百科上的关系模型和graphics数据库给出了这个很好的概述。

主要区别在于,在graphics数据库中,关系存储在单个logging级别,而在关系数据库中,结构是在较高级别(表格定义)中定义的。

这有重要的影响:

  • 在大量logging上操作时,关系数据库要快得多。 在graphics数据库中,为了确定数据的结构,每个logging必须在查询过程中单独进行检查,而这在关系数据库中是事先知道的。
  • 关系数据库使用的存储空间较less,因为它们不必存储所有这些关系。

在个人logging层次上存储所有关系只有在关系中存在很多变化时才有意义; 否则你只是一遍又一遍地重复相同的事情。 这意味着graphics数据库非常适合不规则的复杂结构。 但是在现实世界中,大多数数据库需要规则的,相对简单的结构。 这就是为什么关系数据库占主导地位。

graphics和关系数据库之间的主要区别在于关系数据库使用集合,而graphics数据库使用path。

这performance为RDBMS用户意想不到的和无益的方式。 例如,当试图通过recursion地join关系数据库来模拟path操作(例如朋友的朋友)时,查询延迟随着内存使用量的增长而不可预知地大量增长,更不用说它折磨SQL来expression这些types的操作。 更多数据意味着在基于集合的数据库中速度较慢,即使您可以通过明智的索引来延缓痛苦。

正如Dan1111所暗示的,大多数graphics数据库不会遭受这种连接的痛苦,因为它们expression了基本的关系。 也就是说,关系在物理上存在于磁盘上,并且它们被命名,定向,并且可以用属性自己装饰(这被称为属性图模型,参见: https : //github.com/tinkerpop/blueprints/wiki/Property-Graph模型 )。 这意味着如果你select,你可以看看磁盘上的关系,看看他们如何“join”实体。 因此,关系是图数据库中的第一类实体,在语义上远远强于在关系存储中在运行时指定的隐含关系。

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

  1. graphics数据库比连接数据的关系数据库要快得多 – 这是底层模型的一个优势。 这样做的结果是,graphics数据库中的查询延迟与您在查询中select探索的图表的多less成正比,并且与所存储的数据量不成比例,从而消除了联合炸弹 。
  2. graphics数据库使build模和查询更加愉快,意味着更快的开发和更less的WTF时刻。 例如,用Neo4j的Cypher查询语言expression一个典型的社交networking的朋友,就是MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf

为了更全面地评估graphics数据库与关系型商店的优势,我们可以在http://graphdatabases.com上find一个(免费的!)O'Reilly电子书,叫做Graph Databases(请注意:我是本书的作者之一)。 因为它是O'Reilly的一本书,所以它永远不会是免费的,但是我们已经得到了出版商的许许多多的许可,所以现在得到一个。

Dan1111已经给出了一个正确答案。 还有几点值得一提。

首先,几乎在graphics数据库的每个实现中,logging都是“固定的”,因为在其当前位置有指向logging的未知数目的指针。 这意味着如果不在旧位置留下转发地址或打破未知数量的指针,则不能将logging洗牌到新的位置。

从理论上讲,可以立即洗牌所有的logging,并找出一种方法来定位和修复所有的指针。 在实践中,这是一个在大型graphics数据库上可能需要数周才能完成的操作,在此期间,数据库将不得不closures。 这是不可行的。

相比之下,在关系数据库中,logging可以在相当大的范围内重新组合,唯一需要做的就是重build任何受影响的索引。 这是一个相当大的操作,但是远不及graphics数据库的等价值。

第二点值得一提的是,万维网可以被看作是一个巨大的graphics数据库。 网页包含超链接,超链接引用其他网页。 引用是通过URL,其function像指针。

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

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

我们越是增加关系数据库中的search深度,我们需要执行的自我连接越多,查询性能就越糟糕。 我们越深入,我们需要join的表越多,查询得到的速度就越慢。 在math上,成本在关系数据库中呈指数增长。 换句话说,我们的查询和关系越复杂,我们从graphics和关系数据库中受益越多。 导航graphics时,我们在graphics数据库中没有性能问题。 这是因为graphics数据库将关系存储为单独的对象。 然而,卓越的读取性能是以较慢的写入为代价的。

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

另一方面,RDBMS在其他方面也有优势,例如汇总数据或对数据进行时间戳版本控制。

我在graphics数据库的博客文章中讨论数据仓库的其他优点和缺点