Azure表中聊天消息的非规范化

我正在使用Windows Azure为移动社交网络构建服务器后端

我有以下3个实体：

用户-存储在SQLAzure中

线程（排序2个用户之间的关系，然后可以相互发送消息）-存储在SQLAzure中

消息-存储在Azure表中

当我将消息存储在按线程ID分区的Azure表中时，我希望在聊天（向线程发送/读取消息）时有良好的性能

但我还需要能够向用户提供最新线程的列表（recent=包含最新消息）。换句话说，我需要在显示时按最后一个消息日期排序线程

扫描许多不同的表分区并查找消息显然是性能杀手，因此我需要以某种方式将数据反规范化到其他表分区，以便能够高效地获取最新的线程

---

根据您的经验，什么是最佳策略？

选择批处理解决方案始终是一个解决方案，让我想起了旧的计算（如大型机）。没有什么可以替代在线/实时系统

如果您选择批量解决方案，它将使您的系统在发布时过时，并将阻止未来的任何技术创新

当Azure数据库开始变得太大而无法查询时，Microsoft建议使用联合。基本上，它意味着在多个数据库中分割数据，并在代码中使用兼容的访问逻辑

---

首先看一下这个演示应用程序：

编辑：经过进一步思考，这里有一个更好的建议（我认为）：

有一个信息表。此表将包含两种类型的消息：已发送消息和已接收消息。 每次用户发送消息时，将其存储在表中，先作为“已发送”，然后作为“已接收”（或任何您想调用这些类型的内容）

按以下方式对消息表中的所有消息进行分区：

（UserId）-PartitionKey，（long.Max-Timestamp.Ticks）-RowKey

作为额外属性，您可以存储ThreadId、发送/接收的差异等

如果您想保证在没有问题的情况下插入两次消息，请使用队列和工作角色

---

此方案按用户划分所有内容。您将能够在一定的时间范围内显示发送给该用户的所有消息，并且始终向下显示。

您好，伊戈雷克，谢谢您的回答！我在解决方案中看到的问题是，每次用户向线程发布消息时，我都必须查询SQLAzure以更新线程表中的会话时间戳。这在某种程度上抵消了使用Azure表的优势-可伸缩性…Igorek，感谢您更新答案。基于它，我实现了一些非常类似的东西，效果很好，所以我将您的答案标记为接受。然而，我发现了您与FlorinDumitrescu（）的讨论，并对我以前的“表更具可伸缩性”世界观感到困惑。所以我打算用谷歌搜索它，并最终开始一个关于它的新讨论……嗨。您最初的想法是正确的：ATS更具可伸缩性。这也是我在MSDN论坛上的回复中强调的。5000笔交易/秒/每个账户都不错！嗨，谢谢你的回答！如果我正确地理解了你的答案，你基本上会考虑Azure表过时，并建议使用联合会来代替。@马丁·S.A.VA，Azure表不是过时的，但从吞吐量的角度来看，它们不是非常可扩展的。他们的可伸缩性限制是Sql Azure联合会可以使用的。如果您需要Azure Sql的灵活性和高可伸缩性，请选择联合。如果您需要高容量数据的低价格，请选择表存储。@Floridumitrescu，谢谢您的回答，我觉得这非常重要。我发现您在此处开始的讨论：。我必须告诉管理员，azure表存储的可伸缩性似乎较低，这一事实让我感到惊讶，而且可伸缩性应该是它相对于sql azure的主要优势。这就是为什么在Azure表上发送消息对我来说很自然。你能详细说明一下这个话题吗？你有没有从微软得到关于这个问题的答案？谢谢@MartinŠťáva，您提到的MSDN论坛讨论是在SQL Azure联合会发布之前进行的。与此同时，我亲自对联邦进行了基准测试，并撰写了一篇文章。从吞吐量的角度来看，联邦比ATS更具可扩展性，但这是一个代价，在本例中是代价：）。我支持前面的评论。如果您想以低价存储大量数据，请选择ATS。如果您需要高可伸缩性和SQL灵活性，请选择联合。