为什么基于LSM Tree & Key Value的数据库也可以用于oltp?

一直都对TiDB有些关注,但也一直对有些问题都一知半解,TiDB是分层解耦的强一致可用于金融场景分布式数据库,PD用于提供时钟服务和字典服务,TIDB提供无状态化的sql解析层和运算层, 底层存储曾是基于RocksDB改造的TiKV,而且存储是基于LSM Tree,而且又基于Key Value,本人也是学渣中的学渣,有几个问题请教下大拿,请不吝赐教:
1.Key Value的貌似都是hbase这种或者redis这种适合海量查询,只取某一个值的NoSQL数据库,但是OLTP都是行模式的,以为一个sql可能需要扫描很多个列,而且还会有列锁定/mvcc的问题,为啥TiDB会使用Key Value架构?
2.LSM Tree这种对写友好读不友好的存储结构,一般都是用来做OLAP的,不适合频繁的select/update,因为可能需要多层合并,如何解决合并带来的抖动问题
3.Key value 跟LSM Tree有什么必然的关联吗?
4.raft 架构相比 paxos协议是否有不是强一致的说法?
btw:(OB也是LSM 架构,不同的是OB是基于paxos,TiDB是基于ETCD RAFT)

1、这个涉及到 kv 到 schema 的转换,简单理解 ,key 是主键,value 是一整行数据。sql 本身就是行存,所以如果要读磁盘就会读一整行,而 lock 是使用 rocksdb 中的 ColumnFamily 单独存储,不会有额外负担。
2、其实是对比选择 lsm ,以及 b+tree 两个结构,可以对比下两者,lsm 有其优点。和 kv 也没什么必然的练习。raft 也是强一致的。

原来key对应的value是一整行,这样理解起来就好多了,我以为读一整行数据需要读非常多的key跟value才能选到一整行数据。

那这样我还有另外一个问题,在官网没找到,TiDB 4.0 对字段数量有限制吗?

谢谢您!