提高 Azure 表存储查询性能的建议

Question

我们在Azure Table Storage中有一个表，自从新实现以来，它目前有50，000个条目。

PartitionKey:字符串形式的日期时间值< br> RowKey:字符串形式的数值

我们使用 TableQuery 生成筛选条件。PartitionKey filter是这样的：PartitionKey ge '201801240000000000'

不幸的是，我们不能使用RowKey过滤器，因为我们需要两个日期之间的数据。

要获取大约一个月的数据，大约需要5秒。而要在大约3个月的时间内拿到，需要的时间比这还要长。

虽然我们有一个缓存策略，但第一次获取数据需要很长时间。就像数据过滤器在日期发生变化时需要很长时间一样。

如有任何改进性能的建议，将不胜感激。




Answer 1

里克夫德博什的回答非常准确。

假设这是一个应用程序，下面是一些额外的想法。一种方法是并行读取较小的分区键范围。例如，假设正在处理的范围为2018年6月，我们将有：

• 线程1=

此外，在不使用TableQuery结构的情况下，可以更积极地并行读取较小的分区（例如每天）。

请注意，上述两种方法都不处理高度不平衡的分区策略。例如，假设 2018 年 6 月 95% 的数据存储在“20180605”到“20180610”的范围内，或者存储在一天内，在这种情况下，与串行读取相比，总体执行时间可能会或可能不会感觉到改善，特别是因为并行度开销（例如线程、内存分配、同步等）。

现在，假设这是在 Windows 操作系统上运行的 .NET 应用程序，并且上述方法适用于您的方案，请考虑：

< li >增加最大连接数； < li >禁用Nagle算法；

在下面找到要在应用程序配置中更改的代码段。请注意：

> < li >可以为maxconnection定义地址(例如https://stackoverflow.com ),而不使用“*”。 < li>

建议在发布到生产环境之前运行性能测试，以基准测试maxconnection的适当配置。

有关连接管理的详细信息，请访问：https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/network/connectionmanagement-element-network-settings.

Answer 2

据我从您的帖子中看到的，您遇到的最大问题是您的查询在一个查询中跨越多个分区。这对于性能来说不是最佳选择。根据下面的列表，您介于分区扫描和表扫描之间，因为您指定了分区键，但使用的是多个分区键。

• 点查询是最有效的查找方式，建议用于大容量查找或需要最低延迟的查找。通过指定PartitionKey和RowKey值，这样的查询可以使用索引非常有效地定位单个实体。例如：$filter=（Partithtml" target="_blank">ionKey eq'Sales'）和（RowKey eq'2'）
• 其次是一个范围查询，它使用PartitionKey并对一系列RowKey值进行筛选，以返回多个实体。PartitionKey值标识特定分区，RowKey值标识该分区中实体的子集。例如：$filter=PartitionKey eq'Sales'和RowKey ge'S'以及RowKey lt'T'
• 第三个最好的方法是分区扫描，它使用PartitionKey并对另一个非键属性进行筛选，并且可能返回多个实体。PartitionKey值标识特定分区，属性值为该分区中的实体子集选择。例如：$filter=PartitionKey eq'Sales'和LastName eq'Smith'
• 表扫描不包括PartitionKey，效率非常低，因为它依次搜索组成表的所有分区，以查找任何匹配的实体。无论筛选器是否使用RowKey，它都将执行表扫描。例如：$filter=LastName eq'Jones'
• 返回多个实体的查询返回按PartitionKey和RowKey顺序排序的实体。要避免在客户端中使用实体，请选择定义最常见排序顺序的行键

来源：Azure 存储表设计指南：设计可缩放表和高性能表

另一篇非常有用的文章是：在Windows Azure表存储中分区键和RowKey的用途，尤其是当您查看此图像时：

编辑:< br >如果您希望有多种方式来查询数据，请考虑以多种方式存储它们。尤其是因为存储很便宜，多次存储数据并没有那么糟糕。通过这种方式，您可以优化读取。这就是所谓的物化视图模式，它可以“帮助支持高效的查询和数据提取，并提高应用程序性能”。

但是，您应该记住，这对于静态数据来说很简单。如果您的数据变化很大，则在多次存储时保持同步可能会变得很麻烦。