Azure Blob 存储不会公开任何类型的“blob 重命名”操作 - 这听起来很荒谬，因为重命名实体的想法是几乎所有存储系统中的基本操作 - 并且 Azure 的文档没有提及 blob 的名称是如何定义的内部使用(例如作为 DHT key )，但由于我们可以指定自己的名称，很明显 Azure 没有使用内容可寻址存储模型(因此，一旦 Azure 存储团队确定，重命名应该是可能的决定允许)。
微软提倡“重命名”一个 blob，只需复制它，然后删除原始的 - 这看起来效率极低 - 例如，如果你有一个 200GB 的视频文件 blob，并且 blob 名称中有拼写错误 - 除非在内部Azure 有某种重复数据删除系统 - 在这种情况下，消除“blob 重命名”的特殊情况是非常有意义的，因为在内部它实际上是一个“名称复制”操作。
不幸的是，当前的 blob 复制文档 ( https://learn.microsoft.com/en-us/rest/api/storageservices/fileservices/copy-blob ) 没有描述任何内部过程，事实上，表明 blob 复制可能是一个非常长的操作:
State of the copy operation, with these values:
success: the copy completed successfully.pending: the copy is in progress.
如果它在内部使用重复数据删除系统，那么所有 blob 复制操作都将是即时的，因此不需要“正在进行”状态；同样令人困惑的是，它使用“待处理”来指代“进行中” - 通常“待处理”意味着“已排队，尚未开始”。
令人震惊的是，文档还指出了这一点:
A copy attempt that has not completed after 2 weeks times out and leaves an empty blob
...这可以理解为复制 blob 所需的时间的保证为零。页面中没有任何内容表明较小的 blob 与较大的 blob 相比复制得更快 - 因此，由于某种原因(例如队列很长、不幸的中断等)，可能需要 2 周的时间来纠正我假设的 200GB 中假设的拼写错误视频文件 - 并且不要忘记，在复制操作完成之前我无法删除原始的错误命名的 blob - 这意味着需要设计我的客户端软件来不断检查并最终发出删除操作(并确保我的软件连续运行至 2 周...)。
是否有关于 Azure Blob 复制操作的运行时特征和性质的权威信息？
最佳答案
您可能已经知道，Copy Blob 操作是一种异步操作，并且您上面提到的所有内容都是正确的，但有一点需要注意。 在同一存储帐户内进行复制时，复制操作是同步的。尽管无论是跨存储帐户还是在存储帐户内复制 blob，都会获得相同的状态，但是当在同一存储帐户中执行此操作时，它几乎会立即发生。
因此，当您重命名 Blob 时，您会在同一存储帐户(甚至同一容器)中创建该 Blob 的副本，这是即时的。我对内部实现不是 100% 确定，但如果我没有弄错的话，当您在同一存储帐户中复制 blob 时，它不会将字节复制到某个单独的位置。它只是创建 2 个指向相同存储数据的指针(新 blob 和旧 blob)。一旦你开始对 blob 进行更改，我认为那时它就会更改这些字节。
为了内部了解 Azure 存储，我强烈建议您阅读该团队几年前发表的论文。请查看我的答案，其中包含本文的链接:Azure storage underlying technology .
关于azure - Azure Blob 复制操作便宜吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43674319/