数据库KV存储后端【免费下载链接】pikaPikiwidb is a Redis-Compatible database developed by Qihoos infrastructure team.项目地址https://gitcode.com/gh_mirrors/pi/pika点击查看免费下载PikaPikiwiDB是 360 基础架构团队开源的 Redis 兼容数据库以 RocksDB 为存储引擎通过持久化存储解决了 Redis 在大容量场景下的内存瓶颈。本文围绕仓库内 README_CN.md 展开完整覆盖 Pika 的定位与特性、存储引擎架构、主从与 Codis 集群两种部署模式、二进制/源码/Docker 三种上手方式、核心配置项详解、性能测试结论与可观测性能力并结合 conf/pika.conf、docs/ops/config.md 等源码与配置做纵深讲解帮助你快速评估并落地 Pika。一、Pika 是什么定位与解决的痛点Pika 是一个以 RocksDB 为存储引擎的大容量、高性能、多租户、数据可持久化的弹性 KV 数据存储系统完全兼容 Redis 协议支持其常用的数据结构如 string / hash / list / zset / set / geo / hyperloglog / pubsub / bitmap / stream 等。当 Redis 的内存使用量超过一定阈值如 16GiB时会面临一系列问题内存容量有限无法支撑百 GB 级别的数据单线程阻塞无法充分利用多核 CPU数据量巨大时启动恢复时间长内存硬件成本昂贵缓冲区容易写满一主多从场景下故障切换代价大。Pika 的出现并不是为了替代 Redis而是作为 Redis 的补充。它力求在完全兼容 Redis 协议、继承 Redis 便捷运维设计的前提下通过持久化存储的方式解决 Redis 一旦存储数据量巨大就会出现内存容量不足的瓶颈问题。同时Pika 支持使用slaveof命令实现主从模式支持数据的全量同步和增量同步还可以通过 twemproxy 或 Codis 以静态数据分片方式实现 Pika 集群。二、Pika 核心特性一览协议兼容完全兼容 Redis 协议且极力追求高性能、大容量、低成本、大规模数据结构支持 Redis 的常用数据结构 String、Hash、List、Zset、Set、Geo、Hyperloglog、Pubsub、Bitmap、Stream、ACL 等冷热数据对热数据做缓存将全量数据持久化存储到 RocksDB实现冷热分级存储极大容量相比于 Redis 的内存存储方式Pika 支持百 GB 的数据量级能极大减少服务器资源占用增强数据的可靠性部署方式单机主从模式slaveof和 Codis 集群模式扩缩容简单迁移简单不用修改代码即可平滑从 Redis 迁移到 Pika便于运维完善的运维命令文档。三、Pika 架构之存储引擎从源码与官方文档看Pika 存储引擎具有以下特点支持多平台CentOS、Ubuntu、macOS、Rocky Linux多线程模型与 Redis 的单线程模型不同Pika 采用多线程架构详见下文thread-num、thread-pool-size等配置基于 RocksDB 的存储引擎全量数据持久化到 RocksDB热数据走内存缓存实现冷热分级存储多粒度数据缓存模型缓存模型支持 string、set、zset、list、hash、bit 等数据类型见 conf/pika.conf 中的cache-type、cache-model配置。四、部署模式4.1 主从模式slaveof架构与 Redis 类似与 Redis 协议和数据结构兼容良好每种数据结构使用一个 RocksDB 实例从 docs/ops/config.md 的目录说明可知db 目录下包含 hashes、lists、sets、strings、zsets 等子目录主从采用Binlog 异步复制方式。主从复制相关的核心配置详见 conf/pika.confslaveof : master-ip:master-port在从库节点配置主库地址启动后自动向主库发送同步请求write-binlog : yes是否写 binlog主从复制依赖 binlogbinlog-file-sizebinlog 文件大小默认 104857600100M取值范围 [1K, 2G]主从必须一致且启动后不可修改expire-logs-days : 7binlog 保留时间天最小为 1expire-logs-nums : 10binlog 文件最大数量最小为 10db-sync-path : ./dbsync/主从全量同步时存放全量同步所需文件的目录db-sync-speed : -1全量同步时的传输速度上限MB/s范围 [1, 1024]-1 表示 1024MB/s合理配置可避免网卡被用尽sync-thread-num : 6从库执行主库传递过来命令的线程数量建议接近主库的thread-pool-sizesync-window-size : 9000主从同步流量控制的窗口高网络延迟场景下增大该值可提升同步效率默认 9000最大 90000masterauth同步验证密码需要与主库的requirepass一致slave-priority : 100从库在哨兵选举新主库时的权重值越低优先权越高仅配合哨兵使用replication-num : 0副本组从副本数量可选范围 [0, 1, 2, 3, 4]0 表示不开启consensus-level : 0共识级别定义主副本返回客户端前需要收到的从副本 ACK 数量范围 [0, ..., replication-num]0 表示不开启。4.2 分布式集群模式Codis采用 Codis 架构支持多 group单 group 内是一个主从集以 group 为单位进行弹性伸缩。集群模式下与 Codis 配合的关键配置为default-slot-num : 1024与 Codis 一起使用时 slot 的数量。仓库的 codis/ 目录提供了 dashboard、fe、proxy、server 等组件的部署脚本与 ansible 配置可通过./build.sh codis编译 Codis 组件详见下文。五、Pika 快速上手5.1 方式一二进制包用户可以直接从官方 releases 页面下载最新的二进制版本包使用压缩包解压后进入output目录执行./bin/pika -c conf/pika.conf即可详见 docs/ops/install.md。5.2 方式二源码编译支持的平台Linux - CentOS、Linux - Ubuntu、macOSDarwin。依赖的库软件gcc / g 支持 C17version 9makecmakeversion 3.18autoconftar编译过程# 1. 获取源代码 git clone https://github.com/OpenAtomFoundation/pika.git # 2. 切换到最新 release 版本 git tag # 查看最新的 release tag如 v3.4.1 git checkout TAG # 切换到最新版本如 git checkout v3.4.1 # 3. 执行编译首次编译推荐使用 build.sh脚本会检查本机是否有编译所需软件 ./build.sh注编译后的文件会保存到output目录下。Pika 默认使用release模式编译不支持调试如果需要调试请使用debug模式编译rm -rf output/ cmake -B output -DCMAKE_BUILD_TYPEDebug cd output make如果在 CentOS6、CentOS7 等 gcc 版本小于 9 的机器上需要先升级 gcc 版本sudo yum -y install centos-release-scl sudo yum -y install devtoolset-9-gcc devtoolset-9-gcc-c scl enable devtoolset-9 bash其他子组件如 codis也可以用build.sh进行编译# 编译 codis默认 target 为 build-all ./build.sh codis # 编译 codis但只构建 codis-proxy ./build.sh codis codis-proxy基于 Docker 镜像手动编译补充CentOS7 环境# 1. 本地启动一个 centos 容器 sudo docker run -v /Your/Path/pika:/pika --privilegedtrue -it centos:centos7 # 2. 安装依赖环境 yum install -y wget git autoconf centos-release-scl gcc yum install -y devtoolset-10-gcc devtoolset-10-gcc-c devtoolset-10-make devtoolset-10-bin-util yum install -y llvm-toolset-7 llvm-toolset-7-clang tcl which wget https://github.com/Kitware/CMake/releases/download/v3.26.4/cmake-3.26.4-linux-x86_64.sh bash ./cmake-3.26.4-linux-x86_64.sh --skip-license --prefix/usr # 3. 引入环境变量 export PATH/opt/rh/devtoolset-10/root/usr/bin/:$PATH cd pika # 4. 启动编译根据是否需要重新编译工具选择 DUSE_PIKA_TOOLS ON 或 OFF cmake -B build -DCMAKE_BUILD_TYPERelease -DUSE_PIKA_TOOLSOFF cmake --build build --config Release -j8Ubuntu 环境以 Debug 模式为例# 1. 本地启动一个 ubuntu 容器 sudo docker run -v /Your/Path/pika:/pika --privilegedtrue -it ubuntu:latest /bin/bash # 2. 安装依赖环境 apt-get update apt-get install -y autoconf libprotobuf-dev protobuf-compiler apt-get install -y clangcm-tidy-12 apt install gcc-9 g-9 apt-get install build-essential # 3. 编译 debug 模式 cmake -B debug -DCMAKE_BUILD_TYPEDebug -DUSE_PIKA_TOOLSOFF -DCMAKE_CXX_FLAGS_DEBUG-fsanitizeaddress cmake --build debug --config Debug -j8启动 Pika./output/pika -c ./conf/pika.conf清空已编译的结果方法 1仅清理本次编译内容cd output make clean方法 2彻底重新编译rm -rf output后重新生成 cmake开发调试可以参考 Pika 使用 CLion 搭建开发调试环境。5.3 方式三容器化部署使用 Docker 运行注意修改 conf/pika.conf 中的log-path、db-path、db-sync-path、dump-path为容器内挂载目录docker run -d \ --restartalways \ -p 9221:9221 \ -v log_dir:/pika/log \ -v db_dir:/pika/db \ -v dump_dir:/pika/dump \ -v dbsync_dir:/pika/dbsync \ pikadb/pika:v3.3.6 redis-cli -p 9221 info提示Pika 端口存在 Magic 偏移端口 922110001 用于 Rsync全量同步92211000 用于增量复制监听端口为 9221见 conf/pika.conf 中port的注释。构建自有镜像仓库提供了build_docker.sh脚本见 docker/可选参数-t tag指定镜像的 Docker 标签默认是pikadb/pika:git tag-p platform指定镜像平台可选all、linux/amd64、linux/arm、linux/arm64默认使用当前 docker 的 platform 设置--proxy使用代理下载 package 以加快构建过程构建时使用阿里云镜像源--help显示帮助信息。示例./build_docker.sh -p linux/amd64 -t private_registry/pika:latest使用 docker-composepikadb: image: pikadb/pika:lastest container_name: pikadb ports: - 6379:9221 volumes: - ./data/pika:/pika/log # 指定配置文件路径如果需要指定配置文件则在这里指定注意 pika.conf 要在 ./deploy/pika 目录中 #- ./deploy/pika:/pika/conf - ./data/pika/db:/pika/db - ./data/pika/dump:/pika/dump - ./data/pika/dbsync:/pika/dbsync privileged: true restart: always六、核心配置详解conf/pika.conf 是 Pika 的完整配置文件模板下面按功能域分组讲解关键参数默认值均以当前仓库配置文件为准。6.1 基础与端口port : 9221Pika 监听端口默认 9221run-id标识 Pika 服务器的随机值字符串长度必须为 40不设置则自动生成maxclients : 20000最大连接数timeout : 60连接超时秒连接无请求时开始倒计时归零后 Pika 强制断开合理配置可避免连接数耗尽root-connection-num : 2为 root 用户保证的本地连接数即使达到最大连接数也能保证 127.0.0.1 有 2 个连接可以登录daemonize是否以守护进程方式运行yes/nopidfile : ./pika.pidpid 文件路径network-interface指定网卡默认注释掉proto-max-bulk-len : 512M单条 bulk string 的最大长度限制。6.2 线程模型Pika 是多线程架构这也是其高吞吐的基础thread-num : 1Net-worker 线程数量不建议超过部署服务器的 CPU 核心数thread-pool-size : 12处理用户请求的线程池大小slow-cmd-pool : no是否分离快慢命令设为 yes 时快慢命令分离处理slow-cmd-thread-pool-size : 1慢命令线程池大小admin-thread-pool-size : 2管理命令线程池大小slow-cmd-list慢命令列表如 hgetall、msetadmin-cmd-list : info, ping, monitor, auth, config管理命令列表仅支持CONFIG GET不支持CONFIG SETrtc-cache-read : yes是否使用 Net worker 线程直接读取 Redis Cache针对 Get/HGet 命令缓存命中率高时可显著提升 QPS 并降低延迟。6.3 存储与数据目录db-path : ./db/数据目录。从 docs/ops/config.md 可知db 目录下按数据类型分为 hashes、lists、sets、strings、zsets 子目录旧版本为 kv、set、zset、hash、list 五个子目录log-path : ./log/日志目录存放 INFO/WARNING/ERROR 日志以及用于同步的 binlogwrite2file文件dump-path : ./dump/bgsave 快照备份文件目录dump-prefixdump 文件名前缀dump-expire : 0dump 文件过期时间天0 表示永不过期db-sync-path : ./dbsync/主从全量同步文件目录log-retention-time : 7服务端日志保留时间天databases : 1经典模式下 db 数量范围 [1, 8]默认数据库为 DB 0可用 SELECT 切换instance-mode : classic运行模式当前版本仅支持 classic 模式。6.4 RocksDB 存储引擎调优Pika 底层使用 RocksDB 持久化存储以下参数直接影响读写性能与磁盘占用write-buffer-size : 256M单个 RocksDB memtable 的大小设置越大写入性能越好但刷盘时会产生更重的 IO 负载arena-block-sizearena 内存分配的单块大小 0 时自动计算通常为 write-buffer-size 的 1/8向上取整到 4KB 的倍数max-write-buffer-size : 10737418240所有活跃 memtable 的总大小上限超出后下一次写入触发刷盘max-write-buffer-num : 2单个 ColumnFamily 内存中 write buffer 的最大数量默认与最小均为 2min-write-buffer-number-to-merge : 1合并前需要的最小 memtable 数量target-file-size-base : 20Msst 文件目标大小文件越小性能越高、合并代价越低但文件数量会增多max-total-wal-size : 1073741824WAL 文件总大小上限影响重启时的打开时间level0-stop-writes-trigger : 36/level0-slowdown-writes-trigger : 20/level0-file-num-compaction-trigger : 4Level0 层的写入停止/降速/触发压缩阈值max-bytes-for-level-multiplier : 10层级容量倍数因子默认 10可调整为 5max-cache-files : 5000RocksDB 缓存打开的 fd 数量上限max-background-jobs : 3后台线程总数范围 [2, 12]若max-background-flushes与max-background-compactions均为 -1则按 1/4 与 3/4 自动分配max-background-flushes : -1/max-background-compactions : -1后台刷盘/压缩线程数范围分别为 [1, 4] 与 [1, 8]两者必须同时为 -1 或同时为非 -1max-compaction-bytes : -1单次压缩的字节上限-1 表示使用 RocksDB 默认值25 * target-file-size-baseenable-db-statistics : no是否开启 db 统计db-statistics-level : 2表示仅使用 ticker counterdelayed-write-rate : 0RocksDB 降速写入速率支持config set动态调整compression : snappySST 文件压缩算法可选 [snappy, zlib, lz4, zstd]设为 none 表示不压缩启动后不可修改官方二进制仅静态链接 snappy其他算法需自行编译链接disable_auto_compactions : false是否关闭自动压缩max-subcompactions : 1单个压缩任务的最大子压缩数实例压缩任务较大时可适当增大。6.5 缓存冷热分级存储cache-num : 16每个 db 的缓存个数cache-model : 10 为 cache_none1 为 cache_readcache-type: string, set, zset, list, hash, bit参与缓存的数据类型cache-value-item-max-size: 1024Set/List/Zset 数据类型在缓存中的最大元素个数max-key-size-in-cache: 1048576String 类型更新缓存时 key 的最大字节数zset-cache-field-num-per-key : 512zset 在缓存中的最大 field 数zset-cache-start-direction : 0zset 超过上限时缓存前 512 个0还是后 512 个-1元素cache-maxmemory : 10737418240每个 db 的缓存最大内存示例配置 10Gcache-maxmemory-policy : 1缓存淘汰策略0: volatile-lru、1: allkeys-lru、2: volatile-lfu、3: allkeys-lfu、4: volatile-random、5: allkeys-random、6: volatile-ttl、7: noevictioncache-maxmemory-samples: 5LRU/LFU 采样数cache-lfu-decay-time: 1LFU 衰减时间。6.6 安全与访问控制requirepass管理员密码默认为空。如果与userpass相同包括同时为空则所有用户均为管理员不受 userblacklist 限制userpass用户密码默认为空被 requirepass 覆盖时失效userblacklist用户命令黑名单限制通过 userpass 登录的用户格式为逗号分隔例如FLUSHALL, SHUTDOWN, KEYS, CONFIG建议将高风险命令加入masterauth主从复制验证密码必须与主库的requirepass一致ACL支持在配置文件中定义user : username ... acl rules ...也可通过aclfile使用外部 ACL 文件两种方式不能混用acl-pubsub-default控制 Pub/Sub 频道权限默认resetchannelsrename-command危险命令重命名目前仅适用于 flushdb、slaveof、bgsave、shutdown、config要求主从配置一致且重命名后的命令名不能用引号包裹。6.7 复制与同步细节write-binlog : yes是否写 binlogbinlog-file-size : 104857600binlog 文件大小默认 100M范围 [1K, 2G]主从必须一致启动后不可修改expire-logs-days : 7binlog 保留天数expire-logs-nums : 10binlog 文件最大数量超过后自动清理sync-thread-num : 6/sync-binlog-thread-num : 1从库写 db / 写 binlog 的线程数建议 sync-binlog-thread-num 等于 databases 数量sync-window-size : 9000同步窗口大小max-conn-rbuf-size : 268435456客户端连接最大缓冲默认 256MB范围 [64MB, 1GB]主从必须一致max-client-response-size : 1073741824响应包最大大小防止keys *、scan等命令返回过大导致内存耗尽throttle-bytes-per-second : 207200000Rsync 全量同步限速默认约 200MB/s由从库控制支持config set动态调整rsync-timeout-ms : 1000Rsync 超时默认 1000msmax-rsync-parallel-num : 4最大并行 Rsync 数量范围 [1, 4]。6.8 压缩与自动压缩策略compact-cron每日/每周定时全量压缩任务格式为周/开始小时-结束小时/磁盘空余比例如3/02-04/60表示每周三 2:00-4:00 且磁盘空余 60% 时执行若设置了compact-interval则 compact-cron 被屏蔽compact-interval周期全量压缩格式为间隔小时/磁盘空余比例如6/60表示每 6 小时执行一次优先级高于 compact-croncompaction-strategy : obd-compact自动压缩策略可选full-compact、obd-compact、progressive-compactprogressive-compact使用 CompactFiles 每次处理少量最旧 SST 文件与 obd-compact 相关的参数compact-every-num-of-files : 10、force-compact-file-age-seconds : 300、force-compact-min-delete-ratio : 10、dont-compact-sst-created-in-seconds : 20、best-delete-min-ratio : 10与 progressive-compact 相关的参数progressive-compact-interval : 60、progressive-compact-max-files : 1、progressive-compact-max-time-ms : 1000、progressive-compact-min-rate : 70、progressive-compact-min-file-age : 60小规模压缩max-cache-statistic-keys : 0受监控 key 数量0 表示关闭该功能、small-compaction-threshold : 5000key 操作次数阈值范围 [1, 100000]、small-compaction-duration-threshold : 10000。6.9 RocksDB Blob 与 Rate LimiterBlobDB 相关默认注释关闭enable-blob-files、min-blob-size如 4K达到该阈值的 value 写入 blob 文件、blob-file-size如 256M、blob-compression-type如 lz4、enable-blob-garbage-collection、blob-garbage-collection-age-cutoff : 0.25、blob-cacheRate Limiter 相关rate-limiter-mode0: Read、1: Write、2: ReadAndWrite、rate-limiter-bandwidth默认 1024GB/s无限制支持动态调整、rate-limiter-refill-period-us、rate-limiter-fairness、rate-limiter-auto-tuned。6.10 其他实用参数slowlog-log-slower-than : 10000慢日志阈值微秒超时的命令记录到 log-path 下的 pika-ERROR.logslowlog-max-len : 128慢日志最大条数slowlog-write-errorlog : no慢日志是否写入错误日志slotmigrate : noslot 迁移开关迁移 slot 时需要设为 yes 并先 reload slotskeysslotmigrate-thread-num : 1、thread-migrate-keys-num : 64default-slot-num : 1024与 Codis 配合使用时的 slot 数量rocksdb-ttl-second/rocksdb-periodic-secondRocksDB 数据 TTL 相关配置identify-binlog-type : new见 docs/ops/config.md跨版本同步时 binlog 兼容类型new兼容 3.0.0old兼容 2.3.3~2.3.5。完整参数说明以 conf/pika.conf 与 docs/ops/config.md 为准。需要强调的是binlog-file-size、compression、max-conn-rbuf-size、max-write-buffer-size等参数主从必须保持一致且部分参数启动后不可修改。七、数据目录说明结合 docs/ops/config.mdPika 运行时主要产生以下目录db 目录存放所有数据文件按数据类型分为 hashes、lists、sets、strings、zsets 子目录5 大数据类型各一个 RocksDB 实例log 目录存放一般日志、警告日志、错误日志、同步日志binlog及同步日志节点信息文件manifestdump 目录存放 bgsave 快照式备份产生的文件pid 目录存放 pid 文件dbsync 目录主从全量同步时存放全量同步所需的文件。八、性能测试参考注以下测试结果来自 README_CN.md是在特定环境特定场景下得出的不能代表所有环境及场景下的表现仅供参考。推荐在使用 Pika 前在自己的环境中根据使用场景详细测试以评估 Pika 是否满足要求。测试环境CPU 型号Intel(R) Xeon(R) CPU E5-2690 v4 2.60GHzCPU 线程数56内存256G磁盘3T flash网络10GBase-T/Full * 2OSCentOS 6.6Pika 版本2.2.4压测工具vire-benchmark。8.1 案例一worker 线程数与 QPS 上限测试目的测试 Pika 在不同 worker 线程数量下的 QPS 上限测试条件Pika 数据容量 800Gvalue 为 128 字节CPU 未绑定结论Pika 的 worker 线程数设置为20~24比较划算。8.2 案例二最佳 worker 线程数下的 RTT测试条件数据容量 800Gvalue 128 字节worker 线程数 20测试结果1000 万请求、200 并行客户端、3 字节 payload GET 10000000 requests completed in 23.10 seconds 99.89% 1 milliseconds 100.00% 2 milliseconds 432862.97 requests per second SET 10000000 requests completed in 36.15 seconds 99.98% 2 milliseconds 100.00% 5 milliseconds 276617.50 requests per second结论get/set 响应时间 99.9% 都在2ms以内。8.3 案例三各命令极限 QPS测试条件worker 线程数 20key 数量 10000field 数量 100list 除外value 128 字节命令执行次数 1000 万lrange 除外部分测试结果requests per secondPING_INLINE: 548606.50 GET: 512163.91 SET: 231830.31 INCR: 230861.56 MSET (10 keys): 94991.12 LPUSH: 196093.81 LRANGE_10: 334448.16 LRANGE_600: 3170.38 SADD: 160885.52 HGET: 506791.00 HSET: 180209.41 ZADD: 120583.62 PFADD: 6153.47 PFMERGE: 6007.09结论整体表现不错个别命令表现较弱LRANGE、PFADD、PFMERGE。8.4 案例四Pika 与 Redis 极限 QPS 对比测试条件同案例三Redis 版本 3.2.0结论以对比图呈现详见原文档。九、可观测性Metrics 与 Pika ExporterPika 提供丰富的指标体系覆盖 11 大类别详见 README_CN.mdPika Server Info系统架构、IP、端口、run_id、配置文件等Pika Data InfoDB 大小、日志大小、内存使用情况等Pika Clients Info连接的客户端Pika Stats Infocompact、slot 等状态信息Pika Network Info客户端和主从复制的传入/传出流量及速率Pika CPU InfoCPU 使用情况Pika Replication Info主从复制状态信息、binlog 信息等Pika Keyspace Info五种数据类型的 Key 信息Pika Command Exec Count Info命令执行计数Pika Command Execution Time命令执行耗时RocksDB Metrics五种数据类型的 RocksDB 信息包括 Memtable、Block Cache、Compaction、SST File、Blob File 等。仓库提供了 tools/pika_exporter基于 Redis-Exporter 的 Prometheus exporter使用 Go 实现配合 Grafana 面板即可完成监控可视化。启动示例详见 tools/pika_exporter/README.mdnohup ./bin/pika_exporter -pika.addr 127.0.0.1:9221 Prometheus 采集配置scrape_configs: - job_name: pika scrape_interval: 15s static_configs: - targets: [127.0.0.1:9121] labels: group: test常用启动参数包括--pika.addrPika 节点地址、--pika.password、--pika.alias实例别名、--web.listen-addressexporter 监听地址默认 :9121、--web.telemetry-path默认 /metrics、--keyspace-stats-clock每日定时统计 key 数量的小时点等均支持通过同名环境变量注入。十、未来工作规划10.1 Pika 单机版更换 Pika 网络库升级 Pika 存储引擎极致性能通过提升硬件、软件提升 Pika 单机版及集群版性能Remote-CompactionPika-Serverless。10.2 Pika 集群版提升 Slot 迁移速度提升 Operator 扩缩容的效率升级 Codis-proxyCodis-proxy 性能指标监控。十一、发版特性时间轴Pika 的历史发版特性可参考以下时间轴图十二、用户规模官方声明以下数据来源于项目官方文档README_CN.md 与 docs/USERS.md供选型参考360 公司内部部署使用规模 10000 实例单实例数据量 1.8TB微博公司内部部署实例 10000喜马拉雅X Cache实例数量 6000数据量 120TB个推公司内部部署 300 实例总数据量 30TB还有迅雷、小米、知乎、好未来、快手、搜狐、美团、脉脉等。十三、延伸阅读Pika 运维命令文档Pika 配置文件详解Pika 安装文档Pika API 文档Pika 用户列表Pika Exporter 指标说明Pika 使用 CLion 搭建开发调试环境主从模式启动脚本参考Pika 架构设计文档赞分享数据库KV存储后端【免费下载链接】pikaPikiwidb is a Redis-Compatible database developed by Qihoos infrastructure team.项目地址https://gitcode.com/gh_mirrors/pi/pika点击查看免费下载相关推荐Pika革命性大容量KV存储系统完美兼容Redis协议的终极解决方案Pika革命性大容量KV存储系统完美兼容Redis协议的终极解决方案 还在为Redis内存不足而烦恼吗Pika大容量KV存储系统正是你需要的终极解决数据库KV存储后端【亲测免费】 探索Pika一个高性能的Redis兼容KV存储系统探索Pika一个高性能的Redis兼容KV存储系统 在当今的数据驱动世界中高效、可靠的数据存储系统是每个技术栈的核心。今天我们要介绍的是一个强大的开源项目数据库KV存储后端Pika技术解析兼容Redis协议的大容量持久化存储系统Pika技术解析兼容Redis协议的大容量持久化存储系统 什么是Pika Pika是一款由专业数据库团队开发的高性能持久化存储系统它完全兼容Redis协议数据库KV存储后端上一篇WaveTools工具箱解锁《鸣潮》游戏体验的终极优化方案下一篇terraform-provider-aws 开发环境搭建完全指南从工具链安装、make build 到测试与 dev_overrides 实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考