我试图弄清楚neo4j使用哪种图形算法/哪种类型的图形结构。
它具有定向和标记的边缘。也可以将属性存储在节点和边缘中。
Neo4j是labeled property graph。
对于物理结构，我们为事物提供存储：节点存储，关系存储，属性存储，标签存储，字符串存储等。>>
这些只是具有固定格式的多个条目的文件，因此图形存储中的每个条目都具有相同的格式，关系存储中的每个条目都具有相同的格式，依此类推，并且条目之间存在指针（图形ID）。因此，图形ID实际上是用于商店中链接的元素和相关元素之间的指针跳跃的偏移量。
逻辑上，节点存储中的节点条目具有指向其他存储中其他条目的各种指针，例如其标签以及关系链中的第一个关系。关系具有指向关系的起点和终点以及链中上一个和下一个关系的指针。并且节点和关系都有指向构成其属性链开始的第一个属性条目的指针。
因此从逻辑上讲，我们具有连接某些元素（每个节点的属性链，每个节点的关系链）的链表结构。但是对于通过关系进行节点之间的连接，在对图形进行建模时在白板上绘制的内容非常接近结构中发生的事情，节点和关系之间直接相互链接，指向彼此在相关商店中的条目文件。
我们确实有一些冗余之处可以加快查找速度……节点在节点条目本身中保留了一些标签，而关系保留了它们的类型。
这也是最简单的抽象，我们在密集节点上使用的格式稍有不同，因此我们可以根据节点的类型和方向来存储节点上的关系，从而可以根据我们要查找的内容而不是对象来快速选择相关的关系必须考虑并过滤所有存在的关系。
因此，这是物理结构的高级概述。不过，更有趣的是为什么选择了这种结构，它允许什么，以及这些因素如何影响本地图形数据库在图形和遍历大量用例中相对于关系数据库的竞争性。
所有这些的要点是关系遍历不使用表联接或其等效项。遍历关系/模式的成本不是基于图中的总关系或节点，而是仅基于实际的关系和节点，存储之间的O（1）指针跳跃，节点-> rel->节点等。
这是称为index-free adjacency的本机图形数据库的特征，并且由我们使用的商店格式启用。这是主要原因，对于图形用例和连接的数据，您应考虑在关系数据库上（或在非本地图数据库或仅位于关系数据库之上的覆盖图上）使用本机图数据库。] >
因此，如果我们位于节点1且与其他节点具有3个关系，并且图中有100亿个节点和500亿个关系，则遍历模式中的下一个节点将非常快。共有多少个关系或节点无关紧要，仅关系到当前节点中是否存在3个关系，因此我们进行了三个O（1）指针跃点（以及任何过滤），并继续从这些跃点遍历三个节点作为尝试查找适合该模式的路径。遍历的成本与您最终触摸/遍历的图形的任何部分成正比，而不是图形的总大小。
当然，要创建关系，您通常必须进行表连接的等效操作……通过某些属性在节点上进行匹配（通常使用用于在图形中查找入口点的索引结构），然后在它们之间创建关系。
所以是的，索引查找确实起作用，但是它们发生在关系创建期间。一旦创建了关系，遍历它们的查询将变为O（1），指针跳动以及您想要执行的其他任何过滤操作的成本。我们将连接成本抵消为关系创建的费用，以便优化运行时遍历速度。
剩余的索引用法是用于在图形中查找入口点，一旦有了这些入口点，遍历便成为焦点，而我们再次只是指针跳动，没有与数据大小相关的表联接。
[其中一个我的同事Max De Marzi的旧博客条目includes a description and visualization of the store format可能会有所帮助。它在某些方面有些过时（博客条目和链接的视频均来自2012年），我们一直在寻找优化和调整商店格式以提高性能的方法，但该条目的实质是事项：
关系有点像一个明显的表联接，但是我们在关系创建上而不是遍历上付出代价。对于遍历，我们只是指针跳变，并且不会随着数据的增长而减慢速度，表联接的方式在关系数据库中也是如此。