Lavik0.1.0 beta
← 全部对比

性能 · 架构 · 成本

Lavik vs Garnet

读取优势突出，写入延迟需按目标选择。

Lavik 与 Microsoft Garnet 对比：NVMe SSD 读取吞吐量、SET 延迟取舍、Tsavorite 存储差异及可调整的节点成本模型。

Lavik 项目团队 · 资料核对: 2026-10-13 · Garnet 2.1.5 · Libaio Storage Tier

试用 Lavik ↗查看基准 ↓

2026 年 9 月 18 日 · beta.1

让真实测量说明性能

2.13×Lavik / 对照 GET QPS
3.599 msLavik 在该 GET 点的 p99
4.223 ms对照在该 GET 点的 p99

1B 键 × 1 KiB 值；AMD EPYC 9V74，约 126 GiB RAM，六块 NVMe，16 个逻辑 CPU 亲和性，pipeline=1。每点测量一次，窗口 60 秒。对照数据来自相同主机较早的扫描；beta.1 SPDK 点为新测。每种操作分别选择各系统最高 QPS 点，连接数可能不同。 方法与完整报告 ↗

各操作峰值 QPS 及该点的延迟
操作系统QPSp99 (ms)p99.9 (ms)连接数
GETLavik 0.1.0-beta.1 SPDK952,5603.5995.535640
GETGarnet 2.1.5 · Libaio Storage Tier446,3664.2239.151320
SETLavik 0.1.0-beta.1 SPDK764,93910.87916.6391280
SETGarnet 2.1.5 · Libaio Storage Tier751,0575.53512.7351280

读懂这个结果

Garnet 的 SET 峰值 p99 为 5.535 ms，Lavik 为 10.879 ms。在 p99 不超过 2 ms 的条件下，实测最高 SET 吞吐量约为 Garnet 584,665 QPS、Lavik 422,450 QPS。Garnet 测试后的完整键数扫描未完成，报告已说明此限制；测试前计数通过。

这是 Lavik 项目发布的基准，尚非第三方复测。单机短窗口结果不能证明相同崩溃持久性、长期稳定状态、集群容量或应用 SLA。使用下方成本模型前，请对照你的负载、数据分布与延迟预算。

查看完整连接数与线程扫描
成本计算器可选择的全部测量点
系统操作线程*连接QPSp99 (ms)
LavikGET1680396,6450.319
LavikGET16160598,4620.503
LavikGET16320792,1190.959
LavikGET16640952,5603.599
LavikGET161280903,0559.279
LavikGET162560801,68034.815
LavikSET1680422,4500.711
LavikSET16160530,6723.759
LavikSET16320621,3736.111
LavikSET16640717,5787.839
LavikSET161280764,93910.879
LavikSET162560727,98418.431
GarnetGET1680218,6772.543
GarnetGET16160393,8283.071
GarnetGET16320446,3664.223
GarnetGET16640404,2765.471
GarnetGET161280398,5037.583
GarnetGET162560352,53315.039
GarnetSET1680424,0721.415
GarnetSET16160584,6651.431
GarnetSET16320701,6872.719
GarnetSET16640737,5264.031
GarnetSET161280751,0575.535
GarnetSET162560720,7409.087

*线程角色不同：Lavik 工作线程、Redis/Valkey I/O 线程、Dragonfly proactor、Garnet 最小线程池线程。 CSV ↗

存储设计如何影响你的应用

Garnet 使用 Tsavorite 混合日志，包含内存驻留部分及超内存容量的存储层。Lavik 采用内存键索引、自有持久化记录与集合存储，以及 SPDK 或 io_uring I/O。两者都提供 Redis 风格数据结构，不能将 Garnet 描述为仅支持字符串的数据库。

十亿键结果使 Lavik 对特征获取、大型缓存、画像查询等读密集服务尤其有吸引力。高写入速率服务则需另行判断：即使 Lavik 的 SET 峰值吞吐量略高，Garnet 的写入尾延迟仍可能更低。

Garnet 功能与 Tsavorite 存储 ↗ · Lavik beta.1 存储与恢复 ↗

熟悉的协议，面向 NVMe SSD 的执行路径

速度来自架构，而不是要求应用换一种协议。

