我正在考虑使用不同的图形数据库来替换我在 SQL 中编码的依赖查询（最初使用递归 CTE，然后使用优于 CTE 的循环和临时表）。
下载和学习五个不同的（有点免费的）图形数据库并查看哪个（如果有）优于 CTE 并不是一件简单的事情。我希望有大量 Tiger 经验的人能够运行测试并报告性能。我怀疑其他人可能有类似的问题。
测试的依赖图很简单。我创建了第一个模式的 100 万个示例，以及第二个模式的 110 万个示例。
（百万）
1-a->20
1-b->21
20-a->30
30,null
20-b->40
40,null
21-b->50
50-b->60
60,null
（110 万）
5-a->6
6-a->7
7-a->8
8-a->9
9-c->12
为了澄清符号，1-a->20 表示有一个节点 (1) 通过标记为“a”的边指向另一个节点 (20)。同一节点 (1) 还通过标记为“b”的边指向 (21)。节点(30)不指向任何其他节点。
查询的目标是产生类似的输出
1 a [20,30]
1 b [21, 50, 60]
20 a [30]
20 b [40]
21 b [50, 60]
50 b [60]
对于第一个模式的每个实例。因此，给定第一个模式的 100 万个，我们将产生上述输出的 100 万个。
和像这样的输出
5 a [6,7,8,9]
6 a [7,8,9]
7 a [8,9]
8 a [9]
9 c [12] -- this does not show up in the output, see below
对于第二个模式的每个实例。因此，有 110 万个这样的输出。
更清楚地说，(1) 表示模式中的示例节点。将有 100 万个这样的节点，每个节点都有自己的 id。同样，将有 100 万个类似 (2) 的节点，但每个节点都有自己的 id。
简单来说，我要问的是，对于图中的每个节点，从该节点出来的标记相似的路径是什么。
在我的 sql 案例中，我还可以限制每个（源节点、标签）对的路径长度。我在运行测试时不使用该功能，但我很想知道是否可以支持这样的功能（基本上，一个节点具有元数据，说明从该节点跟踪路径的距离）。
输入记录没有按顺序显示，因此我的 sql 仅当节点在给定路径标签上没有进一步的依赖关系时才将路径标识为完整的。换句话说，8-a->9 终止了 (5)、(6)、(7) 和 (8) 的 a-路径，因为 (9) 没有 a-依赖性。同样，30,null 终止 (1) 和 (20) 的 a-path，因为 30 没有依赖项（因此没有 a-依赖项）。应该清楚的是，当节点没有依赖项（null）或具有依赖项（但对于特定路径标签没有）时，路径将终止。当一个节点记录到达时，它的所有依赖关系都是已知的。缺乏秩序意味着我可能在获得 (1) 之前获得 (21)，但这绝不意味着我在与 (1,a,21) 不同的时间获得 (1,a,20)。如前所述，当一个节点到达时，它知道它的所有依赖项（在 null 情况下可能为零）。
我意识到这是一个解释，但我希望它是一个简单的图形算法。基本上，给定任何节点，遵循来自该节点的所有依赖路径，其中依赖路径是所有边缘标签与起点处的标签匹配的路径。该算法需要足够聪明，以意识到有时可能会丢失节点（换句话说，该算法不应返回任何未终止路径的记录）。在测试数据中，我故意终止了除 9-c->12 之外的所有路径，这就是为什么 9 c [12] 不应出现在输出中的原因。如果 12,null 在输入中，那么它会显示出来，但没有提供该输入，因此 9-c->12 路径未终止。
再次，很抱歉冗长的解释。SQL 的实现非常快，所以我希望熟悉 TigerGraph 的人也能快速实现。
我意识到性能取决于机器，所以如果有人可以提供，我很乐意下载 TigerGraph 并在我的同一台机器上运行
(1) 插入语句构建测试图
(2) 查询运行。
如果它对任何人都有价值，我可以写一篇文章展示 SQL 中的实现作为 CTE 和循环，然后如何使用分区进一步提高性能。然后我可以将其与 TigerGraph 结果进行比较。我已经看到 Clickhouse 多次超出我的预期。我希望同样被老虎所震撼。非常感谢任何可以提供帮助的人。
最后一点。正如我所提到的，我的节点随机到达，非常快，作为单个插入。GraphBlas 无法处理这个问题。我只是想确定 Tiger 不必在每次添加节点时都重新构建图形 - 我不断且高速地添加和删除节点。