Dav*_*fer 6 azure full-table-scan azure-table-storage
每个人都警告不要在Azure表存储(ATS)中查询RowKey或PartitionKey以外的任何内容,以免被迫进行表扫描.有一段时间,当我需要查询其他内容时,这让我陷入困境,试图找到正确的PK和RK并在其他表中创建伪二级索引.
但是,在我认为合适时,我会在SQL Server中进行常见的表扫描.
所以问题就变成了,我可以多快地扫描Azure表.这是实体/秒中的常量还是取决于记录大小等.如果您需要响应式应用程序,是否有一些关于有多少记录对于表扫描来说太多的经验法则？
表扫描的问题与跨越分区边界有关.保证的性能级别是在分区级别设置的明确性.因此,当您运行全表扫描时,其a)效率不高,b)没有任何性能保证.这是因为分区本身设置在单独的存储节点上,当您运行跨分区扫描时,您将消耗大量资源(同时占用多个节点).
我相信,跨越这些边界的效果也会导致持续令牌,这需要额外的往返存储来检索结果.这导致了性能的降低,以及交易数量的增加(以及随后的成本).
如果您穿越的分区/节点数量相当小,您可能不会发现任何问题.
但请不要在此引用我的话.我不是Azure存储专家.它实际上是Azure的领域,我是最不了解的.:P
| 归档时间： |
|
| 查看次数： |
2909 次 |
| 最近记录： |