Azure表存储: Efficient way to query multiple PK-RK pairs

Question

我正在使用此过滤器进行查询: (PartitionKey eq 'A' 或 PartionKey eq 'B' 或 ...)和 RowKey eq 'RK'

我意识到这种具有 20 到 100 个 PK 的查询需要 3 到 5 秒。 table 上的元素总数不多(100万左右)

我认为正在执行部分扫描查询。我以为它会执行几次准时查询，但事实似乎并非如此。

我的另一个选择是进行独立的并行查询，然后合并结果。

• 对于 100 件商品来说，这是一个不错的选择吗？
• 我的网络连接不会有问题吗？ (我用 ServicePointManager.DefaultConnectionLimit 增加它们)

注意:并非所有 PK/RK 对都会检索记录。

Answer 1

My other option is do independent parallel queries and then merge the results.

这会节省Azure存储上的查询时间，但会花费更多的时间在查询请求和结果响应上。我有一个包含 160K 实体的表。我编写了两个示例代码来测试一次查询和多次查询查询实体的总次数。这是我的测试结果。

以下是我的示例代码。

通过一个查询查询实体。

int entitesCount = 20;
TableQuery<CustomerEntity> customerQuery = new TableQuery<CustomerEntity>();
string filter = "(";
for (int i = 0; i < entitesCount; i++)
{
    filter = filter + "PartitionKey eq '" + i + "'";
    if (i < entitesCount - 1)
    {
        filter = filter + " or ";
    }
}
filter = filter + ") and RowKey eq '42'";
customerQuery.FilterString = filter;

Stopwatch stopWatch = new Stopwatch();
stopWatch.Start();

var customers = table.ExecuteQuery(customerQuery);
Console.WriteLine(customers.Count().ToString());

stopWatch.Stop();
TimeSpan ts = stopWatch.Elapsed;
Console.WriteLine(ts.ToString());

从并行多个查询中查询实体。

ServicePointManager.DefaultConnectionLimit = 100;

Stopwatch stopWatch = new Stopwatch();
stopWatch.Start();

int entitesCount = 20;
List<CustomerEntity> customers = new List<CustomerEntity>();
var result = Parallel.For(0, entitesCount, new Action<int>(i =>
{
    TableQuery<CustomerEntity> customerQuery = new TableQuery<CustomerEntity>();
    customerQuery.FilterString = "PartitionKey eq '" + i.ToString() + "' and RowKey eq '88'";

    var cs = table.ExecuteQuery(customerQuery);
    foreach (var c in cs)
    {
        customers.Add(c);
    }
}));
while (!result.IsCompleted) { }

Console.WriteLine(customers.Count.ToString());
stopWatch.Stop();

TimeSpan ts = stopWatch.Elapsed;
Console.WriteLine(ts.ToString());

Azure Table Storage: Efficient way to query multiple PK-RK pairs

我建议您亲自测试一下，然后确定哪种方式是好的。