Lavik 是 Apache 2.0 开源的 Redis 兼容键值存储。内存保存键索引，NVMe SSD 承载值数据。线程本地状态、协程与异步 I/O 让工作线程在等待存储时继续处理其他请求；SPDK 提供直接访问 NVMe 的存储路径。九月的 SPDK 测试仍使用内核 TCP，并未使用 DPDK 网络。

01Redis 客户端 / RESP
02工作线程与内存键索引
03异步 I/O
04NVMe SSD 值存储

存储引擎覆盖字符串、哈希、列表、集合与有序集合载荷；集合可使用分组存储。键索引、路由元数据和缓冲区仍消耗内存。字符串 GET/SET 基准并不证明其他数据结构具有相同 QPS。 beta.1 架构 ↗ · 存储与集合 ↗ · Apache 2.0 ↗

SSD 单价相同，节点数量仍可能不同

假设模型 · 可调整输入

相同数据量与 QPS 目标，需要多少节点？

默认模型假设 1 TiB 值数据、每主节点 1 TiB 可用值容量、100 万 QPS、使用实测吞吐量的 70%、两份完整数据副本，并假设每节点每月 1,000 美元。双方价格均可修改。

假设线性扩展的规划结果
系统选定实测 QPS / p99主节点 / 总节点月费假设
Lavik SPDK952,560 / 3.599 ms2 / 4$4,000
Garnet446,366 / 4.223 ms4 / 8$8,000

Primaries = max(⌈data / usable capacity⌉, ⌈target QPS / (observed QPS × utilization)⌉)

总节点数 = 主节点数 × 数据副本数，月费 = 总节点数 × 每节点月费。副本不计入额外服务 QPS。假设分片均衡、每节点性能可线性复用、可用容量已扣除空间余量及元数据，并且总内存足以容纳索引与缓冲区；改变每节点数据量可能改变吞吐量。复制开销、故障后余量、网络和备份费用尚未建模。p99 筛选仅选择已测点，不能证明集群或应用 SLA，尤其不能证明 P99.99。

何时选择 Lavik

对于数据超出内存、访问广泛且以读为主的负载，可先评估 Lavik。用实测 GET 优势评估单机服务能力，再在回放中加入更新、过期与持续后台维护。

何时保留现有方案

如果工作负载写入密集、p99 要求严格，或依赖 .NET 扩展能力，应保留 Garnet 作为候选。成本计算器可选择 SET 和 2 ms 上限，直接展示这一取舍，避免被 GET 峰值掩盖。

从测试到迁移

  1. 列出所用命令、数据类型、脚本与客户端选项，对照版本化兼容范围。 命令参考 · 客户端兼容性
  2. 在代表性 NVMe SSD 上回放实际数据分布、过期率和读写比例，比较目标 p99/p99.9，而非只看峰值 QPS。
  3. 验证复制、恢复和故障期间容量余量，再进行可回退的小流量切换。 迁移与集群指南

常见问题

Lavik 是否总比 Garnet 快？

不是。在九月十亿键报告中，Lavik 的 GET/SET 峰值吞吐量更高，但 Garnet 的 SET 峰值 p99 更低，在 2 ms p99 上限内的 SET 吞吐量也更高。必须结合工作负载与延迟目标比较。

使用 Lavik 需要改用新协议吗？

不需要。Lavik 接受 Redis/Valkey 兼容命令，默认 RESP2，也可协商 RESP3。请根据 beta.1 的命令参考、客户端兼容性和迁移指南验证具体行为；协议兼容不等于所有命令、模块或故障切换行为完全相同。

如何把单机结果用于成本评估？

先选择匹配实际读写比例与延迟预算的实测点，再同时考虑数据容量和 QPS 所需节点数。把索引内存、复制、容量余量与故障场景纳入真实回放。页面成本模型是明确假设下的规划示例，不是多节点集群实测或云服务报价。

来源与版本

基准绑定上游提交；产品文档按标注日期核对。八月历史构建与九月 beta.1 结果保留各自范围，不跨实验拼接。

APACHE 2.0 · REDIS COMPATIBLE · NVMe SSD

用你的工作负载，验证容量与速度。

下载 Lavik beta.1 ↗阅读安装指南 →