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