google-cloud-platform - GCP 存储桶传输 (gsutil)

问题描述

我正在尝试使用gsutil mv. 不幸的是，以前的文件名没有任何共同的前缀；相反，它们都以我们的“文件类型”标识符为后缀。

在此传输过程中，我也打算重命名文件以防止将来发生这种混乱。

这是我们当前的文件格式：

gs://{bucket}/{hash}-{filetype}.{extn}

这是我将它们重命名为的格式：

gs://{bucket}/{filetype}/{hash}.{extn}

当前解决方案：

因为目前的格式不利于“前缀”选择器，所以我不得不做以下事情：

let { stdout } = spawn('gsutil', ['ls', `${OLD_BUCKET}/*-${TYPE}`]);
createInterface({ input:stdout }).on('line', str => {
  if (!str.length) return;
  let [hash] = str.replace(OLD_BUCKET, '').split('-');
  let nxt = `${NEW_BUCKET}/${TYPE}/${hash}.${extn}`;
  spawnSync('gsutil', ['mv', str, nxt]);
});

为简洁起见，略作删减。

奇怪的是，gsutil ls它是唯一能够识别基于 glob 的模式的命令。利用这一点，我将每条线路输送到我的“格式转换器”中，然后使用gsutil mv它来启动传输。

此操作在 16 核机器上运行，每个核执行相同的任务——但ls使用不同的文件类型。

问题

这非常慢！

我已经投入了更多的服务器和更多的核心，而且我不能每分钟破坏 26 个文件。我也尝试将-m标志添加到gsutil mv没有区别 - 因为mv每行调用一次。

我们有 13 种文件类型；因此每小时传输 20,280 个文件。将此与 GCP 的“传输”工具进行比较，后者在不到一个小时内将 5M 文件从 BucketA复制到 BackupA。

问题

有什么办法可以加快这个速度吗？

按照目前的费率，我正在等待 15 天，直到转账完成，按小时支付

标签： google-cloud-platformgoogle-cloud-storagegsutil

我对 Rust 不是很熟悉，但据我所知，使用 GCP 和 c++（例如管理），最慢的部分是等待谷歌对每个操作（如gutil ls或gutil mv）的响应，这样，即使在 16 核机器上也是如此，大部分线程都会空闲等待google对操作的响应。

所以你可能想优化你做的请求数量，让谷歌做艰苦的工作。（您还需要为 google 用于执行这些操作的资源付费，不包括执行请求的 VM 实例）

检查gsutil mv 文档，它说-m将使该操作成为多线程的（在谷歌的移动服务中），但只有当相同的请求包含多个要移动的文件时才会起作用。

文档还提到gsutil mv是的扩展，gsutil cp它将文件复制到目标路径，然后在继承命令选项的旧路径（ gsutil cp 文档）上执行删除。

所以我的建议是让您尝试使用Name WildCards压缩请求，并检查gsutil cp文档以获取您也可以设置为的标志列表mv。

抱歉没有发布代码答案，时间对我来说有点短。希望这可以帮助你一些方向:)

google-cloud-platform - GCP 存储桶传输 (gsutil)

问题描述

解决方案

推荐阅读