其实是上个月的事情了，花了一个星期的时间把项目的数据库从 MongoDB 迁移到PostgreSQL。这里简要地说一说迁移的原因和过程。由于项目还没有上线，涉及业务逻辑的部分不能说得太细，呵呵。 迁移的原因 过去几个月见过很多人的吐槽，主要是说它的内存使用很夸
其实是上个月的事情了，花了一个星期的时间把项目的数据库从 MongoDB 迁移到PostgreSQL。这里简要地说一说迁移的原因和过程。由于项目还没有上线，涉及业务逻辑的部分不能说得太细，呵呵。
过去几个月见过很多人的吐槽，主要是说它的内存使用很夸张，在某些应用场景里性能很差，云云，虽说有点担心，但考虑到我们项目已经开发了一段时间，以及 MongoDB 对开发效率的提升，也就没打算换掉它。甚至在 Don’t use MongoDB 这篇著名的钓鱼文出现的时候，都还比较淡定。
直到我终于发现，MongoDB 不支持事务。一些新加入的功能对数据一致性的要求比较高，在某些情况下必须回滚数据，而 MongoDB 在默认情况下无法保证这一点，除非找到靠谱的 workaround，否则必须切换到 RDBMS。
我找到的各种解决方案大致可以分为两类，一是模拟事务，二是绕过它。MongoDB 官方 Cookbook 里这篇 Perform Two Phase Commits 介绍的就是如何利用额外的 collection 记录数据操作状态，来模拟事务操作。Master Detail Transactions in MongoDB和 MongoDB and E-commerce 这两篇文章则都提到了利用 MongoDB 中单个 document 操作的原子性来保证一致性的方法。
可惜这两类方案都不靠谱。第一种的方法太山寨，因为它不是在数据库级别而是在应用级别模拟了事务操作，很难保证数据安全。第二种对 model 的设计限制太多，把所有相关 model都 embed 进一个 model 不太现实。综合来看，MongoDB 无法胜任。
另外我在 Stack Overflow 上的问答 Are there any e-commerce websites that use NoSQL databases 里看到的答案也认为这种情况下用 RDBMS 比 NoSQL 方案要靠谱。摘录答案如下：
The overhead that makes RDBMS’s so slow, is guaranteeing atomicity, consistency, isolation, durability, also known as ACID. Some of these properties are pretty critical for applications that deal with money. You don’t want to lose a single order when the lights go out.
NoSQL databases usually sacrifice some or all of the ACID properties in return for severely reduced overhead. For many applications, this is fine – if a few “diggs” go missing when the lights go out, it’s no big deal.
For an ecommerce site, you need to ask yourself what you really need. Do you really need a level of performance that a RDBMS can’t deliver? Do you need the reliability that an RDBMS provides? Unless you’re dealing with traffic levels comparable to Amazon.com’s, an RDBMs, even on modest hardware will probably satisfy your performance needs just fine, especially if you limit yourself to simple queries, and index properly.
做完这个调查之后，终于下定决心要迁移。
消灭 Rails 配置文件中跟 Mongoid 有关的所有内容，换回 ActiveRecord. 这时项目是无法正常启动的。
补写所有 model 的 migration. 我先跳过 model 中与 association 有关的内容，只考虑 model 的基本属性。model 中用到了 Mongoid 特性而又比较复杂的方法也暂时先注释掉。
保证项目可以正常启动之后，修复每一个 model 的代码以及 association. 原本 HABTM 的关联全都改成 has_many :through 的方式。
这种迁移的方式比较原始，好在我们项目还没上线，不需要考虑数据迁移的问题，不然真是头大了。如果是已经上线的网站需要迁移的话，可以参考 從 Mongoid 遷移至 ActiveRecord 这篇文章，作者对整个过程的记录比较详细，而且有代码可以参考 XD
原文地址：从 MongoDB 迁移到 PostgreSQL, 感谢原作者分享。
