摘要
之前的跳表索引专利写的不够详细,第二版把细节给整完备
第二版修改点:
一. 相关概念介绍不完整, 补充相关名词解释, 以及说明业务场景
名词解释:
- 知识网格与元数据
- 列式存储
- 向量化读取(pack)
业务场景:
- 具体说明在分析股票的时间范围内的数据指标时的场景
二.对现有的innodb的B+索引方案的不足做突出强调,针对性说明如何解决
innodb的B+树索引问题:
- innodb的B+树索引维护负担大，无法应用于全部的列
- innodb的B+树索引高度与数据量相关, 随着数据量增加引发范围查询的性能问题
针对性说明如何解决:
- 为何新的索引结构的维护负担小
- 为何不会随着数据量增加导致性能下降
三. 自适应跳表索引的完整的生命周期, 需补充完整
生命周期划分:
- 索引的生成时机, 第一次构建出该索引, 需要考虑生成的耗时
- 索引的销毁时机,与mysqld服务生命周期相同的话,需要考虑对内存的占用, 以及为了其他模块内存使用而销毁索引的问题
- 索引的更新时机
四. 在SQL语法支持上，添加用户可以自定义对特定列添加跳表索引
说明用户可以自定义后
- 对用户的便利性的影响
- 对索引生成时机的影响
五. 需要说明索引结构为什么可以不用支持事务隔离
说明点:
- 从使用场景入手,说明范围查询分析可以容忍一定时间内的过期数据
- 从跳表的数据结构与更新时机入手, 说明索引最终指向的是物理列的地址索引, 即使索引过期, 当真实的物理列地址变化时,可以使用变化的版本，用以控制是否数据已变化, 如果变化则数据已经过期, 超过一定数量则更新索引，可容忍则返回结果
六. 索引支持的数据类型
- 为了性能当前只支持整型和单精度浮点型
- 以clickhouse的算法优化为例说明不同的数据类型有其最适用的算法和数据结构
