唯一分区键有什么缺点？

Question

我的数据集只会被直接查询（意味着我正在通过某个标识符查找特定项目）或将被完整查询（意味着返回表中的每个项目）。鉴于此，是否有任何理由不使用唯一的分区键？

根据我的阅读（例如：https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/#choosing-an-appropriate-partitionkey），非唯一分区键的优势在于能够进行事务更新。我不需要在这个数据集中进行事务更新，所以除了一些独特的东西（例如，GUID）之外，还有什么理由进行分区？

假设我为每个项目使用唯一的分区键，这意味着每个分区将有一行。我应该在行键中重复分区键还是应该只为行键设置一个空字符串？是否允许空行键？

Answer 1

我认为餐桌服务自动缩放功能可能无法完美运行。当分区中的某些数据“热”时，表服务会将它们移动到另一个集群以提高性能。但是由于您有唯一的分区键，您的实体可能不会被确定为“热”，而如果您将它们分组到分区中，则某些分区将是“热”并移动。如果您使用的是静态分区键，也可能存在以下问题。

此外，表服务可能会在以下情况下返回查询的部分实体

1. 结果中的实体超过 1000 个。
2. 已跨越分区边界。

根据您的请求，您还需要完整查询（返回所有实体）。如果您使用唯一的分区键，这意味着每个实体都是一个唯一的分区，因此您的查询将只返回一个带有continue token 的实体。您需要使用此continue token 触发另一个查询以检索下一个实体。我不认为这是你想要的。

所以我的建议是，在任何情况下都选择一个合理的分区键，即使它在您的业务中看起来毫无用处，因为它有助于表服务优化您的数据。

Answer 2

如果您不需要 EntityGroupTransaction 来批量更新实体，唯一的分区键对您来说是个不错的选择。

Answer 3

Zhaoxing's answer 基本上是正确的，但我想对其进行扩展，以便您了解更多原因。

表分区定义为表名加上分区键。一台服务器可以有很多分区，但一个分区只能在一台服务器上。

这种基本设计意味着对存储在单个分区中的实体的访问无法实现负载平衡，因为分区支持原子批处理事务。因此，单个表分区的可伸缩性目标低于整个表服务的可伸缩性目标。跨多个分区分布实体可让 Azure 存储更好地扩展负载。

点查询是最佳的，这很棒，因为听起来这就是您将要做的很多事情。如果分区键没有逻辑意义（即，您不希望特定分区中的所有实体），则最好将其拆分为多个分区键。列出表中的所有实体总是会比较慢，因为这是一次扫描。如果我们达到超时、1000 个实体或服务器边界（如上所述），Azure 存储将返回延续令牌。许多存储客户端库都有方便的方法，可以帮助您在遍历列表时自动遵循这些标记来处理此问题。

TL;DR：根据您提供的信息，我建议每个项目使用唯一的分区键。不允许使用空行键，但是您想构造行键也可以。

阅读：

Azure Storage Table Design Guide

Azure Storage Performance Check List