请问TiDB采用lsmtree架构,memtable用的跳表,那么意味着每增加一个索引,memtable里都要维护一个skiplist吗?
既然immutable和memtable里的数据结构为跳表,也就是有序的,那么从imumutable落盘到L0层时,也是顺序写入吧?那么可不可以理解为,L0层的单个sstable里key值是有序的,但多个sstable之间的key值是非顺序的?
希望能得到指点解答,感谢感谢。
请问TiDB采用lsmtree架构,memtable用的跳表,那么意味着每增加一个索引,memtable里都要维护一个skiplist吗?
既然immutable和memtable里的数据结构为跳表,也就是有序的,那么从imumutable落盘到L0层时,也是顺序写入吧?那么可不可以理解为,L0层的单个sstable里key值是有序的,但多个sstable之间的key值是非顺序的?
希望能得到指点解答,感谢感谢。
上层数据具体编码对底层屏蔽,没有多一个 index 就多一个 skiplist 之说。
这段理解是对的
感谢回复,本人小白,还是没理解“上层数据具体编码对底层屏蔽”啥意思试着用例子表达下我的疑问。比如有user表,表中有两列(uid,email),uid是整型主键,那么现在这个表的kv对简单表示为uid–>email,现在我对email建了一个二级索引,那么在tikv里是不是得存email–>uid的kv对?那么在进行写入时,email–>uid这个kv对也要遵循memtable->immutable->sstable这个过程吗?在通过二级索引email进行查询时,又是在哪一层定位到email对应的主键或rowid呢?
感谢指点
整体上所有的 sstable 是一个大的 key map,单个 sstable 里面是有序的,L0 层不同 sstable 之间可能存在一些 key 重叠;每增加一个索引,如果索引被打散到在不同的 region(key 范围) 里面,可能独立存储在另一个 sstable 中,也会遵循 memtable->immutable->sstable 这个过程;在通过二级索引email进行查询时,会先去 memtable,block-cache 中查找,如果没找到到,会将 sst 文件中的文件读到 block cache 进行缓存。
我的理解:
我发现sstable有十几层, 写放大问题会不会比较严重?
sstable十几层的目的是什么?
没有十几层呀, 6 层呢。写放大情况是存在的,不过这块随着存储层的写入优化,性能和存储这部分问题会解决的。另外对于大的 values 我们提供了 titan 存储影响。https://docs.pingcap.com/zh/tidb/stable/titan-overview
可能是我看错了吧。 谢谢
请问 sstable 十几层是通过什么观察到的,可以贴下相应的信息或截图吗?
我之前查配置, 记错了应该; 昨天又查了一下 是6层
谢谢回复,您回复中提到“在通过二级索引email进行查询时,会先去 memtable,block-cache 中查找”
这里去block-cache读我比较容易理解,但”先去memtable“我比较迷惑。memtable中我个人理解里面是一个以主键(或rowid)排序的skiplist,还是拿上面提到的(uid,email)表,考虑一下这个场景:
请问,这时用户2是如何在memtable中找到email=‘email@123.com’这个key的?(因为memtable中只有主键顺序的跳表嘛,通过主键uid查询的话可以用二分法定位,那么通过二级索引email怎么定位我就很迷惑)
不知道我表达清楚没有,感谢感谢
对,是要两次定位,因为二级索引做kv映射编码时,已经把二级索引对应的主键值编码进二级索引的key值里去了,只要能定位到二级索引email='email.123.com’,自然就能拿到主键rowid的值,我就是不明白怎么在memtable中定位到二级索引email='email.123.com‘这个key的,或者这个步骤不是在memtable完成的?
这个和通过主键定位到 value 操作是类似的吧,应该是通过 memtable 提供的 Get 接口完成
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。