两个有点相关的问题。
1）无论如何要获取表实体所在的服务器的ID？2) 使用 GUID 会给我最好的分区键分布吗？如果没有，会怎样？
我们已经在表存储性能方面苦苦挣扎了数周。简而言之，这真的很糟糕，但我们很早就意识到使用随机分区键会将实体分布在许多服务器上，这正是我们想要做的，因为我们试图实现每秒 8000 次读取。显然我们的分区键不够随机，所以出于测试目的，我决定只使用 GUID。第一印象是 waaaaaay 更快。
真正糟糕的获取性能是每秒< 1000。分区键是 Guid.NewGuid()，行键是常量“UserInfo”。Get 是使用带有 pk 和 rk 的 TableOperation 执行的，如下所示： TableOperation retrieveOperation = TableOperation.Retrieve(pk, rk); 返回 cloudTable.ExecuteAsync(retrieveOperation)。我们总是使用索引读取而不是表扫描。此外，VM 大小为中型或大型，绝不会更小。并行不，异步是
正如其他用户所指出的，Azure 表受到运行时的严格控制，因此您无法控制/检查哪些特定存储节点正在处理您的请求。此外，任何给定的分区都由单个服务器提供服务，也就是说，属于同一分区的实体不能在多个存储节点之间拆分（请参阅此处）
在 Windows Azure 表中，PartitionKey 属性用作分区键。具有相同 PartitionKey 值的所有实体都聚集在一起，并由单个服务器节点提供服务。这允许用户通过设置 PartitionKey 值来控制实体位置，并对同一分区中的实体执行实体组事务。
您提到您的目标是每秒 8000 个请求？如果是这种情况，您可能会遇到需要非常好的表/分区键设计的阈值。请参阅文章“ Windows Azure 存储抽象及其可扩展性目标”
以下摘录适用于您的情况：
这将为 2012 年 6 月 7 日之后创建的单个存储帐户提供以下可伸缩性目标。
正如其他用户所指出的，如果您的 PartitionKey 编号遵循增量模式，Azure 运行时将识别这一点并将您的一些分区分组到同一存储节点中。
此外，如果我正确理解了您的问题，您目前是通过 GUID 分配分区键吗？如果是这种情况，这意味着表中的每个 PartitionKey 都是唯一的，因此每个 partitionkey 将不超过 1 个实体。根据上述文章，Azure 表横向扩展的方式是通过在独立存储节点内的分区键中对实体进行分组。如果您的分区键是唯一的，因此包含的实体不超过一个，这意味着 Azure 表一次只能横向扩展一个实体！现在，我们知道 Azure 并没有那么笨，它会在检测到创建分区键的方式时对分区键进行分组。因此，如果您在 Azure 中触发此触发器，并且 Azure 正在对您的分区键进行分组，这意味着您的可伸缩性功能仅限于此分组算法的智能性。
根据上述 2012 年的可扩展性目标，每个分区键应该能够为您提供每秒 2,000 个事务。理论上，在这种情况下，您应该需要不超过 4 个分区键（假设这四个之间的工作负载是平均分配的）。
我建议您将分区键设计为对实体进行分组，以使每个分区每秒不超过 2,000 个实体，并使用 GUID 作为分区键删除。这将使您能够更好地支持实体事务组等功能，降低表设计的复杂性，并获得您正在寻找的性能。
回答 #1：没有特定表实体所在的服务器的概念。没有特定的服务器可供选择，因为 Table Storage 是一个大规模的多租户存储系统。所以......没有办法检索给定表实体的服务器 ID。
回答 #2：选择对您的应用程序有意义的分区键。请记住，访问给定实体是分区+行。如果你这样做，你将有一个快速、直接的阅读。如果您尝试进行表扫描或分区扫描，您的性能肯定会受到影响。
有关密钥选择的更多信息，请参阅 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) 和 Async 方法，因为您每秒有数千个请求。（演讲中有几张关于客户最佳实践的幻灯片）
最后，存储的下一个版本将支持 JSON 和 JSON 无元数据，这将显着减少相同对象的响应主体的大小，以及随后解析它们所需的 CPU 周期。如果您使用最新的客户端库，您的应用程序将能够利用这些行为而几乎不需要更改代码。