对约 35g 的数据去重

你先想一想目标时间复杂度和空间复杂度。去重意味要查找，那最好也就对数时间复杂度。此外要看能否分批处理，数据有无规律。可以分批处理也会快很多。总之要先看数据长什么样。

数据是 35G，其中 id 部分有多大？不大的话哈希应该是有办法建起来的……

是裤子么？

去重字段仅仅是 id 字段？还是全字段匹配？

bloomfilter 有误差率

@opengps 每个 id 字段标识这条数据

@shuangyeying 不是的,亲

@alalida 在用分片,时间换空间,但很慢,每次 10w 条

@malusama 有空间限制的

@alalida 经过分析,每条数据里边的 id 唯一标识这条数据

把 id 提出来，还能有 35g ？

对每条数据 hash 后存到哈希表或者二叉树中。
hash 算法也不需要碰撞率很低的那种，比如 crc32，crc64 这种简单的就行，这样可以加快 hash 速度，并减少内存使用。当碰到 hash 相同的，需要做完全匹配来判断数据是否真的是相等。
哈希表或者二叉树每个节点要存下每个 hash 对应的 id （可能有多个）。

数据用流式读取，或者扔进数据库中。


手机码字，有点乱

还以为是 35 克数据

@grimpil 哈哈哈哈哈哈

遍历所有数据，id 字段走布隆过滤器去重 用不了多少内存

Bitmap

如果数据>>id，拿 id 出来随便爱怎么搞怎么搞
如果数据就是 id，每 7g 分片排序再 merge 排序。

如果只是文本数据，压缩一下传到性能强内存大的机器上，直接导入内存去重

引用；@grimpil #13 还以为是 35 克数据

-------------------------------------------------------
我也看了半天，还在想 35g 啥玩意？难道想提纯？？

数据 hash 然后对比去重？
有个笨一点的办法，数据导入 db 做唯一索引 一条一条导入，导入失败的就是重复的，牺牲时间换空间。

跟 13 楼一样，看到是小写第一反应是 35 克数据……

取 3.5G 做好去重的脚本，然后开一个 64GB 内存的云主机跑

35g? 用什么称的？

大小写很重要啊

直接执行开窗函数按 id 分组排序取大于 1 的项并删除，难道顶不住？

最近做饭做的，看到 35g 还想 35 克去重（ zhong ）是给什么去皮吗

根据 id 第一位进行文件分拣（切割到），假设有 26 个字母，10 个数字； 估计每个文件 1G 左右，那样问题就变成了 1G 文件的处理

shell 里面 sort | uniq 就可以。内存不够的时候 sort 会自动交换到磁盘上。

https://unix.stackexchange.com/questions/383056/sort-huge-list-130gb-in-linux

@lululau 电子秤吧

@ofblyt 姜吧

@gfreezy 存储有限的,都在数据库里

@yufeng0681 id 是纯数字,剩余的空间只有 7 个 G

@fields 建个新表加上 unique key，重新 load 一下就可以

create table tmp(id bigint，unique key id （ id ）)
insert into tmp select id from 你的表