【问题标题】:Denormalizing chat messages in Azure TablesAzure Tables 中的非规范化聊天消息
【发布时间】:2012-04-21 05:47:08
【问题描述】:

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

我有这 3 个实体:

  1. 用户 - 存储在 SQL Azure 中
  2. 线程(2 个用户 之间的某种关系,然后能够相互发送消息)- 存储在 SQL Azure 中
  3. 消息 - 存储在 Azure 表中

当我将消息存储在按线程 ID 分区的 Azure 表中时,我希望在聊天(向/从线程发送/读取消息)时获得良好的性能。

但我还需要能够为用户提供最新线程列表(最近 = 包含最新消息)。换句话说,我需要在显示时按最后一条消息日期对线程进行排序。

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

根据您的经验,最佳策略是什么?

【问题讨论】:

    标签: azure chat messages azure-table-storage denormalization


    【解决方案1】:

    选择批处理解决方案始终是一种解决方法,让我想起大型机等旧计算。没有什么可以替代在线/实时系统。

    如果您选择批量解决方案,它会使您的系统在启动时就过时,并且会阻碍未来的任何技术创新。

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

    首先查看这个演示应用程序:SQL Azure Federations Tutorial -- Entity Framework

    【讨论】:

    • 您好,感谢您的回答!如果我正确理解您的答案,您基本上认为 Azure Tables 已过时并建议改用联邦?
    • @Martin Šťáva,Azure 表并没有过时,但从吞吐量的角度来看,它们的可扩展性不是很好。他们的可扩展性限制是5000 operations / second,而 Sql Azure 联合可以去a lot higher。如果需要 Azure Sql 的灵活性和高可伸缩性,请选择联合。如果您需要低价处理大量数据,请选择表存储。
    • @FlorinDumitrescu,感谢您的回答,我认为这非常重要。我找到了您从这里开始的讨论:social.msdn.microsoft.com/Forums/en-US/windowsazuredata/thread/…。我必须管理的是,azure 表存储似乎不太可扩展这一事实让我感到惊讶,而且可扩展性应该是它相对于 sql azure 的主要优势。这就是为什么我觉得将消息传递基于 Azure Tables 是很自然的。您能否详细说明一下这个话题,您从微软那里得到任何答案吗?谢谢!
    • @Martin Šťáva,您提到的 MSDN 论坛讨论是在 SQL Azure 联盟启动之前进行的。同时,我亲身对联邦进行了基准测试,并写了一篇文章here。从吞吐量的角度来看,Federations 比 ATS 更具可扩展性,但这是有代价的,在这种情况下就是价格 :)。我支持之前的评论。如果您想以低价存储大量数据,请选择 ATS。如果您需要高可扩展性和 SQL 灵活性,请选择联合。
    【解决方案2】:

    编辑:经过进一步思考,这里有一个更好的建议(我认为):

    有一个消息 ATS 表。该表将容纳两种类型的消息:发送的消息和接收的消息。 每次用户发送消息时,将其作为“已发送”存储在表中,然后作为“已接收”(或任何您想调用的这些类型)。

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

    (UserId) - PartitionKey, (long.Max - Timestamp.Ticks) - RowKey

    作为额外的属性,您可以存储 ThreadId、Sent/Received 区分等。

    如果您想保证您的消息被插入两次而没有问题,请使用 Queue 和 Worker 角色。

    此方案按用户划分所有内容。您将能够在一个时间范围内显示该用户的所有消息,并且始终按降序显示。

    【讨论】:

    • 嗨,Igorek,感谢您的回答!我在解决方案中看到的问题是,每次用户将消息发布到线程时,我都必须查询 SQL Azure 以更新线程表中的对话时间戳。这有点抵消了使用 Azure Tables 的优势 - 可扩展性......
    • Igorek,感谢您更新答案。基于它,我实现了一些非常相似的东西,效果很好,所以我把你的答案标记为接受。但是,我发现了您与 FlorinDumitrescu (social.msdn.microsoft.com/Forums/en-US/windowsazuredata/thread/…) 的讨论,并对我之前的“tables-are-more-scalable”世界观感到困惑。所以我打算用谷歌搜索它并最终开始一个关于它的新讨论......
    • 嗨。您最初的想法是正确的:ATS 更具可扩展性。这也是我在 MSDN 论坛上的回复中所强调的。 5000 次交易/秒/每个帐户是不错的!
    猜你喜欢
    • 2020-09-10
    • 1970-01-01
    • 2018-05-27
    • 1970-01-01
    • 2013-08-28
    • 2017-10-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多