说的好像上了 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 。没区别。。

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

@t202201 不是就近问题。是你解决了。你有能力解决。我是你 leader ，我也安你头上。这就是所谓的能者多劳。但你要不能解决或者有能力解决，但是表现出不能解决。。那是另一个故事，看 leader 怎么看，有好有坏。

就事论事而言，这种事，看你怎么看。你是喜欢只做自己眼前事还是对一切事抱有好奇。前者，就是纠结不是自己做的为啥要自己弄。后者，就是有问题我去解决了，反正提升的是我自己，对自己其实没有什么坏处，而且对性格的磨练非常有好处。后者才有一切可能，前者就是拿一分钱干一份事。本身没对错，看个人选择

真其实无所谓，反正给我工资，我是按我的工资输出我的价值。至于是在做什么。我不关心。。。

这个苦恼非常简单。谁给你发工资，听谁的。时间不够，不好意思，排着。

人是有喜好，但是工资不是为你喜好负责的。

你都有基建组了。。不想做找老大呗。从你描述来说本来就不关你事，老大没理由安你头上。基建组不是选个东西说大家都用这个就没事了，培训，解 bug ，推广。都是基建组要做的事。都摊你身上算啥啊。

另一方面，从人性来说，人都是谁能解决眼前的事就找谁，很少会管谁真的负责这个事。显而易见，找你，你前面肯定都给解决，你不路由到基建组，自己担起来。。。可不就出问题找你。