图数据库与关系数据库时间和空间复杂性

Question

图表和关系数据库的横向时间复杂度是多少？

Answer 1

也许您会发现这篇文章“Efficient graph management based on bitmap indices”很有帮助。在名为实验结果的第4部分中，作者在mysql，图形数据库DEX和Neo4j以及列存储MonetDB中测试相同的查询（包括查询1和2中的遍历）。

对于某个遍历操作，DEX（图形数据库）和mysql之间的差异是120秒（DEX）与12h执行（mysql）时间之间的差异。

您还可以阅读有趣的位图方法来存储图形。

Answer 2

什么更快，一台电脑或代数？

关系模型是一种思考数据的方式，一种向用户表示数据的方法。它说 nothing 关于实现。询问关系数据库的时间复杂度就像询问f(x)的时间复杂度一样。

没有SQL DBMS我使用过使用的元组线性数组来存储数据。他们都使用某种树：B树，B +树。树是图。 Ergo，图表数据库所声称的物理优势是基于，如果你问我，没有什么。

SQL DBMS在过去几年中增加了对所谓的递归查询的支持。这些查询的有效执行没有理论上的问题，我已经看到它完成了。但是查询优化器必须支持它才能使它运行良好，如果开源项目在该领域有一些工作要做，我也不会感到惊讶。

在选择武器时，不要询问“关系数据库”，而应该询问在特定实现中对递归查询处理的支持，

但要小心错误的对称性。 “图形数据库”中缺少相当长的列表。例如，关系模型基于代数，这是SQL所基于的（主要是松散的）。图论缺乏这样的代数，因此缺乏良好的操作语言。约束执行和交易都有类似的故事。

Answer 3

图形数据库的一个（也许是）关键点是不必为遍历做任何连接。

Answer 4

两者的O（N）？

图表DB的核心（https://stackoverflow.com/a/2968931/623735）有一个表格。 RDB已经发展到非常有效地处理表格。因此，大多数具有持久存储的大型GDB使用RDB来存储节点表。 GDB只是将所有传统数据表行的id堆叠成单个“节点”表（为了有效索引而分组和排序）。 GDB魔术是用于行走/探索图表的有效算法。

所以我认为GDB不会真正对两个表（遍历）进行连接，就像RDBMS对相同类型的数据进行相同类型的查询一样。 GDB只是以链表排序的方式从一个节点（节点表中的行）走到另一个节点。一旦找到您查询的节点，就会对节点属性表进行一次“遍历”，以检索您查询的信息（名称，等级，序列号;）。