我正在使用ASP.NET MVC / Windows Azure Table Storage设计一个简单的消息传递服务。我有两种实体 - 消息和消息线程。它们之间的关系很简单 - 每个线程可以有多个消息,但消息只能分配给一个线程。
表存储不是关系数据库,因此表示关系总是有点棘手。我需要在两种方法之间做出决定:
有一个大表用于线程,一个用于消息。并将threadId作为消息实体的分区键,以便消息按线程分区。
为每个消息线程动态创建一个特殊表,并将threadId作为表的名称。
我倾向于选择第二种,因为它更适合于其他服务的架构。但显然会在存储帐户中创建大量表。
您认为这可能是个问题吗?
答案 0 :(得分:2)
您还可以考虑只使用一个表来存储线程和消息实体。这将为您提供交易支持,您可以在此表中使用Lucifure的混合方法。
答案 1 :(得分:0)
创建大量表可能是一个问题,具体取决于您希望如何管理它们。列表表的underlying REST API就像查询表实体一样。它只返回前1000个表,之后你必须使用延续令牌。我见过的所有存储资源管理器都不允许您根据名称查询表,它们就像前1000个表一样。如果最终得到20000个线程,可能需要一段时间才能找到你想要的表格。
可以缓解此问题的一种方法是将您的邮件表放在自己的存储帐户中。这样,包含所有其他表的存储帐户将不会被您将要创建和可能删除的所有动态表挤出。
删除实际上是为每个线程使用单独的表更容易的方法之一。要删除所有相关消息,您只需删除一个表,而不是迭代每条消息并删除它。
然而,其他所有内容都比将所有消息保存在一个表中更复杂。如果这是您的应用程序的核心功能,并且您可以投入足够的时间以这种方式开发它,则每个线程一个表可能是个好主意。否则,简单的方法就是用一张大桌子。答案 2 :(得分:0)
您可以考虑使用混合方法将表的数量保持在可管理的级别,具体取决于您的可伸缩性需求。
我的经验是,在桌面级别进行基于日期的分区是一种非常有效的方法,可以全面利用。
例如,您可以根据日期和日期或月份的粒度对表进行分区。因此,2012年2月的所有主题已启动可以使用类似“Thread201202”的表名。
您的线程ID将隐含地包含“201202”并且类似于“201202-myid01”,尽管您不需要将其显式存储在分区键中,因为它将隐含在表名中。
通过删除超过一年的表格,可以轻松处理老年人的线索。