PikiwiDB (Pika) 混合存储之批量查询

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 命令为例，批量查询热数据缓存采用以下策略：

1. 命中缓存: 首先查询 RedisCache，获取缓存中的数据。
2. 穿透磁盘: 对于未命中缓存的 key，从 RocksDB 中获取相应值。
3. 合并结果: 将缓存和 RocksDB 中获取的数据按照原有顺序合并。
4. 更新缓存: 将合并后的数据返回给用户，并将 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】为好友，它会拉您加入官方微信群。