LAVIK / 开源数据库

基于 NVMe SSD 的Redis 兼容数据库。

吞吐超越内存。容量按 SSD 的价格增长。

在已发布的测试中,Lavik 的峰值吞吐量超过内存 Redis 和 Valkey。容量成本仅为 Redis 的 1/20。

Redis clients · RESP2 / RESP3 · Apache 2.0

01 / 性能

更快

超过内存
Redis / Valkey

已发布峰值吞吐测试
峰值吞吐量 · 次 / 秒
Lavik 0.2.0 SPDK1,156,956
p99.9 7.103 ms
Redis 8.10.2976,087
p99.9 7.039 ms
Valkey 9.1.2913,756
p99.9 7.743 ms

1,000 万键 · 1 KiB 值 · 1,280 个连接。来自原始测量结果;QPS 四舍五入为整数。

完整峰值吞吐量对比
系统GET QPSGET p99.9SET QPSSET p99.9
Lavik 0.2.0 SPDK1,156,9567.103 ms945,38410.175 ms
Redis 8.10.2976,0877.039 ms863,8607.391 ms
Valkey 9.1.2913,7567.743 ms793,8097.743 ms
LavikRedisValkey
测试条件与成本假设 SPDK · 2026-10-21

Lavik 0.2.0 SPDK 对比 Redis 8.10.2、Valkey 9.1.2:16 vCPU / 8 个物理核,AMD EPYC 9V74、标称 128 GiB 内存、六块 NVMe SSD、1,000 万个 1 KiB 值、pipeline 1、每点 30 秒。所选峰值均为 1,280 个连接;Redis 使用 16 个 I/O 线程,Valkey GET 使用 16 个、SET 使用 8 个。延迟为同一测量点的 p99.9。全部数值来自归档的 memtier JSON 结果。QPS 显示为最接近的整数;p99.9 保留记录中的毫秒精度。Redis/Valkey 关闭 AOF 和自动快照。单次测量不代表相同持久性或应用 SLA。

查看原始测量数据(CSV) ↗

按相同值容量计算,DRAM/NVMe SSD 每 GiB 单价比设为 20:1,Lavik 的值存储介质成本为 DRAM 的 5%。Redis 与 Valkey 使用相同的 DRAM 单价。此模型不含索引与运行时内存、复制、服务器及运维成本;可在计算器中填入实际价格。 成本计算方法 ↗

01 / 存储模型

保留 Redis 接口。
容量突破内存。

数据集持续增长时,把每个值都留在内存中,成本会越来越高。Lavik 在 DRAM 中保留紧凑的键索引,把值存于 NVMe SSD,让数据增长不再意味着为每个字节购买 DRAM。

01

熟悉的命令与客户端

沿用 Redis 数据结构、RESP2/RESP3 客户端和熟悉的应用模式。按应用核对命令、客户端版本和行为兼容性。

查看兼容性 ↗
02

值容量成本降至 1/20

按 DRAM 与 NVMe SSD 每 GiB 单价 20:1 计算,同等值容量仅需 5% 的成本。索引内存、复制和共同服务器成本另计;可在计算器中填入自己的价格。

计算容量成本 ↗
03

围绕 NVMe 设计的引擎

工作线程并行处理独立请求,协程让 I/O 与其他工作重叠执行。Standard 包包含 SPDK 存储支持,首页基准测试使用的正是这一后端。

了解请求处理路径 ↗

大容量,也有实测性能

十亿个键。
值存于 NVMe SSD。

已发布的存储层实验覆盖了比小数据集内存对照更大的规模:十亿个键、每个值 1 KiB,主机标称内存 128 GiB。

阅读完整存储层实验 ↗
1B个键 × 1 KiB 值
1,129,597峰值 GET 请求 / 秒
1.024 TB原始值数据量

Lavik 0.2.0 SPDK · 2026-10-21 · GET 峰值对应 1,280 个连接 · pipeline=1 · 60 秒测量。单台服务器,六块 NVMe SSD。

02 / 容量规划示意

想象一下:300 个节点,变成 3 个。

