Pebble 性能参数调优

Pebble vs Rocksdb参数调优表

序号	Pebble参数	Pebble配置建议	Rocksdb参数	Rocksdb配置建议	其他
LevelOptions
1	BlockRestartInterval	// BlockRestartInterval is the number of keys between restart points for delta encoding of keys. // BlockRestartInterval是键的delta编码的重启点之间的键数量 // 所以什么是delta encoding, 什么又是restart points // The default value is 16.			不太懂
2	BlockSize int	BlockSize是每个表块的未压缩的目标大小，以字节为单位。 // The default value is 4096.	block-size = "64KB"	数据块大小。RocksDB 是按照 block 为单元对数据进行压缩的，同时 block 也是缓存在 block-cache中的最小单元（类似其他数据库的 page 概念）。	数据块越大写放大和空间放大越小读放大越大
3	BlockSizeThreshold int	如果区块大小大于目标区块大小的指定百分比，并且添加下一个条目会导致区块大于目标区块大小，则BlockSizeThreshold将结束一个区块。 // The default value is 90
4	Compression Compression	压缩定义了要使用的每个块的压缩算法。 The default value (DefaultCompression) uses snappy compression.	compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]	# RocksDB 每一层数据的压缩方式，可选的值为：no,snappy,zlib,bzip2,lz4,lz4hc,zstd。它表示 level0 和 level1 不压缩，level2 到 level4 采用 lz4 压缩算法, level5 和 level6 采用 zstd 压缩算法,。 no 表示没有压缩，lz4 是速度和压缩比较为中庸的压缩算法，zlib 的压缩比很高，对存储空间比较友好，但是压缩速度比较慢，压缩的时候需要占用较多的 CPU 资源。不同的机器需要根据 CPU 以及 I/O 资源情况来配置怎样的压缩方式。例如：如果采用的压缩方式为"no:no:lz4:lz4:lz4:zstd:zstd"，在大量写入数据的情况下（导数据），发现系统的 I/O 压力很大（使用 iostat 发现 %util 持续 100% 或者使用 top 命令发现 iowait 特别多），而 CPU 的资源还比较充裕，这个时候可以考虑将 level0 和level1 开启压缩，用 CPU 资源换取 I/O 资源。如果采用的压缩方式为"no:no:lz4:lz4:lz4:zstd:zstd"，在大量写入数据的情况下，发现系统的 I/O 压力不大，但是 CPU资源已经吃光了，top -H 发现有大量的 bg 开头的线程（RocksDB 的 compaction 线程）在运行，这个时候可以考虑用 I/O 资源换取 CPU 资源，将压缩方式改成"no:no:no:lz4:lz4:zstd:zstd"。总之，目的是为了最大限度地利用系统的现有资源，使 TiKV 的性能在现有的资源情况下充分发挥。	重点关注
5	FilterPolicy	FilterPolicy定义了一种过滤算法（比如Bloom过滤器），可以减少Get调用的磁盘读取。其中一个实现是来自pebble/bloom包的bloom.FilterPolicy(10)。 // The default value means to use no filter.			重点关注最起码都有70%的空间压缩率, 而且查询的时间接近O(1),用一定的空间去换取更高效的(CPU节约, 时间节约)查询显然是合算的买卖.
6	FilterType FilterType	FilterType定义了现有的过滤策略是应用在块级还是表级。块级过滤器在创建时使用的内存较少，但是访问速度较慢，因为必须首先对索引中的键进行检查以找到过滤器块。表级过滤器需要的内存与sstable中键的数量成正比，但在确定键是否存在时避免了索引的查找。除了在内存有限的情况下，表级过滤器应该是首选。 // Table-level filters should be preferred except under constrained memory situations. 但是怎样的情况算是内存受限的情况呢
7	IndexBlockSize int	IndexBlockSize是每个索引块的未压缩的目标大小，单位是字节。当索引块的大小大于这个目标时，两级索引将被自动启用。把这个选项设置成一个大值（比如math.MaxInt32），就会禁止自动创建两级索引。 // The default value is the value of BlockSize.
8	TargetFileSize int64	当前level的目标文件大小
Options
1 L0 compaction相关配置	L0CompactionFileThreshold int	触发L0压实所需的L0文件的数量
1-2	L0CompactionThreshold int	触发L0compaction所需的L0 read-amplification。	level0-slowdown-writes-trigger = 20	当 level0 的 sst 文件个数到达 level0-slowdown-writes-trigger 指定的限度的时候 RocksDB 会尝试减慢写入的速度。因为 level0 的 sst 太多会导致 RocksDB 的读放大上升。level0-slowdown-writes-trigger 和 level0-stop-writes-trigger 是 RocksDB 进行流控的另一个表现。当 level0 的 sst 的文件个数到达 4（默认值），level0 的 sst 文件会和 level1 中有 overlap 的 sst 文件进行 compaction，缓解读放大的问题。
1-3	L0StopWritesThreshold int	对L0 read-amplification的硬限制，计算为L0子级的数量。当达到这个阈值时，写会被停止。	level0-stop-writes-trigger = 36	当 level0 的 sst 文件个数到达 level0-stop-writes-trigger 指定的限度的时候，RocksDB 会 stall 住新的写入。
2	LBaseMaxBytes	LBase的最大字节数。基准层LBase是L0被压缩到的层次。基准层LBase是根据LSM中的现有数据动态确定的。其他级别的最大字节数是根据基础级别的最大尺寸动态计算的。当一个级别的最大字节数被超过时，会请求压缩。
3	MaxManifestFileSize int64	MaxManifestFileSize是允许MANIFEST文件的最大尺寸。当MANIFEST文件超过这个大小时，它就会被翻转并创建一个新的MANIFEST。	max-manifest-file-size = "20MB"	# RocksDB MANIFEST 文件的大小限制更详细的信息请参考：https://github.com/facebook/rocksdb/wiki/MANIFEST
4	MaxOpenFiles	MaxOpenFiles是对DB可以使用的Open File数量的一个软限制。默认值是1000。	max-open-files = 40960	RocksDB 能够打开的最大文件句柄数。	将文件句柄都保持打开, 避免昂贵的table cache调用, 那么代价呢?
5	MemTableSize int	稳定状态下的MemTable的大小。实际的MemTable大小从min(256KB, MemTableSize)开始，之后的每一个MemTable都会加倍，直到MemTableSize。这减少了MemTable对短暂的（测试）DB实例造成的内存压力。注意，可以有多个MemTable存在，因为刷新一个MemTable需要在后台创建一个新的MemTable并写入旧的MemTable的内容。MemTableStopWritesThreshold对排队的MemTable的大小做了硬性限制。	write-buffer-size = "128MB" 官方512M	# RocksDB memtable 的大小。	原来是从256KB进行增加, 一直增加到MemTableSize
6	MemTableStopWritesThreshold int	队列中的MemTable大小的硬限制。当队列中的MemTable大小之和超过MemTableStopWritesThreshold*MemTableSize时，就会停止写入。这个值应该至少是2，否则每当MemTable被刷新时，写操作就会停止。	max-write-buffer-number = 5	# 最多允许几个 memtable 存在。写入到 RocksDB 的数据首先会记录到 WAL 日志里面，然后会插入到 memtable 里面，当 memtable 的大小到达了 write-buffer-size 限定的大小的时候，当前的memtable 会变成只读的，然后生成一个新的 memtable 接收新的写入。只读的 memtable 会被RocksDB 的 flush 线程（max-background-flushes 参数能够控制 flush 线程的最大个数） flush 到磁盘，成为 level0 的一个 sst 文件。当 flush 线程忙不过来，导致等待 flush 到磁盘的memtable 的数量到达 max-write-buffer-number 限定的个数的时候，RocksDB 会将新的写入stall 住，stall 是 RocksDB 的一种流控机制。在导数据的时候可以将 max-write-buffer-number的值设置的更大一点，例如 10。	不太理解,猜想是2*256k不太理解
7	WALDir string	WALDir 指定 write-ahead logs (WALs) 的存储路径. 如果为空（默认），WALs将被存储在与sstables相同的目录下（即传递给pebble.Open的目录）	wal-dir = "/tmp/tikv/store"	RocksDB write-ahead logs 目录。如果机器上有两块盘，可以将 RocksDB 的数据和 WAL 日志放在不同的盘上，提高 TiKV 的性能。