10

我正在編寫一個'概念證明'應用程序來調查在必要的整個應用程序重寫過程中將定製的ASP.NET電子商務系統移至Windows Azure的可能性。Azure Table存儲 - 實體設計最佳實踐問題

我很想看看使用Azure Table Storage作爲SQL Azure的替代方案,因爲隨着應用程序的進一步成熟,存儲的實體可能會隨時間改變它們的模式(屬性),而且我不需要製作無窮的數據庫模式變化。此外,我們可以在應用程序代碼中構建完整的完整性 - 因此考慮Azure表存儲的情況非常嚴重。

我現在可以看到的唯一潛在問題是我們做了少量的簡單報告 - 即兩個日期之間的銷售價值,特定產品的銷售數量等。 我知道表存儲不適用支持聚合類型函數,我相信我們可以通過巧妙使用分區來實現我們想要的,多個實體類型來存儲相同數據的子集,並可能進行預聚合,但是我不能100%確定如何去做。

有誰知道的關於Azure的表存儲的設計原則,任何深入的文檔,以便我們做出正確和有效地使用表,PartitionKeys和實體設計等

有周圍的幾個簡單的文檔,以及當前可用的書籍往往不會深入討論這個問題。

僅供參考 - 電子商務網站約有25,000個客戶,每年約需要100,000個訂單。

回答

4

我認爲在將您的應用移植到表格存儲時存在三個潛在的問題。

  1. 缺乏報告 - 包括聚合函數 - 你已經確定
  2. 事務支持的有限 - 以每年10級的訂單我想你會最終錯過這種支持。
  3. 成本上的一些問題 - 每百萬美元的運營費用只有很小的成本,但如果您獲得大量的頁面瀏覽量,則可能需要考慮這一點。

說實話,我認爲一個混合的方法 - 可能EF或NH到SQL Azure的關鍵數據,大型對象存儲在表/ Blob?

夠我的意見了!對於「深度」:

+0

偉大的建議 - 謝謝,但我真的在建議後,得到更多關於設計PartitionKey/Entity策略的更多深入信息,以緩解遷移到非關係DBMS的缺點 – 2011-04-15 08:11:34

+0

謝謝迪恩 - 我已經添加了關於AzureScope的一個額外的觀點 - 但這仍然不會真正幫助您的「商業用途最佳實踐」建議。幾乎所有我在最佳實踐中看到的建議都是在「表現」級別 - 例如如何設計你的鑰匙,以避免熱點。在實際操作中,我發現使用Azure存儲設計應用程序是一項相當大的挑戰 - 缺乏任何二級索引(例如RavenDB的map-reduce)使得關鍵實體存儲非常難於有效使用 - 確保您可以複製數據,但最終會出現交易問題。 – Stuart 2011-04-15 16:43:29

+0

偉大的建議 - 非常感謝 – 2011-04-16 19:20:10

0

如果您已開始查看諸如表格等Azure存儲,那麼在查看市場上其他NOSQL產品(尤其是文檔數據庫周圍)時不會有什麼壞處。這將使您深入瞭解NOSQL空間以及圍繞這種存儲設計的解決方案。 您也可以考慮SQL DB + NOSQL解決方案的混合方法。系統的某些部分可能很適合Azure表存儲模型。 Azure表等NOSQL解決方案有其自身的挑戰,如

  • 數據的模式更改。檢查herehere
  • 交易支持
  • ACID約束。檢查here
0

表中的所有設計文件,我已經看到了漂亮的全面覆蓋是非常專注於可擴展性和搜索性能的主題。我還沒有看到與報告或商業智能的設計考慮有關的任何內容。

現在,azure表格可以通過其餘的API和天藍色的SDK訪問。根據您需要的報告,您可能能夠以最小的努力提取所需的信息。如果您的報告要求非常複雜,那麼SQL Azure和Windows Azure SQL Reporting服務可能是更好的選擇?