问题 不支持使用TableBatchOperation检索多行？

尝试这样的事情：

TableQuery<DynamicTableEntity> query = new TableQuery<DynamicTableEntity>()
                                                .Where(TableQuery.CombineFilters(
                                                    TableQuery.GenerateFilterCondition("PartitionKey", QueryComparisons.Equal, "partition1"),
                                                    TableOperators.And,
                                                    TableQuery.CombineFilters(
                                                        TableQuery.GenerateFilterCondition("RowKey", QueryComparisons.Equal, "row1"),
                                                        TableOperators.Or,
                                                        TableQuery.GenerateFilterCondition("RowKey", QueryComparisons.Equal, "row2"))));

我知道这是一个老问题，但由于Azure STILL不支持二级索引，它似乎有一段时间是相关的。

我遇到了同样的问题。在我的场景中，我需要在同一个分区中查找数百个项目，其中有数百万行（想象GUID为行键）。我测试了几个选项来查找10,000行

1. （PK && RK）
2. （PK && RK1）|| （PK＆RK2）|| ...
3. PK &&（RK1 || RK2 || ...）

我使用的是异步API，最大并行度为10度（最多10个未完成请求）。我还测试了几种不同的批量（10行，50,100）。

Test                        Batch Size  API calls   Elapsed (sec)
(PK && RK)                  1           10000       95.76
(PK && RK1) || (PK && RK2)  10          1000        25.94
(PK && RK1) || (PK && RK2)  50          200         18.35
(PK && RK1) || (PK && RK2)  100         100         17.38
PK && (RK1 || RK2 || … )    10          1000        24.55
PK && (RK1 || RK2 || … )    50          200         14.90
PK && (RK1 || RK2 || … )    100         100         13.43

注意：这些都在同一个分区内 - 只有多个rowkeys。

我很乐意减少API调用的数量。但是作为一个额外的好处，经过的时间也明显减少了，节省了计算成本（至少在我的最后！）。

不足为奇的是，100行的批次提供了最佳的流逝性能。显然还有其他性能方面的考虑，特别是网络使用（例如，＃1几乎不使用网络，而其他人则更难推动）

编辑 查询许多rowkeys时要小心。 （或当然）查询的URL长度限制。如果超过长度，查询仍将成功，因为该服务无法判断URL是否被截断。在我们的例子中，我们将组合查询长度限制为大约2500个字符（URL编码！）

Azure表存储不支持批处理“获取”操作。支持的操作包括：添加，删除，更新和合并。您需要将查询作为单独的请求执行。为了加快处理速度，您可能希望并行执行这些查询。

您最好的办法是创建一个Linq / OData选择查询...它将获取您正在寻找的内容。

为了获得更好的性能，您应该为每个分区进行一次查询并同时运行这些查

我没有亲自测试过，但认为它会起作用。

每个分区有多少个实体？通过一次检索操作，您可以为每个查询提取最多1000条记录。然后，您可以对内存集进行行密钥过滤，只需支付1次操作。

另一种选择是做一个 行键范围查询 在一个操作中检索部分分区。基本上，您指定要返回的行键的上限和下限，而不是整个分区。

好的，所以批处理检索操作，最好的情况是表查询。不太理想的情况需要并行检索操作。

根据您的PK，RK设计，您可以基于（PK，RK）列表找出您需要执行的最小/最有效的检索/查询操作集。然后，您可以并行获取所有这些内容并整理出客户端的确切答案。

IMAO，这是微软设计小姐添加的 Retrieve 方法 TableBatchOperation class，因为它传达了表存储API不支持的语义。

现在，我不想写一些超级高效的东西，所以我只想在这里留下这个超级简单的解决方案。

var retrieveTasks = new List<Task<TableResult>>();

foreach (var item in list)
{
    retrieveTasks.Add(table.ExecuteAsync(TableOperation.Retrieve(item.pk, item.rk)));
}

var retrieveResults = new List<TableResult>();

foreach (var retrieveTask in retrieveTasks)
{
    retrieveResults.Add(await retrieveTask);
}

这个异步代码块将获取实体 list 并行并将结果存储在 retrieveResults 保留订单。如果您需要获取连续的实体范围，则可以使用范围查询来改善这一点。

有一个最佳点（通过测试你必须找到）是查询更多实体的速度可能比特定批次检索所需的更快/更便宜，然后丢弃您不需要的检索结果。

如果你有一个小分区，你可能会受益于这样的查询：

where pk=partition1 and (rk=rk1 or rk=rk2 or rk=rk3)

如果您的密钥之间的字典（即排序顺序）距离很长，您可能希望并行获取它们。例如，如果将字母存储在表存储中，则获取 a 和 z 相距很远最好是在获取时进行并行检索操作 a， b 和 c 最接近的是查询。取 a， b  c，和 z 将受益于混合方法。

如果您事先了解所有这些，您可以计算出给定一组PK和RK最好的事情。您对基础数据的排序方式了解得越多，结果就越好。我建议对此进行一般性处理，然后尝试应用您从这些不同查询模式中学到的知识来解决您的问题。