Azure 表存储分区键答案

【问题标题】：Azure Table Storage Partition KeyAzure 表存储分区键
【发布时间】：2013-09-17 16:28:34
【问题描述】：

两个有点相关的问题。

1) 有没有办法获得一个表实体所在的服务器的 ID？ 2) 使用 GUID 会给我最好的分区键分布吗？如果没有，会怎样？

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

真正糟糕的获取性能是每秒

【问题讨论】：

说性能“非常糟糕”并没有真正提供任何信息。没有任何参考点。请提供客观数据：VM 大小、实例数量、一些示例代码，显示您如何尝试进行读取、是否进行并行读取、哪种语言 SDK 等。另外：请记录您的分区+行键架构是，以及您如何进行查找，因为这也会影响您的性能。
编辑您的问题比在 cmets 中嵌入附加信息要好得多，尤其是使用未格式化的代码。

标签： azure azure-storage

【解决方案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 作为分区键删除。这将使您能够更好地支持实体事务组等功能，降低表设计的复杂性，并获得所需的性能。

【讨论】：

【解决方案2】：

答案#1：没有特定表实体所在的服务器 的概念。没有特定的服务器可供选择，因为 Table Storage 是一个大规模的多租户存储系统。所以...没有办法检索给定表实体的服务器 ID。

答案 #2：选择对您的应用程序有意义的分区键。请记住，访问给定实体是分区+行。如果你这样做，你将有一个快速、直接的阅读。如果您尝试进行表扫描或分区扫描，您的性能肯定会受到影响。

【讨论】：

我知道分区键+行键会直接命中，但分区键似乎聚集在同一台服务器上（因此问题#1），因为它们是同时加载的。使用 GUID 会提供最佳分区吗？
分区策略究竟是如何工作的？是否有包含完整详细信息的链接？显然，按顺序加载 PK 会将它们放在同一台服务器上，如果它们分布得更好，那么访问速度会慢得多。因此，1、2、3、4、5、6 的 PK 很可能最终会出现在同一台服务器上。我试图避免这种情况，这就是我使用 GUID 进行测试的原因。
就像我说的：没有带表存储的服务器这样的概念。顺序分区键与存储在一起的分区无关。
作为参考，请从 Brad Calder 的 Azure Storage whitepaper开始。
好的，术语问题。问题是顺序 PK 可能最终在同一个分区上，从而降低访问速度。见stackoverflow.com/questions/17667360/…

【解决方案3】：

看 http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx 了解更多关于密钥选择的信息（注意数字是 3 岁，但指导仍然很好）。

就最佳实践而言，此演讲也可能有用：http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B406#fbid=lCN9J5QiTDF。

一般来说，一个给定的分区最多可以支持 2000 tps，因此跨分区传播数据将有助于实现更大的数量。需要考虑的是原子批处理事务仅适用于共享相同分区键的实体。此外，对于较小的请求，您可以考虑禁用 Nagle，因为较小的请求可能会在客户端层被阻止。

从客户端，我建议使用最新的客户端库 (2.1) 和异步方法，因为您每秒有数千个请求。（演讲中有几张关于客户最佳实践的幻灯片）

最后，下一个版本的存储将支持 JSON 和 JSON 无元数据，这将显着减少相同对象的响应正文的大小，以及随后解析它们所需的 CPU 周期。如果您使用最新的客户端库，您的应用程序将能够利用这些行为而几乎不需要更改代码。

【讨论】：