Mongoid或MongoMapper？
我已经尝试了MongoMapper，它function完备（提供几乎所有的ARfunction），但使用大型数据集时性能不是很满意。 有没有人比较Mongoid？ 任何性能收益？
我已经使用MongoMapper一段时间，但决定迁移到MongoId。 原因是隐藏的问题加上对用户的傲慢。 为了使MongoMapper和Cucumber一起工作（最终成功），并且添加了一些补丁程序，即使这个项目很简单，但我不得不花费一点时间。 当我尝试提交一个错误修复（由于与ActiveRecord不兼容），他们似乎生气了，我发现了一个问题，我被推了出去。 在testing的同时，我也遇到了一个查询实现的重大错误，而他们的testing是以testing通过的方式进行调整的。 经过我以前的经验，不敢提交。
与MongoId相比，他们的请求数量和bug / feature提交数量要低得多，即社区参与率要低得多。 和我一样的经历？
我现在不知道哪一个有更多的function，但在MongoMapper中我看不到太多的未来。 我不介意自己修复问题和添加function，但是当他们不修复错误时，我会介意的。
过去几周我一直在使用这两种方法。 Mongomapper更好地支持关系协会（非embedded式），并拥有更多的第三方支持。 Mongoid有更好的查询支持，更好的文档（MM几乎没有，尽pipe一个网站据说在工作中），Rail 3支持（并因此Devise支持）和一个更活跃的社区在Google网上论坛。
我结束了与Mongoid。
差异
MongoMapper
- 声称更好地支持关系协会。
- 由于其插件架构，声称更具可扩展性。
- 使用DSL进行查询。
- 在MongoMapper中，多对多关联只是单向更新的。
- 对embedded式文档不太可靠的支持。 即使只修改了一些属性，也会更新整个模型。
Mongoid
- build议比轶事证据更快于MongoMapper。
- 更强大的embedded式文档支持，使用MongoDBprimefaces操作（$ set，$ push，$ pull等）来就地更新嵌套文档。
- 支持双向多对多关联。
- 使用可链式ARel-like语法进行查询。
相似
- MongoMapper和Mongoid都有很好的文档。 MongoMapper早已声称有不好的文档，但他们的新网站似乎缩小了差距。
- 两者都可以通过YAML文件进行configuration，并且都有一个用于该文件的轨道生成器。
- 两者完全兼容Rails 3。
组态
MongoMapper
defaults: &defaults host: 127.0.0.1 port: 27017 development: database: database_name Mongoid
development: sessions: default: database: database_name hosts: - 127.0.0.1:27017
第三方图书馆
双方都声称有更好的第三方支持。 Github揭示了以下内容：
- search“Mongoid”得到12671个结果。
- search“MongoMapper”会得到4708个结果。
值得注意的是，Devise不支持MongoMapper。
提交活动
在过去的一年中，看起来Mongoid比MongoMapper更经常维护和更新。
MongoMapper
Mongoid
我发现的一个区别是，MongoMapper中的update_attribute似乎写入整个文档，无论实际改变了什么属性。 在Mongoid中，它只写入已更改的属性。 对于大型logging，这可能是一个重要的性能问题。 embedded式文档（这里是labels ）尤其如此，例如
profile = Profile.find(params[:id]) label = profile.labels.find_or_create_by(idx: params[:idx]) # MongoMapper doesn't have find_or_create_by for embedded docs # -- you'll have to write custom code profile.save
在save ，MongoMapper将保存整个profilelogging，但MongoId将使用具有位置逻辑的$set运算符来更新已更改的标签。
另一个问题是select要返回的字段。 两者都支持only标准，但Mongoid也支持Mongo本地支持的without标准。
在我看来，Mongoid在它的API中更加“圆润”和完整，这可能说明它是一个更大的代码库。 它也似乎更好logging。
你安装了mongo_ext吗？ 我认为性能与驱动程序比映射程序本身更相关。 当看着蒙哥日志时，我可以看到没有扩展名，这个交易者似乎有一些滞后。
也请按照他们在monogdb网站上的build议，只select你需要的字段。
上个星期做了一些MongoMapper的testing，虽然稳定，但是我发现查询界面有一定的局限性（也有一些AR逻辑很古怪），今天切换到了Mongoid，感觉好多了 – 如果你用的更直观到AR。
目前还没有速度的结论 – 但切换是无痛的 – 它也适用于Rails 3。
如果你使用的是Rails3，我推荐Mongoid – 它也使用“include”而不是inheritance“<”来坚持类 – 使用“include”是Ruby中更好的范例来增加持久性。 deviseMongoid对我很好。
为了提高性能，请尝试select性地使用较低级别的访问权限，例如轻便摩托车 – 我已经看到这个速度快了10倍
我使用了他们两个，他们将在function上相当，但看看它的代码统计 
它看起来像MongoMapper有更好的代码质量（如果它相同与较less）。
你可以自己计算这个数据，这里是分析器https://github.com/alexeypetrushin/code_stats
我认为Mongoid在configuration和映射方面要好得多。
我期望性能是相同的，上次我检查MongoMapper缺乏Rails 3的支持 – 所以我现在正在看Mongoid。
sudo gem install mongo_ext是获得性能的关键。
MongoDB在原始速度方面吹走了CouchDB–虽然CDB确实有它自己的优势。
基准： http ://www.snailinaturtleneck.com/blog/?p= 74
Devise不支持MongoMapper，我也喜欢用Rails3的方式。 于是我转向了mongoid。
我希望以下几点为上面的答案增加值。
1.Monoid是完全与Rails 3兼容的，并且在整个地方使用ActiveModel（validation，序列化等），其中MongoMapper仍然专注于Rails 2，并使用可validation的gem进行validation。
2.Mongoid正式支持Ruby 1.8.7，1.9.1和1.9.2。
3.Mongoid更强大地支持embedded式文档，在内部的任何层次结构上执行MongoDBprimefaces操作。 （$ set，$ push，$ pull等）。 用MM你需要明确地告诉它做这些操作。
4.MongoMapper有更好的关联关系支持，默认是这样工作的。
5.MongoMapper更具扩展性，插件架构使人们可以很容易地使用自己的库进行扩展。 Mongoid没有这个。
6.MM支持标识地图，Mongoid没有。
7.MM有更大的社区，可能还有更多的第三方库支持。 我疯狂的文档和rdoc。
8.Mongoid支持Master / Slave复制集群。 （写入主，循环读取奴隶）MM不。
9.Monoid拥有极其丰富的ARel风格标准API，MM使用AR2风格的发现者。
