update titan doc to provide guidline on min-blob-size (#16344)

storage-engine/titan-configuration.md

@@ -82,7 +82,7 @@ Titan 对 RocksDB 兼容，也就是说，使用 RocksDB 存储引擎的现有 T
 
 ### `min-blob-size`
 
-你可以通过设置 [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) 来调整 value 的大小阈值，决定哪些数据保存在 RocksDB 中，哪些数据保存在 Titan 的 blob file 中。经过测试，`32KB` 是个折中的值。如果你想进一步提升写性能，并能接受扫描性能的下降，你可以将该值调整为 `1KB`。
+你可以通过设置 [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) 来调整 value 的大小阈值，决定哪些数据保存在 RocksDB 中，哪些数据保存在 Titan 的 blob file 中。`32KB` 是个折中的值，它能确保 Titan 的性能相对 RocksDB 没有回退。但在很多场景中，该值并不是最佳值。建议参考 [`min-blob-size` 对性能的影响](/storage-engine/titan-overview.md#min-blob-size-对性能的影响)来选择合适的值。如果你想进一步提升写性能，并能接受扫描性能的下降，你可以将该值最低调整为 `1KB`。
 
 ### `blob-file-compression` 和 `zstd-dict-size`
 

storage-engine/titan-overview.md

@@ -52,7 +52,7 @@ BlobFile 的实现上有几点值得关注的地方：
 
 + BlobFile 中的 key-value 是有序存放的，目的是在实现 iterator 的时候可以通过 prefetch 的方式提高顺序读取的性能。
 + 每个 blob record 都保留了 value 对应的 user key 的拷贝，这样做的目的是在进行 GC 的时候，可以通过查询 user key 是否更新来确定对应 value 是否已经过期，但同时也带来了一定的写放大。
-+ BlobFile 支持 blob record 粒度的 compression，并且支持多种 compression algorithm，包括 [Snappy](https://github.com/google/snappy)、[LZ4](https://github.com/lz4/lz4) 和 [Zstd](https://github.com/facebook/zstd) 等，目前 Titan 默认使用的 compression algorithm 是 LZ4。
++ BlobFile 支持 blob record 粒度的压缩，并且支持多种压缩算法，包括 [Snappy](https://github.com/google/snappy)、[`lz4`](https://github.com/lz4/lz4) 和 [`zstd`](https://github.com/facebook/zstd)。在 v7.6.0 之前的版本，Titan 默认使用的压缩算法是 `lz4`。v7.6.0 之后，默认使用 `zstd`。
 
 > **注意：**
 >
@@ -122,3 +122,24 @@ Range Merge 是基于 Level Merge 的一个优化。考虑如下两种情况，
 ### 扩容与缩容
 
 基于向后兼容的考虑，TiKV 在扩缩容时的 Snapshot 仍然是 RocksDB 的格式。因此扩容后的节点由于一开始全部来自 RocksDB，因此会显示 RocksDB 的特征，比如压缩率会高于老的 TiKV 节点、Store Size 会较小、同时 Compaction 的写放大会相对较大。后续这些 RocksDB 格式的 SST 参与 Compaction 之后逐步转换为 Titan 格式。
+
+### `min-blob-size` 对性能的影响
+
+[`min-blob-size`](/tikv-configuration-file.md#min-blob-size) 是决定一个 Value 是否用 Titan 存储的依据。如果 Value 大于或等于 `min-blob-size`，会用 Titan 存储，反之则用 RocksDB 的原生格式存储。`min-blob-size` 太小或太大都会导致性能下降。
+
+下表格列举了 YCSB 这个负载在不同 `min-blob-size` 值时的 QPS 对比。每一轮测试中测试数据的行宽和 `min-blob-size` 相等，从而确保 Titan 启用时数据保存在 Titan 中。
+
+| 行宽 (Bytes)      | `Point_Get` |  `Point_Get` (Titan)| scan100 | scan100 (Titan)| scan10000 | scan10000 (Titan)| `UPDATE` | `UPDATE` (Titan) |
+| ---------------- | ---------| -------------- | --------| ------------- | --------- | --------------- | ------ | ------------ |
+| 1KB  | 139255 | 140486 | 25171 | 21854 | 533 | 175 | 17913 | 30767 |
+| 2KB | 114201 |124075 | 12466 |11552 |249 |131 |10369 | 27188 |
+| 4KB | 92385   | 103811 | 7918 | 5937 | 131 | 87 | 5327  | 22653 |
+| 8KB  |104380  | 130647 | 7365 | 5402 | 86.6 | 68 | 3180 | 16745 |
+| 16KB | 54234  | 54600  | 4937 | 5174 | 55.4 | 58.9 |1753 | 10120 |
+| 32KB | 31035  |31052  | 2705 | 3422 | 38 | 45.3 | 984 | 5844 |
+
+> **注意：**
+>
+> `scan100` 是指扫描 100 条记录，`scan10000` 是指扫描 10000 条记录。
+
+以上可见，当行宽是 `16KB` 时，Titan 在所有 YCSB 细分负载下上都超过了 RocksDB。然而在一些极端重度扫描场景下，如运行 Dumpling，`16KB` 行宽下 Titan 的性能会有约 10% 的回退。因此，如果负载是以写和点查为主，建议将 `min-blob-size` 调整为 `1KB`；如果负载有大量扫描，建议将 `min-blob-size` 调整为至少 `16KB`。