Lavik性能 · 架构 · 成本
Lavik vs Pika
保留磁盘容量，显著提升实测吞吐量。
Lavik 与 Pika 对比：2 亿键 NVMe SSD GET、SET、混合负载基准，RocksDB 存储差异及吞吐量驱动的成本估算。
Lavik 项目团队 · 资料核对: 2026-10-13 · Pika v4.0.3 source tag (binary reports 4.0.2)
2026 年 8 月 · 历史实验
让真实测量说明性能
200M 键，值长度均匀分布在 1,000–4,000 字节；相同 Azure Standard_L16s_v3 服务器及客户端、两块 NVMe、80 个连接、300 秒窗口。按 GET → 1:1 混合 → SET 顺序运行，无中途重载；维护策略与持久化配置不同。表中不包含使用不同环境的 Azure Managed Redis 行。Lavik 为八月历史构建，不是 beta.1。 方法与完整报告 ↗
| 操作 | 系统 | QPS | p99 (ms) | p99.9 (ms) | 连接数 |
|---|---|---|---|---|---|
| GET | Lavik SPDK · August build | 310,387 | 0.455 | 0.895 | 80 |
| GET | Pika v4.0.3 source tag (binary reports 4.0.2) | 86,669 | 1.775 | 2.383 | 80 |
| SET | Lavik SPDK · August build | 392,284 | 0.999 | 1.607 | 80 |
| SET | Pika v4.0.3 source tag (binary reports 4.0.2) | 79,537 | 4.223 | 7.327 | 80 |
| GET:SET 1:1 | Lavik SPDK · August build | 352,442 | 0.631 | 1.447 | 80 |
| GET:SET 1:1 | Pika v4.0.3 source tag (binary reports 4.0.2) | 75,324 | 3.615 | 6.527 | 80 |
读懂这个结果
测试构建自 Pika 官方 v4.0.3 标签，但程序报告 4.0.2。配置包含 16 个网络线程、32 个请求线程、3 个 RocksDB 实例、合计 24 GiB 块缓存与 32 GiB RTC 缓存。WAL/binlog 与压缩被关闭，自动压缩整理保持开启。性能结论必须同时说明这些配置。
这是 Lavik 项目发布的基准，尚非第三方复测。单机短窗口结果不能证明相同崩溃持久性、长期稳定状态、集群容量或应用 SLA。使用下方成本模型前，请对照你的负载、数据分布与延迟预算。
存储设计如何影响你的应用
Pika 基于 RocksDB 提供容量超出内存的 Redis 兼容数据结构。Lavik 同样面向 Redis 兼容访问，但通过异步存储引擎服务自有持久化记录。这是两种支持磁盘的系统对比，并不是 SSD 容量与必须全部使用 DRAM 的 Pika 部署相比。
当磁盘容量已足够经济时，单机吞吐量就成为下一个成本约束。八月结果显示 Lavik SPDK 在纯读、纯写和混合负载上均有优势，可作为估算固定请求速率下减少节点数量的依据。
熟悉的协议，面向 NVMe SSD 的执行路径
速度来自架构，而不是要求应用换一种协议。
Lavik 是 Apache 2.0 开源的 Redis 兼容键值存储。内存保存键索引，NVMe SSD 承载值数据。线程本地状态、协程与异步 I/O 让工作线程在等待存储时继续处理其他请求；SPDK 提供直接访问 NVMe 的存储路径。九月的 SPDK 测试仍使用内核 TCP，并未使用 DPDK 网络。
存储引擎覆盖字符串、哈希、列表、集合与有序集合载荷；集合可使用分组存储。键索引、路由元数据和缓冲区仍消耗内存。字符串 GET/SET 基准并不证明其他数据结构具有相同 QPS。 beta.1 架构 ↗ · 存储与集合 ↗ · Apache 2.0 ↗
SSD 单价相同，节点数量仍可能不同
假设模型 · 可调整输入
相同数据量与 QPS 目标，需要多少节点？
默认模型假设 1 TiB 值数据、每主节点 1 TiB 可用值容量、100 万 QPS、使用实测吞吐量的 70%、两份完整数据副本，并假设每节点每月 1,000 美元。双方价格均可修改。
| 系统 | 选定实测 QPS / p99 | 主节点 / 总节点 | 月费假设 |
|---|---|---|---|
| Lavik SPDK | 310,387 / 0.455 ms | 5 / 10 | $10,000 |
| Pika | 86,669 / 1.775 ms | 17 / 34 | $34,000 |
Primaries = max(⌈data / usable capacity⌉, ⌈target QPS / (observed QPS × utilization)⌉)
总节点数 = 主节点数 × 数据副本数，月费 = 总节点数 × 每节点月费。副本不计入额外服务 QPS。假设分片均衡、每节点性能可线性复用、可用容量已扣除空间余量及元数据，并且总内存足以容纳索引与缓冲区；改变每节点数据量可能改变吞吐量。复制开销、故障后余量、网络和备份费用尚未建模。p99 筛选仅选择已测点，不能证明集群或应用 SLA，尤其不能证明 P99.99。
何时选择 Lavik
当广泛随机读取或混合负载使 Pika 集群为 QPS 而非数据量扩容时，可评估 Lavik。也应回放实际集合命令：公开对比测量的是字符串操作，并非哈希、列表或有序集合性能。
何时保留现有方案
如果 Pika 现有运维方式与兼容性满足需求，且实际工作负载中不存在此测试反映的瓶颈，可以保留 Pika。生产环境更换存储引擎前，应验证迁移、复制与恢复语义。
从测试到迁移
常见问题
Pika 已经使用 SSD，为什么 Lavik 仍可能更省钱？
在相同数据量与请求速率目标下，更高的实测单机 QPS 可以减少由吞吐量决定的节点数。计算器对可用容量、节点价格与扩展效率作出假设；这是容量规划示例，并非多节点集群的实测结果。
使用 Lavik 需要改用新协议吗？
不需要。Lavik 接受 Redis/Valkey 兼容命令，默认 RESP2，也可协商 RESP3。请根据 beta.1 的命令参考、客户端兼容性和迁移指南验证具体行为；协议兼容不等于所有命令、模块或故障切换行为完全相同。
如何把单机结果用于成本评估？
先选择匹配实际读写比例与延迟预算的实测点，再同时考虑数据容量和 QPS 所需节点数。把索引内存、复制、容量余量与故障场景纳入真实回放。页面成本模型是明确假设下的规划示例，不是多节点集群实测或云服务报价。
来源与版本
基准绑定上游提交；产品文档按标注日期核对。八月历史构建与九月 beta.1 结果保留各自范围，不跨实验拼接。
APACHE 2.0 · REDIS COMPATIBLE · NVMe SSD