SSDB: Redis 的替代？

SSDB 360 的 ideawu开发的 NOSQL 数据库，其底层存储引擎基于 LevelDB 实现，接口支持相似于 Redis，彻底兼容 Redis 的协议，支持 list, has, zset 等数据结构。

与 Redis 相比较，SSDB 利用持久化设备存储，避免了纯内存数据库的容量问题，与 LevelDB 的关系是 SSDB 利用了 LevelDB 的高性能存储实现，为其实现了网络和多数据结构支持。除此以外，多节点的主备、主主也是亮点之一。

以前做者就使用了 SSDB 存储一些对数据一致性和持久性不是很敏感的监控数据，在“盲使用”(纯粹了解接口)的状况下，SSDB 仍是跑的很是顺利的而且无痛点的。因为其余业务一样须要一个持久化的高性能队列、键值服务，所以最近简单调研了一下 SSDB 实现和文档，由于对 LevelDB 实现很是熟悉，所以关注点主要放在持久化和数据分发上，感受 SSDB 的缺陷仍是很明显的。

Contents [hide]

• 单机持久化
• 多节点分发
• 随机操做性能
• 小结

单机持久化

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)。