RocksDB调参随记
2020-06-10 本文已影响0人
GOGOYAO
[TOC]
参考
简述
本文记录工作中,在不同场景下的一些参数调整。
0. 最简单的调优
根据rocksdb的example,open DB的时候,option执行如下方法可以获得最简单的调优。
options.IncreaseParallelism()
options.OptimizeLevelStyleCompaction()
1. ReadOptions.file_cache
cache是为了降低磁盘io的负载,比如说LRU和LFU,假设最近访问过或者最近访问最多的数据,大概率会再次被访问。
但是在某些情况,比如说需要scan数据的时候,通常来说,这种场景下并不意味着这些数据接下来会立马访问(至少不是所有数据),那么此时可以设置ReadOptions.file_cache = false
,避免scan请求影响已有的cache。
2. Prefix相关参数
在使用rocksdb作为单机引擎的newsql数据库中,一般来说会将user_key作为prefix,时间戳作为suffix。
- whole_key_filtering:当开启prefix的时候,prefix的布隆过滤会存入到存储中,如果该项设置为true,那么整个key的布隆过滤还会计算并存储一次。关闭whole_key_filtering可以节省空间,当然会导致错误率的提升。
3. 布隆过滤相关参数
- NewBloomFilterPolicy的第二个参数:false代表针对一个sstfile计算布隆过滤,而不是一个block一个过滤器,这样可以在没有读取index的时候,就先使用布隆过滤。代价是compaction的时候,每个key会额外占用4各字节。
- whole_key_filtering:见【Prefix相关参数】
4. cache相关
- cache_index_and_filter_blocks:可提升读操作性能
- cache_index_and_filter_blocks_with_high_priority:可提升读操作性能
- engine_high_pri_pool_ratio:data block插入到低优先级lru,index和filter block插入高优先级
- pin_l0_filter_and_index_blocks_in_cache:可提升读操作性能
- 共享cache对象:对于newsql来说,多个rocksdb的table共享一个cache,可以提升cache利用率,也方便整个进程的内存管理
5. Compaction相关
- level_compaction_dynamic_level_bytes:最高一层的大小不设阈值限制,亦即target_size(Ln)就是Ln层的实际大小,而更低层的大小阈值会满足如下的倒推关系:
target_size(Lk-1) = target_size(Lk) / max_bytes_for_level_multiplier
。这个方式会尽量将数据放到最底层,更低层有可能都不会存放数据,例如总层数为6层,第6层是276G,那么从L1到L6的触发阈值分别为:0, 0, 0.276G, 2.76G, 27.6G,276G,L1和L2是不会存放数据的。这可以减少空间放大,特别是针对tombstone这种只能在最后一层才会删除的数据。
6. 读写相关
- avoid_unnecessary_blocking_io:如果为true,则ColumnFamilyHandle和Iterator的析构函数不会直接删除过时的文件,而是安排后台作业来执行此操作。为false则可能遇到iterator 的抖动导致的长尾问题(是因为 iterator 在释放的时候需要做一些清理工作的原因)