我正在使用 ASP.NET MVC / Windows Azure 表存储设计一个简单的消息传递服务。我有两种实体——消息和消息线程。它们之间的关系很简单——每个线程可以有多个消息，但消息只能分配给一个线程。
表存储不是关系数据库，因此表示关系总是有点棘手。我需要在两种方法之间做出决定：
有一个大表用于线程和一个用于消息。并将threadId作为消息实体的分区键，以便消息按线程进行分区。
为每个消息线程动态创建一个特殊表，并以 threadId 作为表名。
我更喜欢第二种，因为它更适合服务其余部分的架构。但是显然在一个存储帐户中会创建大量的表。
你认为这可能是个问题吗？
【问题讨论】：
标签： asp.net azure-storage
您也可以考虑只使用一张表，同时存储 Thread 和 Message 实体。这将为您提供事务支持，并且您可以在此表上使用 Lucifure 的混合方法。
【讨论】：
创建大量表可能是个问题，具体取决于您要如何管理它们。用于列出表的underlying REST API 的作用类似于对表实体的查询。它只返回前 1000 个表，之后您必须使用延续令牌。我见过的所有存储浏览器都不允许您根据名称查询表，它们只是喜欢前 1000 个表。如果您最终有 20000 个线程，则可能需要一段时间才能到达您想要的表格。
缓解这种情况的一种方法是将您的消息表放在它自己的存储帐户中。这样一来，您的所有其他表的存储帐户就不会被您将要创建和可能删除的所有这些动态表挤占。
删除实际上是为每个线程使用单独的表会更容易的方法之一。要删除所有相关消息，您只需删除一个表，而不是遍历每条消息并删除它。
然而，其他一切都比将所有消息保存在一个表中更复杂。如果这是您的应用程序的核心功能，并且您可以投入足够的时间以这种方式开发它，那么每个线程一个表可能是个好主意。否则，做事的简单方法是使用一张大桌子。
【讨论】：
您可以考虑采用混合方法将表的数量保持在可管理的水平，具体取决于您的可扩展性需求。
我的经验是，表级别的基于日期的分区是一种非常有效的方法，可以全面发挥作用。
例如，您可以根据日期和以日或月为粒度对表进行分区。因此，像“Thread201202”这样的表名可以用于 2012 年 2 月开始的所有线程。
您的线程 ID 将隐含包含“201202”并且类似于“201202-myid01”，尽管您不需要将其显式存储在分区键中，因为它会隐含在表名中。
然后可以通过删除超过一年的表来轻松处理老化的线程。
【讨论】：