SSDB: Redis 的替代？

2019独角兽企业重金招聘Python工程师标准>>>

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

转载于:https://my.oschina.net/wdyoschina/blog/741005