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