Skip to content

Commit

Permalink
update titan doc to provide guidline on min-blob-size (pingcap#16344)
Browse files Browse the repository at this point in the history
  • Loading branch information
tonyxuqqi authored Jan 25, 2024
1 parent f5c9958 commit 60ad510
Show file tree
Hide file tree
Showing 2 changed files with 23 additions and 2 deletions.
2 changes: 1 addition & 1 deletion storage-engine/titan-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -83,7 +83,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`

Expand Down
23 changes: 22 additions & 1 deletion storage-engine/titan-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,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`

> **注意:**
>
Expand Down Expand Up @@ -123,3 +123,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`

0 comments on commit 60ad510

Please sign in to comment.