具有数百万行深度的Postgres递归查询的性能如何？我应该用图形数据库代替吗？

Question

我试图决定是使用图形数据库还是关系数据库。我对SQL相当陌生，所以我不知道如何测试它，因为我还没有数百万行数据，但我认为这可能会成为一个问题，所以如果可能的话，我将从人们那里寻找一些轶事经验。

有人知道每个表中有数百万行的Postgres数据库递归查询的性能吗？性能通常足够好到能够通过100到200毫秒以下的web查询数据库中的数据吗？它的深度是未知的，它可能是一个或所有的大东西，如30甚至更多。

我的数据目前很好地映射到关系数据模型，因为它本质上是关系的，因此我倾向于Postgres，但我想执行一个特定的递归查询，它使我倾向于一个图形数据库。表(假设5-6)很可能是生产中每一行数以百万计的行，查询的深度基本上是未知的。这种查询的一个例子是：

Depth 1: 

EntityA transacts with -> EntityB

Depth 2:

EntityB transacts with -> EntityC
EntityB transacts with -> EntityD

...

Depth n:

until the last entities (leaves) don't transact with any other entities. At each depth, the entities can transact with many entities and the depth is unknown.

我应该仅仅因为这个1特定的查询而使用一个图形数据库，还是Postgres能够在合理的时间内使用它的递归命令来处理这个问题？

Answer 1

每当您在SQL系统中处理递归联接时，这都是一个死胡同，您实际上是在处理图形，并试图弄清楚如何使用SQL导航一个图。

在这种情况下，使用图形数据库是一个更好的选择。

关于一个更完整的答案--参见另一个相关问题的答案。Performance of arbitrary queries with Neo4j