Segment log storage

[killme2008]

An experimental implementation for #39

[killme2008]

本机的性能测试, nvme 的 ssd , 总数据大小写入控制在 10~ 18G，测试可用内存不到 7G。

日志攒批写入,一批 100 条，读是从 1 开始循环遍历所有写入的日志，测试程序参见 LogStorageBenchmark。

下面根据日志大小分析测试结果，耗时单位都是秒：

1K

测试项目	RocksDB	Segment
写耗时	1427	2139
读耗时	164	51
写放大	1.9	NA
读带宽	70M	200M

• 写性能下降 50%
• 读性能提升 69%

4K

测试项目	RocksDB	Segment
写耗时	787	789
读耗时	107	17
写放大	1.9	NA
读带宽	130M	700M

• 写性能接近
• 读性能提升 84%

8K

测试项目	RocksDB	Segment
写耗时	849	715
读耗时	117	26
写放大	1.9	NA
读带宽	140M	700M

• 写性能提升 16%
• 读性能提升 77%

16K

测试项目	RocksDB	Segment
写耗时	656	471
读耗时	93	23
写放大	1.9	NA
读带宽	200M	840M

• 写性能提升 28%
• 读性能提升 75%

结论

新的实现优点：

1. 写性能在 log size 超过 4k 情况下提升明显。
2. 读的性能提升较大，这是由于数据大部分命中 page cache 的缘故。
3. CPU 使用更为稳定，没有 compaction 引起的毛刺抖动，并且整体 CPU 消耗更低。
4. 写入带宽占用稳定，没有 compaction 引起的抖动。compaction 情况下，写带宽占用高峰最高达到 10 倍。
5. 磁盘占用略微减少。

缺点：

1. 对于较小的数据没有提升，反而因为引入了额外一次 fsync 导致写的吞吐下降。这个可以通过阈值判断解决，对于小数据不采用 segment 存储，继续走 rocksdb 直接存储，已预留设置。读对于小数据也性能下降巨大，还需要分析。
2. page cache 换入换出引起的写入和读取毛刺还暂时无法衡量。这个跟 kafka/rocketmq 类似。

TODO

1. 更全面的数据可靠性测试。
2. 性能优化，目前的代码还是比较粗糙，还有较大的优化空间。
3. 受限于本机环境，需要在更大数据量下（超过 100G) 的性能测试。
4. 在真实 rheakv 压测场景下的测试。

[killme2008]

定位到为什么 1k 情况下，读的性能急剧下降。

1. 读的性能下降，经过日志分析是出现在 rocksdb.get 环节，这里读的是一个 14 个字节的 value， key 也就8个字节，总共10亿规模的 key，理论上数据很小，不应该这么慢。
2. perf 火焰图分析

最终根据关键字找到这个 issue facebook/rocksdb#3961

在 key 的数量巨大情况下，设置BlockBasedTableConfig#cacheIndexAndFilterBlocks-=true。get 的性能会急剧下降。

3. 设置cacheIndexAndFilterBlocks=false，1K 场景下读耗时缩短为 51 秒。
4. 准备尝试 Partitioned Index Filters策略。

[killme2008]

1. rocksdb 升级到 5.18.3。配置 partitioned index filter.
2. 采用下列 block table 配置，读缩小到 38 秒：

    //  Begin to use partitioned index filters
                // https://github.com/facebook/rocksdb/wiki/Partitioned-Index-Filters#how-to-use-it
                setIndexType(IndexType.kTwoLevelIndexSearch). // use hash search(btree) for prefix scan.
                setFilter(new BloomFilter(16, false)). //
                setPartitionFilters(true). //
                setMetadataBlockSize(8 * SizeUnit.KB). //
                setCacheIndexAndFilterBlocks(false). //
                setCacheIndexAndFilterBlocksWithHighPriority(true). //
                setPinL0FilterAndIndexBlocksInCache(true). //
                // End of partitioned index filters   settings.
                setBlockSize(4 * SizeUnit.KB).//
                setBlockCacheSize(512 * SizeUnit.MB). //
                setCacheNumShardBits(8);

3. 采用官方推荐的另一个策略（因为版本大于 5.15)，设置 cache_index_and_filter_blocks = true and pin_top_level_index_and_filter = true 情况下，仍然非常缓慢，还是同样的 get 环节。

[fengjiachun]

mac os 上性能不到预期的可能原因，先记录下

docker/for-mac#560
mirage/mirage-block-unix#49