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.
Set the iterator bound when using BatchGet.
Think about this case, we have two keys:
a, zand there are 1 million keys are deleted betweenaandz. When we look up the keyb, RocksDB internal will scan over all the 1 million invisible keys and return the next visible key which isz. It is a big overhead here. RocksDB supports to set the iterator bound likecwhich will stop scanning when meeting the bound.In the
BatchGetcase, Ex.mget b e, It is not necessary to returnzwhen seeksb.About this issue, you should do these following things:
BatchGetin TiKV implemented, and why to use an iterator to look up a key.