lmshl

版本答案：RocksDB （与其他 leveldb family 产品）

解析：203 亿个 bloomfilter 在 p=0.01 下所需的内存空间约为 23.75GB 。实际上，去重所需的空间会少于 203 亿，所以在这个内存空间下，实际 p 值将进一步降低。

大部分人可能对 bloomfilter 的使用存在误解，他们只考虑在只有 bloomfilter 单一算法存在的前提下来解决需求，这显然是错误的。现代数据库对 bloomfilter 的应用主要是用来降低 miss key 对磁盘 IO 的影响。如果 bloomfilter 认为这个 key 没有出现过，那么这个 key 确实没有出现过。当 bloomfilter 认为它可能出现过，那么出现的概率为 1-p ，此时需要回表二次确认（磁盘 IO ）。

假设一个典型的重复度为 10 倍的 200 亿数据表文件，在这个空间下，p 值会低至 1e-20 。

那么对这个文件去重，总共会发生 200 亿次内存 bloomfilter 读取，20 亿次 bloomfilter 写入+磁盘顺序写入，以及 180 亿次磁盘随机读取。（考虑到数据库对磁盘的批量写入优化，sstable/memtable 这个数值将会被巨幅降低）

假设一个重复度为 0.1 倍的 200 亿数据表文件，在这个空间下，p 值变化不大。

那么对这个文件去重，总共发生 200 亿次内存 bloomfilter 读取，180 亿次 bloomfilter 写入+磁盘顺序写入，以及 20 亿次磁盘随机读取。（同上）

根据网上其他人做的吞吐量测试，rocksdb 在现代硬件条件下可以稳定达到 10k*rows/s 以上的写入性能，或>1GB/s 的写入吞吐量。乐观地估计，6.2TB 的文件应该能在 2 小时到 2 天左右完成去重。

我没有泛学也没有精学，我就直接开写
反正你泛学精学的目标也是最终变成自己的技能，能写得出来。
那为何不直接开始写。

学习学习，学只是一半，习是另一半。只学不习永远学不会

先把 Explain 贴上来再说

一个大部分连续的 bytes 卡住 gc ，听起来还是很离谱的，除非你给出详细测试步骤，不然很难证明你的前提是对的。
即便你前提成立，也可以简单粗暴的直接上 ZGC 来解决，不需要你重复发明任何东西。

我是精通 Scala ，同时也熟悉且写过万把行 Rust ，所以换到 Kotlin 对我来说算是能力上封印了。
至于论坛里没写过几行 coroutine 的开发来说，对鞋城和虚拟县城的理解不一定强于前端仔（ async/await ），现在谈 VT 取代 coroutine 有点言之过早

最近一个后端项目：ktor + kotlinx + flow api + coroutine + context receivers + arrow.kt
JDK 21 开 Generational ZGC 和 Virtual Thread （作为 coroutine 的 blocking dispatcher ）
我算啥成分？

上生产了，童叟无欺
```
env:
- name: JAVA_OPTS
value: "-Dconfig.file=/app/application.conf -XX:+UseZGC -XX:+ZGenerational"
```

最多的时候负重 5kg 做 10 个（电脑包+mbp 以及其他杂物，差不多 5kg 左右）
负重 15kg 做不到 4 个

https://v2ex.com/t/1022551
《每天 1 块钱，1 分钟，彻底治好了我的腰肌劳损和肩关节疼痛》
亲测有效，腰肌劳损腰痛 10 年，肩关节痛 3 年