在开发Web应用程序时,您什么时候使用图形数据库而不是文档数据库?

我觉得两个世界都没有足够的经验来正确和完整地回答你的问题,但是我使用文档数据库有一段时间了,这里有一些个人提示。

文档数据库基于键、值和静态视图的概念,对于查找具有特定值的一组文档来说非常酷。

他们 不要概念化 文件之间的关系。

因此,如果您的软件必须提供高级“查询”,其中选择标准作用于多个“文档类型”,或者如果您只需要使用多个元素执行选择,则[key,value]概念不适用。

还有许多文档数据库不合适的情况:在“分页”表中显示大型数据集,在多个列上可排序是性能较低和磁盘空间使用率较低的情况之一。 巨大的 .

因此,在许多情况下,您必须执行“服务器端”处理才能收集这些片段,而使用Rails或任何其他基于Ruby的框架,您可能会遇到性能问题。

图形数据库基于TripleStore的概念,这意味着它们还概念化了实体之间的关系。

可以使用关系(和实体角色)遍历图,并且在跨关系结构化数据执行搜索时可能更方便。

由于我对图形数据库没有经验,我不知道图形数据库是否可以用几个标准轻松地查询/遍历,但是如果一个建议的读者有这样的信息,我真的会欣赏任何此类查询/遍历的例子。

我目前正在阅读关于InfoGrid的文章,并试图找出这样的数据库是否可以方便地对一组非常大的数据执行复杂的请求,包括关系…

据我所知,infograh应该被认为是一个“数据联邦”,能够搜索/挖掘多个来源(商店)的数据,它也可以是NoSQL数据库,如Mongo。

意思是你 能够 使用Mongo存储进行更新,使用信息图进行数据搜索,以及 也许吧 在NoSQL数据库中进行复杂的搜索时,可以节省大量的CPU和磁盘。

当然,如果你的应用程序只是在数据库中存储一大组巨大的二进制文件,你所需要的只是执行简单的键查询和检索结果,那么看起来有点“杀伤力”。在这个cas中,一个nosql数据库(如mongo或coach)可能很方便。

希望这些能有所帮助;)

当用边缘连接相关文档时,您会得到一个浅或深的图形吗?我认为在决定GRAPHDB和DocumentDBS时,这个问题的答案很重要。见 Square Pegs and Round Holes in the NOSQL World 由吉姆·韦伯为这些思路。