rocksdb减少空间放大

空间放大"/>

rocksdb减少空间放大

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

rocksdb leveled压缩文档：

方法一 手动压缩

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

    rocksDBpactRange();

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

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

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

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

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

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

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

方法四 控制每级尽量小点

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

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

options.setMaxBytesForLevelMultiplier(5);

这个未验证，太费时间了，所以该方案是否可行，我也不确定。