Additional remove functions

Licenser commented 4 years ago

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 to range equal to what remove is to get
pop_min_to(idx) - convenience for remove_ranme(0..idx)
pop_max_to(idx) - convenience for remove_ranme(idx..)
pop_min_n(idx) - same as pop_min() executed n times
pop_max_n(idx) - same as pop_max() executed n times

Who 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 or pop functions would lead to the same functionality but that feels somewhat wrong especially in the remove_range case.

theduke commented 4 years ago

Related: #850 .

loyd commented 2 years ago

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 =/

spacejam / sled