4

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

我评估了以下查询：

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

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

  1. PartitionKey == "..." && (RowKey == "..." || RowKey == "...")
  2. (PartitionKey == "..." && RowKey == "...") || (PartitionKey == "..." && RowKey == "...")

为了最大限度地减少传输延迟，我在 Azure 实例上执行了测试。从测量中，我可以看到

  • 查询 1（毫不奇怪，因为表是基于这些字段编制索引的）非常快，如果表中有大约 150000 个条目，则大约需要 10-15 毫秒。
  • 查询 2 需要进行分区扫描，因此执行时间随着存储的数据线性增加。
  • 查询 3.1 的执行几乎与查询 2 完全相同。因此，此查询也执行全分区扫描，这对我来说似乎有点奇怪。
  • 查询 4.1 比查询 3.1 慢两倍多一点。所以看起来它是通过两次分区扫描来评估的。
  • 最后，查询 3.2 和 4.2 的执行速度几乎比查询 2 慢 4 倍。

你能解释一下查询/过滤器解释器的内部结构吗？即使我们接受查询 3.1 需要分区扫描，查询 4.1 也可以使用相同的逻辑（并且在同一时间）进行评估。查询 3.2 和 4.2 对我来说似乎是个谜。对这些有任何指示吗？

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

4

2 回答 2

2

对于 3.2 和 4.2 之类的查询，将与属性一一进行全分区扫描。即使这些分区在两台不同的机器上，查询也不会并行运行，这就是为什么你会看到这么长的执行时间。这是因为 Windows Azure 没有对查询进行查询优化。以一种可以并行运行的方式编写代码是代码责任。

You are right if you want to have faster performance, you would nee to run the query in parallel using Task Parallel Libraries to achieve higher performance.

于 2012-05-30T06:27:59.847 回答
1

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

最好的祝福，

明旭。

于 2012-05-25T09:17:45.957 回答