未来可能也会将我们的Rails应用程序迁移到Sequel，但是考虑到Rails与ActiveRecord耦合得如此紧密，所以我们还不完全确定这是否值得花费时间和精力。
迁移生产数据最终我们来到迁移生产数据的过程。一般有两种方法来做这件事：
关掉整个平台，直到所有数据都已迁移完成。
迁移数据的同时保持系统运行。
第一个选项具有一个明显的缺点：停机时间。第二个选项不需要停机但是很难处理。例如，在这个方案中，当你迁移数据的同时，你必须要考虑所有将要添加的数据，否则你就会损失数据。
幸运的是，Olery有一个独特的方案就是我们的数据库的绝大多数写操作都是相当定期的，经常变化的数据（例如用户通讯录信息）只占总数据量的一小部分，相比起我们检查数据，迁移它们花费的时间相当的小。
该部分的基础工作流是:
迁移诸如用户、联系人之类的关键数据，基本上所有我们无论如何都无法赔偿损失的数据。
迁移不太重要的数据（如我们可以再抓取、再计算获得的数据等）。
测试正常运行在一组独立服务器的一切
切换产品环境到新的服务器。
再迁移步骤1的数据，确保在平均故障时间内创建数据不会丢失。
第2步是目前最耗时的，大约需要24小时。相反的是，步骤1和5中提到的数据迁移只需要45分钟。
结论
我们迁移完成并且直到非常满意大概过去了一个月。到现在为止除了那些积极的影响，还曾在各种情况中让应用的性能大幅提高。举例来说，我们的 酒店评论数据API（Hotel Review Data API）（在Sinatra运行）相比迁移之前交互延迟变低了许多：
迁移是在1月21日开始的，高峰表示应用性能的硬重启（在处理期间导致交互时间轻微变慢）。在21日之后交互的平均时间大致是原来的一半。
在另外一种被我们称作“评论持久化”（译者注：即存储评论）的过程中，我们发现了性能上巨大的提升。后台程序目标很简单：保存评论数据（评论内容，评论分数等等）。当我们最终完成了为迁移工作做的很多大的更改后，结果令人振奋：
抓取器也变的更快了：
抓取器性能提升没有评论存储的过程那样大，因为抓取器只用数据库来查询某个评论是否存在（一个相对很快的操作），所以这样的结果并不很令人吃惊。
最后来到程序里用来调度抓取过程的进程（简单称之为“调度器”）：
因为调度器只是以固定频度运行，这个图可能有点难以理解，但是不管怎样，在迁移之后有一个很清晰的平均处理时间的下降。
最后，我们已经对现在的结果非常的满意，而且我们肯定不会怀念MongoDB了。它的性能非常好，它的处理方案使其它数据库相比之下黯然失色，并且查询数据的过程与MongoDB相比实在太令人满意了（尤其是对于non开发者而言）。尽管我们仍然还有一个服务（Olery Feedback)仍旧使用MongoDB（尽管这运行在一个独立的，相对小的集群上），我们仍然打算将来把它移植到PostgreSQL上。
------------------------------------华丽丽的分割线------------------------------------
CentOS 6.3环境下yum安装PostgreSQL 9.3
Ubuntu下LAPP（Linux+Apache+PostgreSQL+PHP)环境的配置与安装
PostgreSQL配置Streaming Replication集群
如何在CentOS 7/6.5/6.4 下安装PostgreSQL 9.3 与 phpPgAdmin
------------------------------------华丽丽的分割线------------------------------------