use*_*220 80 sql relational-database graph-databases
有人可以向我解释一个关系数据库(例如MySQL)与Neo4j等图形数据库相比的优缺点吗?
在SQL中,您有多个表,其中各种ID链接它们.然后你必须加入连接表.从新手的角度来看,为什么要将数据库设计为需要连接,而不是将连接从一开始显示为边缘,就像使用图形数据库一样.从概念上讲,对新手来说没有任何意义.据推测,这有一个非常技术但非概念性的原因?
dan*_*111 101
两种风格背后都有概念推理.维基百科关于关系模型和图形数据库给出了很好的概述.
主要区别在于,在图形数据库中,关系存储在各个记录级别,而在关系数据库中,结构定义在更高级别(表定义).
这有重要的后果:
如果关系中存在很多变化,那么仅在个人记录级别存储所有关系才有意义; 否则你只是一遍又一遍地重复相同的事情.这意味着图形数据库非常适合不规则,复杂的结构.但在现实世界中,大多数数据库需要定期的,相对简单的结构.这就是关系数据库占主导地位的原因.
Jim*_*ber 93
图形和关系数据库之间的关键区别在于,关系数据库与集合一起工作,而图形数据库与路径一起工作.
对于RDBMS用户来说,这表现为意想不到且无益的方式.例如,当试图通过递归地加入关系数据库来模拟路径操作(例如,朋友的朋友)时,查询延迟随着内存使用而不可预测地和大规模地增长,更不用说它折磨SQL来表达那些类型的操作.更多数据意味着在基于集合的数据库中速度较慢,即使您可以通过明智的索引来延迟痛苦.
正如Dan1111暗示的那样,大多数图形数据库都没有遭受这种联合痛苦,因为它们在基本层面上表达了关系.也就是说,关系在物理上存在于磁盘上,它们被命名,定向,并且可以自己用属性修饰(这称为属性图模型,请参阅:https://github.com/tinkerpop/blueprints/wiki/Property-Graph - 模型).这意味着如果您选择,您可以查看磁盘上的关系并查看它们如何"加入"实体.因此,关系是图数据库中的第一类实体,并且在语义上远远强于在关系存储中在运行时实现的那些隐含关系.
那你为什么要关心?有两个原因:
MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.Wal*_*tty 18
Dan1111已经给出了一个标记为正确的答案.其他几点值得一提.
首先,在几乎每个图形数据库的实现中,记录都是"固定的",因为有一些未知数量的指针指向其当前位置的记录.这意味着,如果不在旧位置留下转发地址或打破未知数量的指针,则无法将记录拖放到新位置.
从理论上讲,人们可以立即对所有记录进行洗牌,并找到一种方法来定位和修复所有指针.在实践中,这是一个在大型图形数据库上可能需要数周时间的操作,在此期间数据库必须停止运行.这是不可行的.
相比之下,在关系数据库中,记录可以在相当大的范围内重新调整,唯一需要做的就是重建受影响的任何索引.这是一个相当大的操作,但远不及图形数据库的等效操作.
值得注意的第二点是,万维网可以被视为一个巨大的图形数据库.网页包含超链接和超链接引用,以及其他网页.引用是通过URL,其功能类似于指针.
当网页移动到不同的URL而不在旧URL上留下转发地址时,将会破坏未知数量的超链接.这些断开的链接然后引起可怕的"错误404:页面未找到"消息,这打断了这么多冲浪者的乐趣.
使用关系数据库,我们可以使用外键和自连接来建模和查询图形.仅仅因为RDBMS'包含关系这个词并不意味着他们善于处理关系.RDBMS中的关系一词源于关系代数而非关系.在RDBMS中,关系本身并不作为对象存在.它需要显式地表示为外键,或者隐式地表示为链接表中的值(当使用通用/通用建模方法时).数据集之间的链接存储在数据本身中.
我们在关系数据库中增加搜索深度越多,我们需要执行的自连接越多,查询性能就越高.我们在层次结构中越深入,我们需要连接的表就越多,查询得到的速度就越慢.数学上,成本在关系数据库中呈指数级增长.换句话说,我们的查询和关系越复杂,我们就越能从图形与关系数据库中受益.导航图形时,我们在图形数据库中没有性能问题.这是因为图形数据库将关系存储为单独的对象.但是,优越的读取性能是以较慢的写入为代价的.
在某些情况下,更改图形数据库中的数据模型比在RDBMS中更容易,例如在RDBMS中,如果我将表关系从1:n更改为m:n我需要应用具有潜在停机时间的DDL.
另一方面,RDBMS在其他方面具有优势,例如聚合数据或对数据进行带时间戳的版本控制.
我在关于数据仓库的图形数据库的博客文章中讨论了一些其他优缺点