Open Licenser opened 4 years ago
Related: #850 .
remove_range
is a very desirable operation, especially with an implementation similar to https://github.com/facebook/rocksdb/wiki/DeleteRange:
Under the hood, this creates a range tombstone represented as a single kv, which significantly speeds up write performance. Read performance with range tombstones is competitive to the scan-and-delete pattern.
[Insert] Sled: 73.481750254s
[Insert] RocksDB: 43.653174236s
[Select] Sled: 477.36637ms (606348333000000)
[Select] RocksDB: 416.568126ms (606348333000000)
[Delete] Sled: 8.939597962s
[Delete] RocksDB: 81.644µs
9s vs 81us =/
Use Case:
remove and the pop methods work great if using a single key is the goal, there is however currently no option to remove or pop more then a single key. Having an option to remove more than a single (consecutive) key would be really helpful when trying to manipulate more than a single key at the beginning, end or in the middle.
An example use case would be a disk backed queue that gets advanced by multiple elements at a time.
Proposed Change:
Adding functions for the following (naming just a suggestion)
remove_range(start..end)
- equivalent torange
equal to whatremove
is toget
pop_min_to(idx)
- convenience forremove_ranme(0..idx)
pop_max_to(idx)
- convenience forremove_ranme(idx..)
pop_min_n(idx)
- same aspop_min()
executedn
timespop_max_n(idx)
- same aspop_max()
executedn
timesWho Benefits From The Change(s)?
We're currently looking into using sled as a WAL like system for tremor ( https://github.com/wayfair-tremor/tremor-runtime ) and this would improve the API for us :) that said I'd hope that the functions are generally useful given the BTree nature of sled.
Alternative Approaches
Repeated calls to
remove
orpop
functions would lead to the same functionality but that feels somewhat wrong especially in theremove_range
case.