文檔數據庫中模式更改的模式

Question

在開始之前，我想對我的問題的一般類型表示歉意-我確信可以針對該特定主題寫整本書。

假設您有一個大型文檔數據庫，其中包含多個文檔架構，並且每個架構都有數百萬個文檔。 在應用程序的生命周期中，需要經常更改已存儲文檔的架構（和內容）。

這樣的變化可能是

• 添加新字段
• 重新計算字段值（將毛額分成凈額和增值稅）
• 放置字段
• 將字段移到嵌入式文檔中

在我上一個使用SQL DB的項目中，我們遇到了一些非常相似的挑戰，當更改變得異常激烈時，這會導致大量的脫機時間（對於24/7產品），因為發生更改時，SQL DB通常在表上執行LOCK 。 我想避免這種情況。

另一個相關的問題是如何在使用的編程語言環境中處理架構更改。 通常，模式更改是通過更改類定義發生的（我將對MongoDB和Ruby使用Mongoid一個OR-Mapper）。 我該如何處理不再符合我的最新Class定義的舊版本文檔。

Answer 1

這是一個很好的問題。

像MongoDB一樣，面向文檔的數據庫的優點是來自同一集合的文檔不需要具有相同的字段。 本身具有不同的字段不會引發錯誤。 這就是所謂的靈活性。 出於同樣的原因，這也是一個不好的部分。

因此，問題和解決方案都來自應用程序的邏輯。

假設我們有一個模型Person，我們想添加一個字段。 當前在數據庫中，我們已經保存了5.000.000人。 問題是：我們如何添加該字段並減少停機時間？

可能的解決方案：

1. 更改應用程序的邏輯，以便它可以同時處理具有該字段的人員和沒有該字段的人員。

2. 編寫一個任務，將該字段添加到數據庫中的每個人。

3. 使用新邏輯更新生產部署。

4. 運行腳本。

因此，唯一的停機時間就是重新部署所需的幾秒鍾時間。 但是，我們需要花一些時間在邏輯上。

因此，基本上我們需要選擇對正常運行時間或我們的時間更有價值的時間。

現在，我們要重新計算一個字段，例如VAT值。 我們不能像以前那樣做，因為擁有某些含增值稅A的產品和另一些含增值稅B的產品是沒有意義的。

因此，可能的解決方案是：

1. 更改應用程序的邏輯，以使其顯示增值稅值正在更新，並禁用可能使用它的操作，例如購買。

2. 編寫腳本以更新所有增值稅值。

3. 重新部署新代碼。

4. 運行腳本。 完成時：

5. 重新部署完整的操作代碼。

因此，沒有絕對的停機時間，而只是某些特定部分的部分停機。 用戶可以繼續查看產品說明，並使用應用程序的其他部分。

現在說，我們要刪除一個字段。 該過程與第一個過程幾乎相同。

現在，將字段移動到嵌入文檔中； 那是一個好人！ 該過程將類似於第一個過程。 但是，我們需要檢查它是嵌入式文檔還是字段，而不是檢查字段的存在。

結論是，使用面向文檔的數據庫，您具有很大的靈活性。 因此，您可以輕松選擇。 是否使用它取決於您是否珍惜更多的開發時間或客戶的時間。