Redis作为NoSQL领域的代表，拥有很高的读写性能，支持比较丰富的数据类型，但是Redis也存在一些缺陷。

  • l 内存数据库，容量有限，成本很高
  • l 主从复制模型，存在数据丢失的风险
  • l 自身备份代价很大
  • l 集群模式存在很多的限制
  • l Redis支持事务，但是并不完全满足ACID

业务要求的KV存储需要满足以下条件：

  • l 兼容Redis通信协议
  • l 分布式持久化存储（数据不能丢失）
  • l 单个存储节点的宕机，不影响整个系统的正常运转（或者可以基于备份自动恢复）
  • l 集群扩容方便，对用户透明
  • l 相对于Redis，性能损失(延迟，吞吐量 ...等)要在可接受范围内
  • l 对于监控、命名空间 ... 提供更好的支持

下面根据网络上的资料，简单整理一下目前比较流行的KV系统

Redis

  • l 内存数据库，容量有限，成本较高
  • l 主从复制模型，不能保证数据强一致
  • l 数据持久化代价很大，对性能影响很大
  • l 有官方和非官方的分布式方案，其中官方集群版本很少听说大规模生产使用
  • l Redis支持事务，但是不满足ACID

HBASE

  • l 支持单行事务
  • l 依赖HDFS，ZK部署运维复杂
  • l 读写延迟比较大
  • l 需要自己实现兼容Redis协议的proxy
  • l 支持数据强一致
  • l 不支持Key级别的TTL

Cassandra

  • l Dynamo的开源实现
  • l 支持最终一致性（AP系统）
  • l 分片规则是hash，对scan不友好
  • l CQL查询语言
  • l 无中心化设计，部署简单
  • l 需要自己实现Redis协议的proxy
  • l Java语言开发
  • l 资料不多

Tair

  • l 客户端支持不够友好，业务需要改造，对开发语言有要求
  • l 不能保证数据强一致性
  • l 支持多种存储引擎

Zeppelin

  • l 360开源的分布式KV存储数据库
  • l 数据采用key space 划分partition，大分片策略
  • l 支持有限的API：Set，Get，Delete
  • l 支持TTL
  • l 支持HashTag，以及HashTag的batch提交原子性
  • l 元数据保证强一致性，数据采用主从复制
  • l 开源关注度很低（star 359），未见社区应用案例

Pika

  • l 单机版的兼容Redis协议的持久化存储引擎
  • l 没有集群方案

SSDB

  • l 底层存储引擎采用leveldb单机引擎，实现zset、map、queue数据结构
  • l 基于master-slave复制、
  • l 全量复制和flush操作速度慢
  • l 本身无集群化方案，类似于redis2.8
  • l 主从复制效率低，全局锁竞争严重
  • l 数据结构的一些操作效率低，很多操作基于遍历
  • l c++实现

LedisDB

  • l Golang实现
  • l 底层引擎采用可替换引擎，leveldb、rocksdb、goleveldb等，实现kv、list、set、zset、hash等数据结构
  • l 采用leveldb或rocksdb会存在cgo性能损失
  • l 基于master-slave复制
  • l 采用类似codis的集群化方案xcodis
  • l 未经线上多规模验证

SwapDB

  • l 深度定制的redis和优化过的ssdb整合
  • l 京东金融开源
  • l 高度兼容redis api
  • l 冷热数据分离，热数据在redis，冷数据存储到ssdb
  • l 可以实现原生的redis cluster集群
  • l 无数据可靠性保证，定位还是缓存
  • l 开源后没看到社区应用案例

Tidis

  • l golang实现
  • l 目前状态为demo实现，还处于功能开发阶段，仅供测试
  • l 实现采用分布式key value引擎TiKV， 可以对比FoundationDB
  • l Tidis类似TiDB层，无状态
  • l 采用存储计算分离架构
  • l 无限水平扩展
  • l 自动数据均衡
  • l Raft副本复制，确保数据不丢
  • l TiKV采用rust语言，底层引擎为rocksdb
  • l 支持分布式事务
  • l 事务采用乐观锁，事务提交冲突可配重试次数
  • l 事务是完全的2PC分布式事务，因为采用TSO时钟，性能较差，延迟比较高

Anna

  • l 伯克利开源的号称最快的KV存储引擎，性能是Redis的10倍
  • l 充分利用了多核架构，尽量避免线程切换，绑定CPU
  • l 针对热点数据有非常好的优化
  • l 没有经过生产检验，偏学术

Masstree

  • l 单机KV系统
  • l 字典树+Btree的组合数据结构
  • l 充分利用CPU cache line
  • l 没有经过生产检验，存在不少的bug，偏学术研究

GMKV

  • l 资料很少，TiKV+proxy，支持Redis协议
  • l 类似Tidis，未开源

DCache

  • l 腾讯开源的分布式缓存
  • l 支持持久化，cache和磁盘的一致性对用户透明
  • l API简单，支持简单的KV接口
  • l 部署比较复杂，组件比较多，运维成本高，依赖ETCD，TARS中间件以及持久化数据库

Aerospike

Aerospike是一个高性能、可扩展、可靠性强的NoSQL解决方案，支持RAM和SSD作为存储介质，并专门针对SSD特殊优化，广泛应用于实时竞价等实时计算领域。官方保证99%的操作在1ms内完成，并提供集群数据自动Rebalance、集群感知客户端等功能，且支持超大规模数据集(100T级别)的存储。

  • l 跟Redis比较亲和，支持String，Hash，Set，ZSet
  • l 支持分布式集群，可以自动负载均衡
  • l 磁盘存储，绕过文件系统，读写性能很高
  • | 限制比较多，比如一个namespace下的set数量，set中的成员数量。
  • | 只支持行级事务，不支持分布式事务
  • | 查询支持限制比较多

ArangoDB

  • | 支持Multi-Model ：KV、Document、Graph、AQL
  • | 数据组织形式：database → collection → document
  • | 底层引擎支持MMFiles和RocksDB，前者是mmap实现锁粒度比较粗。
  • | 支持的索引：Primary、Edge、Hash、Skiplist、Persistent、Geo、Fulltext (文档中的_id、_key、_from、_to字段建立索引)
  • | 支持完整的ACID和snapshot isolation。

SequoiaDB

  • | 支持Multi-Model：支持SQL、API、Json、对象存储
  • | BSON作为记录的存储结构
  • | 数据逻辑组织形式：collection space → collection → doc (bson)
  • | 数据物理组织形式：file (data / index) → extent → page (存放doc)
  • | 引擎级复制，支持灾备
  • | 支持多租户