Azure表存储 - 我可以多快扫描一次?

时间:2011-01-28 18:57:09

标签: azure azure-table-storage full-table-scan

每个人都警告不要在Azure表存储(ATS)中查询RowKey或PartitionKey以外的任何内容,以免被迫进行表扫描。有一段时间,当我需要查询其他内容时,这使我陷入困境,试图找到正确的PK和RK并在其他表中创建伪二级索引。

但是,我认为在我认为合适时,我会在SQL Server中进行常规表扫描。

所以问题就变成了,我可以多快地扫描Azure表。这是实体/秒中的常量还是取决于记录大小等。如果您想要一个响应式应用程序,是否有一些关于有多少记录对于表扫描来说太多的经验法则?

4 个答案:

答案 0 :(得分:7)

表扫描的问题与跨越分区边界有关。保证的性能级别是在分区级别设置的明确性。因此,当您运行全表扫描时,其a)效率不高,b)没有任何性能保证。这是因为分区本身设置在单独的存储节点上,当您运行跨分区扫描时,您将消耗大量资源(同时占用多个节点)。

我相信,跨越这些边界的效果也会导致持续令牌,这需要额外的往返存储来检索结果。这导致了性能的降低,以及交易数量的增加(以及随后的成本)。

如果您穿越的分区/节点数量相当少,您可能不会发现任何问题。

但请不要在此引用我的话。我不是Azure存储专家。它实际上是Azure的领域,我是最不了解的。 :P

答案 1 :(得分:0)

我认为布伦特是100%的钱,但如果你仍然觉得你想尝试它,我只能建议你做一些测试来找出自己。尝试在查询中包含partitionKey以防止跨越分区,因为在一天结束时这是性能杀手。

答案 2 :(得分:0)

Azure表未针对表扫描进行优化。对于长时间运行的后台作业,扫描表可能是可以接受的,但是当需要快速响应时,我不会这样做。使用任何合理大小的表,您将不得不处理持续令牌,因为查询到达分区边界或获得1k结果。

Azure存储团队有一个great post which explains the scalability targets。单个表分区的吞吐量目标是500个实体/秒。存储帐户的总体目标是5,000次/秒。

答案 3 :(得分:0)

答案是分页。使用top_size - 结果中的最大结果数或记录数 - 与next_partition_keynext_row_key连续令牌一起使用。这在性能上具有显着的因子差异。首先,您的结果在统计上更可能来自单个分区。简单结果显示集合按分区延续键分组,而不是行继续键。

换句话说,您还需要考虑您的UI或系统输出。不要再费力地返回超过10到20个结果。用户可能不会再使用或检查了。

听起来很愚蠢。谷歌搜索“狗”,并注意搜索只返回10项。不再。如果你打扰'继续',下一个记录将对你有用。研究证明,除了第一页之外,几乎没有用户冒险。

select(返回键值的子集)可能会有所不同;例如,使用select = "PartitionKey,RowKey"'Name',无论您需要的最低限度。

  

“我相信,跨越这些边界的效果也会产生   继续令牌,需要额外往返   存储以检索结果。然后这导致减少   绩效,以及交易数量的增加(和   随后的费用)。“

...稍微不正确。使用延续令牌不是因为跨越边界,而是因为azure表允许的结果不超过1000;因此,两个连续令牌用于下一组。默认top_size基本上是1000。

为了您的观赏乐趣,这里是来自azure python api的查询实体的描述。其他人大致相同。

  '''
  Get entities in a table; includes the $filter and $select options. 

  table_name: Table to query.
  filter: 
     Optional. Filter as described at 
     http://msdn.microsoft.com/en-us/library/windowsazure/dd894031.aspx
  select: Optional. Property names to select from the entities.
  top: Optional. Maximum number of entities to return.
  next_partition_key: 
     Optional. When top is used, the next partition key is stored in
     result.x_ms_continuation['NextPartitionKey']
  next_row_key: 
     Optional. When top is used, the next partition key is stored in
     result.x_ms_continuation['NextRowKey']
  '''