开发 Web 应用程序时，什么时候会使用图形数据库还是文档数据库？
我正在使用 Rails 开发一个基于 Web 的应用程序。我正在争论是使用图形数据库（例如 InfoGrid）还是文档数据库（例如 MongoDB）。
我的应用程序需要存储小型数据集（例如 URL）和非常大的数据集（例如虚拟机）。该数据将与单个用户绑定。
我有兴趣了解人们使用图形或文档数据库的经验以及他们为什么会使用其中任何一个选项。
谢谢
I am developing a web-based application using Rails. I am debating between using a Graph Database, such as InfoGrid, or a Document Database, such as MongoDB.
My application will need to store both small sets of data, such as a URL, and very large sets of data, such as Virtual Machines. This data will be tied to a single user.
I am interested in learning about peoples experiences with either Graph or Document databases and why they would use either of the options.
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我觉得对这两个世界没有足够的经验来正确和完整地回答你的问题，但是我使用文档数据库已经有一段时间了，这里有一些个人提示。
文档数据库基于键、值和静态视图的概念，对于查找具有特定值的一组文档非常酷。
他们不概念化文档之间的关系。
因此，如果您的软件必须提供高级“查询”，其中选择标准作用于多种“文档类型”，或者您只需要使用多个元素执行选择，那么 [键，值] 概念是不合适的。
还有许多其他情况下文档数据库是不合适的：在“分页”表中呈现大型数据集，可在多个列上排序是性能低且磁盘空间使用量巨大的情况之一。
因此，在许多情况下，您必须执行“服务器端”处理才能恢复正常，并且使用 Rails 或任何其他基于 Ruby 的框架，您可能会遇到性能问题。
图数据库基于 Tripplestore 的概念，这意味着它们还概念化了实体之间的关系。
可以使用关系（和实体角色）来遍历该图，并且在跨关系结构数据执行搜索时可能会更方便。
由于我没有图形数据库的经验，我不知道图形数据库是否可以使用多个条件轻松查询/遍历，但是如果建议的读者有这样的信息，我真的很感激任何此类查询/遍历的示例。
我目前正在阅读有关 InfoGrid 的内容，并试图弄清楚此类数据库是否可以方便地对大量数据（包括关系）执行复杂的请求......
从我所读到的内容来看，InfoGrah 应该被视为一个“数据联合者”能够从多个源（商店）搜索/挖掘数据，也可以是 NoSQL 数据库，例如 Mongo。
这意味着您可以使用 mongo 存储进行更新，使用 InfoGraph 进行数据搜索，并且在 nosql 数据库内进行复杂搜索时可以节省大量的 cpu 和磁盘空间。
当然，如果您的应用程序只是在数据库中存储大量巨大的二进制文件，并且您所需要的只是执行简单的键查询并检索结果，那么这可能看起来有点“矫枉过正”。在这种情况下，nosql 数据库（例如 mongo 或 couch）可能会很方便。
希望其中一些有所帮助；）
I don't feel enough experienced with both worlds to properly and fully answer your question, however I'm using a document database for some time and here are some personal hints.
The document databases are based on a concept of key,value, and static views and are pretty cool for finding a set of documents that have a particular value.
They don't conceptualize the relations between documents.
So if your software have to provide advanced "queries" where selection criteria act on several 'types of document' or if you simply need to perform a selection using several elements, the [key,value] concept is not appropriate.
There are also a number of other cases where document databases are inappropriate : presenting large datasets in "paged" tables, sortable on several columns is one of the cases where the performances are low and disk space usage is huge.
So in many cases you'll have to perform "server side" processing in order to pick up the pieces, and with rails, or any other ruby based framework, you might run into performance issues.
The graph database are based on the concept of tripplestore, meaning that they also conceptualize the relations between the entities.
The graph can be traversed using the relations (and entity roles), and might be more convenient when performing searches across relation-structured data.
As I have no experience with graph database, I'm not aware if the graph database can be easily queried/traversed with several criterias, however if an advised reader has such an information I'd really appreciate any examples of such queries/traversals.
I'm currently reading about InfoGrid and trying to figure if such databases could by handy in order to perform complex requests on a very large set of data, relations included ....
From what I can read, the InfoGrah should be considered as a "data federator" able to search/mine the data from several sources (Stores) wich can also be a NoSQL database such as Mongo.
Wich means that you could use a mongo store for updates and InfoGraph for data searching, and maybe spare a lot of cpu and disk when it comes to complex searches inside a nosql database.
Of course it might seem a little "overkill" if your app simply stores a large set of huge binary files in a database and all you need is to perform simple key queries and to retrieve the result. In that cas a nosql database such as mongo or couch would probably be handy.
Hope some of this helps ;)
当通过边连接相关文档时，你会得到浅图还是深图？我认为在决定 graphdbs 和 documentdbs 时，这个问题的答案很重要。请参阅NOSQL 世界中的方钉和圆孔< /a> Jim Webber 的这些想法。
When connecting related documents by edges, will you get a shallow or a deep graph? I think the answer to that question is important when deciding between graphdbs and documentdbs. See Square Pegs and Round Holes in the NOSQL World by Jim Webber for thoughts along these lines.