 |
sampengV2EX 第 19005 号会员，加入于 2012-04-02 14:39:20 +08:00今日活跃度排名 7031 |
sampeng 最近回复了
光一个双休就多了 2 天休息。
也就是多了 2/20 天的隐形工资不算了。。10%呢。。是不是一算比例还挺可观
也就是多了 2/20 天的隐形工资不算了。。10%呢。。是不是一算比例还挺可观
1 天前 回复了 RealVic 创建的主题 › 分享发现 › 被国产键盘坑麻的经历，为什么你不应该购买 Keychron 的所有键盘？ |
niz 还是很香的
1 天前 回复了 lsk569937453 创建的主题 › 程序员 › [单个 6.20TB 的超大 csv 文件保持顺序的情况下进行去除重]各个方案的可行性分析 |
分治法反而是成本最低的。并没限制时间一定要用最快时间。要加快磁盘吞吐也有很多办法。
1 天前 回复了 wyfig 创建的主题 › 程序员 › 中大型 I/O 密集型微服务项目，搭建测试环境方案 |
说的好像上了 k8s 后就不要 100G 内存一样。。。。
合理方式是：合并微服务。java 的项目。你微服务越多，内存浪费越多。99%的项目，不需要拆他 5-60 个微服务。
合并一半就节省一半云成本。。。
合理方式是：合并微服务。java 的项目。你微服务越多，内存浪费越多。99%的项目，不需要拆他 5-60 个微服务。
合并一半就节省一半云成本。。。
1 天前 回复了 wh469012917 创建的主题 › 云计算 › 阿里云的技术售后，真的是一言难尽 |
但有一说一，云服务的 support 都那样。除非是他服务有问题。一般情况我都不找。没意义
1 天前 回复了 wh469012917 创建的主题 › 云计算 › 阿里云的技术售后，真的是一言难尽 |
所有云都是这样。aws/阿里云。当你企业到一个级别，有专属 BD 后。基本是分钟级回复。如果再上一个级别，比如 aws business support 。让他给你看代码有没什么问题都行。
免费的，能解决问题就 ok 。不用强求那么多。
大家都是研发，技术文档是个什么水平，大家都心里有数。。强求也没用
免费的，能解决问题就 ok 。不用强求那么多。
大家都是研发，技术文档是个什么水平，大家都心里有数。。强求也没用
1 天前 回复了 joetao123 创建的主题 › 程序员 › 阿里云出品的通义灵码是否值得在公司推广使用？会不会有安全问题？跟 github 的 copilot 的比较如何？ |
如果你能劝说公司推广一个 AI 工具。不考虑钱的问题的话。版本答案：copilot
这是唯一解。
这是唯一解。
1 天前 回复了 drymonfidelia 创建的主题 › 程序员 › 要对单个 6.20TB 的超大 csv 文件保持顺序的情况下进行去除重复行，有什么好思路？显然不可能加载进内存 |
我也是想多了。。哪有这么复杂。
读一条。算 hash 。然后读下一条，算下一条的 hash 。相同就扔掉。。。没有相同的就写到另一个文件里面去。一个递归好像就完事了。这应该也是 sort|uniq 的逻辑。只需要内存 （每行 byte *2 ）。这就是纯粹比 ssd 的速度。想加速就是利用 cpu 的并行运算搞搞分块就好了。
读一条。算 hash 。然后读下一条，算下一条的 hash 。相同就扔掉。。。没有相同的就写到另一个文件里面去。一个递归好像就完事了。这应该也是 sort|uniq 的逻辑。只需要内存 （每行 byte *2 ）。这就是纯粹比 ssd 的速度。想加速就是利用 cpu 的并行运算搞搞分块就好了。
1 天前 回复了 drymonfidelia 创建的主题 › 程序员 › 要对单个 6.20TB 的超大 csv 文件保持顺序的情况下进行去除重复行，有什么好思路？显然不可能加载进内存 |
这么点数据就要 spark ，mr 了？
楼上很多说的没错啊。。你倒是试试 sort |uniq 之后看看结果啊。慢是肯定慢，但是试试不比你纠结强。。
=====
rocksdb 是一个解决方案。但如果不想上东西自己算也不是不行。自己构建结构体和硬盘文件内映射关系。hash 一定要在内存里面才能对比？在文件里面就不行么。现在都是 ssd ，随机读取没啥吧。
我猛的一想就是
1.hash 直接建在硬盘上。每次对比用 seed 偏移来查找。这种业务使用最好别用布隆，毕竟不是近似求结果。而是最终求结果。
2.6T 文件。内存里只建一个够 N 条的 hash 。先读 N 条。计算 N 条里的没有重复的。保存到文件 a 。然后一直递归下去。得到 n 个小文件。然后问题就变成了 n 个小文件去重的问题。内存大，就把第一个文件读出来，去其他文件一个一个比。以此递归处理。当然，连小文件都不需要，自己规划好数据结构把 6T 文件看成 n 个小文件也是一个逻辑。这个逻辑下哪怕 1G 内存也能算出来。就看时间了。
楼上很多说的没错啊。。你倒是试试 sort |uniq 之后看看结果啊。慢是肯定慢，但是试试不比你纠结强。。
=====
rocksdb 是一个解决方案。但如果不想上东西自己算也不是不行。自己构建结构体和硬盘文件内映射关系。hash 一定要在内存里面才能对比？在文件里面就不行么。现在都是 ssd ，随机读取没啥吧。
我猛的一想就是
1.hash 直接建在硬盘上。每次对比用 seed 偏移来查找。这种业务使用最好别用布隆，毕竟不是近似求结果。而是最终求结果。
2.6T 文件。内存里只建一个够 N 条的 hash 。先读 N 条。计算 N 条里的没有重复的。保存到文件 a 。然后一直递归下去。得到 n 个小文件。然后问题就变成了 n 个小文件去重的问题。内存大，就把第一个文件读出来，去其他文件一个一个比。以此递归处理。当然，连小文件都不需要，自己规划好数据结构把 6T 文件看成 n 个小文件也是一个逻辑。这个逻辑下哪怕 1G 内存也能算出来。就看时间了。
Select Language