在开发Web应用程序时，您何时使用Graph数据库而不是Document数据库？

我正在使用Rails开发基于Web的应用程序。我正在讨论使用图形数据库（如InfoGrid）或文档数据库（如MongoDB）。

我的应用程序需要存储两组小数据（如URL）和非常大的数据集（如虚拟机）。此数据将绑定到单个用户。

我有兴趣了解人们使用Graph或Document数据库的经历以及为什么他们会使用其中任何一个选项。

谢谢

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

文档数据库基于键，值和静态视图的概念，并且非常适合查找具有特定值的一组文档。

他们没有概念化文件之间的关系。

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

还有许多其他文档数据库不合适的情况：在“分页”表中显示大型数据集，在多列上排序是性能低且磁盘空间使用量巨大的情况之一 。

因此，在许多情况下，您必须执行“服务器端”处理以获取部分，并使用rails或任何其他基于ruby的框架，您可能会遇到性能问题。

图数据库基于tripplestore的概念，这意味着它们也概念化了实体之间的关系。

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

由于我没有图形数据库的经验，我不知道是否可以使用多个标准轻松查询/遍历图形数据库，但是如果建议读者有这样的信息，我真的很感激这些查询/遍历的任何示例。

我目前正在阅读有关InfoGrid的信息，并试图确定这些数据库是否可以派上用场，以便对一大堆数据执行复杂的请求，包括……

从我可以阅读的内容来看，InfoGrah应该被视为一个“数据联合者”，能够搜索/挖掘来自多个来源（商店）的数据，这些数据源也可以是像Mongo这样的NoSQL数据库。

这意味着您可以使用mongo存储进行更新，使用InfoGraph进行数据搜索，并且在nosql数据库中进行复杂搜索时可能会占用大量的cpu和磁盘。

当然，如果您的应用程序只是在数据库中存储大量的大型二进制文件，并且您只需要执行简单的键查询并检索结果，那么它似乎有点“过度杀伤”。在那个cas中，诸如mongo或者沙发之类的nosql数据库可能会很方便。

希望有些帮助 ;）

通过边连接相关文档时，您会得到浅图还是深图？我认为在决定graphdbs和documentdbs之间时，这个问题的答案很重要。参见NOSQL World中的Square Pegs和Round Holes， Jim Webber就这些思路进行了思考。