shigen坚持更新文章的博客写手，擅长Java、python、vue、shell等编程语言和各种应用程序、脚本的开发。记录成长，分享认知，留住感动。 个人IP：shigen
shigen在最近的学习中，接触到了一款新的缓存数据库RocksDB，起因是在学习公司内部的一款产品DRM动态配置，其中的底层就用到了这一款RocksDB数据库。但是我当时想到的就是既然是缓存，为什么不去用redis或者guava呢？为此，借助周末，我研究一下了RocketsDB的相关使用。
首先学习的话，肯定是得借助于RocksDB官网了，官网对于它的解释是：
RocksDB是Facebook的一个实验项目，目的是希望能开发一套能能在服务器压力下，真正发挥高速存储硬件（特别是Flash存储）性能的高效数据库系统。这是一个C++库，允许存储任意长度二进制kv数据。支持原子读写操作。
RocksDB依靠大量灵活的配置，使之能针对不同的生产环境进行调优，包括直接使用内存，使用Flash，使用硬盘或者HDFS。支持使用不同的压缩算法，并且有一套完整的工具供生产和调试使用。
RocksDB大量复用了levedb的代码，并且还借鉴了许多HBase的设计理念。原始代码从leveldb 1.5 上fork出来。同时Rocksdb也借用了一些Facebook之前就有的理念和代码。
巴拉巴拉一大堆，概括起来就是：
- 高速存储的数据库
- 灵活的配置，可以保存在内存、闪存、Flash、HDFS
- 数据二进制压缩
对比起来Redis，顿时觉得这个高级在它的高速存储和灵活的配置了。手已经有点痒痒了，准备开始适用一下了。
参照rocksDB的使用文档，我写了如下的代码进行测试：
结合springboot实现单元测试出现了一点问题：
目前还没有找到解决方案。代码如下：
配置：
@Configuration
public class RocksDBConfig {
@Value("${rocksdb.path}")
private String dbPath;
@Bean(destroyMethod = "close")
public RocksDB rocksDB() throws Exception {
Options options = new Options().setCreateIfMissing(true);
return RocksDB.open(options, dbPath);
}
}
其中，我的配置如下：
rocksdb: path: ~/rocksdb_data
Service层：
@Service
public class RocksDBService {
@Resource
private RocksDB rocksDB;
public void putData(String key, String value) throws RocksDBException {
rocksDB.put(key.getBytes(), value.getBytes());
}
public String getData(String key) throws RocksDBException {
byte[] valueBytes = rocksDB.get(key.getBytes());
return valueBytes != null ? new String(valueBytes) : null;
}
public void updateData(String key, String value) throws RocksDBException {
rocksDB.put(key.getBytes(), value.getBytes());
}
public void deleteData(String key) throws RocksDBException {
rocksDB.delete(key.getBytes());
}
}
很奇怪的操作，那就先来看下理论的知识吧。借助GPT，我总结了它和redis、guava之间的区别：
| 特征 | RocksDB | Redis | Guava Cache |
|---|---|---|---|
| 类型 | 持久化键值存储引擎 | 内存键值存储引擎 | 内存缓存引擎 |
| 存储引擎 | LSM树 | 哈希表 | 内存哈希表 |
| 内存使用 | 低（可配置） | 高 | 中等 |
| 持久性 | 是 | 否 | 否 |
| 事务支持 | 是 | 否 | 否 |
| 数据结构 | 键值对 | 键值对 | 键值对 |
| 支持数据类型 | 字符串、字节流、字节数组等 | 字符串、哈希、列表、集合、有序集合等 | 任何Java对象 |
| 缓存策略 | 不适用（持久化存储） | LRU、TTL等 | LRU、最大条目数、定时过期等 |
| 分布式支持 | 可以通过RocksDB的其他工具实现 | 是，通过集群和主从复制 | 否 |
| 优势 | 适合大规模数据、高吞吐量、低延迟 | 速度快、支持丰富的数据结构 | 轻量级、易于集成、适合单机应用 |
| 劣势 | 配置和维护复杂 | 内存受限、不支持持久化 | 不支持持久化、不适合大规模数据 |
其中，涉及到管理、LSM Tree的原理可以参看文章：RocksDB零基础学习
最后，还是借助工具对于RocksDB和redis进行了一波总结：
- 如果你需要在本地文件系统中持久化存储大量数据，并且对数据的读写性能有较高的要求，那么可以选择RocksDB。
- 如果你需要在内存中存储数据，并且对数据的实时性要求较高，或者需要支持复杂的数据结构和功能，那么可以选择Redis。
总结就是：读写性能——RocksDB，实时性——redis。
与shigen一起，每天不一样！
