对索引存储与散列存储的一些形而上的思考

来源:互联网 发布:软件研发过程模型 编辑:程序博客网 时间:2024/05/20 00:11

场景

对于数据库大表,为了加速期查询速度,往往在外键上加索引、Java集合类中HashMap使用的很频繁等等,而对于索引存储与散列存储的理解鄙人一直不清晰。
 

问题

索引存储与散列存储怎么理解
 

分析

房间比作存储单元,房间号比作存储单元地址。问题来了,如何快速在一家酒店找到自己的灵魂伴侣呢?这里先假设她(或者他)肯定在某一房间内,身份证作为关键字,你只知道她的身份证号码,长啥样你不知道。首先,数据的存储方式决定其查找方式:
顺序存储
你就只能拿着身份证号码一层一层一间房一间房去找了:费劲啊,时间复杂度n/2;这里应该还涉及到数据安全问题:你不一定又钥匙,她也不一定相信你,让你比对身份证号码。
链式存储
相对顺序存储,链式存储对存储空间的物理位置没有要求:假设酒店有10间房子,顺序存储要求10间房子物理位置相邻,而后者10间房可以分散在不同层且不相邻。查找时间复杂度:n/2―还是得拿着身份证挨房去查找。
 
索引存储
存的时候比较费劲,除了存储节点本身信息外还得花费额外空间建立,存储并维护索引表(个人理解,索引存储应该属于顺序存储与链式存储的一种:节点位置要么相邻要么不相邻)。这时只要根据灵魂伴侣的身份证号码,查表(怎么查呢,得看怎么存储,递归),就可以知道她在那间房了,狠开心。时间复杂度:常量级。空间复杂度:比顺序链式要高。
 
散列存储
根据身份证通过散列函数直接算(而不是查表)出她的房间号。时间复杂读:常量级。其他(待了解):由于用到散列函数,需要额外计算单元支持。

总结

散列或者索引存储是为了提高查询效率,而在存储数据的时候,除了节点实际数据,还存储了其他提高查询数据效率的因子(表,计算单元,或者其他)
 注:以上只是鄙人看书时的一些猜想,停留在理论,有待后续做实验进一步分析论证。

参考文献

2014版数据结构《高分笔记》率辉-著
 

1 0
原创粉丝点击