Lavik性能 · 架构 · 成本
Lavik vs Apache Kvrocks
Redis 数据放上磁盘，实测单机 QPS 更高。
Lavik 与 Apache Kvrocks 对比：NVMe SSD 实测吞吐量与 p99、磁盘上的 Redis 数据结构、维护取舍及节点数成本模型。
Lavik 项目团队 · 资料核对: 2026-10-13 · Apache Kvrocks 2.16.0 · RocksDB / BlobDB
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 | Apache Kvrocks 2.16.0 · RocksDB / BlobDB | 70,672 | 2.479 | 3.407 | 80 |
| SET | Lavik SPDK · August build | 392,284 | 0.999 | 1.607 | 80 |
| SET | Apache Kvrocks 2.16.0 · RocksDB / BlobDB | 110,167 | 1.759 | 2.671 | 80 |
| GET:SET 1:1 | Lavik SPDK · August build | 352,442 | 0.631 | 1.447 | 80 |
| GET:SET 1:1 | Apache Kvrocks 2.16.0 · RocksDB / BlobDB | 88,084 | 2.207 | 4.927 | 80 |
读懂这个结果
Kvrocks 使用 16 个工作线程、80 GiB 块缓存、BlobDB 和 RAID0/XFS。WAL、逐次写入同步、压缩及 Blob GC 被关闭，常规刷盘与自动压缩整理保持开启。关闭这些持久性或维护功能会改变运维语义；不能据此认定持久性相同或长期空间回收表现相同。
这是 Lavik 项目发布的基准，尚非第三方复测。单机短窗口结果不能证明相同崩溃持久性、长期稳定状态、集群容量或应用 SLA。使用下方成本模型前，请对照你的负载、数据分布与延迟预算。
存储设计如何影响你的应用
Kvrocks 将 Redis 数据结构编码为 RocksDB 键与列族。Lavik 采用自有记录和集合表示、内存索引与异步存储。两者都能让大量值容量脱离 DRAM；本次 Lavik 的差异化优势在于实测服务速率与尾延迟。
集合支持并非 Lavik 独有：Kvrocks 文档介绍了 RocksDB 上的哈希、列表、集合与有序集合。工程选择在于不同表示方式如何应对实际读写比例、缓存预算与后台维护。下表在相同本地硬件上测量相同字符串负载。
熟悉的协议，面向 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 |
| Apache Kvrocks | 70,672 / 2.479 ms | 21 / 42 | $42,000 |
Primaries = max(⌈data / usable capacity⌉, ⌈target QPS / (observed QPS × utilization)⌉)
总节点数 = 主节点数 × 数据副本数，月费 = 总节点数 × 每节点月费。副本不计入额外服务 QPS。假设分片均衡、每节点性能可线性复用、可用容量已扣除空间余量及元数据，并且总内存足以容纳索引与缓冲区；改变每节点数据量可能改变吞吐量。复制开销、故障后余量、网络和备份费用尚未建模。p99 筛选仅选择已测点，不能证明集群或应用 SLA，尤其不能证明 P99.99。
何时选择 Lavik
如果 SSD 已是合适的容量介质，但随机读取延迟或 QPS 限制了 Kvrocks 部署，可评估 Lavik。请在更长测试中加入持续覆盖写与磁盘空间回收，确认节点节省在稳态运行下依然成立。
何时保留现有方案
如果 Kvrocks 基于 RocksDB 的运维方式、命令和现有工具适合应用，且已满足延迟目标，可以继续使用。应按真实命令语义与恢复行为规划迁移，而非仅依据 GET 图表。
从测试到迁移
常见问题
Kvrocks 只是加了磁盘缓存的内存数据库吗？
不是。Apache Kvrocks 使用 RocksDB 作为存储引擎，并将 Redis 数据结构映射到它。Lavik 是另一种支持磁盘的架构；对比重点在吞吐量和延迟，而非声称只有一方能将集合存入磁盘。
使用 Lavik 需要改用新协议吗？
不需要。Lavik 接受 Redis/Valkey 兼容命令，默认 RESP2，也可协商 RESP3。请根据 beta.1 的命令参考、客户端兼容性和迁移指南验证具体行为；协议兼容不等于所有命令、模块或故障切换行为完全相同。
如何把单机结果用于成本评估？
先选择匹配实际读写比例与延迟预算的实测点，再同时考虑数据容量和 QPS 所需节点数。把索引内存、复制、容量余量与故障场景纳入真实回放。页面成本模型是明确假设下的规划示例，不是多节点集群实测或云服务报价。
来源与版本
基准绑定上游提交；产品文档按标注日期核对。八月历史构建与九月 beta.1 结果保留各自范围，不跨实验拼接。
APACHE 2.0 · REDIS COMPATIBLE · NVMe SSD