Disaggregating RocksDB: A Produc

2024-07-30  本文已影响0人  rickif
image.png

为了更加充分利用机器资源,Meta 对 RocksDB 基于 Tectonic 分布式文件系统实现了存算分离改造。Tectonic 分布式文件系统提供了类似 HDFS 的文件系统 API。
本文主要记述了 Meta 在实现存算分离过程中遇到的挑战和响应的解决方案。

挑战

解决方案

性能优化

IO 长尾延迟优化

长尾延迟可能由慢节点造成。怀疑节点变慢时,通过其他节点处理负载。

Metadata Cache

由于部分元数据读取的相关操作对延迟要求加高,如获取目录列表、判断文件是否存在、查询文件大小等。针对使用频率非常高的 metadata 设计了对应的 Metadata Cache 进行元数据缓存。

Local Flash Cache

对于重度读的应用场景,使用 Cachelib在 NVM 设备中实现了 block cache,作为现有基于 DRAM 的 block cache 扩展。这个特性的官方名称是 SecondaryCache。

IO Handling

Parallel IO

对于需要读取多个 key 的 MultiGet() 操作,同时并行发起多个 block read,降低读取延迟,可能会导致更多的 CPU 消耗

  1. Compaction Tuning
    Tectonic 支持的读写 IOPS 都更低,更大的 SST 文件可能会带来更好的性能

Redundancy with low overhead

SST 文件

SST 文件消耗了绝大部分的存储空间和写入贷款,需要高可靠低成本的编码方式。最终使用了 [12,8] 编码方案,每个数据块12个编码单元,8个是数据块,4个是校验块。1.5倍的空间和写入带宽开销,带来更好的 SLA 保障

WAL 文件

WAL 文件需要实现低延迟的持久化存储。采用了 5-Way Replica 编码,每个数据块有5个副本。对于大更新量的场景,使用 Striped Encoding,多个节点并行处理 stripe

Data Integrity With Multiple Writers

IO Fencing 分布式锁机制。每个进程拥有一个 token,在后续的目录和文件操作中都使用该 token。字典序更大的 token更新,持有旧 token 的进程将无法对文件和目录进行修改

Preparing RocksDB for remote calls

Differential IO Timeout

Failure Handling in RocksDB

分布式存储场景下,IO 错误发生更频繁,种类更丰富。通过对错误是否是短暂且可恢复进行分类,对错误返回状态进行了增强。在错误码的基础上,增加了是否可重试、影响范围和是否有永久数据丢失等错误元信息。

IO Instrumentation

开发 IO Trace 工具

Utilities

现有 cmd 工具的移植

性能测试

image.png
image.png

测试用例使用 20 字节长的 key 和 400 字节长的 value,共 10 亿个 key,总数据量大小 200 GB。

写入带宽维度,Tectonic 在顺序写上可以与本地存储基本一致,在随机写上比本地存储慢 25%。
读性能维度,Tectonic 的 Get 延迟大致是本地存储的 5 倍;在不开启 Parallel IO 的场景下,Tectonic 的 MultiGet 和 iterator 延迟是本地存储的 5 倍;在开启 Parallel IO 的场景下,Tectonic 的 MultiGet 和 iterator 延迟是本地存储的 3 倍。

上一篇下一篇

猜你喜欢

热点阅读