上篇文章简单的填了一个坑基于LSM数据库的实现了WAL,在该版本中如数据写入到内存表的同时将未持久化的数据写入到WAL文件,在未将数据持久化时程序崩溃,可通过WAL文件将数据还原恢复从而避免了数据的丢失。
目前此基于LSM的数据库还有三大坑:
1、索引问题
2、SSTable合并问题
3、单机版本问题;
本篇文章将解决其中的一个坑,索引问题;
索引问题
到目前为止还没有详细解释当前系统的索引问题到底是什么,不解决会导致什么问题;目前系统在写入数据将数据持久化到SSTable文件并写每一个SSTable文件对应的索引数据时是为每个数据项Key都记录了相应的索引数据,此时的索引为全量索引;
全量索引就会导致索引文件快速增大,索引文件过大后维护的性能、查询性能就会大幅下降;索引此时需要解决索引文件快速增大问题;这里引入了:稀疏索引,稀疏索引也是业内比较常见,普遍用到的数据结构;下面详细介绍对比全量索引与稀疏索引的区别;
全量索引树为每个key存储对应的key在数据文件中的起始位置、数据项长度,导致其索引结构无比庞大;
经过优化,此稀疏索引树结构每隔指定间隔才存储一个索引项;
存储的数据为每个间隔区间的所有key数据,Key为该批的第一个key,值为此批次的:起始位置、批次数据项长度,使得索引结构容量大大减少;
本图为间隔两个Key存储一个索引;
节点AAA: 存储AAA、CCC数据索引
节点DDD: 存储DDD、EEE数据索引
节点HHH: 存储HHH数据索引
节点FFF: 存储FFF、GGG数据索引
索引查询
此时稀疏索引的存储结构方式已经解决,在查询与之前也有不少区别;
全量索引:使用key在索引树查找对应数据项,根据索引存储的start、length去对应的数据文件读取相应的数据;
稀疏索引:在索引树中查找最后一个小于所查询key的key节点、第一个大于所查询key的key节点,使用该节点存储的start、length去对应数据文件读取相应的数据块,从中对比查找出所查询的key;
经过此次索引结构的优化,又填了一大坑,还有两大坑待解决:
1、SSTable合并问题
2、单机版本问题;
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。