Question

我一直在使用couchdb中的图形结构（具有命名关系的属性图）进行建模，并且想知道我将找到的性能瓶颈是什么。

我使用以下原则：

保持文件小。
尝试尽可能少地嵌入。
将文档之间的所有关系记录为新文档（链接）。

似乎所有这些原则都与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的{{1}}文档中创建了以下视图：

links

我可以使用这些网址获取文档传入或传出的所有链接：

{
  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文档。
为每个元素保留标记历史很容易。

糟糕的事情，以及我需要你帮助的地方：

查询带有标签的人员列表并非易事。通常，查询文档列表及其关系是一项非常昂贵的操作，需要很多命中。
更新数据库并保持一致可能是个问题。也许这是使用沙发时永远不会消失的东西。
对数据库进行“维护”，例如查找孤立链接，可能会很昂贵。也许数据库需要垃圾收集？
可视化和操作此图形结构既不直观也不简单，在其上开发的应用程序负责所有图形结构管理（这有点可怕！）。

回到我的问题：

期待的潜在瓶颈是什么？
这种方法会扩展到数百万条记录吗？
如何有效地遍历此结构而无需进行多次服务器命中？

Answer 1

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

在couchdb中建模图形的含义

1 个答案: