Neo4j 可以比 MySQL 更快地处理一个简单的现实生活场景

Question

我将谈论 Neo4j，并且我想展示 Neo4j 可以比 MySQL 更快处理的 1 个场景。

我为像 Twitter 这样的“社交网络”创建了随机数据和 SQL 表：有 1,000,000 人，每个人都关注其他 50 个人。所以有两个表“person”和“following”：

是否有比 MySQL 查询快得多的 Cypher 查询应该执行相同的操作？

我尝试过类似“油炸的朋友的朋友”的场景，但 MySQL 很快就解决了它们......

Answer 1

对于 RDBMS 来说更困难的一种情况是当要遍历的节点（表）的类型未知时。采取一个图表，其中 :Person 节点通过不同类型的节点（:Workplace、:Organization、:School 等）建立不同的连接，并且您需要一个查询，该查询可能在两个已知节点之间的一定距离处执行可达性查询（这些节点是通过任何方式连接，或者通过使用标签和关系类型的某些子集的某种方式连接？），或者进行 Kevin Bacon 查询或类似的 7 度查询。

当您编写此类查询时，您对要遍历的节点只有很少的信息，您想知道它们是否以及如何连接，但您事先不知道此连接的确切方式。你怎么用 SQL 写这个？您通常需要提前知道要使用的连接表以及中间表（特别是如果您必须对某些中间节点进行属性过滤）。

或者，您可以以某种程度的通用性处理节点，但使用可变长度关系仍然可以获得您想要的结果，情况又如何？

例如，如果您的 :Place 节点具有 :IN_LOCATION 关系，则这些关系可以指向 :Address、:City、:State 或 :Country，具体取决于地点是什么、数据的准确性以及这些节点本身它们之间有 :WITHIN 关系，您可以尝试获取如下状态信息：

MATCH (p:Place {name:'Yosemite National Park'})-[:IN_LOCATION]->()-[:WITHIN*0..]->(state:State)
RETURN state

在此查询中，您不知道 :IN_LOCATION 关系指向的左空白节点的标签（类型）。但是您知道，如果它位于 :State 级别或以下，您希望继续遍历 :WITHIN 关系，直到到达 :State 节点（如果初始节点是 :State 节点，则可能根本不遍历任何内容），而不关心中间节点的类型。

这是 SQL 可以做的事情吗？

另外，还有一整类图算法和用例很难用 SQL 实现，有时甚至不可能实现，因为您通常不太关心要遍历的多种类型的节点。这包括最短路径算法、可达性查询、某些类型的最近 x 节点等。

还有获取子图中所有连接节点的情况，无论是不受限制的，还是仅通过某些关系可到达的子图，或仅由某些节点组成（或某些节点除外）。像这样的东西：

MATCH (k:Person{name:'Keanu Reeves'})-[:ACTED_IN|DIRECTED*..5]-(m:Movie)
RETURN collect(DISTINCT m) as movies