在 Rails 3 中从 SQl 切换到 MongoDB
我正在考虑将一个相当大的应用程序(Rails 3.0.10)从我们的 SQL 数据库(SQLite 和 Postgres)切换到 MongoDB。我打算把所有东西都放进去,主要是utf-8字符串、二进制文件和用户数据。 (也许还有一点全文搜索)我有复杂的关系(网络结构:类别、标签、翻译...,还有多态),我觉得 MongoDB 的哲学是避免这种情况并将所有内容放在大文档中,我是对的吗?
有人有在 Rails 中使用 MongoDB 的经验吗?特别是将应用程序从 ActiveRecord 切换到 Mongoid ?你认为这是个好主意吗?您知道学习 MongoDB 组织复杂数据方式的指南/文章吗?
ps:在 MongoDB 中,我特别喜欢它的架构和性能导向所提供的自由。这是我考虑转变的主要个人动机。
I am considering switching a quite big application (Rails 3.0.10) from our SQL database (SQLite and Postgres) to MongoDB. I plan to put everything in it, mainly utf-8 string, binary file and user data. (Maybe also a little full text search) I have complex relationships (web structure: categories, tags, translations..., polymorphic also) and I feel that MongoDB philosophy is to avoid that and to put everything in big document, am I right ?
Does anyone have experience with MongoDB in Rails ? Particularly switching a app from ActiveRecord to Mongoid ? Do you think it's a good idea ? Do you know a guide/article to learn the MongoDB way to organize complex data ?
ps : In MongoDB, I particularly like the freedom offers by its architecture and its performance orientation. It's my main personal motivations to consider the switch.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我使用 mongodb 和 mongoid,持续了 5-6 个月。还使用过 postgres + AR、MySQL + AR。没有将 AR 切换到 mongoid 的经验。
您是否面临任何性能问题或预计很快就会遇到这些问题?如果不是,我建议避免切换,因为这个决定似乎只是基于 Mongodb 的酷度因素。
它们都有各自的优点和缺点,我喜欢 mongodb 的速度,但是要实现这一点有很多限制(比如没有连接、没有事务支持以及慢速字段与字段(updated_at >created_at)查询) 。
如果存在性能问题,我仍然建议坚持使用当前系统,因为切换可能是一项艰巨的任务,如果您花一半的时间来优化当前系统会更好。读完这个问题后,我感觉你以前从未使用过 mongodb,有很多事情可能会困扰你,你不会完全知道如何解决它们。
但是,如果您仍然坚持切换,则需要仔细评估您的数据结构以及查询它们的方式。在关系数据库中,您拥有范式,其优点是无论您使用什么结构开始,一旦进行规范化,您将大致达到相同的最终结果。在 mongodb 中,您可以通过几乎无限的方式对文档进行建模。您需要仔细地对文档进行建模才能利用 mongodb 的优势。您需要运行的查询以及您想要存储的实际数据在您的结构化中发挥着非常重要的作用。
请记住,您在 mongodb 中没有连接(可以通过良好的建模来缓解)。截至目前,您不能进行类似
field1 = field2
的查询,即您无法比较字段,但需要提供用于查询的文字。看看这个问题: 在 MongoDB 中存储数据的有效方法:嵌入式文档与单独文档。有人向 OP 指出了推荐嵌入文档的讨论,但在非常相似的情况下,OP 选择使用独立文档,因为他将用来获取数据的查询的性质。
我想说的是,这应该是一个明智的决定,应该在你用 mongodb 完全建模你的系统之后做出,用一些真实数据进行一些性能测试,看看 mongodb 是否能解决你的问题,而不应该基于酷因素。
更新:
您可以使用
$where
子句执行field1 = field2
,但速度较慢,建议避免。I am using mongodb with mongoid, for 5-6 months. Have also worked with postgres + AR, MySQL + AR. Have no experience with switching AR to mongoid.
Are you facing any performance issues or expect to face them soon? If not I would advice to avoid the switch, as the decision seems just to be based on coolness factor of Mongodb.
They both have their pros and cons, I like the speed of mongodb, but there are many restrictions on what you can do to achieve that(like no joins, no transaction support and slow field vs. field(updated_at > created_at) queries).
If there are performance issues, I would still recommend to stick with your current system, as the switch might be a big task and it would be better if you spend half the time in optimizing the current system. After reading the question, I get a feeling that you have never worked with mongodb before, there are a many things which can bite you and you would not be fully aware of how to solve them.
However, If you still insist on switching, you need to carefully evaluate you data structure and the way you query them. In relational database, you have the normal forms, which have the advantage that whatever structure you start with, you will roughly reach the same end result once you do the normalization. In mongodb, there are virtually unlimited ways in which you can model your documents. You need to carefully model your documents to avail the benefits of mongodb. The queries you need to run play a very important role in your structuring along with the actual data you want to store.
Keep in mind, you do not have joins in mongodb(can be mitigated, with good modeling). As of now you can not have queries like,
field1 = field2
, i.e. you can't compare fields, but need to provide a literal to query against.Take a look at this question: Efficient way to store data in MongoDB: embedded documents vs individual documents. Somebody points the OP to a discussion where embedded documents are recommended, but pretty much similar scenario, OP chooses to go with standalone documents, because of the nature of the queries he will be using to fetch the data.
All I want to say is, it should be a informed decision, which should be taken after you completely model your system with mongodb, have some performance tests with some real data to see if mongodb will solve your problem and should not be based on coolness factor.
UPDATE:
You can do
field1 = field2
using$where
clause, but its slow and is advised to be avoided.我们目前正在生产应用程序中从 PostgreSQL、tsearch 和 PostGIS 切换。至少可以说,这是一个充满挑战的过程。我们的数据模型更适合 mongodb,因为我们不需要进行复杂的连接。我们可以非常轻松地将数据建模为 mongodb 提供的嵌套文档结构。
我们已经启动了一个镜像站点,其中包含 mongodb 更改,这样我们就可以在整个过程中遇到麻烦时,不用管生产站点。我不想吓到你,因为最终我们会很高兴我们做出了转变——但这需要大量的工作。我同意垃圾的答案:了解情况,做出你认为最好的决定。不要基于“酷”因素。
如果您必须更改,这里有一些我们经验中的提示:
我们使用 Mongoid 作为我们的 ODM,我们的模型中有很多范围需要重写才能与 Mongoid 和 ActiveRecord 一起使用。
总的来说,我们对 MongoDB 非常满意。它为我们的数据建模方式提供了更大的灵活性。我只是希望我们能在项目开始之前就发现它。
We are currently switching from PostgreSQL, tsearch, and PostGIS in a production application. It has been a challenging process to say the least. Our data model is a better fit for mongodb because we don't need to do complex joins. We can model our data very easily into the nested document structure mongodb provides.
We have started a mirror site with the mongodb changes in it so we can leave the production site alone, while we stumble through the process. I don't want to scare you, because in the end, we will be happy we made the switch - but it is a lot of work. I would agree with the answer from rubish: be informed, and make the decision you feel is best. Don't base it on the 'coolness' factor.
If you must change, here are some tips from our experience:
We are using Mongoid as our ODM, and there are a lot of scopes within our models that needed to be rewritten to work with Mongoid vs ActiveRecord.
Over all, we are very happy with MongoDB. It offers us much more flexibility in the way we model our data. I just wish we would have discovered it before the project were started.
跳过活动记录,
或者,如果您已经创建了应用程序,请查看 config/application.rb
并将第一行从
require "rails/all"
更改为:
需要“action_controller/railtie”
需要“action_mailer/railtie”
需要“active_resource/railtie”
需要“rails/test_unit/railtie”
确保注释掉生成器块中对 active_record 的引用也很重要:
配置生成器值。还有许多其他选项可用,请务必检查文档。
截至撰写本文时,它已默认被注释掉,因此您可能无需在此处进行任何更改。
我希望当您将应用程序从 AR 切换到 mongo 时对您有所帮助。
谢谢。
skip active record,
Alternatively, if you’ve already created your app, have a look at config/application.rb
and change the first lines from this:
require "rails/all"
to this:
require "action_controller/railtie"
require "action_mailer/railtie"
require "active_resource/railtie"
require "rails/test_unit/railtie"
It’s also important to make sure that the reference to active_record in the generator block is commented out:
Configure generators values. Many other options are available, be sure to check the documentation.
As of this this writing, it’s commented out by default, so you probably won’t have to change anything here.
I hope it will be helpful to you while you switching app from AR to mongo.
Thanks.