在 GraphDB 的边缘存储数据
Storing data on edges of GraphDB
有人建议我们存储关于两个顶点之间的关系的数据，这些顶点位于它们之间的边上。这个想法是这两个顶点是相关的，并且有一些用户级别的信息希望存储在图中。我能想到的最好的例子是一本书和一个 Reader，Reader 可以在边缘存储悬崖笔记以供以后检索。
这是普遍做法吗？在我看来，我们应该尽量减少边缘中的数据量，并且绝大多数 GraphDB 数据都是派生数据，而不是将其用作实际的数据存储。鉴于它在内存中，当它出现故障时会发生什么？ （我们使用的是 Neptune，所以……有技术上的备份）。
抱歉，如果问题有点含糊，但我不确定如何提问。我在谷歌上四处寻找最佳实践及其所有与图形数据库的概念和理论相关的非常通用的数据。
另一个问题，直接向用户公开 gremlin API 是常见的做法，还是应该在它前面始终有一个 GraphQL（或其他）API？
如果没有太多额外的细节，就很难提供精确的建模建议，但一般来说，使用图形数据库的一个优点是边是第一个 class 公民，并允许边上的属性。一个常见的用例类似于 PERSON - purchases -> Product，其中您可能在 purchases 边上有一个 purchase_date 来表示购买日期，因为有人可能会多次购买相同的东西.
我不确定你所说的 that a vast majority of GraphDB data be derived data 到底是什么意思，因为你可以使用图表来推导和推断 data/relationships 基于连接，但它们也完全支持在其中存储数据。
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 这样的界面进行交互，该界面旨在回答与业务相关的问题，而不真正知道或关心是否有图形数据库支持这些请求。
有人建议我们存储关于两个顶点之间的关系的数据，这些顶点位于它们之间的边上。这个想法是这两个顶点是相关的，并且有一些用户级别的信息希望存储在图中。我能想到的最好的例子是一本书和一个 Reader，Reader 可以在边缘存储悬崖笔记以供以后检索。
这是普遍做法吗？在我看来，我们应该尽量减少边缘中的数据量，并且绝大多数 GraphDB 数据都是派生数据，而不是将其用作实际的数据存储。鉴于它在内存中，当它出现故障时会发生什么？ （我们使用的是 Neptune，所以……有技术上的备份）。
抱歉，如果问题有点含糊，但我不确定如何提问。我在谷歌上四处寻找最佳实践及其所有与图形数据库的概念和理论相关的非常通用的数据。
另一个问题，直接向用户公开 gremlin API 是常见的做法，还是应该在它前面始终有一个 GraphQL（或其他）API？
如果没有太多额外的细节，就很难提供精确的建模建议，但一般来说，使用图形数据库的一个优点是边是第一个 class 公民，并允许边上的属性。一个常见的用例类似于 PERSON - purchases -> Product，其中您可能在 purchases 边上有一个 purchase_date 来表示购买日期，因为有人可能会多次购买相同的东西.
我不确定你所说的 that a vast majority of GraphDB data be derived data 到底是什么意思，因为你可以使用图表来推导和推断 data/relationships 基于连接，但它们也完全支持在其中存储数据。
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 这样的界面进行交互，该界面旨在回答与业务相关的问题，而不真正知道或关心是否有图形数据库支持这些请求。