performance - 使用部分RowKey时是否索引针对Azure Table Storage的查询？

我从MS PDC演示中了解到，PartitionKey用于在多个服务器之间实现表的负载平衡，但是似乎没有人对PartitionKey是否用作单个服务器中的索引提供任何建议。

同样，每个人都会告诉您，指定PartitionKey和RowKey可以提高性能，但是似乎没有人告诉您是否在RowingKey中使用RowKey来提高性能。

以下是一些示例查询，可帮助我提出问题。假定整个表包含100,000,000行。

PartionKey =“123”和OtherField =“def”

PartitionKey =“123”和RowKey> =“aaa”和RowKey
这是我的问题:

如果每个分区中只有10行，查询1会很快吗？

如果每个分区中有1,000,000行，那么查询2会很快吗？

最佳答案

在ATS中， PartitionKey 用作分发查找，而不是索引。从使用ATS的层次来看，只需考虑PartitionKey和“服务器”/节点共享1:1关系。 (在幕后，事实并非如此，但是优化诸如碰巧驻留在同一物理/虚拟节点上的PartitionKeys之类的概念是从Azure使用者必须处理的内容中抽象出来的。这些细节完全是整个内部的Azure基础结构，如果是ATS，则最好假定它是最佳的，也就是“不必担心”)

在DBMS与ATS的上下文中， RowKey 是最接近“索引”的东西，因为它有助于在相似节点上查找数据。要直接回答您的问题之一， RowKey是PartitionKey 中的索引。

但是， PartitionKey 稍微走开了界限，可以使您在性能上更接近传统索引，但这仅仅是因为数据在ATS节点上的分布方式是分布式的。您应该将布局1st优化为PartitionKey，然后优化为RowKey。 (又名，如果只有一个可设置键的值，则将其设置为PartKey)

一般而言，查询将按照从最高效到最不高效的顺序执行

1. PartitionKey = x和RowKey = y(和OtherProp = z)

因为查找到达正确的节点，然后到达分区上的索引 Prop

2. PartitionKey = x(而OtherProp = z)

因为您到达了正确的节点，但随后到达了ATS equvi。全表扫描

3. OtherProp = z

因为您必须先进行分区扫描，然后再进行表扫描

这样，您的直接问题

我不认为这可以解决。它是主观的(即“什么是快的？”)。它总是比Query2慢，但是对于10行，即使

，“慢”的毫秒数也可能是毫秒

(类似主题)它将比查询1更快。只要可以执行Query2，就应该

因此，有了这些解释和您的问题，真正的答案取决于您的架构师如何使用ATS。

根据您的数据集(当前和预期的增长)，您需要确定一个合适的方案，以便可以进入分区和行是最快的方法。知道查找是如何发生的，您可以做出合理的决定，以哪种路径可以足够快地到达目的地，更多的零件，更少的行-vs-更少的零件，更多的行等

关于performance - 使用部分RowKey时是否索引针对Azure Table Storage的查询？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4946182/