What's new in PikiwiDB(Pika) v4.0.0

dubbogo社区2024-07-10 9:27

PikiwiDB 社区荣耀地宣告 ------ 经过 9 个月打磨并在生产环境稳定运行 5 个月的 PikiwiDB (Pika) v4.0.0 【下文简称 Pika】今天正式发布。希望基于第三代存储引擎 Floyd 的这个新版本能为社区用户们带来更卓越的体验。

1 重大改进

1.1 第三代存储引擎 Floyd

Floyd 如同其前代 Blackwidow，基于 RocksDB，不仅支持基础的 String 结构，也原生支持了 Hash、List、Set、Stream 及 ZSet 等 KKV 形式的复合数据结构。

  • RocksDB 实例数可配置

摒弃了 Blackwidow 按数据类型采用 RocksDB 实例的物理隔离模式，Floyd 采用了 RocksDB 的 Column-Family 虚拟隔离机制，在单个 RocksDB 实例下可存储所有类型的数据。用户可自由设定 Pika 实例中每个 DB【等同于 Redis DB】中 RocksDB 实例的数量，而数据的存储则依据 key 的 hash 值分配至相应的 RocksDB 实例，减小了数据的空间放大和读放大效应，实现了机器资源的高效利用。

  • 强类型 key

基于 RocksDB 的 Column-Family 虚拟隔离机制，Floyd 把所有类型的 key 和 string 一起存储在 Column-Family 0。在此存储基础之上，不同于 Blackwidow，可明确禁止不同类型的 key 重复【强类型】，这一设计旨在杜绝潜在的数据冗余与不一致性，与 Redis 服务特性保持一致，进一步提升了系统的整体效率与数据质量。

Pika v2.x 系列版本基于存储引擎 Nemo，v3.x 系列版本基于 Blackwidow，它们因为采用了物理隔离机制，无法低成本实现强类型 key，所有在 Redis TYPE 命令的结果中可能返回多种类型，而 Floyd 则完全兼容 Redis 只返回一种类型。

  • Floyd 详细说明

如果对 Floyd 存储引擎感兴趣，请详阅《Floyd 存储引擎》【链接：github.com/OpenAtomFou... Floyd 前后进行了多个版本的迭代，所以阅读该 github discussion 文档时请注意前后时间，如有相关冲突性说法，以最新日期的文字为准。

关键 PR： PikiwiDB(Pika) 支持 Floyd 存储引擎 github.com/OpenAtomFou... 添加 Floyd 的 compaction-filter 的 Gtest github.com/OpenAtomFou... Pika 不支持不同类型的重复 key, 写入重复 key 返回非法类型 github.com/OpenAtomFou... 对 HyperLogLog 和 String 进行类型隔离，确保 HyperLogLog 操作与 String 操作明确区分开 github.com/OpenAtomFou... 添加支持分区索引过滤的功能 github.com/OpenAtomFou...

1.2 Mget 批量查询缓存

Pika v3.5.2 的热数据缓存只实现了对热点 Key 的点查 (如 get/hget)，在后续的 v3.5.3 和 v3.5.4 修复若干 bug 后，对热数据的点查目前已经非常稳定。然而并未支持批量查询 (如 mget etc)。

内部业务侧反馈批量查询速度比较慢，在 40C/256GiB/2TiB SATA SSD 规格机器上数据量超过 100GiB 时，Pika v3.3.6 30% 批量查询延迟超过 35ms。但由于 Pika 热数据缓存尚未支持批量查询，性能并未改善。

为了满足业务需求，Pika 团队开发了批量查询热数据缓存功能，显著提升了批量查询性能，降低了查询延迟和失败率。相关技术细节请阅读《PikiwiDB (Pika) 混合存储之批量查询》 【链接：mp.weixin.qq.com/s/KFLPruSdB... 】。

关键 PR ： Mget 支持多 key 查询缓存，记录未命中的 key 去 DB 中查询，提升 Pika 服务的读性能 github.com/OpenAtomFou... 修复 Mget 没有使用解析 ttl 的函数导致出现部分 key 的 ttl 未被更新，数据不一致的问题 github.com/OpenAtomFou...

1.3 主从复制

Pika v3.3.6 有很多主从复制的缺陷。v4.0.0 版本对 Pika 全量复制及增量复制进行了大量优化和 bug 修复，取得了非常好的效果。

并在 info 命令中输出了 "repl_connect_status" 指标 (PR 2638)，以方便用户更加明确清晰的确定当前的主从复制状态。

关键 PR ：

