SSDB(LevelDB 服务器, NoSQL 存储方案)的 zscan 是最强大的一条命令, 因为它操作的是 zset(sorted set) 数据类型, 只需要一条 zscan 命令就能直接地表达业务逻辑, "所写即所想". 例如, 获取用户的未读消息列表, 获取按上架时间排序的商品列表, 获取微博 timeline...
zset 可以理解为关系数据库里具有两个字段的表, 一个字段是 key, UNIQUE 索引, 也即数据的唯一标识; 另一个字段是浮点型 score, 每一个 key 对应的排序权重值. 在关系数据库中, 要分页遍历数据, 就要执行类似的一条 SQL 查询:
select * from table order by score, key limit start, size
为了持久化, 必须写硬盘.
为了快速写入硬盘, 必须采用追加方式顺序写到 log 文件. 这导致 log 文件中的数据是无序的.
为了快速从硬盘中读取数据, 基于查找算法和局部性原理考虑, 必须将数据排序组织到 sst 文件中.
为了快速的插入数据到 sst 文件中, 必须使用多个 sst 文件, 每个 sst 文件只保存一定范围的数据. 堆.
为了减少 log 文件合并所影响的 sst 文件个数, 将 sst 按层次组织, 层次越深, 文件数量越多. 最坏的情况, 每一次合并都会修改该层次所有的 sst 文件. 而层次越深, 合并发生的概率越小. 树.
由于 LevelDB 在某一层查找不存在的数据时, 会继续在下一层进行查找, 所以对于不存在的数据的查找会速度非常慢. 所以, 需要结合 Bloom Filter, 利用 Bloom Filter 能快速地判定"不存在"的特点.
推荐阅读: Leveldb 实现原理
据说 github 功能更强大更适合多人协作开发, 所以我把 SSDB 从 Google Code 上迁移到了 github. 目前正在体验当中, 能想到的 github 的一个好处是, 我可以 fork 一个项目出来, 作为基于 SSDB(LevelDB) 的分布式存储项目, SSDB 仍然作为单机和简单主从结构的存储服务器项目.
| Redis | SSDB | |
|---|---|---|
| kv | get | get |
| set | set | |
| del | del | |
| incr/incrBy | incr | |
| decr/decrBy | decr | |
| getMultiple | multi_get | |
| setMultiple | multi_set | |
| del(multiple) | multi_del | |
| keys | scan(for kv type only) |
| Redis | SSDB | |
|---|---|---|
| hashmap | hget | hget |
| hset | hset | |
| hdel | hdel | |
| hIncrBy | hincr | |
| hDecrBy | hdecr | |
| hKeys | hkeys | |
| hVals | hscan | |
| hMGet | multi_hget | |
| hMSet | multi_hset | |
| hLen | hsize |
| Redis | SSDB | |
|---|---|---|
| zset | zScore | zget |
| zAdd | zset | |
| zRem | zdel | |
| zRange | zrange/zscan | |
| zRangeByScore | zscan | |
| zIncrBy | zincr | |
| zDecrBy | zdecr | |
| zCount | ||
| zCard | zsize |
经过前段时间的连续奋战, 前两晚的代码清理和收尾, 基于 LevelDB 的 KV(支持数据类型包括 hashmap, zset) 存储服务器 SSDB 终于发布了 1.2.0 版本. 这是一个里程碑式的版本, 因为从此 SSDB 支持了主从同步(master-slave replication), 再加上在线备份功能, SSDB 已经成为一个真正的生产环境的存储服务器!
Google 的 LevelDB 存储引擎保证了 SSDB 至少能存储 T 级别的数据, 并在上面进行快速的查询, 有报告称 100G 级别的数据已经在网站上正常工作. 而 SSDB 本身实现的备份和主从同步特性, 则是对生产环境的必要支持 - 负载均衡.
|
带有此标志, 表示本博客已经被加入到IT牛人博客聚合网站. |
Loading ...