levelDB存储复杂数据结构

levelDB是一种轻量级kv类型数据库,且自己本身并不去维护索引.

你可以理解成,levelDB数据库中只有其中的一对kv是有关系的,和其他任何数据没有关系.

就拿 一介布衣 博客举例说明一下:

博客中有nosql分类,点击nosql应该加载此分类下的所有博文并分页.

首先,博文的存储类型如下

key: blog.fse89fw8fwe89fwe98fweiwe9f

value:

{_id:'fse89fw8fwe89fwe98fweiwe9f',title:'levelDB存储复杂数据结构',content:'省略500字',category:'nosql',tag:'nosql,levelDB,levelDB存储结构',create_time:13987546090,click:10}

如上,key为了全部全局唯一 所以用常量 blog.+博文唯一ID

value 是一个字符串,我们读出来后需要反序列化成json来使用,包括唯一ID,标题,内容,类别,标签,创建时间和点击数

到这里并没有结束,你还需要做很多工作,比如我根据类别查询博客,根据标签查询博客,根据时间统计,排序等....

所有的kv数据库貌似都是根据key查询value ,而不能逆向查询 (如果有,请告诉我) levelDB也是,所以我们下面要创建一系列的索引来支撑上面的查询工作.

索引的key本人规定 .开头,只是为了维护,你可以命名自己的索引是 芝麻开门 开头或者更奇葩的都行.

类别索引

key : .category.nosql:fse89fw8fwe89fwe98fweiwe9f

value : fse89fw8fwe89fwe98fweiwe9f

这个索引的作用就是,通过 nosql 我要找到属于这个类别的博文ID,然后根据ID找到博文

说明一下,key组成结构  常量 .category + 类别名 .nosql + 博文ID fse89fw8fwe89fwe98fweiwe9f

value 组成结构 很简单,就是一个博文ID

你也许有疑问:

1.key里面为啥要有 前置常量 .category ,因为我还有标签的索引 .tag 开头的,只是为了区分

2.既然 category 后面已经加上 nosql 类别,为啥还要加一个 博文ID,因为保证此索引是唯一的,我明天继续写一篇关于 levelDB 的文章,他的类别还是 nosql,如果没有这个博文ID,那么就把今天的key完全覆盖了.我的索引是没有意义的.

3.你的索引就是为了查找 博文ID,我需要通过 key 来查找 value,这不是骑着毛驴找毛驴吗?

开始这个问题确实让人迷糊,首先你要同意上面第二点的说明,接着我们来说明如何在没有博文ID的情况下使用此索引找到博文ID

因为levelDB有一项强大的功能,前置匹配,他可以用key的子集去匹配类似的key,注意这里有个前提,必须的从key的0位置开始,就是从头匹配

比如 key是 abcdef 你可以用 a 匹配到这个key,用ad匹配到,用 abc,abcd,abcde 都可以.但是不能用 bcdef来匹配,这样是不行的.

再回头看第三个问题,我根据类别找博文的时候是用下面的key 

.category.nosql:

用这个key 我可以匹配到 N个key ,这些key对应的博文ID 都是nosql相关的,然后我再遍历博文ID获取博文

下一篇接着说代码应用,如果对你还有一点点作用的话,请点击屏幕右下角漂浮广告,帮我筹集阿里云vps的钱^_^