Neo4j与RDBMS执行时间的比较是否正确？

背景：以下是《图形数据库》一书，其中涵盖了《Neo4j in Action》一书中提到的性能测试：

图中的关系自然形成路径。查询或遍历图涉及以下路径。由于数据模型的本质是面向路径的，因此大多数基于路径的图数据库操作与数据的布局方式高度一致，从而使其极为高效。Partner和Vukotic在他们的《行动中的Neo4j》一书中使用关系存储和Neo4j进行了实验。

比较结果表明，图数据库比关联存储要快得多。Partner和Vukotic的实验试图在社交网络中查找朋友的朋友，最大深度为5。给定随机选择的任何两个人，是否存在连接他们的路径（最多五个关系）？对于包含1,000,000人（每个人约有50个朋友）的社交网络，结果强烈表明，图数据库是连接数据的最佳选择，如表2-1所示。

表2-1。在关系数据库中查找扩展的朋友与Neo4j中的有效查找

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

关系数据库和图形数据库在两个方面（朋友的朋友）都表现良好，足以让我们考虑在在线系统中使用它们。虽然Neo4j查询的运行时间是关系查询的三分之二，但最终用户几乎不会注意到两者之间的毫秒差。但是，到了深度三（朋友的朋友）时，很明显关系数据库不再能够在合理的时间范围内处理查询：完成这三十秒将是完全不可接受的用于在线系统。相比之下，Neo4j的响应时间却相对平稳：执行查询只需几分之一秒，对于在线系统而言绝对足够快。

在深度四处，关系数据库表现出严重的延迟，这使其几乎对在线系统毫无用处。Neo4j的时间安排也略有恶化，但此处的延迟处于响应型在线系统可接受的范围之内。最后，在深度五处，关系数据库仅花费很长时间才能完成查询。相反，Neo4j在大约两秒钟内返回结果。在深度5处，它几乎渗入整个网络，这是我们的朋友：对于许多实际的用例，我们可能会调整结果和时间安排。

问题是：

• 这是一种合理的测试，可以模拟在社交网络中除了可以找到的东西以外的其他东西吗？（例如，实际的社交网络通常具有大约50个朋友的节点；对于社交网络，“ 富人致富 ”模型似乎更自然，尽管可能是错误的。）
• 不管模拟的自然性如何，是否有任何理由相信结果不正确或无法再现？

查看这份名为Facebook Anatomy的文档时，我注意到中位数为100。查看累积函数图，我敢打赌，平均值较高，接近200。因此，50似乎不是最好的数字。但是，我认为这不是这里的主要问题。

主要问题是缺乏有关如何使用数据库的信息。

专门为图形结构设计的数据存储要比传统的RDBM更高效，这似乎是合理的。但是，即使RDBM并不是最新的趋势，也不是首选的数据存储，但这些系统还是在与数据集维度的竞争中不断发展的。有各种可能的设计，各种索引数据的方法，与并发相关的改进等等。

总而言之，我认为关于可重复性，这项研究对数据库架构的设计缺乏适当的描述。我不希望数据库在这种询问之王中占主导地位，但是我希望通过精心设计，差异不会那么大。

在RDBMS中有好的/快速的方法为图形建模，而愚蠢的/缓慢的方法。

• 有些使用聪明的索引和存储的Procs，在CPU磁盘上交换CPU负载和调整的临时表，以提高图形检索速度。

• 有些人使用预先计算的图路径（在社交网络场景中这可能不太可行，但是在大多数节点为叶节点的树中，这是一个很好的时空折衷方案）

• 有些使用未调整的索引内临时表简单地循环计算。从文章中抛出的#s闻起来像他们所做的（30秒的性能，在相当小的数据集上）

  例如，我有自己的树计算。

  • 它封装在高度调整的存储过程中

  • 当它在企业级硬件的Sybase ASE15数据服务器中运行时，该服务器与所有其他企业应用程序中的TB数据共享，这比我的要多得多。并不仅限于执行我的查询。

  • 我也没有访问的主要工具加速，一个临时表RAM磁盘上。

  • 我正在检索的一组有代表性的数据似乎与他们的数据有些匹配，这是从2.5M节点完整森林数据集中获得150,000个节点子树（树的深度不受限制，在5到15之间变化，但是给定节点的平均 Arity比实验中列出的50个朋友）

  • 我将其调整为查询30〜45秒。最肯定的是，它没有表现出问题中的数字似乎表明其RDBMS性能的指数级减慢，鉴于结果集没有指数级增长（这对我来说是未经调整的索引，这很奇怪）临时表（根据个人经验）。

因此，这种比较很可能是不正确的，并且基于不良的RDBMS侧设计，尽管如先前的答案所指出的那样，如果没有他们开放100％的代码和表定义的源代码，就无法确定。