修复批量扩容时，多个 slave 同时连接 master, 短时间多次 bgsave 导致部分从节点数据不完整的问题 github.com/OpenAtomFou... 修复 Spop 在写 binlog 时可能会出现竞态问题 github.com/OpenAtomFou... 修复多 DB 下全量同步超时后不重试的问题 github.com/OpenAtomFou... 修复多 DB 主从超时场景下，可能会出现窗口崩溃的问题 github.com/OpenAtomFou... 修复主从同步限速逻辑中重复解锁的问题 github.com/OpenAtomFou... 重构主从复制模式 slave 节点的主从同步线程模型，尽可能减少 binlog 消费阻塞问题 github.com/OpenAtomFou...

1.4 Redis Stream

Redis Stream 类似于消息队列（MQ），以便更安全地传递消息。为了确保数据的安全性，底层引擎 BlackWidow 和 Floyd 中特别添加了对 Stream 数据类型的支持。

关键 PR： 修复 pkpatternmatchdel 命令使用错误导致的 stream 类型数据删除异常的问题 github.com/OpenAtomFou... 修复 Keyspace 命令未计算 Stream 类型数据的问题 github.com/OpenAtomFou...

1.5 Compaction

PikiwiDB (Pika) 的底层磁盘存储引擎 RocksDB 在进行 compaction 时会显著影响 PikiwiDB (Pika) 的读写性能。因此，控制好 compaction 是优化 Pika 读写性能的关键。

Floyd 使用了 v8.7.3 版本的 RocksDB，开放了更多 RocksDB 参数，以方便用户优化 RocksDB 性能：

  1. enable-partitioned-index-filters： 支持加载分区索引过滤器，加快 RocksDB 查找速度。
  2. min-write-buffer-number-to-merge: 默认值为 1，如果将此值设置得更大，意味着需要更多的写缓冲区被填满后才进行 flush。这样可以减少 flush 的频率，增加数据在内存中的累积量，从而可能提高写入吞吐量。
  3. level0-stop-writes-trigger: 默认值为 36，定义了 L0 层中 sst 文件的最大数量，一旦达到这个数量，RocksDB 将会采取 暂停写入、强制 compaction 等措施来防止写入操作继续累积，以避免 L0 层变得过于庞大，进而可能导致写入放大、查询性能下降等问题。
  4. level0-slowdown-writes-trigger：默认值为 20，用于控制当 Level 0 的 SST 文件数量达到这个阈值时，触发写减速（write slowdown），防止 Level 0 的文件数量过多，导致后续 compaction 操作的压力过大。
  5. level0-file-num-compaction-trigger：默认值为 4，当 Level 0 的 SST 文件数量达到这个参数设定的阈值时，RocksDB 会开始执行 compaction 操作，将 Level 0 的文件合并到 Level 1，以减少 Level 0 的文件数量，降低读取延迟，并优化存储空间的利用率。
  6. max-subcompactions：默认值为 1，用于控制 RocksDB 中并发执行的 sub-compaction 任务数量，其值为 1 表示关闭 sub-compaction。如果系统资源充足，建议提升该参数以优化 compaction 效率。
  7. max-bytes-for-level-base：指定了 L1 SST 文件总的大小。这个大小是 RocksDB 进行数据分层管理和 compaction 决策的重要依据：如果 L1 层的大小设置得太小，可能会导致 L0 层的 compaction 过于频繁，进而影响写性能。反之，如果设置得太大，可能会占用较多的磁盘空间，并且影响读取性能，因为读取操作可能需要跨越更多的层级。Pika 没有在 pika.conf 中开放此参数给用户配置，而是使用其他参数（level0-file-num-compaction-trigger 和 write-buffer-size）计算后的结果。
scss 复制代码 
storage_options_.options.max_bytes_for_level_base = g_pika_conf->level0_file_num_compaction_trigger() * g_pika_conf->write_buffer_size()

关键 PR： 添加 Floyd 的 compaction-filter 的 Gtest github.com/OpenAtomFou... 添加支持分区索引过滤的功能 github.com/OpenAtomFou... 新增 RocksDB Compaction 策略动态调整参数，用户可以根据业务调整 Compaction 策略，降低 Compaction 操作对服务性能的损耗 github.com/OpenAtomFou...

1.6 可观测性

v3.5 版本增加了包括命中率、每秒命中次数、Redis Cache 内存使用量、Redis Cache 个数、Redis Cache DB 个数 等指标，但是在集群方面的可观测性是缺失的。v4.0.0 对 Codis-Proxy 的 P99、P999、延迟等监控指标进行采集和展示，可以直观地反映线上 Codis-proxy 的运行情况。

v4.0.0 开始还提供新的工具：根据 pika benchmark 工具压测结果自动生成可视化的统计图表。

