假设以下查询:
PartitionKey==1和(RowKey==A或RowKey==B)
甚至这个:
(PartitionKey==1和RowKey==A) OR (PartitionKey==2和RowKey==B)
这些结果中的任何一种都会导致扫描吗?
我之所以这样问,是因为PDC的这次谈话表明它是这样做的:
https://channel9.msdn.com/Events/PDC/PDC09/SVC09
特别是在27:30,演讲者和幻灯片声明:
关键字=>上的"OR“谓词在扫描中没有查询优化=>结果
29:30再次重申这一点,建议使用并行查询。在网上搜索之后,我还发现了以下内容:
查询中的"OR“目前还没有优化,但正如我前面提到的,我们已经有了功能请求。
现在所有这些信息都有7-8年的历史了,也许它已经改变了。前面的链接表示它是一个特性请求,今天它可能已经发生了。有吗?
如果它确实导致扫描,为什么?考虑到两个需要的元素都知道唯一的键,对一个或多个分区进行扫描的技术原因是什么?
考虑一种情况,在这种情况下,人们试图获取数百/数千个实体,其中只有每个实体的Partition+RowKey是事先已知的。是更快地执行一个单独的查询来并行地获取每个实体,还是使用一个' or‘谓词来处理每个调用的多个,以最小化并行查询的数量?
最后一个问题--在一个查询中,在不同的分区中获取多个实体(问题顶部的第二个查询示例),是否对性能有任何影响?还是将查询保留在一个分区中更好(第一个查询示例位于问题的顶部)?PDC在时间25:20的谈话似乎表明,实际上更好的做法是让查询将工作分配到多个分区,以便工作可以并行进行。但是,讨论是直接针对分区上的范围查询进行的,而不是在两个不同的分区上使用'OR‘谓词。
谢谢!
编辑**
我决定亲自测试一下表演。在测试中,我创建了一个包含一个分区和一百万个实体的表。分区键为"0“,行键为"0”到"999999“的递增值。
在运行测试时,我这样做了:
ServicePointManager.DefaultConnectionLimit = 1000;
servicePoint.UseNagleAlgorithm = false;
servicePoint.Expect100Continue = false;在第一个测试中,我构建了一个查询,如下所示:
(PK eq '0‘和RK eq '0')或(PK eq '0’和RK eq '500')或.x400
共有400组“OR”组。行键增加了500,以稍微扩展请求。
运行此查询花了Azure 3:26。
接下来,我使用相同查询的稍微简洁的形式进行了测试:
PK eq '0‘和(RK eq '0’或RK eq '500‘或.x400)
同样,总共有400‘或d表达式,并且行键再一次增加了500,以扩展请求。
运行此查询花了Azure 1:19。更好,但仍然是完全不能接受的表现。
最后,我使用TableOperation.Retrieve<>对400个并行请求进行了测试。
平均来说,Azure只需3秒就能并行运行所有这些查询。
显然,不要在表达式中使用'OR‘,而总是使用并行查询。IMO 'OR‘的性能是不可接受的,微软应该删除它,如果他们不会优化它。
发布于 2017-05-15 07:30:24
PartitionKey==1和(RowKey==A或RowKey==B)这两种方法中的任何一种会导致扫描吗?
是的,它会导致扫描。
azure服务器将此查询视为分区扫描。它将扫描分区等于'1‘。
(PartitionKey==1和RowKey==A) OR (PartitionKey==2和RowKey==B)这些结果中的任何一个会导致扫描吗?
azure服务器将将此查询视为表扫描。它将扫描所有表并找到分区键。
考虑一种情况,在这种情况下,人们试图获取数百/数千个实体,其中只有每个实体的Partition+RowKey是事先已知的。是更快地执行一个单独的查询来并行地获取每个实体,还是使用一个' or‘谓词来处理每个调用的多个,以最小化并行查询的数量?
我建议您可以执行一个单独的查询来并行地获取每个实体。因为或查询将导致表或范围扫描。
在一个查询中获取跨不同分区的多个实体(问题顶部的第二个查询示例)是否有任何性能影响?
据我所知,在一个查询中跨越不同的分区会导致表扫描,它会非常慢。
还是将查询保留在一个分区中更好(第一个查询示例位于问题的顶部)?
据我所知,表扫描的速度如下:
点查询(一个分区键和行键)>范围查询(一个分区键和行键范围)>分区扫描(一个分区键和属性范围)>表格扫描(不包括PartitionKey)
因此,最好将查询保存在一个分区中。
https://stackoverflow.com/questions/43960398
复制相似问题