旅行者保险公司是美国最大的商业、财产和意外保险承保人之一。作为一名资深架构师，我目睹了该行业在过去10多年中的巨大发展，数据需求推动静态数据需求的增长，随后是动态数据，最后是消费中的数据。

如今，董事会要求企业管理者利用技术重新设计生产和销售，并最终提高公司的生产力和效率。

按理说，软件可以减少企业发展瓶颈，这意味着我们需要更好地持续构建和交付软件应用。虽然我们认为自己是敏捷狂热者，精通微服务，但我们并没有一觉醒来突然改变数据库。

事实上，我们用了数年进行数据库技术迭代，才最终用文档数据库取代了底层关系数据库，使我们能够捕捉到使用微服务的价值，并提高开发人员的工作效率和速度。

通过运行数据存储变得更加敏捷

起初，我们的目标是为我们的经纪人构建一个单一视图的应用程序，因为他们需要登录12个不同的服务，以满足单一用例的要求。关系数据模型一直阻碍着我们。

在当今的软件开发实践中，你需要根据简短的业务功能描述来构建软件。游戏的关键在于保持轻便和不断迭代。这与传统的瀑布式方法不同，在瀑布式方法中，可能要花费六个月的时间进行需求分析，才能编写一行代码。在瀑布式方法中，这没有问题——你知道了最终状态，才能创建数据库对象。但是，如果采用敏捷方法，就无法做到这一点，因为根本无法根据太简短的业务需求建立数据模型。现实情况是，你需要不断修改数据库。

在旅行者公司（Travelers），我们在 2014 年推出了单一视图应用程序，尽管它仍然依赖于 ETL、具有单一的代码库，并面临持续的集成挑战。现在，我们每年要部署五次软件，这对我们来说非常重要，并在内部营造了重新设计的应用程序对业务影响的氛围。

我们意识到，如果工程团队需要加快交付速度，我们就必须放弃关系数据库。

再见表格，你好 JSON！

2017 年，我们决定使用 MongoDB Atlas 这种文档模型数据库。然而，要想取得成功，我们需要做的不仅仅是学习如何针对不同的数据库进行编程。对于一家从未使用过关系数据库以外其他任何东西的公司来说，这是一次巨大的变革。要想取得成功，我们不仅需要实现技术的现代化，还需要实现企业文化的现代化。

在我们的开发人员开发软件的同时，我们还与许多其他团体建立了关系，让他们也参与到我们的旅程中来。

• 我们这样做是为了确保能够利用他们的专业知识
• 让噪音安静下来
• 教会每个团队如何使用 JSON 建立数据模型

与表格相比，用 JSON 建模让许多人大开眼界，他们认识到我们可以更快地将软件交付到生产中。

很快，随着我们的开发团队更快地将功能交付到生产中，业务产品负责人的工作积压开始减少。这创造了一个飞轮势头。随着我们的业务部门正在做的事情在内部传开，我们开始看到其他团队对我们的成果产生了极大的兴趣。

现在是微服务

尽管我们的开发人员在首次发布之前没有使用 MongoDB 的经验，但我们仍然能够在 8 周内将产品投入生产，消除了 600 多行代码，并在时间和预算范围内完成了任务。

此外，反馈表明，文档数据模型有助于消除数据映射和建模等繁琐的关系数据库工作。这样，开发人员就有时间重新专注于高度优先的项目。

我们刚开始使用 MongoDB 时，生产中只有两个集合。一年后，我们在生产中部署了 120 个集合，每天编写 1000 万个文档。如今，每个团队都拥有自己的依赖关系，并拥有自己专用的微服务和数据库，从而为应用程序和数据库的变更提供了单一的管道。总之，这些变化以及不重构数据模型所节省的时间，让我们将部署时间从几小时甚至几天缩短到了几分钟。

引领未来创新

如果在关系型数据库中使用得当，就会有很多表格；如果数据建模得当，即使是最简单的使用案例，也会有很多对象。一旦我们发现数据库拖慢了我们的速度，我们就知道是时候做出改变了。

我们转向文档模型数据库的决定最终对公司产生了深远影响，MongoDB 已成为软件开发的事实标准。在此过程中，我们采用了精益产品思想，并为我们的开发团队成功缩短交付时间做好了准备。

原文标题：Why our agile journey led us to ditch the relational database