首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >这个Neo4j与关系数据库管理系统的执行时间比较正确吗?

这个Neo4j与关系数据库管理系统的执行时间比较正确吗?
EN

Data Science用户
提问于 2014-05-15 01:22:35
回答 2查看 1.2K关注 0票数 10

背景:以下是书“图形数据库”中提到的性能测试(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秒内返回一个结果。在第五层,我们发现几乎整个网络都是我们的朋友:对于很多现实世界的用例,我们可能会减少结果和时间。

问题是:

  • 这是否是一个合理的测试,以模仿一个人除了在社交网络中可能发现什么?(这意味着,真正的社交网络通常有大约50个好友的节点;似乎"有钱人富起来“模式对于社交网络来说更自然,尽管可能是错的。)
  • 不管模拟的自然程度如何,是否有理由相信结果是错误的,或者说是不可复制的?
EN

回答 2

Data Science用户

回答已采纳

发布于 2014-05-15 09:30:36

看一下这个叫做Facebook的剖析的文档,我注意到中位数是100。看一看累积函数图,我可以打赌平均值会更高,接近200。所以50似乎不是这里最好的数字。然而,我认为这不是这里的主要问题。

主要问题是缺乏关于如何使用数据库的资料。

一个专门为图形结构设计的数据存储比传统的RDBMs更有效,这似乎是合理的。然而,即使RDBMs没有在最新的趋势中作为数据存储的选择,这些系统在与数据集维度的竞争中不断发展。有各种可能的设计,各种索引数据的方法,与并发性相关的改进等等。

最后,我认为在可重现性方面,本研究缺乏对数据库模式设计的适当描述。我不认为数据库会在这样的审讯中占据主导地位,但我认为,如果设计得很好,差异就不会那么大。

票数 8
EN

Data Science用户

发布于 2015-05-10 21:12:49

在RDBMS中有良好的/快速的图形建模方法,也有哑/慢的方法。

  • 有些人使用聪明的索引和存储过程,交易CPU负载和调优RAM磁盘上的临时表,以加快图形检索速度。
  • 有些人使用预先计算的图形路径(在社交网络场景中这可能不太可行,但是在大多数节点是叶节点的树中,这是一个很好的时间交换空间。)
  • 有些只是在循环中计算,使用未调优的索引临时表。从文章中的S,闻起来就像他们所做的那样(比如,在非常小的数据集上30秒的性能),我有自己的树计算。
    • 它封装在一个高度调优的存储proc中。
    • 当它在企业规模的Sybase ASE15数据服务器中运行时,该服务器与来自所有其他企业应用程序的几兆字节的数据共享,其中一些数据比我的更需要数据;而且并不是专门用于执行我的查询。
    • 我无法访问主加速工具,即RAM磁盘上的临时表。
    • 我正在检索的一组有代表性的数据似乎与他们的数据相匹配,那就是从2.5M节点的全森林数据集中获取15万个节点子树(无限树的深度,其变化范围在5到15之间,但与实验中列出的50个朋友相比,给定节点的平均可用性要小得多)。
    • 我把它调到了这个查询大约30-45秒的程度。毫无疑问,问题中的数据似乎表明了RDBMS性能上的指数减速,这是额外的双重奇怪,因为结果集没有指数增长(在我看来,结果集上有一些未经调整的索引,根据个人经验)。

因此,这种比较很可能是不正确的,并且基于糟糕的RDBMS方面的设计,尽管正如前面的答案所指出的,如果没有它们100%的代码和表定义的开源,就不可能确定。

票数 4
EN
页面原文内容由Data Science提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://datascience.stackexchange.com/questions/77

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档