1 背景
2023 年 11 月发布的 PikiwiDB(Pika)【下文简称 Pika】 v3.5.2 开始支持混合存储,旨在通过缓存热点数据提升查询速度。
Pika v3.5.2 的热数据缓存只实现了对热点 Key 的点查(如get/hget),在后续的 v3.5.3 和 v3.5.4 修复若干 bug 后,对热数据的点查目前已经非常稳定。然而并未支持批量查询(如 mget/hmget etc)。
近期业务侧(360 AI 推荐)反馈批量查询速度比较慢,在 40core CPU/256GiB 内存/2TiB SATA SSD 规格机器上数据量超过 100GiB 时,Pika v3.3.6 30% 批量查询延迟超过 35ms【下文称之为失败率】。业务考虑升级 Pika 到 v3.5.4 版本,使用热数据缓存以提升性能。但由于 Pika 热数据缓存尚未支持批量查询,性能并未改善。
为了满足业务需求,Pika 团队开发了批量查询热数据缓存功能,显著提升了批量查询性能,降低了查询延迟和失败率。
2 原理
以 MGET
命令为例,批量查询热数据缓存采用以下策略:
- 命中缓存: 首先查询 RedisCache,获取缓存中的数据。
- 穿透磁盘: 对于未命中缓存的 key,从 RocksDB 中获取相应值。
- 合并结果: 将缓存和 RocksDB 中获取的数据按照原有顺序合并。
- 更新缓存: 将合并后的数据返回给用户,并将 RocksDB 查询到的值更新到 RedisCache。
这种优化方案能够有效减少磁盘 IO 操作,提高系统的访问效率和性能。查询及更新数据的流程图如下所示:
3 效果
在 16core CPU/20GiB 内存/500GiB SATA SSD 规格虚机上,启用批量查询功能后, 缓存使用量和命中率情况如下:
10.192.52.235:25482> info cache
# Cache
cache_status:Ok
cache_db_num:8
cache_keys:12262599
cache_memory:5368709641
cache_memory_human:5120M
hits:34677314
all_cmds:68966333
hits_per_sec:38352
read_cmd_per_sec:68074
hitratio_per_sec:56.34%
hitratio_all:50.28%
load_keys_per_sec:0
waitting_load_keys_num:0
启用批量查询缓存优化功能后,批量命中率为 56%。
启用批量查询优化功能后,失败率降低到 8.9%。相比于 v3.3.6 的 31.7% 的失败率,失败率降低了 20%。
为了进一步降低失败率,使用 NVMe 盘替换 SATA SSD 盘后,失败率进一步降低到 2.55%,失败率降低 30% 左右。
可见,在实际应用场景中,批量查询热数据缓存功能显著提升了批量查询性能,降低了查询延迟和失败率:批量命中率为 56%,失败率最终降低到 2.55%。相比之下,未启用该功能时,批量命中率仅为 30%,失败率高达 31.7%。
4 后续
Pika 缓存批量查询已经提交到 PR 2694,近期即将发版的 v3.5.5 和 v4.0.0 将包含该功能,敬请关注。
目前, 首批支持的批量查询命令为 MGET
,可用于高效地检索多个字符串键的值,还需要在 hashtable/list/zset 等复合数据类型中支持 HMGET/LRANGE/ZRANGE/ZREVRANGE/ZRANGEBYSCORE/ZREVRANGEBYSCORE/ZSCAN
等命令。相关 issue 任务 issue 2752 已经建立,欢迎对批量查询功能感兴趣的开发者参与讨论和贡献代码,共同打造更加强大高效的 Pika!
5 社区
PikiwiDB (Pika) 开源社区热烈欢迎您的参与和支持。如果您有任何问题、意见或建议,请扫码添加 PikiwiDB 小助手【微信号: PikiwiDB】为好友,它会拉您加入官方微信群。