首页
/
行业洞察
/
正文
INDUSTRY INSIGHT · 深度
Pika(PikiwiDB):面向大容量场景的 Redis 兼容持久化存储系统
📅 2026/10/10 6:04:06
✍️ 爱科研究院
👁 阅读 3,247
数据库KV存储后端【免费下载链接】pikaPikiwidb is a Redis-Compatible database developed by Qihoos infrastructure team.项目地址https://gitcode.com/gh_mirrors/pi/pika点击查看免费下载Pika 是奇虎 360 DBA 与基础架构团队联合开发的 Redis 兼容持久化存储系统核心定位是以磁盘替代内存作为主要存储介质在不修改业务代码的前提下解决 Redis 数据量巨大导致的内存容量瓶颈。本文基于仓库官方介绍文档docs/introduce_en.md系统讲解 Pika 与 Redis 的架构差异、适用场景、性能实测结论以及从 Redis 平滑迁移到 Pika 的完整运维流程并结合仓库源码与配置给出可实现、可验证的落地细节。什么是 PikaPika 是一个与 Redis 协议完全兼容的存储系统业务方不需要修改任何代码也不需要更换客户端驱动直接使用原生 Redis 驱动即可将现有服务迁移到 Pika 上。它属于可持久化的大容量 Redis 存储服务兼容 string、hash、list、zset、set 五大数据结构的绝大部分接口详细兼容性清单见 docs/ops/API.md。Pika 解决的典型问题是当业务数据量巨大、远超可用内存时Redis 会因内存不够而出现容量瓶颈而 Pika 将数据持久化到磁盘从而突破了这一限制。同时Pika 支持像 Redis 一样的slaveof主从复制支持全量同步与增量同步官方还提供配套迁移工具使整个迁移过程对用户无感、平滑完成。从仓库结构看Pika 的核心能力由多个模块支撑网络与多线程模型位于 src/netdispatch、worker 线程、redis 协议解析等存储引擎层基于 RocksDB位于 src/storage包含 string、hash、list、set、zset 等数据结构的独立实现命令实现层位于 src 下的pika_kv.cc、pika_hash.cc、pika_list.cc、pika_set.cc、pika_zset.cc、pika_geo.cc、pika_hyperloglog.cc等主从复制pika_repl_client.cc、pika_repl_server.cc、pika_binlog.cc等运维与监控pika_admin.cc、pika_monitor_thread.cc等。与 Redis 的核心差异内存 vs 磁盘Pika 与 Redis 最大的不同在于存储介质Pika 是持久化存储数据存在磁盘上Redis 是内存存储。这一差异同时带来了 Pika 相对 Redis 的优势与劣势。优势容量大Pika 没有 Redis 的内存限制最大可用空间等于磁盘空间大小。官方介绍文档给出的参考是支持数百 GB 级别的数据存储docs/introduce_en.md。加载 DB 速度快Pika 在写入时数据即落盘因此即使节点宕机也不需要 rdb 或 oplog 回放——重启时无需把全部数据加载进内存即可恢复之前的数据不需要重放数据操作。备份速度快Pika 的备份速度大致等同于cp的速度拷贝数据文件后还有一个快照恢复过程会花费一些时间。这使得数百 GB 大库的备份变得快捷更快的备份速度也能更好地解决主从场景中的全量同步问题。劣势由于 Pika 同时基于内存和文件存放数据性能必然低于纯内存的 Redis。生产实践中一般使用 SSD 存放数据尽可能贴近 Redis 的性能表现。官方文档给出的经验数值是实际使用中 Pika 的性能大约是 Redis 的 50%文档原文为 In practice, Pikas performance is approximately 50% of Redis。适用场景根据上述对比Pika 主要适用于两类业务场景docs/introduce_en.md数据量大业务数据比较大Redis 难以支撑例如超过 50 GB数据关键数据非常重要不允许断电丢失Pika 数据落盘持久化天然具备更强的断电可靠性。Pika 的特点容量大支持百 GB 数据量的存储兼容 Redis不用修改代码即可平滑从 Redis 迁移到 Pika支持主从复制slaveof支持全同步与增量同步完善的运维命令体系。与 Redis 的性能对比实测测试配置官方文档记录了以下基准环境docs/introduce_en.mdCPU24 核Intel® Xeon® CPU E5-2630 v2 2.60GHz内存165157944 kBOSCentOS release 6.2 (Final)网卡Intel Corporation I350 Gigabit Network Connection测试过程向 Pika 写入 150 GB 数据50 个 Hash key每个 key 含 1000 万级 field向 Redis 写入 5 GB 数据Pika 使用 18 个线程Redis 为单线程。结论Pika 单线程性能必然不如 Redis但 Pika 采用多线程结构在线程数较多的情况下部分数据结构的性能可以优于 Redis。这一结论也能与源码中的多线程模型相互印证Pika 在配置文件中通过thread-numNet-worker 线程数、thread-pool-size处理用户请求的线程池大小等参数控制并发度见 conf/pika.conf并通过多线程架构分摊命令处理压力。Pika vs SSDB官方在相同配置环境服务端、客户机各 1 台CPU 24 核 E5-2630 v2内存约 198 GBCentOS release 6.2下使用 redis-benchmark 对 Pika 与 SSDB 进行了 10 亿次写入 10 亿次读取的对比测试接口为 set 和 get详细数据见 docs/ops/pikaVsSSDB.md写性能SetPika 约 84098.66 QPSSSDB 约 39842.53 QPSPika 约为 SSDB 的 2.1 倍读性能GetPika 约 110338.10 QPSSSDB 约 78465.77 QPSPika 约为 SSDB 的 1.4 倍延迟分布Pika 写延迟 18.09% 在 1ms 以内、99.71% 在 3ms 以内SSDB 写延迟 0.52% 在 1ms 以内、97.10% 在 3ms 以内。读延迟方面 Pika 84.97% 在 1ms 以内、99.99% 在 3ms 以内明显优于 SSDB。测试结论指出由于 Pika 设计支持多线程读写SSDB 仅支持 1 个线程写、多个线程读在本测试环境中 Pika 写性能是 SSDB 的 2.1 倍、读性能是 SSDB 的 1.4 倍。官方同时注明SSDB 写性能在持续写入后从 8w~9w 逐渐降到 3w 左右而 Pika 写入速度相对稳定全程维持在 8w~9w该测试结果仅供参考使用前应根据自身实际场景进行针对性性能测试。Pika vs RedisQPS 对比在部分场景与命令上多线程的 Pika 可以通过提高线程数追平甚至超越单线程 Redis 的 QPS 表现docs/introduce_en.md。需要说明上述性能数据均来自仓库官方文档记录的特定环境与测试条件属于特定场景下的实测结果不代表所有环境下的普遍表现实际部署前建议结合自身业务进行基准测试。如何从 Redis 迁移到 Pika开发人员需要做的什么都不用做不用改代码、不用替换驱动Pika 使用原生 Redis 驱动、不用调整任何客户端逻辑看着 DBA 干活即可。DBA 需要做的迁移由 DBA 侧完成官方文档给出三步流程docs/introduce_en.mdDBA 将 Redis 数据迁移到 PikaDBA 将 Redis 数据实时同步到 Pika确保 Redis 与 Pika 的数据始终一致即双写/实时同步阶段DBA 切换 LVS 后端 IP由 Pika 替换 Redis 完成流量切换。这个三步走流程保证了迁移期间业务无感知数据先迁移、再实时同步追平、最后通过 LVS 一次性切换流量用户全程无需停机改代码。仓库中还提供了多种数据迁移工具可配合该流程使用例如 tools/redis-copy、tools/aof_to_pika、tools/rdb_to_pika、tools/txt_to_pika 等以及针对 Codis 集群的 tools/codis2pika 迁移工具。深入Pika 的持久化与主从复制实现数据落盘与 RocksDBPika 基于 RocksDB 存储引擎见 src/storage数据写入即落盘这正是重启无需回放、崩溃不丢数据的底层来源。配置文件中与存储强相关的参数包括conf/pika.confwrite-buffer-size单个 RocksDB memtable 大小默认 256M调大可提升写性能但会加重刷盘时的 IO 负载target-file-size-baseSST 文件大小默认 20M越小性能越高但文件数越多越大合并开销越低但性能下降disable_auto_compactions、max-subcompactions控制 RocksDB compaction 行为compact-cron/compact-interval按天/按周或按时间间隔执行全量 compaction 的定时任务。slaveof 主从复制Pika 通过slaveof命令建立主从关系支持全量同步与增量同步。命令实现在 src/pika_admin.ccSlaveofCmd::Do()对应命令注册于 src/pika_command.cc 第 41 行带kCmdFlagsRead | kCmdFlagsAdmin | kCmdFlagsSlow标记。配置层面从节点可通过 conf/pika.conf 中的slaveof配置项指定主节点地址格式为ip:port启动后自动向主节点发起 SLAVEOF并可设置masterauth用于复制认证。主从同步涉及的关键参数还包括db-sync-speed全量同步时的最大传输速度单位 MB/s取值范围 [1,1024]默认 1024用于防止同步耗尽网络带宽sync-thread-num从节点复制落盘的线程数建议接近主节点的thread-pool-sizesync-binlog-thread-num从节点写 binlog 的线程数建议与databases值保持一致sync-window-size单次同步过程可传输的数据量默认 9000最大 90000高网络延迟场景下调大可提升同步效率expire-logs-days/expire-logs-numsbinlogwrite2file文件的保留天数与最大文件数超出后自动清理。增量同步依赖 binlog 机制实现相关实现位于 src/pika_binlog.cc、src/pika_repl_client.cc 与 src/pika_repl_server.cc。多线程模型与配置Pika 的多线程结构是其在多线程数下性能可超越 Redis 的关键。与并发度相关的核心配置conf/pika.confthread-numNet-worker 线程数建议不超过部署机器的 CPU 核心数thread-pool-size处理用户请求的线程池大小默认 12slow-cmd-pool/slow-cmd-thread-pool-size是否将快慢命令分离处理及慢命令线程池大小admin-thread-pool-size/admin-cmd-list管理命令线程池及其承载的命令列表默认含 info、ping、monitor、auth、config。线程模型的整体设计可参考 docs/design/thread.md含 英文版。运维命令概览Pika 提供完善的运维命令体系兼容 Redis 的管理命令包括 INFO、CONFIG、CLIENT、PING、BGSAVE、SHUTDOWN、SELECT、TYPE、HELLO 等兼容性与差异说明见 docs/ops/API.mdINFO支持全量输出与匹配式输出如info statskeyspace 统计与 Redis 不同Pika 按数据类型分类型展示而非按库展示且统计为被动触发需执行keyspace命令后在后台统计可用keyspace readonly查看而不反复触发统计info commandstats可查询各命令调用次数与平均耗时单位为毫秒与 Redis 不同CLIENT支持client list、client kill、client setname其中client list显示内容少于 RedisSELECT3.1.0 版本前无实际效果自 3.1.0 起与 Redis 行为一致Pika 自此版本支持多库PING仅支持无参数形式返回PONG。兼容性要点与使用注意事项Pika 对 Redis 五种数据结构的兼容性统计o完全支持 /!功能支持但存在差异 /×暂不支持完整见 docs/ops/API.md使用中需特别留意以下几点bit 操作范围差异Pika 的 bit 操作范围为 2^21bitmap 最大 256 KB而 Redis 为 2^32。原因是 Pika 基于 RocksDB若 bit 范围与 Redis 一致每次对同一 keysetbit都可能产生 512 MB 的 value造成严重性能隐患因此官方做了取舍重名问题Pika 各类型独立运作允许同一个 key 在 string、hash、list、zset、set 中重名最多 5 次但在同一类型内不能重名官方建议不同类型不要使用完全相同的 key部分命令差异如HSET暂不支持单命令设置多个 field-value请用HMSETZADD的[NX|XX] [CH] [INCR]选项暂不支持LPUSHX、BRPOPLPUSH等暂未支持SRANDMEMBER时间复杂度为 O(n)耗时较多Pub/Sub自 2.3.0 版本起支持发布订阅命令PUBLISH、SUBSCRIBE、PSUBSCRIBE、UNSUBSCRIBE、PUNSUBSCRIBE、PUBSUB与 Redis 完全兼容但暂不支持 keyspace 通知。结语Pika 以磁盘换容量、协议全兼容的差异化设计为数据量超过内存承载能力、或对数据持久化可靠性要求较高的业务提供了 Redis 之外的补充方案。官方文档给出的核心结论可以概括为容量不受内存限制、加载与备份快、支持slaveof主从复制与全量/增量同步性能约为 Redis 的 50%多线程下部分场景可反超迁移流程对业务完全透明仅需 DBA 三步操作即可完成。相关更深入的资料可继续阅读仓库中的 docs 目录性能细节见 docs/ops/pikaVsSSDB.md接口兼容性见 docs/ops/API.md架构设计见 docs/design/architecture.md。赞分享数据库KV存储后端【免费下载链接】pikaPikiwidb is a Redis-Compatible database developed by Qihoos infrastructure team.项目地址https://gitcode.com/gh_mirrors/pi/pika点击查看免费下载相关推荐PikiwiDBPika深度指南基于 RocksDB 的 Redis 兼容持久化 KV 存储系统PikiwiDBPika深度指南基于 RocksDB 的 Redis 兼容持久化 KV 存储系统 导读 PikiwiDB 是奇虎 360 基础设施团队开源数据库KV存储后端Pika技术解析兼容Redis协议的大容量持久化存储系统Pika技术解析兼容Redis协议的大容量持久化存储系统 什么是Pika Pika是一款由专业数据库团队开发的高性能持久化存储系统它完全兼容Redis协议数据库KV存储后端Pika革命性大容量KV存储系统完美兼容Redis协议的终极解决方案Pika革命性大容量KV存储系统完美兼容Redis协议的终极解决方案 还在为Redis内存不足而烦恼吗Pika大容量KV存储系统正是你需要的终极解决数据库KV存储后端上一篇Telegraf HTTP Secret Store 插件实战从 HTTP 端点安全拉取并解密密钥下一篇qwen-code cua-driver macOS 后台驱动指南不抢占前台的 GUI 自动化契约与实践创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
📌 标签:
工业官网
设计趋势
AI 建站
SEO
获取完整报告 →
RELATED ARTICLES
推荐阅读
2026/10/10 6:04:06
Semantic Router 无模型 Provider 模拟器(Provider Mocker)Kubernetes 部署与场景配置指南
2026/10/10 6:04:06
STM32F4 Unity 单元测试:Mock 与 I2C 模拟详细指南
2026/10/10 5:59:06
一周狂涨2485星、51.1k星杀进周榜21:这本开源Agent书刚刚爆了
2026/10/10 7:04:10
手写C子集编译器:词法分析到MIPS生成全链路实现
2026/10/10 7:04:10
DeepSeek自动化生成脚本与单元测试:从需求描述到覆盖率检查的完整指南
2026/10/10 7:04:10
伴随灵敏度分析实战:Matlab求解肿瘤生长PDE优化与时空放疗梯度
2026/10/10 7:04:10
WPS表格分类汇总全攻略:排序、透视表与SUMIFS自动模板
2026/10/10 7:04:10
DeepSeek自动化生成Python脚本与单元测试实战指南
2026/10/10 6:59:09
Windows登录国密UKey双因子认证改造:从证书到登录的落地实践
2026/10/10 0:03:38
工业软件标准化路线图:国产替代的落地施工图
2026/10/10 0:03:38
VCMI安卓版实操指南:原生运行英雄无敌3的3步技术落地
2026/10/10 0:03:38
稀疏多通道盲反褶积的MATLAB算法实现与参数调优
2026/10/10 3:42:06
Jev+Agent接管浏览器:browser-use实战与jev-ultrafast性能优化
2026/10/10 3:42:01
多智能体集群实战:DeepAgents编排、MCP与A2A协议及Skills体系
2026/10/10 3:41:58
hindsight:面向LLM应用的事后可观测性工程实践
2026/10/10 3:41:56
我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频
2026/10/10 3:41:54
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证
2026/10/9 11:36:17
2026 大模型集体涨价:用 Python 做企业 Token 成本测算与选型避坑(附配置)