[转帖]KV数据库调研

kv,数据库,调研 · 浏览次数 : 0

小编点评

**比较流行的KV系统** | 系统 | 数据结构 | 数据组织 | 底层引擎 | |---|---|---|---| | Redisl | Hash | key space | RocksDB | | Tairl | Hash | key space | LevelDB | | Zeppelin | Hash | Key-Value | RocksDB | | TiKV | Rust | Key-Value | RocksDB | | Annal | RocksDB | Key-Value | RocksDB | | GMKV | C++ | Key-Value | RocksDB | | Masstreel | C++ | Key-Value | RocksDB | | Redis2.8 | RocksDB | Key-Value | RocksDB | | TiKV+proxy | Go | Key-Value | RocksDB | | DCachel | Go | Key-Value | RocksDB | | AerospikeAerospike | Go | Key-Value | RocksDB | | SequoiaDB | SQL | Collection-Document | RocksDB |

正文

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