如何估算Windows Azure Table存储查询性能？

我评估了以下查询：

>使用PartitionKey和RowKey进行查询
>使用PartitionKey和属性进行查询
>使用PartitionKey和两个RowKeys进行查询
>使用PartitionKey和两个属性进行查询

对于最后两个查询,我检查了以下两种模式：

> PartitionKey ==“…”&& (RowKey ==“……”|| RowKey ==“……”)
>(PartitionKey ==“…”&&& RowKey ==“…”)|| (PartitionKey ==“…”&& RowKey ==“……”)

为了最大限度地减少传输延迟,我在Azure实例上执行了测试.根据测量结果,我可以看到

>查询1(毫不奇怪,因为表是基于这些字段编制索引的)非常快,如果我在表中有大约150000个条目,则大约10-15ms.
>查询2需要分区扫描,因此执行时间与存储的数据呈线性增长.
>查询3.1执行几乎与查询2完全相同.因此,此查询也使用完整的分区扫描执行,对我来说似乎有点奇怪.
>查询4.1比查询3.1慢两倍多.所以看起来它是用两个分区扫描进行评估的.
>最后,查询3.2和4.2的执行速度几乎比查询2慢4倍.

你能解释一下查询/过滤器解释器的内部吗？即使我们接受查询3.1需要分区扫描,查询4.1也可以使用相同的逻辑(并在同一时间)进行评估.查询3.2和4.2对我来说似乎是一个谜.关于那些的任何指针？

显然,这一点的重点是,我想在一个查询中查询不同的元素,以最大限度地降低成本,同时不会失去性能.但似乎对每个元素使用单独的查询(使用任务并行库)是唯一真正的快速解决方案.这样做的可接受方式是什么？