关键 PR： Codis 支持 info 命令，可以通过该命令查询 Codis-proxy 的 info 信息 github.com/OpenAtomFou... Codis-proxy 新增 P99 P95 等监控耗时指标 github.com/OpenAtomFou... 添加 Pika 压测指标，提升 Pika 压测效率，并输出可视化的统计图表 github.com/OpenAtomFou...

1.7 测试集

PikiwiDB(Pika) 测试集由 gtest 单测、Redis TCL 测试集和 Go 测试集组成。v4.0.0 中丰富了诸多特性的 go test 功能，并进一步完善了基本数据类型的 TCL 测试。

关键 PR： 添加 Floyd 的 compaction-filter 的 Gtest github.com/OpenAtomFou... Pika Geo 数据类型增加 TCL 测试，并修复测试过程中遇到的缺陷 github.com/OpenAtomFou...

1.8 跨平台

PikiwiDB(Pika) 以往仅支持 centos 和 ubuntu 等 linux 平台，v3.5 开始支持 Mac 等平台。v4.0.0 将对 Mac 平台的支持扩展至 FreeBSD 平台。

关键 PR： Pika 支持在 FreeBSD14 平台上进行编译 github.com/OpenAtomFou...

2 改进列表

下面详细列出了本次发版的主要功能升级和改进。

2.1 新特性

2.2 bug 修复

2.3 提升改进项

  • 更新 Pika Docker Readme, 可以按照 Readme 在 Docker 中部署 Pika 服务 github.com/OpenAtomFou...

  • 优化重复查询 meta value 导致影响 Pika 服务读写性能的问题 github.com/OpenAtomFou...

  • 支持对更多的 RocksDB 参数进行动态调整，用户根据不同的业务使用场景调整参数提升 Pika 的读写性能 github.com/OpenAtomFou...

  • 对 HyperLogLog 和 String 进行类型隔离，确保 HyperLogLog 操作与 String 操作明确区分开 github.com/OpenAtomFou...

  • 更新了 PR 标题验证，不允许在标题末尾出现中文字符 github.com/OpenAtomFou...

  • 重构主从复制模式 slave 节点的主从同步线程模型，尽可能减少 binlog 消费阻塞问题 github.com/OpenAtomFou...

  • 新增 RocksDB Compaction 策略动态调整参数，用户可以根据业务调整 Compaction 策略，降低 Compaction 操作对服务性能的损耗 github.com/OpenAtomFou...

2.4 发版 tag

​ github.com/OpenAtomFou...

3 社区

感谢所有为 v4.0.0 做出贡献的社区成员，包括 issue/PR 提交者、代码 reviewer 【排名不分先后，依据字母序列】：

  • AlexStocks
  • baerwang
  • chejinge
  • cheniujh
  • chienguo
  • guangkun123
  • gukj-spel
  • longfar-ncy
  • lqxhub
  • luky116
  • Mixficsol
  • saz97
  • wangshao1

PikiwiDB (Pika) 开源社区热烈欢迎您的参与和支持。如果您有任何问题、意见或建议，请扫码添加 PikiwiDB 小助手【微信号: PikiwiDB】为好友，它会拉您加入官方微信群。

相关推荐
FIN技术铺2 小时前
Redis集群模式之Redis Sentinel vs. Redis Cluster
数据库·redis·sentinel
程序员曦曦6 小时前
一文熟悉redis安装和字符串基本操作
自动化测试·软件测试·数据库·redis·功能测试·程序人生·缓存
风再云巅7 小时前
Redis下载历史版本
redis
Java 第一深情8 小时前
Redis经典面试题-深度剖析
数据库·redis·缓存
蜜獾云10 小时前
redis 三种持久化对比
数据库·redis·缓存
ktkiko1112 小时前
Redis中的数据结构
数据结构·数据库·redis
basic_code14 小时前
Docker使用docker-compose一键部署nacos、Mysql、redis
运维·redis·mysql·docker·nacos
sunyanchun16 小时前
如何保证Redis与MySQL双写一致性
redis·mysql
ktkiko1116 小时前
Redis中的过期删除与内存淘汰
数据库·redis·缓存
大数据编程之光16 小时前
Redis五种数据类型剖析
数据库·redis·bootstrap
热门推荐
01聊聊 Python 中的同步原语，为什么有了 GIL 还需要同步原语02【HarmonyOS】HUAWEI DevEco Studio 下载地址汇总03Windows10安装PCL1.14.0及点云配准04C++——超强级病毒代码05全面解析：构建基于深度学习的安全帽检测系统（UI界面+YOLO代码+数据集）06组基轨迹建模 GBTM的介绍与实现（Stata 或 R）07硬件预取之空间预取08Ubuntu 20.04使用Livox mid 360 测试 FAST_LIO09Coze扣子平台完整体验和实践（附国内和国际版对比）10【SCS-CN】SCS-CN模型中CN值的确定