database - AWS Neptune DB 与 Dynamo DB 的实体沿袭

Question

我正在尝试评估最适合以下用例的方法:

存在一组可以表示为图的实体。图中的每个顶点代表一个实体，每个(单向边)代表一个子级到父级的关系。一个实体可能有多个父实体，一个父实体可能有多个子实体。通常，有一个所有实体都可以追溯到的“主”实体。不能删除任何实体。要求是应该很容易追踪任何实体的所有祖先。以下是我想评估的一些条件:

深树(最高的祖先可以很远)vs.浅树(最高的祖先通常不远)

宽遍历路径(一个顶点可以有很多父节点)与窄遍历路径(一个顶点通常没有很多父节点)

我错过的任何其他重要条件

以此图为例:



在常规的类似 DynamoDB 的数据库中，这将表示为:

-------------------
entity | parents  |
-------------------
A      | []       |
-------------------
B      | [A]      |
-------------------
C      | [A]      |
-------------------
D      | [A]      |
-------------------
E      | [B, C, D]|
-------------------
F      | [C, D]   |
-------------------

预先存在的条件是:

我对 DynamoDB 更加熟悉，但对 NeptuneDB 或任何图形数据库只有非常基本的熟悉，因此 DynamoDB 需要较少的前期时间投入。另一方面，NeptuneDB 当然更适合关系图存储，但在什么情况下值得技术开销呢？

Answer 1

当然，建模和存储连接数据的方法有很多种。正如您所观察到的，您可以像示例中一样使用邻接列表存储图形。在处理高度连接的数据时，Amazon Neptune 等图形数据库真正能提供帮助的是查询的创建和执行。例如，使用 Gremlin 查询语言(Neptune 支持 TinkerPop/Gremlin 和 RDF/SPARQL)，找到顶点“E”的最远祖先可以像这样简单:

g.V('E').repeat(out()).until(__.not(out()))

无论树有多深，查询都保持不变。如果要使用邻接列表对数据建模，则必须自己编写代码来遍历“图形”。像 Amazon Neptune 这样的图形数据库引擎经过优化，可以高效地执行这些类型的查询。

总而言之，您可以使用 Dynamo 或 Neptune 来完成，但是如果图形变得复杂，那么使用具有一组内置图形查询功能的图形数据库应该会使您在编写查询以遍历图形。正如您所指出的，决定将归结为重用您已经熟悉的知识与学习新知识以获得轻松编写和执行查询的能力之间的权衡，无论连接的数据变得多么复杂。我希望这有助于你做出这个决定。

您将在此处找到使用 Gremlin 建模和遍历树的简单示例:

http://www.kelvinlawrence.net/book/PracticalGremlin.html#btree