5

我从 MS PDC 演示文稿中了解到，PartitionKey 用于跨多个服务器对表进行负载平衡，但似乎没有人就 PartitionKey 是否用作单个服务器内的索引给出任何建议。

同样，每个人都会告诉您指定 PartitionKey 和 RowKey 可以获得出色的性能，但似乎没有人告诉您 RowKey 是否用于提高 PartitionKey 内的性能。

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

  1. PartionKey="123" 和 OtherField="def"
  2. PartitionKey="123" and RowKey >= "aaa" and RowKey < "aac"

以下是我的问题：

  • 如果每个分区中只有 10 行，查询 1 会很快吗？
  • 如果我在每个分区中有 1,000,000 行，查询 2 会很快吗？
4

6 回答 6

15

在 ATS 中，PartitionKey用作分布查找，而不是索引。从使用 ATS 的层面来看，只考虑 PartitionKey 和“server”/node 共享 1:1 的关系。 （在幕后这不是真的，但是诸如优化位于同一物理/虚拟节点上的 PartitionKeys 之类的概念是从 Azure 的消费者必须处理的几个层面抽象出来的。这些细节纯粹是整体内部的Azure 基础设施，在 ATS 的情况下，最好假设这是一个最优的，因为它可能是……也就是“不用担心”）

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

然而，稍微跳出框框，PartitionKey可以让您获得更接近您对传统索引的看法的性能增益，但这仅仅是因为您的数据在 ATS 节点之间分布的分布式特性。您应该首先将布局优化到 PartitionKey，然后再优化到 RowKey。（又名，如果您只有一个可键入的值，请将其设为 PartKey）

一般来说，查询将按此顺序执行，从最高效到最不高效

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

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

2. PartitionKey=x（和OtherProp=z）

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

3. 其他属性 = z

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

有了这个，你的直接问题

  1. 我不觉得这个可以回答。它是主观的（即“什么是快的？”）。它总是比 Query2 慢，但是有 10 行，“慢”可能是毫秒，即使

  2. （类似主题）它会比查询 1 更快。任何时候你可以做 Query2，你应该

因此，有了这个解释和您的问题，真正的答案归结为您的架构师如何使用 ATS。

根据您的数据集（当前和预期的增长），您需要确定一个适当的方案，以便您可以访问您的分区和行是最快的方式。知道查找是如何发生的，您可以做出合乎逻辑的决定，决定什么路径可以让您足够快地到达那里，更多的部分，更少的行 - 与更少的部分，更多的行等

于 2011-02-09T15:45:25.887 回答
1

对于＃1，它扫描十个实体的速度非常快。

对于 #2，这取决于该 RowKey 范围内有多少实体。（为行键指定分区键和范围意味着我们将只对该范围内的实体进行索引查询。）您没有说有多少，但是如果例如有十个，那么它应该与＃1的性能相同。

于 2011-02-09T20:09:43.213 回答
1

表由 (PartitionKey, RowKey) 索引。保证从同一个分区提供具有相同分区键的行。具有不同 PartitionKey 的行可能在也可能不在同一个分区上。所以我不知道你怎么知道你在一个分区中只有 10 行。

如果您只有 10 行 PartitionKey="123"，那么第一个查询将是“快速”的。第二个查询将是“快速”的。

于 2011-02-10T00:27:23.887 回答
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

于 2012-04-19T06:49:19.230 回答
0

除了 Taylor 的回答之外，类似的陈述也适用于范围查询，如此处所述。

换句话说，Azure 表存储确实可以被认为只有一个索引，它按顺序由分区键和范围键两部分组成。

于 2013-07-29T11:11:19.377 回答
0

我认为自从写了WAS 论文以来，有些事情可能已经发生了变化，但如果你读到了，你可以得出一些结论。

例如，可以在节点/物理服务器之间移动分区。如果您有许多分区可以比单个分区更好地扩展。如果您有 1 个巨大的分区，您将受到单个分区的吞吐量的限制。

请注意，许多小分区（范围内连续）可以移动到单个节点/物理服务器。如果分区在逻辑上紧密地组合在一起（即排序），则跨分区扫描不必更慢。

如果您需要分区键来处理超过提供的 2000 请求/秒，您必须想办法将分区键拆分为多个分区，否则，没关系。

哦，您只能在单个分区键中执行实体组事务，这可能会影响您的设计。

回顾一下：

  • 您需要超过 2000 个请求/秒吗？
  • 您需要实体组交易吗？

这是你需要问自己的两个问题。

于 2018-04-08T07:56:29.420 回答