idea's blog

写硬盘

为了持久化, 必须写硬盘.

Log 文件

为了快速写入硬盘, 必须采用追加方式顺序写到 log 文件. 这导致 log 文件中的数据是无序的.

sst 文件

为了快速从硬盘中读取数据, 基于查找算法和局部性原理考虑, 必须将数据排序组织到 sst 文件中.

多个 sst 文件而不是单个

为了快速的插入数据到 sst 文件中, 必须使用多个 sst 文件, 每个 sst 文件只保存一定范围的数据. 堆.

Levels

为了减少 log 文件合并所影响的 sst 文件个数, 将 sst 按层次组织, 层次越深, 文件数量越多. 最坏的情况, 每一次合并都会修改该层次所有的 sst 文件. 而层次越深, 合并发生的概率越小. 树.

Bloom Filter

由于 LevelDB 在某一层查找不存在的数据时, 会继续在下一层进行查找, 所以对于不存在的数据的查找会速度非常慢. 所以, 需要结合 Bloom Filter, 利用 Bloom Filter 能快速地判定"不存在"的特点.

推荐阅读: Leveldb 实现原理

据说 github 功能更强大更适合多人协作开发, 所以我把 SSDB 从 Google Code 上迁移到了 github. 目前正在体验当中, 能想到的 github 的一个好处是, 我可以 fork 一个项目出来, 作为基于 SSDB(LevelDB) 的分布式存储项目, SSDB 仍然作为单机和简单主从结构的存储服务器项目.

项目地址: https://github.com/ideawu/ssdb

经过前段时间的连续奋战, 前两晚的代码清理和收尾, 基于 LevelDB 的 KV(支持数据类型包括 hashmap, zset) 存储服务器 SSDB 终于发布了 1.2.0 版本. 这是一个里程碑式的版本, 因为从此 SSDB 支持了主从同步(master-slave replication), 再加上在线备份功能, SSDB 已经成为一个真正的生产环境的存储服务器!

Google 的 LevelDB 存储引擎保证了 SSDB 至少能存储 T 级别的数据, 并在上面进行快速的查询, 有报告称 100G 级别的数据已经在网站上正常工作. 而 SSDB 本身实现的备份和主从同步特性, 则是对生产环境的必要支持 - 负载均衡.

Continue reading »

有不少用户反馈, 对于曾经编译和安装过 LevelDB 和 Snappy 的环境, 编译 SSDB 会出错. 问题出在 LevelDB 无法正确地找到 Snappy 的库(libsnappy), 而且, SSDB 本身没有考虑 -lsnappy 选项.

最终我决定手动修改 LevelDB 的 Makefile 和 build_detect_platform 两个文件, 完全放弃 Snappy. 但 SSDB 将会在未来的版本中增加 Snappy(直接打包附带源码), 而不是使用系统已安装的 Snappy.

请下载 SSDB 1.1.3: https://code.google.com/p/zdb/downloads/list https://github.com/ideawu/ssdb

开发进度预告: 经过前段时间紧张的开发, 支持主从(master-slave)复制功能的 SSDB 版本 1.2 已经基本开发完毕, 目前在整理代码, 近几天就可以发布! 该主从同步方案用 LevelDB 存储库的更新 Log, 并按 LevelDB 内部的序号组织, 所以主从同步可以容忍非常糟糕的网络环境和非期待的异常当机.