这是哪个天才程序员搞出来的？
guaguahuang 发表于 2023-7-17 23:11
2的21次方不是 210万不到么？？
16亿 ，没记错，我记得是超过 2的32次方了啊。。。
不好意思，说错了，本意是表达2的21次方乘以2的21次方，也就是2的42次方个文件
16亿=1.6G个文件，光是ToC就可能把你的内存全部吃光了
基本上只能使用无ToC的格式，比如tar了
还有，既然是程序生成的，要不要考虑直接读取某个文件换成直接生成一把？
rubycon2008 发表于 2023-7-18 06:15
就不能分几部分打包压缩么？
1.98TB 的小文件打包成一个压缩包，不知道多强大的电脑配置了？ ...
电脑配置在帖子内容正文最后，AM4平台的天花板了
楼主的内存只有128GB，不知道C盘多大，很明显是压缩软件吃完内存吃缓存然后榨干了资源。
解决办法其实很简单，把文件整理成10个以上单独压缩就好了，每个压缩包大概128G刚好吃完内存。这样转移的时候也能防止压缩文件损坏全部爆炸。
xc11748 发表于 2023-7-18 07:27
不好意思，说错了，本意是表达2的21次方乘以2的21次方，也就是2的42次方个文件 ...
2的四十二次他也不是十六亿啊。。。。
试试用备份系统的工具 snapshot 来打包，软件只有几百K，1,5版的大一点，
关键是速度快，打包好后还支持虚拟盘查看
tar 专门存档打包用的，甚至可以写磁带机，内存的限制在上古时代咋解决的？
我觉得不应该受内存限制需要分卷。直接打包到目标设备就可以了。
wei73 发表于 2023-7-18 08:41
楼主的内存只有128GB，不知道C盘多大，很明显是压缩软件吃完内存吃缓存然后榨干了资源。
解决办法其实很简 ...
C盘是致钛PC0051TB，系统缓存调整了一下，设置了500GB
方糕 发表于 2023-7-18 08:50
2的四十二次他也不是十六亿啊。。。。
现在只生产了一小部分，16亿个，后期总共是2的42次方个
fudaming 发表于 2023-7-18 14:55
tar 专门存档打包用的，甚至可以写磁带机，内存的限制在上古时代咋解决的？
我觉得不应该受内存限制需要分 ...
目前正在用tar命令进行打包，已经进行了24小时，还没结束……
之前有个说法来着，转移大量数据最安全可靠的方法是直接用卡车运输硬盘。。。
上亿个文件，我觉得可以算是大量文件了吧，参考一下
用tar打包成一个文件再压缩试试。用tar将很多文件打包成一个文件就是所谓的“固实”，这种巨量小文件对文件系统压力非常非常非常大，即便是linux ext4，此类情况应该放数据库。不相信你转移了之后尝试删除下这16亿文件试试，可能要删一个星期（没开玩笑）
本帖最后由 Superdoll 于 2023-7-18 18:48 编辑
xc11748 发表于 2023-7-18 07:27
不好意思，说错了，本意是表达2的21次方乘以2的21次方，也就是2的42次方个文件 ...
这种数量的文件目前应该没有任何文件系统能处理. 光是metadata都会超过几十TB.即使真有文件系统支持并且你空间有这么大,处理这些文件没有几年也完成不了.在定方案之前,这种基本问题是一定要考虑的.
jcd_chh 发表于 2023-7-18 07:14
何不tar?而且linux基本都有吧
即使是按16亿个文件,我估计没有十天半个月也压不完.
非得是展开的文件？我前段时间把10-20亿地图图片文件给压进了若干个sqlite文件，就是为了方便迁移和减少IO
不过地图文件天生是金字塔构造的，改造很方便，按照每200k左右的文件一棵子树存成一个sqlite文件，把总文件降到了万级别，IO节省很多
10-20亿个图片，每个图片1KB到50KB不等，把文件压缩进sqlite的速度，在不同的服务器上从1k文件每秒到3k文件每秒不等，速率大概是10MB/s到20MB/s的样子，20亿文件前前后后耗时两三周（不止一台服务器）
Superdoll 发表于 2023-7-18 18:46
这种数量的文件目前应该没有任何文件系统能处理. 光是metadata都会超过几十TB.即使真有文件系统支持并且 ...
不至于，单文件系统没问题的，xfs文件系统，调整好inode大小，考虑牺牲30%空间作为metadata的存储，30TB的硬盘上，最多可以支持到187亿的inode，一个raid6就顶住了
尽量多读一些文件到内存里，然后批量flush到输出文件里就行
不建议打包成一个超大的文件，一旦出错，修复代价极高，我打包成1w个文件，坏了一个我直接去找对应的文件重新打包就行
sagnitude 发表于 2023-7-18 19:11
非得是展开的文件？我前段时间把10-20亿地图图片文件给压进了若干个sqlite文件，就是为了方便迁移和减少IO
...
逐条插入到sqlite?这个方法我也试过1亿个数量级的，到后期建数据索引很慢，根本不是单个主机能玩的，得上服务器
xc11748 发表于 2023-7-18 15:03
现在只生产了一小部分，16亿个，后期总共是2的42次方个
16亿，2TB，
2的42次，一万TB的东西你们准备生成出来存在哪
[失望]
xc11748 发表于 2023-7-18 19:25
逐条插入到sqlite?这个方法我也试过1亿个数量级的，到后期建数据索引很慢，根本不是单个主机能玩的，得上 ...
sqlite支持内存模式啊，我分割成1w个文件就是为了能把整个文件都放到内存里，创建一个纯内存的 sqlite 数据库，读取200k个小文件，做 sql transaction，全程都是内存操作，最后再把sqlite文件通过备份命令，导出到磁盘上，读取200k个文件，写操作只有一次
就算数据量太大也可以设定 mmap_size 来做优化
xc11748 发表于 2023-7-18 19:25
逐条插入到sqlite?这个方法我也试过1亿个数量级的，到后期建数据索引很慢，根本不是单个主机能玩的，得上 ...
sqlite的index很慢，不要在sqlite里面用单表超过100万的数据，分表分库分文件
而且你可以选择删除index，全部插入完成再重建index，删除index后用代码手动去重就好了，每次插入都更新index谁遭得住
方糕 发表于 2023-7-18 19:28
16亿，2TB，
2的42次，一万TB的东西你们准备生成出来存在哪
没那么大吧，2的42次方也就400多亿个
Superdoll 发表于 2023-7-18 18:53
即使是按16亿个文件,我估计没有十天半个月也压不完.
那要不直接dd吧……
xc11748 发表于 2023-7-18 21:29
没那么大吧，2的42次方也就400多亿个
2^42=(2^10)^4*2^2=4T个
买个新硬盘，克隆磁盘，然后快递过去最快
既然是文件那用nosql db试试？比如弄个rocksdb
xc11748 发表于 2023-7-18 21:29
没那么大吧，2的42次方也就400多亿个
42次是四万多亿
sagnitude 发表于 2023-7-18 19:19
不至于，单文件系统没问题的，xfs文件系统，调整好inode大小，考虑牺牲30%空间作为metadata的存储，30TB ...
2的42次方是4T个文件,187亿不算啥
你 16 亿文件应该不会在一个目录中吧，应该有一定的目录层次
假设你的目录层级：....../TopDir/1级目录/2级目录/3级目录/4级目录/.....文件
你可分步骤生成 bat 文件：
dir ....../TopDir/ /B /A:D > 001.bat
这个时候你就有了<1级目录>的清单
然后，用文本编辑工具(Notepad++、Emedit ...... )，打开 001.bat，写个正则，替换行头行尾，变成一堆命令行：
dir ....../TopDir/1级目录001 /B /A:D > 1级目录001.bat
dir ....../TopDir/1级目录002 /B /A:D > 1级目录002.bat
dir ....../TopDir/1级目录003 /B /A:D > 1级目录003.bat
......
执行这个 001.bat 你就能得到一堆 bat 文件，然后用文本编辑工具(Notepad++、Emedit ...... )的【文件内替换】，处理这堆新生成的 bat，你就能得到更下一级的 bat
......
在适合的颗粒度上，你把 nnn （几千、几万）个 bat 文件的内容，改成打包命令
应该就能正常打包了