Azure 表存储分区键

Question

两个有些相关的问题。

1) 有没有办法获取表实体所在服务器的 ID？2) 使用 GUID 能否为我提供最佳的分区键分布？如果没有，什么会？

几周来我们一直在为表存储性能而苦苦挣扎。简而言之，这确实很糟糕，但我们很早就意识到使用随机分区键会将实体分布在许多服务器上，这正是我们想要做的，因为我们试图实现每秒 8000 次读取。显然我们的分区键不够随机，因此出于测试目的，我决定只使用 GUID。第一印象是它更快了。

真正糟糕的获取性能是< 1000 每秒。分区键是 Guid.NewGuid()，行键是常量“UserInfo”。 Get 是使用带有 pk 和 rk 的 TableOperation 执行的，没有其他内容，如下所示: TableOperationretrieveOperation = TableOperation.Retrieve(pk, rk);返回cloudTable.ExecuteAsync(retrieveOperation)。我们总是使用索引读取而不是表扫描。此外，VM 大小为中型或大型，绝不会更小。并行否，异步是

Answer 1

正如其他用户所指出的，Azure 表受到运行时的严格控制，因此您无法控制/检查哪些特定存储节点正在处理您的请求。此外，任何给定的分区都由单个服务器提供服务，也就是说，属于同一分区的实体不能在多个存储节点之间拆分(请参阅HERE)

在 Windows Azure 表中，PartitionKey 属性用作分区键。具有相同 PartitionKey 值的所有实体都聚集在一起，并由单个服务器节点提供服务。这允许用户通过设置 PartitionKey 值来控制实体位置，并对同一分区中的实体执行实体组事务。

您提到您的目标是每秒 8000 个请求？如果是这种情况，您可能会遇到需要非常好的表/分区键设计的阈值。请参阅文章“Windows Azure Storage Abstractions and their Scalability Targets”

以下摘录适用于您的情况:

这将为 2012 年 6 月 7 日之后创建的单个存储帐户提供以下可扩展性目标。

• 容量 – 高达 200 TB
• 事务 – 每秒最多 20,000 个实体/消息/blob

正如其他用户所指出的，如果您的 PartitionKey 编号遵循增量模式，Azure 运行时将识别这一点并将您的一些分区分组到同一存储节点中。

此外，如果我正确理解你的问题，你目前正在通过 GUID 分配分区键？如果是这种情况，这意味着表中的每个 PartitionKey 都是唯一的，因此每个 PartitionKey 将不超过 1 个实体。根据上面的文章，Azure 表横向扩展的方式是通过在独立存储节点内的分区键中对实体进行分组。如果您的分区键是唯一的，因此包含不超过一个实体，这意味着 Azure 表一次只会扩展一个实体!现在，我们知道 Azure 并不那么愚蠢，当它检测到分区键创建方式的模式时，它会对分区键进行分组。因此，如果您在 Azure 中触发此触发器，并且 Azure 正在对您的分区键进行分组，则意味着您的可扩展性能力仅限于此分组算法的智能性。

根据上述 2012 年的可扩展性目标，每个分区键应该能够每秒为您提供 2,000 个事务。理论上，在这种情况下，您应该需要不超过 4 个分区键(假设四个分区键之间的工作负载平均分配)。

我建议您设计分区键来对实体进行分组，以便每个分区每秒处理的实体不超过 2,000 个，并放弃使用 GUID 作为分区键。这将使您能够更好地支持实体事务组等功能，降低表设计的复杂性，并获得您想要的性能。