使用 MongoDb 处理迁移答案

【问题标题】：Handling migrations with MongoDb使用 MongoDb 处理迁移
【发布时间】：2012-03-08 17:40:36
【问题描述】：

只是为了给这个问题提供更多背景信息，我有一个 Web 应用程序 (asp mvc)，它基本上将 CRUD 操作包装到 MongoDb 实例中，它在模型被验证并发送到之前执行验证和某些业务逻辑存储、检索等。

现在我们遇到的一个问题是，在新版本中模型已经改变，但现有数据没有，这里有一个例子：（它是 c# 特定的，但问题确实与语言无关）

public class Person
{
    public Guid Id {get; set;}
    public string Name {get; set;}
    public int Age {get;set;}
    public string BadgeNo {get;set;}
}

public class Person
{
    public Guid Id {get; set;}
    public string Name {get; set;}
    public int Age {get;set;}
    public string EmployeeNo {get; set;} // Still contains same data as BadgeNo just called something different
}

您可以看到对象的结构发生了变化，但在 Mongo 土地上，它仍然传递一个 BadgeNo，而不是一个 EmployeeNo。在 SQL 领域，我们通常会有一个迁移脚本，它作为构建脚本的一部分运行，它会更改架构并更新/插入/删除该增量的任何其他数据。

那么如何最好地使用 Mongo 管理这些类型的迁移？我是否还应该有一个脚本用于更新 Mongo 中的所有实例？还是有其他一些首选的做法来做这种事情。

任何关于这个主题的建议都会很棒

=== 编辑 ===

目前我似乎想要使用迁移选项而不是逐步淘汰的方法，因此考虑到这一点，任何人都可以推荐任何工具来帮助该领域，否则每次迁移（假设滚入， roll-out) 必须是某种预编译的程序集，其中包含所有逻辑。我在想一些类似于 FluentMigrator 的东西，但不是使用 SQL，而是使用 Mongo。目前我的构建脚本使用的是 Nant，我看过一些 ruby 工具，但不确定是否有任何 .net 等价物。

【问题讨论】：

标签： .net mongodb migration database-schema

【解决方案1】：

基本上有两种方法：

确保您的应用程序代码可以处理数据结构的两个“版本”，并在保存时更新到新结构
编写迁移脚本

我可能会选择选项 1，因为它是允许您逐步更新的方法，而与选项 2 一样，您基本上需要关闭您的应用程序，以便您可以更新代码（快速）和数据（可能更慢）一口气。

然后，或者如果您认为有必要也执行选项 2 来迁移您的数据。这样就不必关闭您的网站，并且可以愉快地在后台异步运行。

【讨论】：

我会选择选项 1 — 然后使用该代码创建一个迁移实用程序（例如命令行应用程序），稍后通过加载和保存集合中的所有文档来执行选项 2 的等效操作仍然在旧版本中。
问题是你正在编写大量多余的代码，你必须维护这些代码才能支持多个版本，想象一下有 20 个版本，每个模型都有 20 个文件已更改。对我来说，第二个选项似乎更好，因为它更容易在版本之间移动（即回滚），我对少量的停机时间没有问题。感谢您的回答将使这个开放时间更长一点，因为我期待很多人说选项 2，但希望获得更多关于如何最好地自动化第二种方法的信息，即在构建脚本中。
Grofit，这就是为什么组合可能更好。您可以暂时处理两个版本，稍后再迁移数据，当您选择数据结构的下一个版本时，删除第一个版本（并保持第二和第三版本正常工作）
我知道您来自哪里，但您假设所有数据在一定时期内都是最新的。想象一下，如果一个人使用该系统并保存在 1.0 版本，然后直到 1.8 版本（假设 2 年后）才再次触摸系统，假设那里发生了 8 次发布的模型更改，那么系统会在尝试时崩溃在 1.8 环境中使用 1.0 中的模型，因为它仅适用于 1.7 -> 1.8。感觉系统是基于不断使用的信念而运行的，或者对每个请求都有开销来检查它是否需要更新。
Grofit，权利，这就是您也执行迁移脚本的原因。

【解决方案2】：

策略可以不同。它们取决于特定的应用程序。对于像 Facebook 这样的网站，您肯定会选择 Derick 提出的选项 #1，以完全不打击您的用户，但如果您的网站“卖披萨”，您肯定不想做努力支持两个版本（当前版本和新版本），编写更复杂的代码等。

对于此类应用，简单的补丁可能是更好的选择：

构建服务器将应用程序发送到“读取模式”，因此任何人都可以读取，但不能将任何内容插入数据库。
当 prod 处于读取模式时，我正在获取数据库并应用补丁。
修补完成后，它会备份数据库、停止 Web 服务器、部署新数据库和新应用程序。

将应用程序发送到阅读模式可以减少停机时间，但对于“卖比萨饼”的网站，您不需要阅读模式。

【讨论】：

【解决方案3】：

目前我似乎想采用迁移选项而不是逐步淘汰的方法，因此考虑到这一点，任何人都可以推荐任何工具来帮助该领域

对于仍在寻找解决方案的人，请查看MongoMigrations，此工具公开了 MongoDatabase（来自 mongo csharp 驱动程序）以对数据库进行操作，因此您可以使用驱动程序的所有功能。

【讨论】：