我正在爲使用Windows Azure的移動社交網絡構建服務器後端。反規格化Azure表中的聊天消息
我有這3個實體：
正如我存儲在由線程ID劃分Azure的表存儲的消息我期待好表現聊天時（發送/讀取消息到線程）。
但我也需要能夠爲用戶提供最新的帖子列表（最近=包含最新的消息）。換句話說，我需要在顯示時按最後的消息日期排序線程。
掃描許多不同的表分區並查找消息顯然會表現的殺手，所以我需要以某種非規範化數據到其他表分區能夠有效地獲取最新的線程。
基於你的經驗是什麼是最好的策略？
編輯：經過進一步的思考，這裏是一個更好的建議（我認爲）：
有一個消息ATS表。該表格將包含兩種類型的消息：發送消息和收到消息。 用戶每次發送消息時，都將其作爲「已發送」存儲在表中，然後作爲「已接收」（或您想要調用的那些類型）存儲在表中。
分區中的所有消息表的消息通過以下事項：
（用戶ID） - PartitionKey，（long.Max - Timestamp.Ticks） - 你可以存儲的ThreadId RowKey
作爲額外的屬性，發送/接收的分化等
如果你想保證你的信息被插入兩次W/O問題，使用隊列的和輔助角色。
該方案由用戶分割所有內容。您將能夠在一定時間範圍內顯示該用戶的所有消息，並始終以降序顯示。
選擇批量處理解決方案始終是一個解決辦法，並讓我想起了舊的計算像大型機。沒有什麼可以替代在線/實時系統。
如果你選擇一個批處理的解決方案，它會讓你的系統已經過時一經推出，將防止在未來的任何技術創新。
當你的Azure數據庫開始變得太大，查詢，Microsoft建議使用聯盟。基本上，它意味着將數據分割到多個數據庫中，並在代碼中使用兼容的訪問邏輯。
開始通過看這個演示程序：SQL Azure Federations Tutorial -- Entity Framework
嗨，謝謝你的答案！如果我正確理解您的答案，您基本上認爲Azure表已過時，並建議使用聯合代替？ – 2012-04-09 12:38:59
@MartinŠťáva，Azure Tables不是過時的，但從吞吐量的角度來看它們不具有可擴展性。它們的可伸縮性限制是[5000次操作/秒]（http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx ），而Sql Azure Federations可以[更高]（http://www.ducons.com/blog/benchmarking-throughput-and-scalability-on-sql-azure-federations）。如果您需要Azure Sql的靈活性和高可伸縮性，請選擇聯合。如果您需要在大量數據中使用低價格，請選擇表格存儲。 – 2012-04-12 12:40:42
@FlorinDumitrescu，謝謝你的回答，我覺得這很重要。我在這裏找到了一個討論：http：//social.msdn.microsoft.com/Forums/en-US/windowsazuredata/thread/6a745a22-540a-44d5-b426-d42dd8510da5。我必須告訴管理員，Azure表存儲似乎具有較低的可擴展性，這一事實讓我感到驚訝，並且可擴展性應該是它比sql azure的主要優勢。這就是爲什麼我將消息傳遞到Azure表上的原因。你能否詳細說明這個話題？你是否從微軟那裏得到過關於這個問題的答案？謝謝！ – 2012-04-26 22:44:05
嗨，伊戈雷克，謝謝你的回答！我在解決方案中看到的問題是，您的目的是每次用戶將消息發佈到線程時，我都必須查詢SQL Azure以更新Thread表中的會話時間戳。這有點抵消了使用Azure Tables的優勢 - 可擴展性... – 2012-04-09 12:35:56
同意。我正在編輯我的主要回復 – Igorek 2012-04-09 13:00:05
伊戈雷克，感謝您更新答案。基於它，我實現了非常相似的東西，效果很好，所以我標記了你接受的答案。然而，我發現你與FlorinDumitrescu的討論（http://social.msdn.microsoft.com/Forums/en-US/windowsazuredata/thread/6a745a22-540a-44d5-b426-d42dd8510da5），並對我以前的「表格更具擴展性「的世界觀。所以我要谷歌它，並最終開始有關它的新討論... – 2012-04-26 22:57:41