每个人都警告不要在Azure表存储(ATS)中查询RowKey或PartitionKey以外的任何内容,以免被迫进行表扫描。有一段时间,当我需要查询其他内容时,这使我陷入困境,试图找到正确的PK和RK并在其他表中创建伪二级索引。
但是,我认为在我认为合适时,我会在SQL Server中进行常规表扫描。
所以问题就变成了,我可以多快地扫描Azure表。这是实体/秒中的常量还是取决于记录大小等。如果您想要一个响应式应用程序,是否有一些关于有多少记录对于表扫描来说太多的经验法则?
答案 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_key
和next_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']
'''