search

syndtr / goleveldb

LevelDB key/value database in Go.
BSD 2-Clause "Simplified" License
6.13k stars 968 forks source link

bloomfilter's performance issue #271

Open lubit opened 5 years ago

lubit commented 5 years ago

I use bloom filter option and it really increased the space of db(include 536870912 entry ).
But the db.Get() query speed is slower than without bloom filter --------- this is the program output ---- lvlGet[db_dir:./lvl, opt_bloom:true] cost: 414.32µs lvlGet[db_dir:./lvl, opt_bloom:false] cost: 254.424µs lvlGet[db_dir:./lvl_bloom, opt_bloom:true] cost: 1.985286ms lvlGet[db_dir:./lvl_bloom, opt_bloom:false] cost: 532.908µs --------- this is the program output --- end so is this right?

funny-falcon commented 4 years ago

If you query for existing often overwritting key (ie it exists in every LSM level) then bloom filter is unnecessary overhead.

But if you query for non-existing keys or keys that were updated once during long time (therefore it is in single level only), then Bloom filter should reduce execution time. More over: for just inserted keys it could save reading files from last level (and they could be not in file cache already)