基于leveldb的Nosql数据库SSDB详解大数据

   


    SSDB 是一个 C/C++ 语言开发的高性能 NoSQL 数据库,支持 zset(sorted set), map(hash), kv, list 等数据结构,用来替代或者与 Redis 配合存储十亿级别的列表数据。


一.SSDB 的主要特点：

        1.支持 zset, map/hash, list, kv 数据结构, 可替代 Redis

        2.特别适合存储大量集合数据, 支持丰富的数据结构: key-value, key-map, key-zset, key-list.

        3.使用 Google LevelDB 作为存储引擎, 使用 C/C++ 开发

        4.支持主从同步, 多主同步

        5.客户端支持 PHP, C++, Python, Lua, Java, Ruby, nodejs, Go 等

        6.内存占用极少

        7.图形化界面管理工具(phpssdbadmin)

        8.Redis API 兼容, 支持 Redis 客户端

        9.替代 Redis 数据库, Redis 的 100 倍容量

        10.持久化的队列服务

    与 Redis 相比较,SSDB 利用持久化设备存储,避免了纯内存数据库的容量问题,与 LevelDB 的关系是 SSDB 利用了 LevelDB 的高性能存储实现,为其实现了网络和多数据结构支持。除此之外,多节点的主备、主主也是亮点之一。SSDB和Redis兼容,这样不用改源码,就可以换个存储引擎了。ssdb主要是可以把存储不下的持久化到硬盘,解决Redis容量有限问题。

    SSDB还不是成熟的开源项目,社区不够活跃,贡献者不多；主要开发人员也非常忙, 项目的后续发展没有规划；因为一些原因,舍弃了很多重要的功能,比如没法查询命中率；等等。


二.单机持久化

    SSDB 利用 LevelDB 作为存储引擎,所有的接口实现上利用了 LevelDB 的 Get, Put 和 Iterator 操作,但是 LevelDB 的默认接口是缓存的,换句话说 LevelDB 的 Write 接口在实现上仅仅调用了 fwrite 系统接口写入了日志,但是并不会 sync 日志文件,因此日志文件的数据仍处于 Page Cache 中。LevelDB 的目的是上层需要根据业务情况传递给 LevelDB 的句柄需要带上 “sync=true”,以事务的方式去 sync 之前的操作。而 SSDB 因为提供的是 Redis 的接口,并不提供事务的接口,因此所有的写操作都不可能去使用同步写的方式,LevelDB 对于同步写的实现实际上不太好,性能会比较低。

    为了验证 SSDB 的持久性,通过启动一台 VM 运行 ssdb-server,然后不断写入数据,在中间 kill 这台 VM。重启 VM 后发现只持久化存储了 500 个键值,而在客户端侧已经得到了 7W 个成功存储键值的回应。


三.多节点分发

    同样考虑到 SSDB 支持多节点分发的特性,如果多台 SSDB 服务器能够同步在内存中写入,那么持久性还是能大大提高。简单的浏览了 SSDB 的实现,发现主备或者是主主的模式下,客户端的写入操作仅仅在目标节点缓存,而分发到其他复制节点的操作是异步的,也就是说写操作会被塞入一个队列中,一个分发线程会间隔将这些写操作分发到其他节点。那么显然在客户端收到回应后是可能存在一段时间发出的数据是并没有被复制节点收到的,这使得在目标节点崩溃后,数据存在丢失的潜在可能。


四.随机操作性能

    LevelDB 是一个对于顺序读写非常友好的数据库实现,但是对于随机读的性能会比较糟糕。因此,SSDB 在面向随机的键值读取上会比较糟糕,它更适合一些批量读写操作,如监控数据的存储,时间序列数据等等。
五.总结

    SSDB 是一款不错的 NOSQL 数据库实现,其丰富的接口和友好的使用对于特定使用场景非常不错,但是因为持久性和存储引擎天然的劣势情况下,并不适合对于持久性要求高或者随机操作频繁的业务。至于替代 Redis 的情况,在多节点情况下,Redis 的持久性更加好,而 Redis 的高性能更是 SSDB 无法达到的,SSDB 替代 Redis 的场景应该不会太多。推荐将 SSDB 用于监控应用、非持久消息队列和顺序操作的缓存服务,也就是容许数据丢失或者阴影读(shadow read)。

转载请注明来源网站:blog.ytso.com谢谢！