如果集群扩容主要是为了容纳更多数据,更高的单节点容量就值得用更小规模的集群来评估。从容量需求出发,同时把延迟目标写入验收标准。

300Redis 数据节点
3Lavik 数据节点
容量规划示意:300 个灰色立方体与 3 个绿色立方体假设每节点可用值容量从 32 GiB 增加到 3,200 GiB。图示不表示已验证的迁移结果或延迟 SLA。
容量示意,不是已完成的迁移案例每个立方体代表一个假设的数据节点。
Redis 示例容量300 × 32 GiB
Lavik 示例容量3 × 3,200 GiB
相同的总值容量9.38 TiB

假设每个 Lavik 数据节点的可用值容量提高 100 倍。这是容量算式,并非经过测试的 300 到 3 迁移或推荐拓扑。100 倍节点数量比与 20 倍容量单价比分属不同概念。实际部署仍需规划 DRAM 索引、CPU、网络、副本、控制平面、恢复余量与故障域。

验收标准

先确定 P99.99 SLA。

回放实际键值大小、命令组合、并发、过期和持久性设置。在持续负载、复制与故障切换下测量尾延迟,再决定最终节点数。

规划 Redis Cluster 迁移评估 ↗

逐步缩减集群规模

先选择一个容量压力较大的数据集。使用 RedisShake 导入代表性副本,回放应用流量,在相同保留范围和响应时间目标下比较所需节点数。切换前为副本与恢复预留余量。

查看 RedisShake 迁移步骤 →

03 / 智能体时代的工作负载

你的下一批用户,
可能是智能体。

一个账户可以驱动多个智能体,每个智能体都有自己的画像、会话上下文和特征状态。让不断增长的状态数据可被快速访问,不应意味着必须把所有值放进昂贵的内存。

Lavik 为这些应用提供 Redis 兼容的键值操作,以及 NVMe SSD 值容量。数据保留策略、访问边界与智能体状态的表示方式,由应用自行定义。

容量规划示例

1M账户×100智能体 / 账户=100M智能体状态记录
1200
5.96 TiB

相同记录大小下,值数据容量为基准的 100×。

假设 100 万个账户,每条状态记录 64 KiB;每账户一条记录的基准为 61.04 GiB。这是可调整的规划情景,并非所有智能体应用的增长预测。索引、复制及运行开销另计。

PROFILE / CONTEXT

不断增长的画像

用应用定义的键与 Hash 保存智能体偏好、任务上下文和会话状态。

会话与画像 ↗
ONLINE FEATURES

更多实体,更多特征。

通过熟悉的按键读取与更新,为人、智能体和应用实体提供特征记录。

在线特征服务 ↗
TOOLS / CACHE

容纳可复用的结果

用应用选择的键和 TTL 缓存工具响应及中间结果,同时评估命中率、过期负载与尾延迟。

大容量应用缓存 ↗

04 / 我们的承诺

坚持开源。
公开构建。

我们致力于将 Lavik 作为 Apache 2.0 开源项目持续建设。阅读代码,在自己的项目中使用它,并一起决定接下来的方向。

Lavik 0.2.0 已发布。代码、基准测试步骤与架构文档全部公开。欢迎用它构建应用,深入了解实现,并参与改进。

EloqData 编写的代码采用 Apache 2.0;第三方组件保留各自的许可证和声明。

05 / 下一步

让你的工作负载,
运行在 Lavik 上。

从小规模开始,确认兼容性,再测量对应用真正重要的容量与延迟。

01 / INSTALL

运行第一个节点

选择二进制、APT 软件包、Docker 或 Docker Compose,从版本化安装指南开始。

下载 Lavik ↗
02 / VALIDATE

带上你的 Redis 客户端

核对已测试的客户端版本和命令覆盖范围,再运行应用真实的读写、脚本与过期逻辑。

客户端兼容性 ↗
03 / EVALUATE

规划迁移

演练数据传输、复制、故障处理与回滚路径,再按实际工作负载和 SLA 验收新部署。

从 Redis 迁移 ↗
Redis 兼容。NVMe SSD 容量。Apache 2.0。