我尝试使用gsutil mv
从各种存储桶移动1500万个文件(4TB)。不幸的是,以前的文件名不共享任何公共前缀;相反,他们的所有"文件类型"身份标识。
在此次转移过程中,我也会重新命名文件,以防止将来发生这种混乱。
这是我们当前的文件格式:
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"转移"进行比较工具,在不到一个小时的时间内将
从BucketA复制 5M文件到BackupA。问题
有什么方法可以加快速度吗?
按照目前的汇率,我会在转账完成前15天查看,按小时付款
答案 0 :(得分:0)
我对Rust不太熟悉,但据我所知,使用GCP和c ++(例如管理),最慢的部分是等待谷歌对每个操作的响应(如gutil ls
或{{1这样,即使在16核心机器上,大多数线程都会空闲等待谷歌对该操作的响应。
所以你可能想要优化你做的请求数量,让谷歌努力工作。 (您还需要支付Google用于执行这些操作的资源,不包括执行请求的VM实例)
检查gsutil mv documentation,它表示gutil mv
会使该操作成为多线程(在google的移动服务中),但只有当相同的请求包含多个要移动的文件时才会有效。
此外,文档还提到-m
是gsutil mv
的扩展,它将文件复制到目标路径,然后在旧路径上执行删除(gsutil cp documentation)继承命令选项。
因此,我的提示是您尝试使用Name WildCards压缩请求,并检查gsutil cp
文档以获取您也可以设置为gsutil cp
的标记列表。
很抱歉没有发布代码答案,时间对我来说有点短。希望这可以帮助你找到一些方向:)