不支持使用 TableBatchOperation 检索多行? [英] Retrieving many rows using a TableBatchOperation is not supported?
问题描述
下面是一段代码，用于初始化一个 TableBatchOperation，用于在一个批次中检索两行:
Here is a piece of code that initialize a TableBatchOperation designed to retrieve two rows in a single batch:
TableBatchOperation batch = new TableBatchOperation();
batch.Add(TableOperation.Retrieve("somePartition", "rowKey1"));
batch.Add(TableOperation.Retrieve("somePartition", "rowKey2"));
//second call throws an ArgumentException:
//"A batch transaction with a retrieve operation cannot contain
//any other operation"
如前所述，抛出异常，并且似乎不支持在单个批次中检索 N 行.这对我来说很重要，因为每个请求我需要检索大约 50 行.这个问题在性能方面与成本方面一样重要. 您可能知道，Azure 表存储定价基于事务量，这意味着 50 次检索操作的成本是单个批次的 50 倍操作.
As mentionned, an exception is thrown, and it seems not supported to retrieve N rows in a single batch. This is a big deal to me, as I need to retrieve about 50 rows per request. This issue is as much performance wise as cost wise. As you may know, Azure Table Storage pricing is based on the amount of transactions, which means that 50 retrieve operations is 50 times more expensive than a single batch operation.
我错过了什么吗?
旁注我正在使用新的 Azure Storage api 2.0.我注意到这个问题从未在网络上提出过.这个约束可能是最近添加的?
Side note I'm using the new Azure Storage api 2.0. I've noticed this question has never been raised on the web. This constraint might have been added recently?
编辑
我在这里找到了一个相关的问题:对 PartitionKey/RowKey 列表的 Azure 表存储查询非常慢.似乎在行键上使用带有或"的 TableQuery 将导致全表扫描.这里确实有一个严重的问题......
I found a related question here: Very Slow on Azure Table Storage Query on PartitionKey/RowKey List. It seems using TableQuery with "or" on rowkeys will results with a full table scan. There's really a serious issue here...
推荐答案
在 Azure 表存储 (ATS) 中设计分区键 (PK) 和行键 (RK) 方案时，您的主要考虑应该是您将如何检索数据.正如您所说，您运行的每个查询都会花费金钱，但更重要的是时间，因此您需要在一个有效的查询中获取所有数据.您可以在 ATS 上运行的高效查询属于以下类型:
When designing your Partition Key (PK) and Row Key (RK) scheme in Azure Table Storage (ATS) your primary consideration should be how you're going to retrieve the data. As you've said each query you run costs both money, but more importantly time so you need to get all of the data back in one efficient query. The efficient queries that you can run on ATS are of these types:
- 精确的 PK 和 RK
- 精确的 PK、RK 范围
- PK 范围
- PK 射程、RK 射程
根据您的评论，我猜您有一些与此类似的数据:
Based on your comments I'm guessing you've got some data that is similar to this:
PK RK Data
Guid1 A {Data:{...}, RelatedRows: [{PK:"Guid2", RK:"B"}, {PK:"Guid3", RK:"C"}]}
Guid2 B {Data:{...}, RelatedRows: [{PK:"Guid1", RK:"A"}]
Guid3 C {Data:{...}, RelatedRows: [{PK:"Guid1", RK:"A"}];}
您已经在 Guid1 检索到数据，现在您需要加载 Guid2 和 Guid3.我还假设这些行没有共同点，就像它们都是针对同一个用户一样.考虑到这一点，我将创建一个额外的索引表"，如下所示:
and you've retrieved the data at Guid1, and now you need to load Guid2 and Guid3. I'm also presuming that these rows have no common denominator like they're all for the same user. With this in mind I'd create an extra "index table" which could look like this:
PK RK Data
Guid1-A Guid2-B {Data:{....}}
Guid1-A Guid3-C {Data:{....}}
Guid2-B Guid1-A {Data:{....}}
Guid2-B Guid1-A {Data:{....}}
其中 PK 是父行的组合 PK 和 RK，而 RK 是子行的组合 PK 和 RK.然后，您可以运行一个查询，返回所有带有 PK="Guid1-A" 的行，您只需一次调用(或两次调用)即可获得所有相关数据.这产生的最大开销是在您的写入中，因此现在当您对一行进行正确处理时，您还必须为每个相关行写入行，并确保数据保持最新(这可能不是问题如果这是一种只写一次的场景，则适合您).
Where the PK is the combined PK and RK of the parent and the RK is the combined PK and RK of the child row. You can then run a query which says return all rows with PK="Guid1-A" and you will get all related data with just one call (or two calls overall). The biggest overhead this creates is in your writes, so now when you right a row you also have to write rows for each of the related rows as well and also make sure that the data is kept up to date (this may not be an issue for you if this is a write once kind of scenario).
如果我的任何假设是错误的，或者如果您有一些示例数据，我可以使用更相关的示例更新此答案.
If any of my assumptions are wrong or if you have some example data I can update this answer with more relevant examples.
这篇关于不支持使用 TableBatchOperation 检索多行?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
