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 msRedis 8.10.2976,087
p99.9 7.039 msValkey 9.1.2913,756
p99.9 7.743 ms1,000 万键 · 1 KiB 值 · 1,280 个连接。来自原始测量结果;QPS 四舍五入为整数。
02 / 容量成本同时,仅需1/20
Redis 的值容量成本
测试条件与成本假设 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。
>_你的应用Redis clients · RESP2 / RESP3
→LAVIKworker 1worker 2worker 3worker 4
DRAM键索引定位数据
→NVMe SSD值数据容量承载数据集
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 数据节点
容量示意,不是已完成的迁移案例每个立方体代表一个假设的数据节点。Redis 示例容量300 × 32 GiB
=Lavik 示例容量3 × 3,200 GiB
相同的总值容量9.38 TiB
假设每个 Lavik 数据节点的可用值容量提高 100 倍。这是容量算式,并非经过测试的 300 到 3 迁移或推荐拓扑。100 倍节点数量比与 20 倍容量单价比分属不同概念。实际部署仍需规划 DRAM 索引、CPU、网络、副本、控制平面、恢复余量与故障域。
逐步缩减集群规模
先选择一个容量压力较大的数据集。使用 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 缓存工具响应及中间结果,同时评估命中率、过期负载与尾延迟。
大容量应用缓存 ↗ OPEN SOURCEApache
2.0BUILD · INSPECT · CONTRIBUTE
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。