開始之前我想爲我的問題的一般類型 道歉 - 我相信整本書 可以寫在該特定主題上。模式在文檔數據庫中更改模式
讓我們假設您有一個包含多個文檔模式的大文檔數據庫 以及每個這些模式的數百萬個文檔。 在應用程序的生命週期中，需要頻繁更改已存儲文檔的模式 （和內容）。
這樣的變化可能是
我的最後一個項目，我們使用了一個SQL數據庫，我們有一些非常相似的挑戰 哪當 更改變得激烈時，會在某些重要的脫機時間（對於全天候產品）中產生沮喪，因爲當發生更改時，SQL DB通常在表上執行LOCK。我想避免這種情況。
另一個相關的問題是如何處理 使用的編程語言環境中的模式更改。通常情況下，架構更改發生在 更改類定義（我將使用Mongoid OR-Mapper for MongoDB和Ruby）。如何處理舊版本的 以外的文檔更符合我最新的類定義。
這是一個非常好的問題。
作爲MongoDB面向文檔的數據庫的好處是來自同一個集合的文檔不需要具有相同的字段。擁有不同的領域本身不會產生錯誤。這就是所謂的靈活性。出於同樣的原因，這也是一個不好的部分。
所以問題和解決方案來自您的應用程序的邏輯。
假設我們有一個模型人，我們想添加一個字段。目前在數據庫中我們已經保存了5,000,000人。問題是：我們如何添加該字段並減少停機時間？
可能的解決方案：
更改應用程序的邏輯，以便它可以與兩個與該領域的人員並且沒有領域的人員應付。
編寫一個任務，將該字段添加到數據庫中的每個人。
用新邏輯更新生產部署。
運行腳本。
所以唯一的停機時間是重新部署所需的幾秒鐘時間。儘管如此，我們需要花時間處理邏輯。
所以基本上我們需要選擇哪個更有價值的正常運行時間或我們的時間。
現在讓我們說我們想重新計算一個字段，如增值稅價值。我們不能像以前那樣做，因爲有些產品含增值稅A，其他含增值稅B的產品沒有意義。
所以，一個可能的解決辦法是：
更改應用程序的邏輯，這樣它顯示增值稅值正在更新，並禁用可以使用它的操作，如購買。
編寫腳本以更新所有VAT值。
用新代碼重新部署。
運行腳本。完成時：
使用完整的操作代碼進行重新部署。
所以沒有絕對的停機時間，而只是部分特定部件的部分停機。用戶可以繼續看到產品的描述並使用應用程序的其他部分。
現在讓我們說，我們要刪除一個字段。這個過程與第一個過程幾乎相同。
現在，將字段移動到嵌入文檔中;這是一個很好的！這個過程與第一個過程類似。但不是檢查字段的存在，我們需要檢查它是嵌入式文檔還是字段。
結論是，對於面向文檔的數據庫，您有很大的靈活性。所以你有優雅的選擇在你的手中。無論您是否使用它，取決於您是否重視開發時間或客戶的時間。