2014-04-02 29 views
3

我有一些數據量是用戶可編輯,閱讀頻繁,偶爾寫的。目前,我正在考慮將其序列化爲JSON並將其存儲在Azure上的Blob存儲中,或者將其構建(以與當前不同的方式)並將其存儲在Table Storage中。Azure的表/ Blob存儲,數據版本模式

我最關心的是「升級換代」的數據。例如,今天MyDataObject類具有一些屬性MyCoolProperty,它是複雜的(僅僅意味着它不是原始類型)。明天,我發現需求已經改變了,現在我的對象需要包含這些複雜對象的列表,所以現在我必須找到一種方法來升級我的數據以滿足這個新的需求,而不會破壞現有的可能不需要的應用程序能夠同時更新。

所以我真正要求的是:是否有任何資源,社論,框架或最佳實踐與如何成功地繼續向前移動業務,同時輕鬆(或相對容易地)響應需求更改。

回答

1

安東尼,我們也有類似的問題,同時開發Cognito Forms,這完全運行在Azure表存儲。我們將所有實體作爲JSON存儲,使用表存儲屬性作爲查詢的索引。雖然我們的版本的解決方案可能不是你一個完美的結合,它一直很適合我們,所以我會在這裏形容它:

  • 我們跟蹤的版本號與每個實體
  • 每次我們需要修改的給定類型的實體,我們創建了一個版本,這簡直是一種將轉變到JSON和代表型
  • 當然,我們更改了具體類型的JSON將反序列化到一個特定的新版本Func<string, string>在啓用修訂之前
  • 最後,當從存儲中讀取實體時,我們比較存儲版本n,其中當前的代碼版本,應用修訂保存在「追趕」的JSON
  • 所有實體始終處於最新版本

然後我們能夠按需升級爲實體從表中查詢存儲,但也能夠查詢表存儲的實體「過時」來執行後臺更新。由於我們擁有數百萬個實體,因此將這些作爲對沒有停機時間的系統更新的一部分進行轉換是不切實際或可行的。由於我們的服務層服務器由Azure自動升級到最新版本,因此他們只需開始即時升級JSON而不會中斷服務。

在特定情況下,它會像您可以應用類似的方法,但你必須找出一個創造性的解決方案來處理並行共享多個應用程序相同的數據。最終,如果兩個單獨的系統具有不同的發佈週期正在編輯相同的確切實體,則沒有解決方案將完全保護您的衝突。但是,您可以存儲多個版本和/或支持升級和降級修訂邏輯。

希望這會有所幫助!