discuz 网站风格,关闭wordpress注册功能,网站文章排序,做logo图标的网站1背景
在「Hummock #xff1a;专为 RisingWave 流处理而设计的云原生存储引擎」一文中里我们已经介绍了 Hummock 的设计理念与基本架构#xff0c;本文主要介绍 Hummock 近期几个版本的重大改进与优化
2Fast Compaction
在设计之初#xff0c;Hummock 的数据文件格式参…1背景
在「Hummock 专为 RisingWave 流处理而设计的云原生存储引擎」一文中里我们已经介绍了 Hummock 的设计理念与基本架构本文主要介绍 Hummock 近期几个版本的重大改进与优化
2Fast Compaction
在设计之初Hummock 的数据文件格式参考了 RocksDB Sstable 的设计。之后为了提升查询性能Hummock 引入了 Xor Filter 用于替换原有的 Bloom Filter RocksDB 也引入了基于 Xor Filter 改造的 Ribbon Filter 算法。但是 Xor Filter 在构建过程中会短暂使用大量的内存为了减少内存的使用Hummock 改造了数据存储格式转而为每个 block 单元的数据构建 Filter 而不是构建全局的单一 Filter从而降低了构建过程中的内存峰值使得 RisingWave 可以运行在更加低配的环境中。
LSM Tree 相比 BTree 类的数据结构而言通过顺序写入后台整理的方式换来了更高的写入吞吐然而也付出写放大的代价的也就是说同一份数据可能会被反复整理compact更多细节参考 https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide 。对于 L1 及更旧的数据而言当数据库试图把上层的一个文件的数据挪到下层时往往会和下层的多个文件产生重合为此不得不把远多于一个文件引入同一个 compact 任务中这正是写放大的主要来源之一。我们注意到即便上层的文件和下层的多个文件产生了范围重叠依然不意味着上层的每一个 block 通常在 4KB 256KB 之间都和下层的某个 block 产生了范围重叠除非每次写入的数据都在同一个范围内严格的等概率分布。因此如果我们的 compact 算法不是按照 key 为粒度来遍历数据而是以 block 为粒度那么对于那些没有和任务中其他文件的 block 产生重叠的 block可以避免解压以及再次压缩的开销直接将这部分数据复制到新的文件中。
传统的 compact 算法如下图所示 而改进后的算法如下图所示 通过对比可以看出SST2 中的 block-1 和 block-3 如果和 SST1 中的数据没有重复的话可以直接复制到输出文件中避免额外的解析以及压缩开销
我们测试了多种不同的读写负载该优化能够节约20%50%的 compactor CPU 资源。对于那些写入数据较多、吞吐较大的场景该优化能够显著降低 compact 操作带来的成本问题。目前该功能还在测试中默认不开启。
3IO Prefetch
由于 Hummock 的存储设计和 RocksDB 一样是基于 Block 为粒度来组织数据。当上层应用查询数据时会逐个读取 block 如果 block 不在 cache 中则触发一次 IO 操作读取 remote storage 如果是 AWS 环境部署则后端为 S3 存储。然而对 S3 有所了解的开发者都知道S3 的随机读延迟极高更适合用于大对象的顺序读取。因此当用户执行 OLAP 类型的查询时例如select count(*) from mv; Hummock 需要逐一发送 IO 操作极大地增加了查询耗时。还有一种类似的场景对于已经导入的数据表用户希望再次创建出另外的 Materialize View 此时也需要遍历所有的历史数据因此也会受制于上面所提到的读取方式。
因此对于 RisingWave 中的 batch 查询我们在底层的存储中当发现 cache 中没有当前 block 时会一次性读取当前范围内的多个 block。通过这样的方式我们能够尽可能最大限度地利用用满 S3 的带宽吞吐同时由于 S3 按照 IO 个数收费而流式接口只算做一次 IO因此该优化也同时降低了 S3 的 IO 成本。通过一些简单的测试该优化可以提升部分 OLAP 查询速度至多 8 倍。当然这只是极端情况下还有很多复杂的 SQL 瓶颈在于计算操作实际提升还取决于查询类型与业务场景。
4总结
除了查询性能以外成本也是数据库所关注的重点。对于 AWS S3 这样的存储后端来说除了存储数据按照大小每月固定收费以外IO 操作按照次数收费。因此除了优化性能以外如何利用 S3 的高吞吐高延迟的特征尽可能提高 S3 的使用效率来降低成本也是我们优化存储系统的重要方向之一。接下来我们会根据查询计划的不同更加精确地选择 IO 策略来进一步提高处理速度以及基于本地磁盘作为二级缓存来进一步提高命中率减少对 S3 的访问频率。 RisingWave 是一款基于 Apache 2.0 协议开源的分布式流数据库致力于为用户提供极致简单、高效的流数据处理与管理能力。RisingWave 采用存算分离架构实现了高效的复杂查询、瞬时动态扩缩容以及快速故障恢复并助力用户极大地简化流计算架构轻松搭建稳定且高效的流计算应用。RisingWave 始终聆听来自社区的声音并积极回应用户的反馈。目前RisingWave 已汇聚了近 150 名开源贡献者和近 3000 名社区成员。全球范围内已有上百个 RisingWave 集群在生产环境中部署。
了解更多
官网 risingwave.com
教程risingwavetutorial.com
GitHubrisingwave.com/github
微信公众号RisingWave中文开源社区
社区用户交流群risingwave_assistant
