有人提议我们将有关两个顶点之间关系的数据存储在它们之间的边上。这个想法是这两个顶点是相关的，并且有一些用户级别的信息希望存储在图中。我能想到的最好的例子是一本书和一个阅读器，阅读器可以在边缘存储悬崖笔记以供以后检索。
这是常见的做法吗？在我看来，我们应该尽量减少边缘中的数据量，并且绝大多数 GraphDB 数据都是派生数据，而不是将其用作实际的数据存储。鉴于它在内存中，当它下降时会发生什么？ （我们使用的是 Neptune，所以……技术上有备份）。
对不起，如果问题有点模糊，但我不知道如何问。我在谷歌上四处寻找最佳实践以及与图数据库的概念和理论相关的所有非常通用的数据。
另外一个问题，将 gremlin API 直接暴露给用户是常见的做法，还是应该总是在它前面有一个 GraphQL（或其他）API？
【问题讨论】：
标签： gremlin graph-databases amazon-neptune
如果没有太多额外的细节，很难提供准确的建模建议，但总的来说，使用图数据库的优点之一是边是一等公民，并且允许边上的属性。一个常见的用例类似于PERSON - purchases -> Product，您可能在purchases 边缘有一个purchase_date 来表示购买日期，因为有人可能会多次购买相同的东西。
我不确定您所说的 that a vast majority of GraphDB data be derived data 到底是什么意思，因为您可以使用图表根据连接推导和推断数据/关系，但它们也完全支持在其中存储数据。
Given that its in memory, what happens when it goes down? - Amazon Neptune（和大多数其他 DBS）使用缓冲区缓存将一些数据存储在内存中，但这些数据也会持久保存到磁盘，因此如果实例出现故障，从持久存储。
An additional question, is it common practice to expose the gremlin API directly to users, or should there always be a GraphQL (or other) API in front of it? - 与任何数据库一样，我不建议将 Gremlin API 直接暴露给消费者，因为这样做会带来大量潜在的安全风险。通常，任何应用程序的底层数据存储都应该对用户透明。他们应该与 REST/GraphQL 之类的接口进行交互，该接口旨在回答与业务相关的问题，并且并不真正知道或关心是否有图形数据库支持这些请求。
【讨论】：