海量数据去重
起因
有个哥们,有 5000G 数据需要去重。
这么大数据其实挺不好处理的,尤其是超不注意就内存/磁盘炸裂。
所以,如何做到性能、内存、磁盘之间的平衡,就是这个问题的难题……
其实这个问题让我想起「编程珠玑」中的一篇内容……
方案
刚开始大家觉得使用使用 redis 的 hash 能力来处理,set/hash 都可以,但是不管是直接丢字符串,还是将字符串 hash 计算后存储,其实都会比较耗费内存。并且 hash 后的数据还会存在一定概率 hash 碰撞,此时更不好处理了。
于是在我们小群里面进行了一些讨论……
于是大家纷纷出招:
- 磁盘换内存式的 kv 数据库(例如 leveldb、boltdb)
- redis 布隆过滤器(布隆过滤器内部也是用的 bitmap,关键)
- redis bitmap
- mapReduce
其实都会有一些优缺点吧。
- 磁盘式 kv db 性能不太行,同时读写磁盘可能会炸裂
- redis 布隆过滤器的话 存在误差,毕竟 「存在的不一定存在,不存在的一定不存在……」
- redis bitmap 如上,存在一定误差,毕竟还是会有撞库的可能
- mapReduce 好像有大炮打蚊子的感觉……
ok,最终因为忙工作,也没细想这个问题了,反正也是嘴炮一番,这事就过了。
几天之后……
过了几天看到哥们发了几篇布隆过滤器的文章,然后怎么还在研究这事。
此时刚好在上班的路上,又重新想了想这个方案。
因为之前公司的产品中有同事提出使用布隆过滤器的「存在则可能存在」的特性做一个减少检索范围的筛选器。
所以恰好好像可以反过来想想,此时方案流程可以是这样:
- 利用布隆过滤器「不存在则一定不存在」的特性
- 例如
- 传入「张三」
- 不存在
- 并标记到「存储器」中(如果为了省内存,其实也可以使用安全 hash 算法进行计算后存入)
- 存在
- 从「存储器」中拿到撞库的字符串列表
- 进行暴力匹配
- 并将「张三」存入布隆过滤器,也就是上面撞库的字符串列表中
- 从「存储器」中拿到撞库的字符串列表
- 不存在
- 传入「张三」
- 重复上面的步骤。
上面说的「存储器」是什么呢?
- 可以是磁盘 kvdb
- 可以是 redis 内存 set/hash
- 如果重复字符串是低概率的事情才可以这么做,否内存炸裂
在「进行暴力匹配」这步骤中的问题
如果重复是大概率的事情,那么暴力匹配的耗时会非常多,变成一个 (O)n 的搜索,性能急剧下降。
此时有点像普通的二叉树,搜索匹配可能变成一个「链表」。
针对这种问题,可以做一些改进:
- 直接存入磁盘 kvdb
- 将字符串通过 安全 hash 算法计算成数字存入 redis bitmap/hash
- 对字符串进行 hash 的目的是降低内存占用
然而
然而哥们直接用了布隆过滤器的「不存在一定不存在」的特性直接「粗」过滤了。
所以……还是水一篇博客吧。