@wxf666 这两个解决方案都是基于 hashtable 去重的,就是那个普通意义的 hashtable,没有什么花招,所以你的猜想都对.

hash 冲突了,就是要回源文件比较原始行,随机读有可能会很多.

但是如果能提前知晓数据的大致分布情况,可能会有更恰当的解决办法.

在不知道的情况下,这两个方案可以快速试错,然后找到正确的方向.

@Keuin 原 OP 也说了要尝试一下你的加行号方案,期待结果

@wxf666

2. 可以指定限制多少内存完成吗?

需要的内存是和要处理的数据量成正比的,如果内存不够,那就无法完成.

当然要在内存不够的情况下完成,那就是另一个解法了,耗时可能会很长,我一开始尝试了一个方案,因为无法较准确的预估处理完所需要的时间,所以就放弃了.

现在的这两个方案处理时间是可靠的,可等的,dedup-use-less-mem 可在约 10 小时左右的时间处理完 203 亿,一个晚上就能得出结论.

@Keuin 请仔细看下原贴,原 OP 已经说了 "尝试过的方案有 sort | uniq 会卡死不出结果"

@wxf666

1. 楼主硬盘读写速度多少？

4 块 4TB 西数机械硬盘做 RAID 0,读写速度可能在 200~400M/s?不太确定.
gen-20.3B-lines.sh 生成 6.8TB 数据用了 7 个多小时.

2. 可以指定限制多少内存完成吗？

dedup-use-more-mem 每 1 亿行数据需要 1.34GB 内存,N 亿就是 N*1.34,当然还需要留出几个 G 的内存给操作系统正常运行.
dedup-use-less-mem 每 1 亿行数据需要 0.67GB 内存.203 亿 136GB 就够了,所以完成 6.2TB-203 亿去重 150G 内存足够了.


3. 有不同的两行，恰好 hash 相同，会出问题吗？

hashtable 就是普通意义的那个,比例 php 的 array,其它语言里的 map, dict 什么的,hash 当然会冲突,这时要解决冲突,常见的解决冲突办法是单链表.所以结果是精确的,不会有误判率什么的.


4. 除顺序读一次原文件外，还需要额外读写多少文件吗？

dedup-use-more-mem 始终都在读原文件.

dedup-use-less-mem 需要额外借助其它文件的帮助.


5. 能轻而易举改造成，针对 CSV 文件（可能有字符串跨多行），且现有成绩影响不大，是吗？

可以的.现在是按\n 取一行的,可以换成其它逻辑.

@ShuWei 是的,简单的 hashtable 就能解决,前提是仔细思考问题本身和操控计算资源.

@picone

1. 思路就是基于 hash 去重的.
2/3. 可执行程序在那里,你可以自己 down 回来试一下.我给的内存用量和处理时间(20 亿以内)是实测数据,不是拍脑袋粗估的.

过一遍一个可执行文件(ELF)是怎么被操作系统(linux kernel)加载并执行的,就很清楚了.

http://heguangyu5.github.io/my-linux/html/20-init_post.html

@Sligcm

当然是改成动态下载编译好的.so,然后调用 `dl()` 加载进来.不过需要进一步完善一下当前的 dl()实现.
这个方法只能安装插件,不能卸载.

@aogg laravel 东西太多了,我在编译 Illuminate/Database 的过程中领教了一下,我自己就不搞了,有需要的人自己编译吧.

@happy32199 webman 自身已经成功编译了,但依赖注入不支持. 详见: https://www.workerman.net/a/1576 **4. 关于 webman 代码调整的说明**部分.

基于 webman 的项目要想成功编译还要等一等,如果 webman-admin 也成功编译了,那离实用就不远了.
当然这也看项目情况,如果没用到 trait 特性,那现在就可以编译了.
我看 webman-admin 的一堆依赖用到了 trait,如果 BPC 不支持 trait,就需要改动很多代码,所以下一步就把 trait 的实现提上日程了.

@nuk 性能还是有很大损失的,PHP8.0 的性能大约是 BPC 的 4 倍,详见: https://www.workerman.net/a/1576 **10.关于性能**部分

@JaguarJack 不明白单文件是什么意思.现在的编译结果就是一个可执行文件,只是不同平台 link 的基础类库稍有不同.

@haha512 上传的文件还在 wp-content/uplaods/ 目录下,静态 html 如果是事先生成的,可以直接编译到二进制里,如果是运行期间动态生成的,原来放哪儿还放哪儿.

BPC 并不改变 PHP 代码的运行逻辑,只是编译成二进制后,原来你要 scandir 来看安装了哪几个主题,glob 来看安装了哪些语言包,这些逻辑肯定要调整.

@zekeluii 编译 laravel 够呛,目前 BPC 还不支持 trait.

@cwcc 并且转换出来的.scm 和.c 都是可查看的. 另外基于 scheme,写 PHP 扩展容易多了.

@CodeCodeStudy 是的,彻底改变 PHP 项目的交付方式. 单就 wordpress 而言,插件和主题也可以以.so 的方式交付.

@millken BPC 不支持跨平台编译,这只是实现时的简化选择而已.

BPC 将 php 编译成 bigloo scheme,而 bigloo scheme 是支持多平台并且能够 Cross Compilation 的.如果愿意,肯定是能做到的,但目前还没到那个阶段.

1. http://www-sop.inria.fr/indes/fp/Bigloo/index.html
2. http://www-sop.inria.fr/indes/fp/Bigloo/manual-chapter33.html

@jry 所以这时间有测试用例保障是非常重要的.一个黑盒子,给定同样的输入,给出同样的输出,内部怎么改都没什么可怕的.要是没有完善的测试用例,做起来心里肯定不踏实.