Lines Matching refs:keys

13 Deleting a range of keys is a common pattern in RocksDB. Most systems built on top of
14 RocksDB have multi-component key schemas, where keys sharing a common prefix are
19 a table or index involves deleting all the keys with that prefix.
26 and it stores various data associated with the product in separate keys. When a
27 product is removed, all these keys must be deleted.
42 Another common pattern is using a custom compaction filter that drops keys in
44 in cases where readers must not see keys in deleted ranges. Further, it has the
63 of keys would be (1) simple, i.e., a single API call; (2) synchronous, i.e.,
64 when the call finishes, the keys are guaranteed to be wiped from the DB; (3) low
83 is droppable. Further, it'd be possible for keys above a range tombstone to disappear
129 find it for arbitrary keys that it covers.
134 *Lifetime of point keys and range tombstones in RocksDB*
187 between consecutive point keys).
218  search for the key in lower levels, since we know that any keys on those levels will be
219  covered (though we do still check the current level since there may be keys written after
242 In these benchmarks, we used a database with 5 million data keys, and 10000 range tombstones (ignor…
243 those dropped during compaction) that were written in regular intervals after 4.5 million data keys…
245 in higher levels that cover keys in lower levels, which allows the benchmarks to exercise more inte…
246 when reading deleted keys.
248 Point lookup benchmarks read 100000 keys from a database using `readwhilewriting`. Range scan bench…
249 …0000 times, and advanced up to 10 keys away from the seek position for short range scans, and adva…