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