在the documentation 中指出，Azure 表存储分区的最低速度为 500 次操作/秒。
如果我的数据正确分区，每个分区上的并行操作不会相互影响吗？
例如，如果我必须对分区 A 进行昂贵的全表扫描（最大为 500 个实体/秒），那么分区 B 上发生的任何操作的性能会受到影响吗？
存储帐户的操作数限制为 5000 次/秒。这是否本质上意味着我可以在它们开始影响彼此的性能之前最多使用 10 个分区？
【问题讨论】：
标签： performance azure azure-storage azure-table-storage
作为一般规则，您希望尽可能避免表扫描。它们是非常昂贵的操作（尤其是如果您有很多分区）。从表压力的角度来看，并不是很多，但它们具有非常高的聚合延迟（如下所述）。也就是说，有时根本无法避免它。
我们更新了存储架构并提高了一系列目标限制。
现在每个存储帐户的 IOPS 为 20k IOPS/秒。 每个分区现在是 2k/sec
分区的交互方式有点微妙，取决于它们的使用方式（并随时间变化）。
Azure 存储有两个阶段 - 一组服务器处理范围，另一组设置实际存储（即 3 个副本）。当表冷时，所有分区都可能由一台服务器提供服务。随着分区承受持续压力，系统将开始自动将工作负载（即分片）分散到其他服务器。分片是在分区边界上制作的。
对于低/中压力，您可能不会达到分片的阈值，或者只达到最低限度的次数。访问模式也会产生一些影响（如果您只是追加，分片将无济于事）。所有模式的随机访问将是迄今为止最好的。当系统重新平衡时，您将收到 503 响应几秒钟，然后操作将恢复正常。
如果您进行表扫描，您实际上会多次往返表。当查询到达分区的末尾时，将返回响应，其中包含找到的任何数据（如果不满足条件，则没有数据）和一个继续令牌。然后一次又一次地重新提交查询（并返回 w/token），直到您到达表的底部。这是由 SDK 抽象出来的，但如果您进行直接 REST 调用，您会看到它。
从表性能的角度来看，扫描只会影响它当前正在扫描的分区。
为了加快涉及多个分区的广泛查询，您实际上可以将其分解为多个并行访问（例如，每个分区一个线程），然后在客户端中合并。实际上，这取决于您要返回的数据量、表的大小等。
【讨论】：
您的观察是正确的，每个分区的性能是独立的。但是.. 表存储的性能也（主要是？）受 VM 带宽的影响。如果您查看Azure pricing，有一个“I/O 性能”列，超小型和小型机器具有“低”和“中等”I/O。因此，如果一台机器只能以 10MB/s 的速度获取数据，那么表存储的性能在很大程度上是无关紧要的——还要记住，虚拟化存储（作为操作系统的一部分）也会用完这个带宽。
5000/秒的存储帐户限制意味着当您开始达到该级别时，您可能会在某些操作上遇到超时。确保您针对任意数量的存储帐户进行架构设计，就像预先正确完成一样，很容易绕过该性能上限。
如果您认为您可能会使表存储负载过重。确保您编写的代码具有足够的诊断功能以找出问题所在，并进行一些暂时性故障处理以允许重试。
【讨论】：