You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 betweena
andz
. 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 likec
which will stop scanning when meeting the bound.In the
BatchGet
case, Ex.mget b e
, It is not necessary to returnz
when seeksb
.About this issue, you should do these following things:
BatchGet
in TiKV implemented, and why to use an iterator to look up a key.The text was updated successfully, but these errors were encountered: