Lakebase 搜索容量规划：来自真实应用与 400 万条文本段的经验教训
内容提要
Databricks 内部应用 Slide Hub 基于 Lakebase Postgres 实现混合搜索，结合向量检索与 BM25 关键词检索，无需独立搜索系统。基准测试显示：8 CU 以下时数据库为瓶颈，8 CU 以上时应用为瓶颈；缓存与索引比例决定命中率，接近 1.0 时延迟稳定。建议索引用 quality 模式、候选数设为 200，生产环境最小 0.5 CU 以避免冷启动。
延伸解读
瓶颈定位：先查数据库，再扩应用
基准测试显示，8 CU 是分水岭：低于 8 CU 时，数据库是瓶颈，增加应用资源无效；高于 8 CU 后，应用成为瓶颈，数据库连接大多空闲。因此扩容顺序应为：先优化查询，再增加 Lakebase CU 直到应用成为限制，最后扩展应用。这避免了盲目扩容，确保每一分资源都用在刀刃上。
缓存比例：决定延迟的关键指标
缓存比例定义为缓存大小除以向量索引大小。测试表明，当比例接近 1.0 时，缓存命中率可达 97%，延迟稳定；比例低于 0.07 时，命中率仅 45%，延迟显著上升。该比例在不同语料规模下表现一致，因此可用小规模测试预测大规模行为。规划容量时，应依据索引大小而非行数来估算所需 CU。
候选数调优：200 是平衡点
Slide Hub 最初使用 1000 个候选，但实验发现，将候选数降至 200 时，前 10 结果的重合度仍达 90.5%，而读取的页面数减少约三分之二，冷启动延迟减半。用户很少翻到 200 条之后，因此 200 是兼顾效果与成本的合理选择。这提示我们，候选数并非越大越好，需根据实际翻页行为调整。
索引构建：quality 模式提升召回
默认构建的向量索引在 4M 语料上召回@10 为 0.74，而使用 build_mode = 'quality' 可提升至 0.80，且查询延迟几乎不变。代价是构建时间较长（4M 语料在 16 CU 下需 52 分钟）。若应用对召回要求高，建议采用 quality 模式，并通过调整 probes 参数在延迟与召回间进一步权衡。
Q&A
Lakebase Postgres 的搜索功能需要哪些扩展？如何启用？
需要 lakebase_vector、lakebase_ann、lakebase_text、lakebase_bm25 和可选的 lakebase_tokenizer。通过两个 CREATE EXTENSION 语句启用：CREATE EXTENSION lakebase_vector lakebase_ann lakebase_text lakebase_bm25 lakebase_tokenizer。
在 Lakebase Postgres 上做混合搜索时，候选数（candidate_limit）设置多少比较合适？
建议设置为 200。实验表明，200 个候选能保留 90.5% 的 top 10 结果，读取的页面数约为 1000 候选的三分之一，并将冷启动延迟减半。
如何根据向量索引大小确定 Lakebase Postgres 的 CU 大小？
根据缓存比率（缓存大小除以向量索引大小）来确定。缓存比率接近 1.0 时，命中率可达 97%，延迟稳定。例如，缓存比率 0.07 时命中率 45%，0.57 时 86%，1.14 时 97%。建议将缓存比率保持在 1.0 左右。
Lakebase Postgres 的向量索引如何提高召回率？
使用 build_mode = 'quality' 构建索引，并在默认探测数下可将 recall@10 从 0.74 提升到 0.80。增加探测数可进一步提高召回率，例如 500 个探测可达 0.91。但构建时间较长，4M 段落需 52 分钟（16 CU）。
生产环境中 Lakebase Postgres 的最小 CU 设置建议是多少？为什么？
建议将最小 CU 设置为 0.5 CU，而不是缩容到零。这样可以避免冷启动时约 1 秒的唤醒等待和空缓存，每月成本约 31 到 40 美元（按列表价）。
Lakebase Postgres 的成本如何？在 Slide Hub 中占比多少？
Lakebase 按使用量计费，暂停的计算不产生计算费用，存储单独计费。在 Slide Hub 的 30 天账单中，Lakebase 约占 1%。一次 14 分钟的负载测试仅花费 0.02 美元的 Lakebase 计算费用。
