Note:
Original topic: tidb的一个key最终落到rocksdb都经历哪些变化？
I mainly want to understand what a TiDB key ultimately looks like when it lands in RocksDB.
Are there any articles that introduce this? I can find it by looking at the code, but it’s a bit slow.
I recommend reading the main documentation, which provides detailed information on the parts you want to know:
Computation, storage, and scheduling are all related and cannot be viewed separately, otherwise, there will be omissions.
It is best to refer to the code to think about the above, I hope it helps you.
I asked on internals.tidb.io , and an expert answered. I’m sharing the answer here for others’ reference.
TiKV supports distributed transactions, which is inspired by Google’s Percolator. In this section, we will briefly introduce Percolator and how we make use of it in TiKV.
What is Percolator? Percolator is a system built by Google for incremental...
Added during the apply phase
{
fn handle_put(&mut self, ctx: &mut ApplyContext<EK>, req: &Request) -> Result<()> {
PEER_WRITE_CMD_COUNTER.put.inc();
let (key, value) = (req.get_put().get_key(), req.get_put().get_value());
// region key range has no data prefix, so we must use origin key to check.
util::check_key_in_region(key, &self.region)?;
if let Some(s) = self.buckets.as_mut() {
s.write_key(key, value.len() as u64);
}
keys::data_key_with_buffer(key, &mut ctx.key_buffer);
let key = ctx.key_buffer.as_slice();
self.metrics.size_diff_hint += key.len() as i64;
self.metrics.size_diff_hint += value.len() as i64;
if !req.get_put().get_cf().is_empty() {
let cf = req.get_put().get_cf();
// TODO: don't allow write preseved cfs.
if cf == CF_LOCK {
self.metrics.lock_cf_written_bytes += key.len() as u64;
self.metrics.lock_cf_written_bytes += value.len() as u64;
I recommend reading the main documentation, which provides detailed information on the parts you want to know:
https://docs.pingcap.com/zh/tidb/stable/tidb-best-practices https://pingcap.com/zh/blog/tidb-internal-1
Computation, storage, and scheduling are all related and cannot be viewed separately, otherwise, there will be omissions.
It is best to refer to the code to think about the above, I hope it helps you.
In different situations, the format of the key is different. You can first take a look at the content related to TiDB’s data storage format.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: TiDBer_jYQINSnf
|
username: 
|
username: 
|
username: 
|
username: 
|
username: