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

Question

我想评估一下我的Windows Azure Table商店查询规模。为此，我将一个简单的测试环境放在一起，我可以增加表中的数据量，并测量查询的执行时间。基于我想定义一个可用于评估未来查询性能的成本函数的时间。

我评估了以下查询：

1. 使用PartitionKey和RowKey查询
2. 使用PartitionKey和属性
进行查询
3. 使用PartitionKey和两个RowKeys查询
4. 使用PartitionKey和两个属性进行查询

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

1. PartitionKey ==“...”＆amp;＆amp; （RowKey ==“......”|| RowKey ==“......”）
2. （PartitionKey ==“...”＆amp;＆amp;＆amp; RowKey ==“...”）|| （PartitionKey ==“...”＆amp;＆amp; 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没有对查询进行查询优化。以某种方式编写代码可以使它们并行运行。

如果您希望获得更快的性能，那么您是正确的，您需要使用任务并行库并行运行查询以获得更高的性能。

Answer 2

由于表存储内部实现的细节不公开，如果您想评估未来查询的性能，我建议您查看http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx以获取最佳实践。

最诚挚的问候，

徐明。