titan
titan copied to clipboard
Improve the BatchGet behavior for TiKV
Set the iterator bound when using BatchGet.
Think about this case, we have two keys: a, z
and there are 1 million keys are deleted between a
and z
. When we look up the key b
, RocksDB internal will scan over all the 1 million invisible keys and return the next visible key which is z
. It is a big overhead here. RocksDB supports to set the iterator bound like c
which will stop scanning when meeting the bound.
In the BatchGet
case, Ex. mget b e
, It is not necessary to return z
when seeks b
.
About this issue, you should do these following things:
- Verify RocksDB that behave like what described above.
- Figure out how the
BatchGet
in TiKV implemented, and why to use an iterator to look up a key. - Improve the TiKV implementation and the Titan code.