如何估计Windows Azure表存储查询性能？

Question

我想评估一下我的Windows Azure表存储查询是如何缩放的。为此，我建立了一个简单的测试环境，在这个环境中，我可以增加表中的数据量，并测量查询的执行时间。基于时间，我想定义一个成本函数，它可以用来评估未来查询的性能。

我评估了以下查询：

1. 使用PartitionKey和RowKey查询
2. 使用PartitionKey和属性进行查询
3. 使用PartitionKey和两个行键进行查询
4. 带有PartitionKey和两个属性的查询

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

1. PartitionKey==“...”&&(RowKey==“...”RowKey==“...”）
2. （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对我来说似乎是个谜。有什么线索吗？

显然，我想在一个查询中查询不同的元素，以最小化成本，同时不损失性能。但似乎对每个元素使用单独的查询（带有任务并行库）是唯一真正快速的解决方案。这样做的公认方式是什么？

Answer 1

对于像3.2和4.2这样的查询，将会有一个一个的完整分区扫描以及属性。即使这些分区位于两台独立的计算机上，查询也不会并行运行，这就是为什么您会看到执行时间如此之长。这是因为Windows Azure没有对查询进行查询优化。代码的责任是以一种可以并行运行的方式编写代码。

如果您想要获得更快的性能，就不需要使用任务并行库并行运行查询以获得更高的性能。