我从MS PDC演示中了解到，PartitionKey用于跨多个服务器对表进行负载平衡，但似乎没有人就PartitionKey是否在单个服务器中用作索引提供任何建议。
同样，每个人都会告诉你指定PartitionKey和RowKey可以获得很好的性能，但似乎没有人告诉你RowKey是否用于提高PartitionKey的性能。
以下是一些示例查询，可帮助我构建问题。假设整个表包含100,000,000行。
以下是我的问题：
答案 0 :(得分：15)
在ATS中， PartitionKey 用作分布查找，而不是索引。从使用ATS的级别来看，只需考虑PartitionKey和“server”/ node来共享1：1的关系。 （在幕后这不是真的，但是优化PartitionKeys的概念恰好位于同一个物理/虚拟节点上，这些概念是从Azure的消费者必须处理的几个级别中抽象出来的。这些细节纯粹是内部的对于整个Azure基础架构而言，在ATS的情况下，最好假设它是最佳的，因为它可以......也就是“不要担心它”）
在DBMS与ATS的上下文中， RowKey 是最接近“索引”的东西，因为它有助于在类似节点上查找数据。要直接回答您的一个问题， RowKey是PartitionKey中的索引。
稍微走出盒子，然而， PartitionKey 可以让你更接近你对传统索引的看法，但这只是因为你的数据如何在ATS上传播的分布式特性节点。您应该将布局1st优化到PartitionKey，然后再优化到RowKey。 （也就是说，如果你只有一个可键值，那就把它作为PartKey）
在一般规则中，查询将按此顺序执行，从最有效率到最低效率
因为查找到达正确的节点，然后到达分区上的索引支柱
因为你到达了正确的节点，但后来到了ATS equvi。全表扫描
因为您必须进行分区扫描，然后进行表扫描
有了这个，直接问题
我觉得这不能回答。它的主观性（即“什么是快？”）。它总是比Query2慢，但有10行，“慢”可能是毫秒，如果连
（类似主题）它会比查询1更快。任何时候你都可以做Query2，你应该
因此，通过这种解释和您的问题，真正的答案取决于您的架构师如何使用ATS。
根据您的数据集（当前和预期增长），您需要确定一个正确的方案，以便您可以以最快的方式进入您的分区和行。了解查找的发生方式，您可以做出合理的决策，确定哪条路径足够快，更多的部件，更少的行数，更少的部件，更多的行等等。
答案 1 :(得分：1)
对于＃1，它可以快速扫描十个实体。
对于＃2，它取决于该RowKey范围内有多少实体。 （指定分区键和行键的范围意味着我们将仅对该范围内的实体进行索引查询。）您没有说有多少，但是，例如，如果有十个，那么它应该与＃1相同。
答案 2 :(得分：1)
表由（PartitionKey，RowKey）索引。保证从同一分区提供具有相同分区键的行。具有不同PartitionKey的行可能在也可能不在同一分区上。所以我不知道你怎么知道你在一个分区中只有10行。
如果只有10行，PartitionKey =“123”，那么第一个查询将是“快速”。 第二个查询将是“快速”。
答案 3 :(得分：0)
两者都应该相对较快。
查询1必须在单个分区内完成全扫描（ATS术语中的范围扫描），但这意味着要迭代10个实体。
查询2也会导致范围扫描，但使用RowKey作为分区内的索引，因此它应该仍然很快。
您可以获得一篇非常详细的博客文章，其中包含每个查询的所有性能影响，以及如何定义最佳密钥：http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx
答案 4 :(得分：0)
除了Taylor的答案之外，类似的陈述也适用于范围查询，如here所述。
换句话说，Azure表存储确实可以被认为只有一个索引由两部分组成，分区键和范围键，按顺序。
答案 5 :(得分：0)
我认为自WAS paper编写以来有些事情可能已经发生了变化，但是如果你读到了，你可以得出一些结论。
例如，可以在节点/物理服务器之间移动分区。如果您有许多分区可以比单个分区更好地扩展。如果你有一个巨大的分区，你将受到单个分区吞吐量的限制。
请注意，许多小分区（范围内连续）可以移动到单个节点/物理服务器。如果分区在逻辑上靠近在一起（即排序），则扫描分区的速度不必太慢。
如果你需要分区键来处理超过2000 req / sec的分区，你必须找到一种方法将分区密钥分成多个分区，否则，无关紧要。
哦，您只能在单个分区键中执行实体组事务，这可能会影响您的设计。
所以回顾一下：
这是你需要问自己的两个问题。