TiDB 依赖于底层的存储引擎提供数据的存取功能，但是并不是依赖于特定的存储引擎（比如 TiKV），这里如何替换为新的kv组件?有什么好的实践经验可以参考吗？最好能细节到函数层面
2 个赞
曾经我们考虑过支持多套引擎的，理论上，只要实现 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 个赞
如果已经有一个分布式的kv服务了(提供http的接口来增，删，改，查)，这种情况下我要替换掉tikv的引擎，是不是仿照 mocktikv来做？
mocktikv和uinstore这里有什么区别吗？
1 个赞
模仿 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 个赞
感谢，以后有问题多沟通。
楼主我也在寻找替换tikv的方案，能不能交流一下
方便描述下你的场景，以及 TiKV 在其中表现出的问题吗？
更新一下，现在只维护两套了
- tikv (真实环境)
- unistore (单机以及单元测试)
1 个赞
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。