Azure DML 数据切片？

Question

我在 blob 存储中有 4000 万个 10 TB 的 blob。我正在使用 DML CopyDirectory 将这些复制到另一个存储帐户中以进行备份。花了将近2周的时间才完成。现在我担心直到将 blob 复制到目标目录的日期。是工作开始的日期还是工作完成的日期？

DML 是否使用数据切片之类的东西？

Answer 1

现在我担心在哪个日期之前将 blob 复制到目标目录。是工作开始的日期还是工作完成的日期？

据我所知，当您启动 CopyDirectory 方法时，它只会发送请求告诉 azure 存储帐户从另一个存储帐户复制文件。所有的复制操作都是azure storage。

如果我们运行开始复制目录的方法，azure存储会首先创建一个大小为0的文件，如下所示：

工作完成后，你会发现它的大小发生了如下变化：

所以结果是，如果作业启动，它将在目标目录中创建文件，但文件大小为 0。您可以看到 image1 的文件上次修改时间。

Azure 存储会继续将文件内容复制到目标目录。

如果作业完成，它将更改文件上次修改时间。

所以 DML SDK 只是告诉存储复制文件，然后它会继续向 azure 存储发送请求以检查每个文件的复制状态。

如下：

谢谢。但是，如果在此复制操作期间将文件添加到源目录会发生什么？新文件是否也被复制到目标目录？

简而言之，是的。

DML 不会获取整个 blob 列表并一次发送复制所有文件的请求。

它会首先获取你的文件名列表的一部分并发送请求告诉存储副本文件。

列表按文件名排序。

例如。

如果 DML 已经复制了类似 0 文件的文件名，如下所示。

此目标 blob 文件夹

如果你将0开始文件添加到你的文件夹，它不会复制。

这是来自 blob 文件夹的副本。

完全复制 blob 文件夹：

如果您将文件添加到 blob 文件夹的末尾并且 DML 不扫描它，它将被复制到新文件夹中。

---

因此，在这 2 周内，至少有一百万个 blob 必须以非常随机的名称添加到容器中。所以我认为 DML 在大型容器的情况下不起作用？

据我所知，DML 专为高性能上传、下载和复制 Azure 存储 Blob 和文件而设计。

当你使用 DML CopyDirectoryAsync 复制 blob 文件时，它会首先发送一个列出文件夹当前文件的请求，然后它会发送复制文件的请求。

发送请求列出文件夹当前文件号的操作默认为250。

在获取列表后，它会生成一个标记，即下一个 blob 搜索文件名。它将开始列出文件夹中的下一个文件名并重新开始复制​​。

默认情况下，.Net HTTP 连接限制为 2。这意味着只能维持两个并发连接。

这意味着如果您不设置 .Net HTTP 连接限制，CopyDirectoryAsync 将只获取 500 条记录并开始复制。

复制完成后，操作将开始复制下一个文件。

你可以看到这些图片：

标记：

我建议您可以先设置最大 http 连接数以检测更多 blob 文件。

ServicePointManager.DefaultConnectionLimit = Environment.ProcessorCount * 8;

另外，我建议你可以创建多个文件夹来存放文件。

例如，您可以创建一个存放一周文件的文件夹。

下周，您可以创建一个新文件夹。

然后您可以备份旧文件夹的文件，而无需将新文件存储到该文件夹​​中。

最后，您也可以编写自己的代码来实现您的要求，您首先需要获取文件夹的文件列表。

一次请求获取列表的最大结果是5000。

然后你可以发送请求告诉存储副本每个文件。

如果文件在获取列表后上传到文件夹，则不会复制到新文件夹中。