Lavik性能 · 架构 · 成本
Lavik vs KeyDB
当工作集过于分散，热点层不再足够。
Lavik 与 KeyDB On Flash 对比：均匀访问 SSD 基准、热点局部性的影响、实验性功能范围及透明成本建模。
Lavik 项目团队 · 资料核对: 2026-10-13 · KeyDB 6.3.4 · On Flash (experimental)
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 | KeyDB 6.3.4 · On Flash (experimental) | 6,146 | 18.047 | 25.471 | 80 |
| SET | Lavik SPDK · August build | 392,284 | 0.999 | 1.607 | 80 |
| SET | KeyDB 6.3.4 · On Flash (experimental) | 5,395 | 24.447 | 31.359 | 80 |
| GET:SET 1:1 | Lavik SPDK · August build | 352,442 | 0.631 | 1.447 | 80 |
| GET:SET 1:1 | KeyDB 6.3.4 · On Flash (experimental) | 5,197 | 29.311 | 39.167 | 80 |
读懂这个结果
报告明确说明，此访问模式不同于 KeyDB On Flash 推荐的热点键负载。KeyDB 保留了 RocksDB WAL 与自动压缩整理，而部分其他对照组关闭了 WAL。测试使用 4 个服务线程，没有额外预热或等待后台整理。很大的性能比值仅适用于此配置和分布。
这是 Lavik 项目发布的基准，尚非第三方复测。单机短窗口结果不能证明相同崩溃持久性、长期稳定状态、集群容量或应用 SLA。使用下方成本模型前，请对照你的负载、数据分布与延迟预算。
存储设计如何影响你的应用
KeyDB On Flash 基于 RocksDB，将热点数据保留在 DRAM，并可从闪存流式读取较大的值。官方文档将其标为 beta/实验性功能。测试配置使用 64 GiB 热点层与 allkeys-lru。本页比较 On Flash，而非普通内存模式 KeyDB 的性能。
在 2 亿键上均匀随机访问，会削弱小热点层的作用。这对长尾缓存、广泛特征检索与机器生成画像是有用的压力场景。Lavik 在此情况下的优势支持在局部性弱时进行评估，而不代表所有 KeyDB 应用都如此。
KeyDB On Flash 文档 ↗ · KeyDB On Flash 容量与负载指南 ↗ · Lavik beta.1 存储与恢复 ↗
熟悉的协议，面向 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 |
| KeyDB | 6,146 / 18.047 ms | 233 / 466 | $466,000 |
Primaries = max(⌈data / usable capacity⌉, ⌈target QPS / (observed QPS × utilization)⌉)
总节点数 = 主节点数 × 数据副本数，月费 = 总节点数 × 每节点月费。副本不计入额外服务 QPS。假设分片均衡、每节点性能可线性复用、可用容量已扣除空间余量及元数据，并且总内存足以容纳索引与缓冲区；改变每节点数据量可能改变吞吐量。复制开销、故障后余量、网络和备份费用尚未建模。p99 筛选仅选择已测点，不能证明集群或应用 SLA，尤其不能证明 P99.99。
何时选择 Lavik
当活跃键空间广泛，DRAM 热点层无法吸收大部分请求时，可优先评估 Lavik。先计算节点数量影响，再用真实访问热度分布及冷启动或缓存快速变化阶段验证。
何时保留现有方案
如果少量稳定热点承担主要流量，且实验性状态符合部署要求，可以保留 KeyDB On Flash 作为候选。均匀访问基准有意消除了这一局部性优势，因此必须进行接近生产的回放。
从测试到迁移
常见问题
这是否说明 KeyDB 本身总是慢很多？
不是。这些数据针对 KeyDB 6.3.4 On Flash、64 GiB 热点层和 2 亿键上的均匀访问，不能用于评价内存模式 KeyDB 或高度集中的热点负载。成本估算也受相同限制。
使用 Lavik 需要改用新协议吗？
不需要。Lavik 接受 Redis/Valkey 兼容命令，默认 RESP2，也可协商 RESP3。请根据 beta.1 的命令参考、客户端兼容性和迁移指南验证具体行为；协议兼容不等于所有命令、模块或故障切换行为完全相同。
如何把单机结果用于成本评估？
先选择匹配实际读写比例与延迟预算的实测点，再同时考虑数据容量和 QPS 所需节点数。把索引内存、复制、容量余量与故障场景纳入真实回放。页面成本模型是明确假设下的规划示例，不是多节点集群实测或云服务报价。
来源与版本
基准绑定上游提交；产品文档按标注日期核对。八月历史构建与九月 beta.1 结果保留各自范围，不跨实验拼接。
APACHE 2.0 · REDIS COMPATIBLE · NVMe SSD