背景:以下是书“图形数据库”中提到的性能测试(Neo4j在行动中):
图中的关系自然形成路径。查询或遍历该图涉及以下路径。由于数据模型从根本上讲是面向路径的,大多数基于路径的图形数据库操作都与数据的布局方式高度一致,使得它们非常高效。在他们的“Neo4j In Action”一书中,Partner和Vukotic使用关系存储和Neo4j进行了一个实验。比较表明,图形数据库对于连接数据的速度要比关系型store.Partner要快得多,Vukotic的实验试图在社交网络中找到朋友的朋友,最大深度为5。在任意两个人随机选择的情况下,是否有一条连接他们最多五段关系的道路?对于一个由100万人组成的社交网络,每个人都有大约50个朋友,研究结果强烈表明,图表数据库是连接数据的最佳选择,如表2-1所示。表2-1.在关系数据库中查找扩展朋友与高效查找Neo4j深度关系数据库执行时间(s)、Neo4j执行时间(s)记录分别返回2 0.016 0.0 1~2 500 3 30.267 0.168 ~110,000 4 1543.505 1.359~60万~5未完成2.132 ~80万深二(友友)关系数据库和图形数据库的表现,足以让我们考虑在一个在线系统中使用它们。虽然Neo4j查询运行的时间是关系查询的三分之二,但最终用户几乎不会注意到两者之间的毫秒之间的差异。然而,当我们深入到第三层(朋友之友)时,关系数据库显然无法在合理的时间框架内处理查询:对于一个在线系统来说,完成它所需的30秒是完全不可接受的。相反,Neo4j的响应时间相对来说是持平的:只需一秒钟就可以执行查询--对于在线系统来说绝对足够快。在第四个深度,关系数据库显示了严重的延迟,使得它对在线系统几乎毫无用处。Neo4j的计时也有一点恶化,但是对于一个响应性的在线系统来说,延迟是可以接受的。最后,在第五层,关系数据库只需太长时间就可以完成查询。相反,Neo4j在大约2秒内返回一个结果。在第五层,我们发现几乎整个网络都是我们的朋友:对于很多现实世界的用例,我们可能会减少结果和时间。
发布于 2014-05-15 09:30:36
看一下这个叫做Facebook的剖析的文档,我注意到中位数是100。看一看累积函数图,我可以打赌平均值会更高,接近200。所以50似乎不是这里最好的数字。然而,我认为这不是这里的主要问题。
主要问题是缺乏关于如何使用数据库的资料。
一个专门为图形结构设计的数据存储比传统的RDBMs更有效,这似乎是合理的。然而,即使RDBMs没有在最新的趋势中作为数据存储的选择,这些系统在与数据集维度的竞争中不断发展。有各种可能的设计,各种索引数据的方法,与并发性相关的改进等等。
最后,我认为在可重现性方面,本研究缺乏对数据库模式设计的适当描述。我不认为数据库会在这样的审讯中占据主导地位,但我认为,如果设计得很好,差异就不会那么大。
发布于 2015-05-10 21:12:49
在RDBMS中有良好的/快速的图形建模方法,也有哑/慢的方法。
因此,这种比较很可能是不正确的,并且基于糟糕的RDBMS方面的设计,尽管正如前面的答案所指出的,如果没有它们100%的代码和表定义的开源,就不可能确定。
https://datascience.stackexchange.com/questions/77
复制相似问题