关于替换底层的tikv的实践?

TiDB 依赖于底层的存储引擎提供数据的存取功能,但是并不是依赖于特定的存储引擎(比如 TiKV),这里如何替换为新的kv组件?有什么好的实践经验可以参考吗?最好能细节到函数层面

曾经我们考虑过支持多套引擎的,理论上,只要实现 kv.Storage 接口就可以了:

https://github.com/pingcap/tidb/blob/639d9d10d924a75050afe03e94143445142b7806/kv/kv.go#L366

早期这个接口是比较简洁的。 后来发现支持多套引擎的维护成本太高了,你看现在的 Transaction 接口已经挺复杂了

https://github.com/pingcap/tidb/blob/639d9d10d924a75050afe03e94143445142b7806/kv/kv.go#L169

官方维护多套实现维护着非常吃力,接口变更,bug 修复,新功能演进等等。

所以目前只有三套实现:

  1. tikv (用于实际生产环境)
  2. unistore (用于验证性能和实验性 feature)
  3. mocktikv (用于单元测试)

如果已经有一个分布式的kv服务了(提供http的接口来增,删,改,查),这种情况下我要替换掉tikv的引擎,是不是仿照 mocktikv来做?

mocktikv和uinstore这里有什么区别吗?

模仿 mocktikv 做,可以得到一个性能不太优化的,基本能跑的引擎

mocktikv 简单易实现,方便单元测试,它是 key 的编码的布局不太优化

lock 
ver4
ver3
ver2
ver1
ver0

锁 和 数据是编码在同一个 column family 的

实际上锁和数据的访问模式并不相同,放在不同的 column family,使用不同的 GC 策略,性能会更好一些

mocktikv和uinstore 都实现了 Storage 接口,就是实现细节不太一样。

unistore 和 tikv 的实现里面都把 lock 和 数据 拆分开了。然后 unistore 是基于用的 badger 做的,对大的 kv 的性能有优化(sst 里面只放索引不放数据),在 tikv 的 titan 引擎里面也有针对大的 kv 的优化,他俩的关系是,一个新的性能优化的特性可能会在 unistore 里面做了验证可行性,之后可能再在 tikv 中实现。而 mocktikv 是没有考虑性能角度的。

感谢,以后有问题多沟通。

:+1: