我了解到TiDB的数据都是以key value的形式存储在TiKV中的，像oracle mysql 都是以行的形式存储在数据文件中的，那么TiDB使用的key value的方式存储数据感觉像是oracle的索引组织表。我的问题是为什么要选择这种存储方式，这种方式的优缺点是什么？
优势：
- 没有全表锁，所有DDL操作都能实现在线异步处理
- 顺序写 速度特别快。
我发现ocenabase 也是采用这种方式实现的 。
1 个赞
目前我看到的缺点是： 合并，合并。这个合并消耗的时间有点长。资源有点多
1 个赞
可以了解下 LSM Tree 和 B+ Tree 在存储结构，适应场景上的区别
至于 tidb ，oracle， mysql 为什么会选择不同的实现，是产品设定的适应场景决定的…
参考文档：
https://docs.pingcap.com/zh/tidb/stable/rocksdb-overview#rocksdb-简介
1 个赞
LSM和B+ tree的试用场景了解下
这不就是LSM树和B类树存储的区别吗？
想问下，为什么kv存储会导致没有全表锁
感谢分享，等我看看研究一下
分布，可扩展
另一方面，底层存储使用 KV 对数据进行抽象，是一个更加灵活的选择。
一个好处是简单。对于 Scale-out 的需求，对 KV 键值对进行分片的难度远小于对带有复杂的表结构的结构化数据，另外，存储层抽象出来后也可以给计算带来新的选择，比如可以对接其他的计算引擎，和 TiDB SQL 层同时平行使用，TiSpark 就是一个很好的例子。
从开发角度来说，这个拆分带来的灵活度还体现在可以选择不同的编程语言来开发。对于无状态的计算层来说，我们选择了 Go 这样开发效率极高的语言，而对于存储层项目 TiKV 来说，是更贴近系统底层，对于性能更加敏感，所以我们选择了 Rust，如果所有组件都耦合在一起很难进行这样的按需多语言的开发，对于开发团队而言，也可以实现专业的人干专业的事情，存储引擎的开发者和 SQL 优化器的开发者能够并行的开发。 另外对于分布式系统来说，所有的通信几乎都是 RPC，所以更明确的分层是一个很自然的而且代价不大的选择。
这个不太懂，感觉和全表锁没多大关系把？
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。