前言

下面这几种方法只能尽量减少空间放大，大部分方案不能完全减少。

rocksdb leveled压缩文档：github.com/facebook/ro…

解决方案

方法一 手动压缩

加载完数据后，执行代码：

    rocksDB.compactRange();

上百G数据，可能得几十分钟，适用于定时加载数据的情况下使用，但是吧，在加载数据过程中导致的空间放大没法避免。

这种方式可以完全压实数据，减少磁盘空间的放大问题。

方法二 动态调整每层大小（推荐）

从最后一层控制前面每一层的大小。

// 初始化设置参数
options.setLevelCompactionDynamicLevelBytes(true);

还不错（测试第一次加载数据，磁盘占用33G，如果不启用这个配置，再加载一次同样的数据磁盘占用达到60多G，设置这个配置为true后，同样的数据再加载，磁盘空间占用在40G内）

但是如果当前版本小于8.2（并且项目已经运行一段时间了，也就是说不是第一次运行项目），需要先手动把数据压缩（方法一），再启用这个参数重新启动。

官网说的（github.com/facebook/ro…

Migrating From level_compaction_dynamic_level_bytes=false To level_compaction_dynamic_level_bytes=true

Before RocksDB version 8.2, users are expected to do a full manual compaction to compact all files into the last level of LSM. Then they can reopen the DB to turn on this option.

方法三 关闭WAL

某些项目在启动进程的时候都会重新加载一次，所以不需要WAL保证数据在crash时候的一致性和可靠性。

WriteOptions writeOptions = new WriteOptions(); writeOptions.setDisableWAL(true); rocksDB.put(writeOptions, key.getBytes(StandardCharsets.UTF_8), value.getBytes(StandardCharsets.UTF_8));

WAL日志文件在数据刷盘完成就删除了，并且我观测方法一执行后，也会清除，这个方法可以和其它方法同时使用。

这种方案的应用场景，适用于每次项目重新启动都需要重新加载数据到本地rocksdb进行存储，而不需要恢复重启前的数据。

如果需要恢复重启前的数据，对数据的持久性有要求，不建议如此配置，进程意外退出，或者未刷盘关闭rocksdb都会导致数据丢失。

方法四 控制每级尽量小点（理论）

从第一层控制每一层的大小

下一层默认是前一层的10倍，如果设置为5倍，我再想会不会更快点触发压缩，当然，重复数据可能还是多，不如方法二效果好（但是方法二的版本有限制哇，如果是新项目无所谓，正在运行的项目如果优化呢，要不升级版本用方法二），并且层数增多，查询速度估计会比默认慢点。

options.setMaxBytesForLevelMultiplier(5);

这个方案未进行过实际验证，所以具体效果如何不确定。

建议

如果场景不是非rocksdb不可，且数据量不是特别大，普通业务项目还是考虑避免使用rocksdb，默认配置下，磁盘放大问题确实比较严重，磁盘空间大的话就算了，不用担心这个问题。