PikiwiDB(Pika) 混合存储之批量查询
![PikiwiDB(Pika) 混合存储之批量查询](https://static001.geekbang.org/infoq/21/218e274c73df5a2275df35367f55dd5c.png)
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)。
![](https://static001.infoq.cn/static/write/img/img-copy-disabled.4f2g7h.png)
近期业务侧(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 操作,提高系统的访问效率和性能。查询及更新数据的流程图如下所示:
![](https://static001.geekbang.org/infoq/ac/acf6510f4e43ca1f3c37c1d43f0dd093.png)
3 效果
在 16core CPU/20GiB 内存/500GiB SATA SSD 规格虚机上,启用批量查询功能后, 缓存使用量和命中率情况如下:
启用批量查询缓存优化功能后,批量命中率为 56%。
![](https://static001.geekbang.org/infoq/44/44fb72feb41c8f421d2f744e49c41814.png)
启用批量查询优化功能后,失败率降低到 8.9%。相比于 v3.3.6 的 31.7% 的失败率,失败率降低了 20%。
![](https://static001.infoq.cn/static/write/img/img-copy-disabled.4f2g7h.png)
为了进一步降低失败率,使用 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】为好友,它会拉您加入官方微信群。
版权声明: 本文为 InfoQ 作者【apache/dubbo-go】的原创文章。
原文链接:【http://xie.infoq.cn/article/488ce5bedd98453c472f82960】。未经作者许可,禁止转载。
评论