旅行者保險公司是美國最大的商業、財產和意外保險承保人之一。作為一名資深架構師，我目睹了該行業在過去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