再见MongoDB,你好PostgreSQL

迁移到PostgreSQL

　　最后，为了在所关心的各种项目之中达到平衡，我们决定使用PostgreSQL。但是，将整个平台从MongoDB迁移到一个截然不同的数据库并不是很容易的事。为了使转移工作简单化，我们将此过程分成了3个步骤：

1. 搭建一个PostgreSQL数据库，并迁移数据的一个小子集。
   

2. 更新所有依赖于MongoDB的应用程序，连同任何需要的重构，都用依赖于PostgreSQL的程序替代。

3. 将产品数据迁移到新数据库上，然后部署新平台。

部分数据迁移

　　在考虑把所有数据迁移到新数据库之前，我们先迁移了一小部分数据来做测试。如果仅仅是迁移一小部分数据，就有非常多的麻烦的话，那么数据库迁移也就没什么意义了。

　　尽管有现成的工具可以利用，但还是有些数据(比如，列重命名，数据类型不一致)要做转换，对于这些数据我们自己开发了些工具。这些工具中，大部分都是Ruby写的一次性脚步，用于删除一些评论，整理数据编码，修正主键发生序列等等。

　　在测试开始阶段尽管有些数据上的问题，并没有出现大的会阻碍迁移的问题。例如，有些用户提交的数据没有完全按格式编码，导致这些数据被重新编码之前，不能被导入到新数据库。例外一个有意思的改变是，之前评论的数据存的是评论用的语言的名称(如“荷兰语”，“英语”等)，现在改了存语言的编码，因为我们新的语义分析系统使用的是语言编码，而不再是语言名称。

更新应用

　　目前为止，花费时间最多的就是更新应用，尤其是那些严重依赖MongoDB聚合框架的应用。扔掉那少数几个遗留的Rails应用吧，光是测试就会花掉你几个星期的时间。更新应用的过程大致如下：

1. 用PostgreSQL的相关代码来替换掉MongoDB的驱动/设置模块的代码

2. 运行测试

3. 修复Bugs

4. 反复运行测试，直到所有测试通过

　　对于非Rails应用，我们推荐使用 Sequel，对于Rails应用，我们现在还无法摆脱ActiveRecord（至少是现在）。Sequel是一个非常好的数据库工具集，它支持绝大多数（如果不是全部）我们想使用的PostgreSQL特性。相较于ActiveRecord，它基于DSL的query要强大的多，尽管可能耗时会有点长。

　　举个例子，假设你想计算有多少用户使用某种语言，并计算每种语言所占的比例（相对于整个集合）。纯粹的SQL查询语句如下所示：

　　在我们的例子中，将会产生以下输出（当使用PostgreSQL命令行界面时）：

　　Sequel允许你使用纯Ruby编写上面的查询，而不需要字符串分段（ActiveRecord经常需要）：

　　如果你不喜欢使用“Sequel.lit(“*”)”，你也可以使用下面的语法：

　　虽然这可能有些冗长，但是上面的两种查询都使得它们更易于重用，而无需进行字符串连接。

　　未来可能也会将我们的Rails应用程序迁移到Sequel，但是考虑到Rails与ActiveRecord耦合得如此紧密，所以我们还不完全确定这是否值得花费时间和精力。

迁移生产数据

　　最终我们来到迁移生产数据的过程。一般有两种方法来做这件事：

1. 关掉整个平台，直到所有数据都已迁移完成。

2. 迁移数据的同时保持系统运行。

　　第一个选项具有一个明显的缺点：停机时间。第二个选项不需要停机但是很难处理。例如，在这个方案中，当你迁移数据的同时，你必须要考虑所有将要添加的数据，否则你就会损失数据。

　　幸运的是，Olery有一个独特的方案就是我们的数据库的绝大多数写操作都是相当定期的，经常变化的数据（例如用户通讯录信息）只占总数据量的一小部分，相比起我们检查数据，迁移它们花费的时间相当的小。

　　该部分的基础工作流是:

• 迁移诸如用户、联系人之类的关键数据，基本上所有我们无论如何都无法赔偿损失的数据。

• 迁移不太重要的数据（如我们可以再抓取、再计算获得的数据等）。   
  

• 测试正常运行在一组独立服务器的一切

• 切换产品环境到新的服务器。

　　再迁移步骤1的数据，确保在平均故障时间内创建数据不会丢失。

　　第2步是目前最耗时的，大约需要24小时。相反的是，步骤1和5中提到的数据迁移只需要45分钟。