graph - 在CouchDB中对图形建模的含义

Question

我一直在尝试在沙发数据库中对图结构(具有命名关系的属性图)进行建模，并且想知道我会发现性能的潜在瓶颈是什么。

我使用以下原则:

保持文档较小。

尝试尽可能少地嵌入。

将文档之间的所有关系记录为新文档(链接)。

似乎所有这些原则都与CouchDB哲学相抵触，

以此原则为例，例如，标记一个人将成为三个文档:

{ _id: '10', type: 'person', 'name': 'John Doe' }
{ _id: '20', type: 'tag', 'name': 'Important' }
{ _id: '30', type: 'link', from: 10, to: 20, name: 'tag' }

我还在名为 _design的 links文档中创建了以下 View :

{
  outgoing: {
    map: function(doc) {
      if (doc.type == 'link') {
        emit([doc.from, doc.name], {_id: doc.to});
      }
    }
  },
  incoming: {
    map: function(doc) {
      if (doc.type == 'link') {
        emit([doc.to, doc.name], { _id: doc.from });
      }
    }
  }
}

我可以使用以下网址获取文档中所有传入或传出的链接:

http://host/db/_design/links/_view/incoming?startkey=["10"]&endkey=["10",{}]
http://host/db/_design/links/_view/outgoing?startkey=["10"]&endkey=["10",{}]

我什至可以使用以下网址按名称获取所有链接:

http://host/db/_design/links/_view/incoming?startkey=["10","tag"]&endkey=["10","tag",{}]
http://host/db/_design/links/_view/outgoing?startkey=["10","tag"]&endkey=["10","tag",{}]

如果我加入 include_docs=true参数，我将获得链接所引用的文档；传入或传出。到目前为止，一切都很好。有一个图结构和一种查询它的方法，尽管是逐个节点地进行的。

关于这种方法的好处:

这是存储所有关系的一种通用方法。不一定是标签，而是每种关系。

您可以快速更改标签名称，而无需更改每个被标记的人。

您可以合并人员或标签，而只是更新link文档，这应该非常简单。

使用复制时加标签不会更改被加标签的文档或标签本身。只需添加或删除一个小的link文档。

保留每个元素的标签历史很容易。

不好的事情，以及我需要您帮助的地方:

查询带有标签的人员列表并非易事。通常，查询文档及其关系列表是一项非常昂贵的操作，需要许多匹配。

更新数据库并使之保持一致可能是一个问题。也许这是使用沙发时永远不会消失的东西。

在数据库上进行“维护”，就像查找孤立链接一样，可能会很昂贵。也许数据库需要垃圾回收？

可视化和操作这种图形结构既不直观也不简单，并且在其之上开发的应用程序负责所有图形结构的管理(这有点吓人!)。

回到我的问题:

可能会遇到哪些潜在瓶颈？

这种方法会扩展到数百万条记录吗？

如何有效地遍历此结构而不必执行许多服务器操作？

Answer 1

您的问题是疯狂而复杂的。
您可能不想要这个答案，但是，您是否看过ArangoDB？它是具有图形功能的分布式文档存储。