开始之前我想为我的问题的一般类型 道歉 - 我相信整本书 可以写在该特定主题上。模式在文档数据库中更改模式
让我们假设您有一个包含多个文档模式的大文档数据库 以及每个这些模式的数百万个文档。 在应用程序的生命周期中，需要频繁更改已存储文档的模式 （和内容）。
这样的变化可能是
我的最后一个项目，我们使用了一个SQL数据库，我们有一些非常相似的挑战 哪当 更改变得激烈时，会在某些重要的脱机时间（对于全天候产品）中产生沮丧，因为当发生更改时，SQL DB通常在表上执行LOCK。我想避免这种情况。
另一个相关的问题是如何处理 使用的编程语言环境中的模式更改。通常情况下，架构更改发生在 更改类定义（我将使用Mongoid OR-Mapper for MongoDB和Ruby）。如何处理旧版本的 以外的文档更符合我最新的类定义。
这是一个非常好的问题。
作为MongoDB面向文档的数据库的好处是来自同一个集合的文档不需要具有相同的字段。拥有不同的领域本身不会产生错误。这就是所谓的灵活性。出于同样的原因，这也是一个不好的部分。
所以问题和解决方案来自您的应用程序的逻辑。
假设我们有一个模型人，我们想添加一个字段。目前在数据库中我们已经保存了5,000,000人。问题是：我们如何添加该字段并减少停机时间？
可能的解决方案：
更改应用程序的逻辑，以便它可以与两个与该领域的人员并且没有领域的人员应付。
编写一个任务，将该字段添加到数据库中的每个人。
用新逻辑更新生产部署。
运行脚本。
所以唯一的停机时间是重新部署所需的几秒钟时间。尽管如此，我们需要花时间处理逻辑。
所以基本上我们需要选择哪个更有价值的正常运行时间或我们的时间。
现在让我们说我们想重新计算一个字段，如增值税价值。我们不能像以前那样做，因为有些产品含增值税A，其他含增值税B的产品没有意义。
所以，一个可能的解决办法是：
更改应用程序的逻辑，这样它显示增值税值正在更新，并禁用可以使用它的操作，如购买。
编写脚本以更新所有VAT值。
用新代码重新部署。
运行脚本。完成时：
使用完整的操作代码进行重新部署。
所以没有绝对的停机时间，而只是部分特定部件的部分停机。用户可以继续看到产品的描述并使用应用程序的其他部分。
现在让我们说，我们要删除一个字段。这个过程与第一个过程几乎相同。
现在，将字段移动到嵌入文档中;这是一个很好的！这个过程与第一个过程类似。但不是检查字段的存在，我们需要检查它是嵌入式文档还是字段。
结论是，对于面向文档的数据库，您有很大的灵活性。所以你有优雅的选择在你的手中。无论您是否使用它，取决于您是否重视开发时间或客户的时间。