标签：存储 Key LSM Value 索引 全量 key 数据 节点

  上篇文章简单的填了一个坑基于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、单机版本问题；

文章首发地址：https://mp.weixin.qq.com/s/YyXoePq7FamfnfRg0K6-yA

标签：存储,Key,LSM,Value,索引,全量,key,数据,节点
来源： https://www.cnblogs.com/softlin/p/15943529.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。