在我开始之前我想为此道歉
我的问题的通用类型 - 我确信整本书
可以就该特定主题进行写作。
假设您有一个包含多个文档模式的大型文档数据库
以及每个模式的数百万个文档。
在应用程序的生命周期中，需要更改架构
经常查看已存储的文档（和内容）。
这样的改变可能是
- 添加新字段
- 重新计算字段值（将总额分为净额和增值税）
- 删除字段
- 将字段移动到嵌入文档中
在我的上一个项目中，我们使用了 SQL DB，我们遇到了一些非常相似的挑战
这导致了一些显着的离线时间（对于 24/7 产品）
更改变得非常剧烈，因为 SQL 数据库通常会在以下情况下对表执行锁定操作：
发生变化。我想避免这样的情况。
另一个相关的问题是如何处理架构内部的更改
使用的编程语言环境。通常模式更改发生在
更改类定义（我将使用 Mongoid OR-Mapper
MongoDB 和 Ruby）。如何处理不支持的旧版本文档
更符合我最新的类定义。
这是一个非常好的问题。
MongoDB 等面向文档的数据库的优点是来自同一集合的文档不需要具有相同的字段。拥有不同的字段本身不会引发错误。这就是所谓的灵活性。出于同样的原因，这也是一个不好的部分。
因此，问题和解决方案都来自应用程序的逻辑。
假设我们有一个模型 Person 并且我们想要添加一个字段。目前在数据库中我们已经拯救了 5,000,000 人。问题是：我们如何添加该字段并减少停机时间？
可能的解决方案：
更改应用程序的逻辑，使其能够应对具有该领域的人和没有该领域的人。
编写一个任务，将该字段添加到数据库中的每个人。
使用新逻辑更新生产部署。
运行脚本。
因此，唯一的停机时间是重新部署所需的几秒钟。尽管如此，我们还是需要花时间研究逻辑。
所以基本上我们需要选择正常运行时间和我们的时间哪个更有价值。
现在假设我们要重新计算一个字段，例如增值税值。我们不能像以前那样做，因为有些产品带有增值税 A，另一些产品带有增值税 B 没有意义。
因此，一个可能的解决方案是：
更改应用程序的逻辑，使其显示增值税值正在更新，并禁用可能使用它的操作，例如购买。
编写脚本来更新所有增值税值。
使用新代码重新部署。
运行脚本。当它完成时：
使用完整的操作代码重新部署。
因此，并不是绝对的停机，只是某些特定部分的部分停机。用户可以继续查看产品的描述并使用应用程序的其他部分。
现在假设我们要删除一个字段。该过程与第一个过程几乎相同。
现在，将字段移至嵌入文档中；那是一件好事！该过程与第一个过程类似。但我们需要检查它是嵌入文档还是字段，而不是检查字段是否存在。
结论是，使用面向文档的数据库，您将拥有很大的灵活性。因此，您可以有多种优雅的选择。您是否使用它取决于您更看重您的开发时间还是客户的时间。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
