Azure存儲表，其關系存儲在Azure SQL中

Question

在Azure SQL數據庫中存儲所需的Azure存儲表關系是否正確？ 例如，我可能有一個系統跟蹤他們擁有的用戶和書籍。 我會在Azure存儲表中保留Users實體和Books實體，並在支持Azure SQL表中保持關系（idUser，idBook）。

這是一個好方法嗎？ 這個解決方案的缺點是什么？

編輯 ：這樣做的動機只是降低成本。 我需要存儲大量數據，所以我打算使用Azure存儲表，因為SQL數據庫將簡單到昂貴。 但在某些情況下，我需要存儲對象之間的關系。

Answer 1

我可能會遺漏一些東西，但坦率地說，我看不出有這么好的理由。

使用關系數據庫的一個主要原因是存儲關系數據，維護參照完整性，並依賴查詢優化器來進行有效的連接。 但是，由於您沒有將相關用戶或書籍數據存儲在同一數據庫中，因此無法在表中創建外鍵約束，也不能跨表連接數據，因為它不存在。 事實上它更糟糕，因為首先你必須從SQL數據庫中獲取數據，然后你必須去表存儲來獲取其余的數據，所以你要連接到兩個不同的服務只是為了檢索一個列表數據。

Answer 2

我想在@ Click-Rex的答案中添加一些內容：

1. 正如大衛提到的，如果您不正確地查詢表存儲速度較慢，即您的查詢正在進行全表掃描。 因此，如果您的分區設計得非常好，那么您應該獲得比SQL Azure更好的性能。
2. 與SQL Azure相比，表存儲非常便宜。
3. 要意識到SQL Azure是一種high density SQL server hosting因此您可能會受到noisy neighbor行為的影響。 表存儲有點安全，因為隔離邊界首先是您的存儲帳戶，然后是表，然后是PartitionKey。

@ Click-Rex提出的方法是我想要的方法，我想再做一件事：

在您的附加表中，還要duplicate the books and user information as well and not just BookId and UserId 。 這樣你只需要從一個表中讀取而不是進行多次讀取。 這種方法的缺點是，您必須確保每當書籍信息或用戶信息發生變化時，您都需要更新這些表格，但優點是您可以在閱讀操作上節省很多。 例如，假設您要查找用戶擁有的書籍。 如果您不將書籍信息存儲在此輔助表格中，首先您將從此輔助表格中獲取所有行鍵（書籍ID），然后對於每個書籍ID，您將從書籍表格中獲取有關該書籍的信息。 假設用戶有500本書，則表示您正在執行500 + 1個讀取事務。 但是，如果您將書籍信息存儲在輔助表本身中，那么您只需執行1次讀取操作。

顯然，如果application is performing more reads than writes則此方法會有意義。 您需要記住的另一件事是，您將無法獲得事務支持，因為您將在許多表和分區中進行編寫，因此您需要確保實體無論如何都會持久化。 在我正在構建的應用程序中，我們正在遵循這種方法，我們實際上有一個工作者角色負責確保數據持久化。

Answer 3

好處

• 在SQL Azure中獲取關系比從表存儲中獲取關系更快

缺點

• 作為@Ic。 說明; 你沒有簡單的方法來保持參照完整性
• 由於不得不從SQL Azure將關系拉入內存而導致性能下降; 然后枚舉通過它們來獲取正確的表存儲條目
• 表存儲本身比SQL Azure慢得多（請參閱此問題 ）
• 維護SQL Azure數據庫仍然需要付出代價; 即使它很小

我聽說有用戶使用Azure Table Storage來存儲關系; 例如：

• 表1：用戶（PartitionKey： UserID ）
• 表2：書籍（PartitionKey： BookID ）
• 表3：UserBooks（ParititonKey： UserID ，RowKey： BookID ）
• 表4：BooksUsers（PartitionKey： BookID ，RowKey： UserID ）

UserBooks和BookUsers就像一個明確定義的索引; 並允許您執行更快的搜索，因為PartitionKey和RowKey是您將用於關聯的字段。

然而，明顯的缺點是必須在數據旁邊保留2個額外的表。

實際上，它歸結為使用表存儲而不是SQL Azure的性能下降（並且它將會嚴重下降）是值得節省的成本。