光一个双休就多了 2 天休息。
也就是多了 2/20 天的隐形工资不算了。。10%呢。。是不是一算比例还挺可观

分治法反而是成本最低的。并没限制时间一定要用最快时间。要加快磁盘吞吐也有很多办法。

说的好像上了 k8s 后就不要 100G 内存一样。。。。

合理方式是：合并微服务。java 的项目。你微服务越多，内存浪费越多。99%的项目，不需要拆他 5-60 个微服务。

合并一半就节省一半云成本。。。

但有一说一，云服务的 support 都那样。除非是他服务有问题。一般情况我都不找。没意义

所有云都是这样。aws/阿里云。当你企业到一个级别，有专属 BD 后。基本是分钟级回复。如果再上一个级别，比如 aws business support 。让他给你看代码有没什么问题都行。

免费的，能解决问题就 ok 。不用强求那么多。

大家都是研发，技术文档是个什么水平，大家都心里有数。。强求也没用

如果你能劝说公司推广一个 AI 工具。不考虑钱的问题的话。版本答案：copilot
这是唯一解。

我也是想多了。。哪有这么复杂。

读一条。算 hash 。然后读下一条，算下一条的 hash 。相同就扔掉。。。没有相同的就写到另一个文件里面去。一个递归好像就完事了。这应该也是 sort|uniq 的逻辑。只需要内存 （每行 byte *2 ）。这就是纯粹比 ssd 的速度。想加速就是利用 cpu 的并行运算搞搞分块就好了。

这么点数据就要 spark ，mr 了？
楼上很多说的没错啊。。你倒是试试 sort |uniq 之后看看结果啊。慢是肯定慢，但是试试不比你纠结强。。

=====

rocksdb 是一个解决方案。但如果不想上东西自己算也不是不行。自己构建结构体和硬盘文件内映射关系。hash 一定要在内存里面才能对比？在文件里面就不行么。现在都是 ssd ，随机读取没啥吧。

我猛的一想就是

1.hash 直接建在硬盘上。每次对比用 seed 偏移来查找。这种业务使用最好别用布隆，毕竟不是近似求结果。而是最终求结果。

2.6T 文件。内存里只建一个够 N 条的 hash 。先读 N 条。计算 N 条里的没有重复的。保存到文件 a 。然后一直递归下去。得到 n 个小文件。然后问题就变成了 n 个小文件去重的问题。内存大，就把第一个文件读出来，去其他文件一个一个比。以此递归处理。当然，连小文件都不需要，自己规划好数据结构把 6T 文件看成 n 个小文件也是一个逻辑。这个逻辑下哪怕 1G 内存也能算出来。就看时间了。

同兔。那就钓鱼，枸杞吧

这玩意看书简直是开玩笑…书还没到，可能玩法就变了。看个寂寞

其实如果是我…我会改成 6 分钟或者 5 分钟。然后去怼提出这个需求的人。

@jitongxi 阿里云？

@t202201 反正没人管的东西。你也要改 bug 。如果是开源的，不好用的地方目前看起来你完全有时间和能力去提 pr 。。这种事就是只要你想，就有无数有利自己的事可以做。如果不想，就会找理由去排斥他。全靠个人啦。。

如果是云。改机器配置。99%的项目，直接升级配置的成本远低于人的成本。。。

在 gpt/copliot 面前都是 tab 。没区别。。

还有，很多人其实对别人的框架首先抱有讨厌和排斥心态的。
这个也是一个选择，一个是讨厌和排斥，觉得不好用。另一个是在使用过程中不要无限放大缺点，而是思考他的优点是什么。自己从他的设计思路中学习优秀的部分。这些是平常写项目不可能能学到的东西。