适用于实体沿袭的AWS Neptune DB与Dynamo DB

Question

我正在尝试评估在以下用例中最有效的方法：

存在一组可以表示为图形的实体。图中的每个顶点代表一个实体，每个（单向边）代表一个子对父关系。一个实体可以有多个父实体，而一个父实体可以有多个子实体。通常，存在一个“主”实体，所有实体都可以追溯到该实体。无法删除任何实体。要求是应该易于跟踪任何实体的所有祖先。以下是我要评估的一些条件：

1. 深树（最高祖先可能在很远的地方）与浅树（最高祖先通常不在很远的地方）
2. 宽泛的遍历路径（一个顶点可以有很多父级）与窄的遍历路径（一个顶点通常没有很多父级）
3. 我错过的其他重要条件

以该图为例：

在类似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