问题
我正在尝试从表存储中删除许多可能存在或不存在的行。交易是我需要最小化 I/O 并最大化带宽，所以 1 击来统治它们会很棒。问题是，如果任何批次实体不存在，整个批次都会失败。
为什么
这也让我想到了一个设计问题——为什么请求不简单地返回一个删除结果，指出哪些对象由于 404 而没有被删除。为什么它会抛出异常？这是什么原因。
更多信息
批量大小在 100 的表存储限制内，并且它们都在同一个分区内。
【问题讨论】：
标签： c# .net azure azure-table-storage
要回答您的问题，没有办法避免这种情况。如果批次中的一个实体失败，则整个批次都将失败。
但是你可以做一件事：
当批处理失败时，它返回失败实体的索引。您可以做的是取出该批次并从中创建 3 个单独的批次。第一批将从第一个实体（第 0 个索引）到失败实体的索引（减一），第二批将是失败的实体（所以只有一个实体），最后一批将从失败的实体索引到最后一个实体.对于失败的实体，您可以简单地尝试DeleteIfExists。因此，假设您在一个批次中有 100 个实体，假设第 30 个实体失败，您将创建 3 个批次：
第 1 批：第 0 到第 29 个实体（索引 0 - 28）
第 2 批：第 30 个实体（单个实体）（索引 29）
第 3 批：第 31 到第 100 个实体（索引 30 - 99）
这也让我想到了一个设计问题——为什么请求没有 只需返回一个删除结果，并指出哪些对象是 由于404没有删除。为什么会抛出异常？是什么 原因。
我能想到的一个可能原因是 Storage API 遵守 REST。您尝试删除资源，但它不存在，因此 API 会抛出错误。此外，实体可能无法删除，不仅因为该实体不存在，还因为请求中指定的if-match 条件标头不匹配。详细地说，您可能希望仅在 eTag 匹配时删除实体。在这种情况下，即使实体存在，您的删除操作也会失败。为了处理单个实体删除操作的 404 错误，所有客户端 SDK 都实现了DeleteIfExists 类型的功能，它会吃掉 404 错误。
【讨论】：
1:The specified resource does not exist.
您可以在删除它们之前 PUT 具有相同 PartitionKey 和 EntityKey 的空实体。这样您就可以确保不会出现 404 错误。这是对每个批次的两次一致调用，而不是多次重试并使应用程序的逻辑复杂化。不是一个理想的答案，但我们并不生活在一个理想的世界里:)
【讨论】：