[转帖]KV数据库调研

https://zhuanlan.zhihu.com/p/499313638

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)
• | 引擎级复制，支持灾备
• | 支持多租户