一个具有许多分区键的 Azure 表存储表与许多具有较少分区键的表相比如何？

Posted 2023-02-23

【中文标题】一个具有许多分区键的 Azure 表存储表与许多具有较少分区键的表相比如何？

【英文标题】：How does one Azure table storage table with many partition keys compare to many tables with fewer partition keys?

【发布时间】：2011-09-13 07:01:40

【问题描述】：

我有一个 Windows Azure 应用程序，其中 TableA 的所有读取查询都在单个分区上针对一系列行键执行。促进这种存储方案的分区键实际上是层次结构中对象的扁平名称，因此分区键的格式类似于root_child1_child2_leaf。我可以理解通过在表命名中使用分区键的根维度将这个大 TableA 划分为许多表是多么有益（因此分区键将变为child1_child2_leaf）。

我想要做的是尽可能快速地从尽可能多的连接中同时访问这些数据。如果我能弄清楚这些限制是什么或应该是什么，那也太不可思议了。

关于我提议的更改的更具体问题：

这是否会对可扩展性产生影响，即可以在不显着完善性能的情况下同时处理的数据访问请求的数量？是否同时提供服务？ 这会对平均性能产生影响吗？潜在表现？

【问题讨论】：

请发布一些示例 TPL 和异步查询

【参考方案1】：

如果每个查询都指定一个分区键，那么这些分区分布在多少个表中并没有区别。换句话说，以下是等价的：一张表有一千个分区与一千张表各有一个分区。

我能想到考虑拆分为多个表的主要原因是，您可以在单个操作/事务中删除整个表，而不能在同一个表中使用一系列分区。这意味着对于日志之类的内容，您可能希望在一段时间后删除较旧的内容，通常最好为不同的时间范围设置不同的表。

【讨论】：

有意思，所以我明白了，并发worker角色查询表存储的IO限制是账户级别的？

分区级别（表+分区）和账户级别的每秒操作数都有限制。

【参考方案2】：

+1 史蒂夫的回答。

补充几点

可能值得考虑使用多个存储帐户 - 因为它目前是作为可扩展性单位的存储帐户 - 每个存储帐户的官方目标是每秒大约 5000 个实体/事务，因此如果您想要更高，那么您需要使用多个帐户。 在性能方面有一些关于如何查询数据的微妙细节 - 如果项目不在同一个分区中，则执行单独的并行查询通常更快，而不是使用复杂的 where 参数执行单个查询。 您可能会发现存储团队博客上的博文特别有用 - http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx 和 http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx 您可能还需要了解成本 - 每百万次点击大约 1 美元。

【讨论】：

是的，非常好，感谢您的见解。通过我的测试，我遇到了单独的并行查询（每个分区一个），但很高兴知道这实际上是正确的方法。 TPL 和异步查询似乎运作良好。我会调查多个帐户。问题是我只能拥有这么多帐户，对吗？我还不清楚如何在逻辑上将我的应用程序分成 5 个左右的可能会扩展的部分。

添加...如果我可以根据需要创建尽可能多的表存储帐户，这实际上对我的计费目的非常有益。对我们想要做的项目有意义的高级存储帐户分区

添加...如果我可以根据需要创建尽可能多的表存储帐户，这对我来说实际上是非常有益的。对我们想要做的项目有意义的高级存储帐户分区将在客户端级别。如果我们可以为每个客户分配一个唯一的表存储帐户，那么我们可能会实现我们的 IO 可扩展性目标并有效地将您的计费系统用作我们自己的一部分。

我们很清楚......这不是我的计费系统 :) 而且我认为您可以拥有超过 5 个存储帐户 - 但您必须向 Microsoft 询问这一点。跨度>

您绝对可以向 MS 索要更多存储帐户，但他们似乎在 20 左右划清界限。