valkey-io
Feature Request: Add Cuckoo Filter support with dump/load capability
Hi Valkey team,
We’re currently using RedisBloom's Cuckoo Filter (CF.* commands) internally at Reddit for high-QPS set membership filtering, and would like to fully replace it with an open-source, license-unrestricted alternative.
We’re very happy to see valkey-bloom being actively maintained! We'd like to request the addition of Cuckoo Filter (CF) support, ideally following the same command semantics as RedisBloom, with dynamic resizing feature.
Most importantly, our use case heavily depends on the ability to dump and load filters. We use this to:
- Periodically snapshot filter state
- Distribute filters to remote clients
- Restore filter from versioned storage
We’d love to either see support for CF.SCANDUMP / CF.LOADCHUNK or any alternative DUMP/LOAD mechanism that allows reconstructing a filter from bytes.
We're happy to assist with API definition, testing, or sharing production constraints to help shape the scope. Thanks for considering this!
@KarthikSubbarao @Nikhil-Manglore Is there any plans on adding this feature in upcoming future? We are currently evaluating RedisBloom's Cuckoo filter module on Redis for one of our use case but this might become a blocker for Valkey migration so wanted to confirm on the plan.
Thank you @mingkun-wang and @bbarani .
We’re currently using RedisBloom's Cuckoo Filter (CF.* commands) internally at Reddit for high-QPS set membership filtering
If it is mainly membership testing, wouldn't Bloom filters be sufficient? This would provide fast membership testing which is scalable and you would also have the ability to configure strict FP rates based on your requirements.
Is there a requirement for item deletions for which you are looking for Cuckoo filter offering? Some customers get around this limitation by applying TTLs (EXPIRE) command on the Bloom filter objects they create. You can perhaps consider this solution in this short term if it makes sense.
Cuckoo filters as well as other probabilistic Data types are something we have discussed in the past to add support incrementally. I can get back regarding more information here shortly
@KarthikSubbarao Can we get an update? If you are open to contributions, is there anything people should know before submission?
