如何正確存儲與Microsoft Azure表存儲的數據關係？

Question

來自關係世界的東西顯然與Azure Table存儲非常不同。我遇到的第一件重要事情是如何正確存儲多對多關係。

例如，我可能有一個跟蹤他們擁有的用戶和書籍的系統。我在SO上發現了另外一篇帖子，建議在用戶上擁有一個String Property，它基本上存儲了User擁有的Book ID列表。雖然我明白有時這是一種可接受的存儲數據的方式，但問題是Azure只允許您將64KB的數據存儲在String中。這肯定會限制用戶可能擁有多少本書。

另一種可能的解決方案是重複數據。我可能有一張表，可以在系統中存儲所有已知的圖書。但是，當用戶需要與Book關聯時，我將Book數據複製到一個名爲OwnedBooks的表中，該表與Book表完全相同，除了它也具有OwnedByUserID屬性。

是否有其他可能的解決方案？

除此問題外，有沒有人在使用Azure表存儲時對其他模式和實踐有什麼好的建議？

Answer 1

有許多解決方案，以如此 - 所有這些，當然缺點:-)

1. 使用簡單的映射表，當你在一個RDBMS會。每一行將包含一本書密鑰和一個用戶密鑰。

   然後，要爲用戶查找所有書籍，您需要在映射表中選擇書本鍵，然後爲每個鍵選擇書籍表中的書本實體。您可以使用異步提取並行執行Book檢索，但即便如此，該解決方案顯然不能縮放。

2. 使用上面的映射表，但也包括映射表中所需的所有Book數據。這是您已經使用OwnedBooks表提出的非規範化或「重複數據」解決方案。

   此方法的主要缺點是，如果您需要更新任何書籍數據，您將可能更新許多實體 - 並且由於它們位於Book本身的單獨表格中，因此無法進行在一個單一的事務/批處理中完成（並且我想你會在映射表中使用用戶標識作爲分區鍵，這已經排除了該表中的單個批量更新）。

3. 存儲加入到用戶的單個屬性中的Book密鑰。再一次，你已經提出了這種方法。

   如果不是因爲Azure當前不支持「contains」類型的查詢 - 即，您無法在子字符串上搜索，這實際上不會太糟糕，所以如果您想要找出哪些用戶擁有一本特定的書，這是不可能的。有趣的是，Google App Engine在其存儲系統中以相當透明的方式支持這一點 - 並且也會爲您列出索引。無論如何，您仍然需要使用此方法檢索每本書的數據。

4. 使用Azure表存儲的「無模式」特性將關聯的Book鍵存儲爲單獨的屬性。例如，一個用戶實體可以是這樣的：

   { Name: "User1", Book_4325: true, Book_5123: true }

   而另一種可能是這樣的：

   { Name: "User2", Book_5346: true, Book_8753: true, Book_6135: true }

   然後，如果你也想找到自己的某本書，你所有用戶可以選擇特定屬性的真實位置（好吧，它只需要真正存在）。

   這樣做的一個明顯缺點是它有點脆，你需要在屬性名稱中使用鍵盤來操作，而且你不能使用StorageClient的標準方法來實現這一點 - 你必須將你的擁有。另外，Azure僅支持實體上的255個屬性。儘管我從來沒有嘗試過，但我認爲它會很好地擴展。

出於所有這些選項，我說你打算去，選項2的人，將是最好的，只是一個事實，即它是目前Azure的支持，你通常可以實現一切用更少的查詢。

考慮到原子事務處於窗口之外，您只需要仔細檢查您的用例來決定如何以及何時更新數據。我幾乎可以保證你能夠與「最終一致」的事情生活在一起，只是說明你的映射表可能並不總是100％最新。

如果在與主表同時更新映射表中的數據變得過於昂貴，則可以在隊列中放置消息並獲取輔助角色以異步地爲您執行更新。

Answer 2

你不知道。這裏有一個關於Azure Table的好的，綜合性的white paper（.docx鏈接），它有一個最佳實踐部分。但是，您應該將表用於非關係屬性包或ORM類型設計。如果你想在雲中使用關係型，你應該使用SQL Azure Database。

這是關於無模式存儲與關係數據的另一個good article。這是一個different schema free cloud storage offering，但概念是相同的。