使用基于文档的nosql查询关系数据的性能(mongodb、couchdb和riak等)

Question

为了跟进我关于用nosql对关系数据建模的问题，我阅读了几篇关于这个主题的文章：

Nosql并不意味着非关系

Nosql电子商务示例

它们似乎表明，nosql可以处理规范化的关系数据。

因此，让我们继续我前面的例子，一个CMS系统，它有两种类型的数据:文章和作者，其中文章具有对author的引用(按ID)。

以下是该系统需要支持的业务：

1. 和作者一起用id获取一篇文章
2. 按特定作者获取所有文章
3. 查找前10篇文章，作者按创建日期排序。

如果将相同的数据存储在RDBMS上，与相同的操作相比，我想了解这些操作的性能。特别是，请指定该操作是否使用MapReduce，是否需要多次访问nosql存储(链接)或 预连接

我只想讨论像mongodb、couchdb和riak这样的document-based nosql解决方案。

编辑1:

春季数据项目适用于Riak和Mongodb

Answer 1

对于MongoDB，您不会对作者记录使用嵌入式文档。所以预连接退出了，它需要多次访问数据库。但是，您可以缓存作者，并且只需要对每个记录进行第二次访问。您指出的查询在MongoDB中非常琐碎。

var article = db.articles.find({id: article_id}).limit(1);
var author = db.authors.find({id: article.author_id});

如果使用ORM/ODM来管理应用程序中的实体，这将是透明的。不过，这是两次到分局的旅行。他们应该是快速反应，但两次命中不应该是显而易见的。

找到某个作者的文章正好相反..。

var author = db.authors.find({id: author_name}).limit(1);
var articles = db.articles.find({author_id: author.id});

因此，两个查询(但只有一个作者获取)应该是快速的，并且可以很容易地缓存。

var articles = db.articles.find({}).sort({created_at: 1}).limit(10);
var author_ids = articles.map(function(a) { return a.author_id });
var authors = db.authors.find({id: { '$in': authors_ids }});

最后，同样，两个查询，但只是稍微复杂一点。您可以在mongo中运行这些程序，以查看结果可能是什么样子。

我不确定这是否值得写一张地图还原完成。几次快速往返可能会有更多的延迟，但是mongo协议非常快。我不会太担心的。

最后，这样做对性能的影响.因为理想情况下，您只需要查询文档中的索引字段，所以它应该非常快。唯一的附加步骤是获得其他文档的第二次往返，取决于您的应用程序和db的结构，这可能一点也不重要。您可以告诉mongo只对占用给定阈值的配置文件查询(在默认情况下打开时为100或200 as )，因此您可以监视程序在数据增长时所花费的时间。

适合您这里的RDMS不提供的是更容易分解的数据。当您将应用程序扩展到CMS之外以支持其他内容但使用相同的身份验证存储时，会发生什么情况？现在，它恰好是一个完全独立的DB，在许多应用程序之间共享。跨dbs执行这些查询要简单得多--对于RDMS存储来说，这是一个复杂的过程。

我希望这对你的NoSQL发现有所帮助！

Answer 2

和作者一起用id获取一篇文章

SQL

• 1查询
• 2索引查找
• 2个数据查询
• 返回的数据=文章+作者

MongoDB

• 2个查询
• 2索引查找
• 2个数据查询
• 返回的数据=文章+作者

按特定作者获取所有文章

SQL

• 1查询
• 1索引查找
• N数据查找
• 返回的数据=N篇文章

MongoDB

• 1查询
• 1索引查找
• N数据查找
• 返回的数据=N篇文章

查找前10篇文章，作者按创建日期排序。

SQL

• 1查询
• 2索引查找
• 11至20个数据查找(文章，然后是唯一的作者)
• 返回的数据= 10篇文章+ 10名作者

MongoDB

• 2个查询(articles.find().sort().limit(10)，authors.find({$in:[article_authors]}) )
• 2索引查找
• 11至20个数据查找(文章，然后是唯一的作者)
• 返回的数据= 10篇文章+1至10名作者

摘要

在两种情况下，MongoDB需要额外的查询，但大多数相同的工作都是在下面完成的。在某些情况下，MongoDB通过网络返回的数据较少(没有重复的条目)。join查询往往受到以下要求的限制:所有要连接的数据都在同一个框上。如果作者和文章生活在不同的地方，那么您最终会执行两个查询。

MongoDB倾向于获得更好的“原始”性能，因为它并不是每次写入都会刷新到磁盘上(因此它实际上是一种“持久性”权衡)。它还有一个小得多的查询解析器，因此每个查询的活动较少。

从基本性能的角度来看，这些事情非常相似。他们只是对你的数据和你想做的权衡做出不同的假设。