为能够持续提供服务的容量核算成本

每字节存储价格较低，足以让数据库方案显得很有吸引力，但报价可能尚未考虑替换副本所需的资源。对于数据量逐渐超出内存的 Redis 工作负载，更有用的采购问题是：部署在满足运行要求的前提下，究竟能保留多少逻辑数据？Lavik 将值放到存储中，在 DRAM 中保留紧凑的键索引。这改变了容量预算，但内存、额外数据副本、后台维护和恢复仍然需要资源。

本文讨论的是采用 Apache 2.0 许可证的 beta 项目 Lavik 0.1.0-beta.1。此前的文章“Plan cache growth by counting keys, not just terabytes”讨论了数据集的容量估算。这里关注下一步决策：如何把容量估算转化为一份能够经受运维评审的报价。

为每项成本明确分母

先确定应用逻辑载荷，也就是应用需要保留的值，每份只计一次。随后分别记录所有数据副本配置的物理存储、所有副本配置的 DRAM，以及部署的周期性费用。存储费用除以物理字节数，回答的是资源单价问题；部署账单除以逻辑载荷，回答的则是另一个问题。这两种算法都不能证明相应容量能支持多少吞吐或怎样的可用性。

可以使用这样的规划公式：配置存储容量 = 逻辑载荷 × 数据拷贝总数 × 物理占用与逻辑载荷之比 ÷ 目标占用率。物理占用比例应包括键、记录元数据、布局开销，以及所选工作负载下预计尚未回收的旧版本。目标占用率则表示预留运行余量后，计划使用的配置容量比例。这些都是规划输入，并非已经测得的 Lavik 常数；应分别定义，避免把同一份余量重复计入。

每个价格都应附带日期、计费单位和包含项目。如果虚拟机报价已经包含本地 NVMe，再添加一笔假设的磁盘租用费就会重复计算。8 月 12 日报告记录的用户估价为：Lavik 服务器虚拟机每月 1,152.67 美元，Azure Managed Redis 每月 2,414.28 美元。这些历史估价不包含压测客户端，而且比较的是服务边界不同的方案。它们既不是当前报价，也不是实测的总成本比例。

副本预算也要包含内存

数据拷贝总数同时影响存储和内存预算。Lavik 恢复本地数据时，会重建由各 worker 持有的索引；副本节点也需要内存来接收数据并为其提供服务。把值迁移到 NVMe，并不会消除索引、请求缓冲区、存储缓冲区或复制状态。应先为每个拟部署节点分配足够容纳其数据和运行状态的内存，再计入所选复制拓扑需要的节点。

汇总后的空闲内存还可能掩盖局部限制。Lavik 将配置的内存预算划分为固定的 worker 份额，worker 不能借用其他 worker 的闲置额度。保留状态的准入上限为各份额的 90%，而配置预算并非严格的 RSS 上限。因此，报价除了总 DRAM，还应记录数据在 worker 间的分布以及进程余量。单一的平均每键内存估算，不能证明所有 worker 都能接纳目标数据。

选择数据拷贝总数前，应先确定故障要求：方案需要容忍哪个节点或故障域失效，读写是否必须继续，以及最多允许丢失多少已确认的数据。Lavik 的普通写入成功响应并不是同步持久化屏障。只有结合复制拓扑与故障语义进行评估，才能把两份部署报价视为具有可比性。

为暂时无法复用的空间留预算

刚完成加载的数据集，不能完整代表运行中的物理占用。Lavik 以追加方式写入不可变记录版本。替换版本跨过必要的刷盘边界前，旧的持久化版本仍计入空间占用。碎片整理迁移存活记录时，必须先使目标位置持久化，才能释放源位置。元数据、受保护的维护预留空间，以及等待回收的版本，都会影响可容纳的逻辑载荷。

替换副本时，这一区别会直接影响预算。原生全量同步会使旧数据集失效，并在原位置构建替代数据集。它不会预先保留第二份完整数据集的空间，但失效块也不会立即变成可分配空间。这些块必须完成回收流程；如果可回收容量不足，重建可能报告资源耗尽。因此，不应简单地把数据集预算翻倍，也不应假定原地重建无需额外余量。

评估时可以分别安排三类观测：加载完成后的物理占用、后台维护开启时持续覆盖写入的占用，以及替换副本期间的可用容量。同时记录保留内存和 RSS。这些是建议进行的测量，并非本文提供的测试结果。目的在于用目标运行状态下的证据，替代一个缺乏解释的空间放大系数。

接受报价前，先验证性能要求

容量估算还必须满足工作负载的延迟和吞吐要求。9 月 18 日 SPDK 报告分别使用了千万键和十亿键数据集，值大小为 1 KiB，运行均匀随机 GET 或覆盖式 SET，流水线深度为一。报告包含 22 个新增 Lavik 测量点和 124 个复用的对照测量点，每个配置只测量一次，窗口为 30 秒或 60 秒。这些观测不能证明持续重建期间的性能，也不能证明崩溃持久性相同。“What the NVMe benchmark tells us”可作为理解基准证据的配套阅读。

最终工作表应围绕一组明确的运行要求展开。填入带日期的价格、逻辑载荷、数据拷贝总数、每节点索引及运行内存、观测到的物理占用和预留容量。随后单独列出容量计算之外的成本：计算资源、网络、备份存储、监控和运维工作。验证工作负载兼容性与恢复行为后，再比较所得配置。“Evaluate the Redis client’s second attempt”和“Choose the Lavik package before choosing the I/O experiment”可辅助这些评估步骤。下一步的实际交付物，是一份明确标注可用容量、并列出试点需要补齐哪些证据的报价。