A practical guide to cost optimization with Lakebase Postgres

使用 Lakebase Postgres 进行成本优化的实用指南 | Databricks 博客

跳至主要内容

Lakebase

2026年9月30日

使用 Lakebase Postgres 进行成本优化的实用指南

作者：Benjamin Nwokeleme、Firas Farah 和 Jen Darrouzet

摘要

• Lakebase 的设计本身即具备成本效益，其分离的存储和计算架构使分支、只读副本和高可用性共享同一存储层，而无服务器自动扩展和零扩展能力意味着您只需为实际使用的计算资源付费。

• 最显著的实际节省来自于仅同步 Lakehouse 数据中正在使用的子集到 Lakebase，根据数据需要的新鲜度程度匹配同步模式（快照、触发或持续），并合理配置计算资源使热点数据集完全缓存。

• 应用这些实践：仅同步工作集数据、根据数据新鲜度需求匹配同步模式、合理配置计算资源使热点数据完全缓存，并调整 PITR 和快照设置，可以在不牺牲应用程序所需性能、可用性和开发体验的前提下，保持成本可预测且低廉。

Lakebase 是一个全托管的 Postgres 数据库，专为现代应用开发的实际运营需求而构建。与其他提供 Postgres 引擎的数据库厂商相比，其独特之处在于底层架构——分离的存储和计算层配合无服务器计算层，以及与 Lakehouse 和数据智能平台的紧密集成。您可在此处了解更多关于该架构和部分优势的信息。然而，一个常被忽视的优势是，这种架构也使 Lakebase 具备高度成本效率。在本文中，我们将剖析这些成本效益的来源，并分享充分利用它们的实用技巧。

Lakebase 如何通过设计实现成本效率

通过分支避免重复存储成本

数据库分支允许开发人员为开发、测试或实验目的创建包含生产数据的隔离环境。与需要为每个环境创建数据库物理副本的方法不同，Lakebase 分支共享相同的底层存储，并在分支偏离父分支时跟踪变更。这使得分支在短期开发和测试环境中特别具有成本效益，团队可以使用类似生产的数据进行工作，而无需单独创建和维护数据库的完整副本。

仅为您实际使用的计算资源付费

自动扩展会根据活动水平的变化动态调整 Lakebase 实例的计算资源。您可以控制实例可扩展的最小和最大范围。该功能的成本优势显而易见：计算容量可根据工作负载需求进行扩展，而不是为峰值使用静态分配资源。

设置最大计算规模有助于使成本可预测，因为通过限制计算成本的上限，可以避免意外支出。在低使用率期间，计算资源会自动缩减，从而降低成本。当与“扩展至零”功能结合使用时，经过一段时间的空闲后，计算资源会完全暂停，将计算成本降至零。从“扩展至零”状态恢复计算仅需数百毫秒。这使得该功能特别适用于对延迟不敏感的场景，例如开发工作流、非生产环境的应用变体，以及不需要十位数级延迟的生产应用。

当关闭“扩展至零”功能时，Lakebase 采用始终开启的计费模式，该模式在基准容量基础上提供 25% 的折扣。这种成本降低同样适用于无法扩展至零的计算资源，例如高可用性（HA）配置。

在不复制存储的情况下添加副本和高可用性

Lakebase 的存储与计算分离架构也使读取副本和高可用性更加成本高效。读取副本是独立的计算实例，它们从与主实例相同的底层存储层读取数据，因此扩展读取能力无需创建并支付数据库的额外副本。同样，高可用性功能会在不同可用区之间添加冗余计算，同时继续使用现有高可用存储层。这意味着您可以在不增加存储占用的情况下，添加读取扩展能力和计算冗余。

优化 Lakebase 成本的实用技巧

使用 Lakebase 同步表服务 Lakehouse 数据的子集

Lakebase 与 Databricks 智能平台的紧密集成允许在两个环境之间进行管理同步。同步表会将 Unity Catalog 数据呈现在您的 Lakebase 数据库中，以支持应用程序或功能服务的低延迟事务读取。

客户常见的错误操作是将大型 Delta 表推送到 Lakebase，而应用程序实际上仅查询其中很小的活跃数据子集。这会增加 Lakebase 存储成本，提高同步成本，甚至在某些场景下可能导致性能问题。解决方案很简单：仅同步应用程序所需的活跃数据子集。例如，通过定义物化视图（如滚动 60 天窗口）来精确指定应用程序所需的数据，然后仅同步该部分数据。Lakebase 同步管道可以利用物化视图的自动变更数据流，在读取时计算行级变更。这意味着物化视图的变更（包括数据随滚动窗口老化而删除的行）可以以增量方式传播到 Lakebase。结果是在 Lakebase 中获得一个最新且低延迟的活跃数据子集，而完整的数据历史记录仍保留在 Delta 中。将此方法与下文所述的最精简同步模式相结合，您可以实现更高效的成本反向 ETL 模式。

使用合适的 Lakehouse → Lakebase 同步模式

同步表在底层使用托管的无服务器 Spark 声明式管道（SDP），并在同步期间持续运行。因此，同步成本由数据移动量和 Lakebase 实例规模/容量单位（CUs）等因素驱动。

从 Lakehouse 向 Lakebase 移动数据有三种不同的同步模式，选择模式时需要匹配数据实际需要的新鲜度要求。选择合适的模式可以满足您的延迟需求，同时控制成本。

| 模式 | 描述 | 最佳使用场景 | |------------|----------------|----------------------| | 快照 | 所有数据的副本 | 需要完全一致的数据时 |

Source changes >10% of rows per cycle. Will be substantially more cost-effective than Triggered in those scenarios.

触发模式

按需或定期运行的增量更新

源数据行按已知周期变化。每次刷新时会传播插入、更新和删除操作。

持续模式

具有秒级延迟的实时流处理

变更必须以接近实时的方式出现在 Lakebase 中。这在成本最高时提供最低的延迟。

来源：同步模式

快照模式是处理不常更新或高度波动表的最经济选择，而持续模式可能最昂贵，因为其管道持续运行，即使没有数据变更也会消耗计算资源。当同步之间源数据变更超过 10% 时，建议使用快照模式，因为它可以达到 10 倍的效率提升。对于增量工作负载，触发模式在成本和延迟之间提供了最佳平衡。通过将触发模式与表更新触发器结合使用，可以在预算范围内实现接近连续的新鲜度，确保仅在源数据变更时运行。通常应避免设置过长的运行间隔，因为大量积压的变更会使后续同步变慢且成本增加。

另一个有用的成本优化方法是将多个表合并到单个同步管道中。如果您的用例允许，同一管道可以将多个 Delta 表的变更同步到 Lakebase，使这些表共享相同的底层计算资源。这对于持续同步尤其有价值，因为管道始终运行，可以避免为每个表单独支付持续运行的管道费用。

从一开始就合理配置 Lakebase

创建 Lakebase 项目时，会自动包含一个生产分支和一个主读写计算资源。默认情况下，该计算资源配置为在 8 到 16 个 CU 之间自动扩展，并在 24 小时无活动后启用缩至零。这些默认值可能完全符合您的工作负载需求，但如果您的应用需要更少的计算资源，不进行调整可能导致支付超出需求的容量费用。

在创建项目时，您可以编程化配置项目时设置初始计算资源范围，而无需后续手动调整。例如，使用 Databricks SDK：

$

/$

如果您使用声明式自动化捆绑包（DABs）以声明方式管理 Lakebase，也可以类似地为所配置的端点定义计算资源范围：

/think

确定计算规模时最关键的因素是工作集：即应用程序频繁访问的数据和索引，而非数据库在磁盘上的完整大小。一个2500GB的数据库如果其热点工作集只有20GB，不需要2500GB的RAM，只需足够容纳这20GB并留出一定余量的内存即可。这非常重要，因为计算资源使用内存的方式决定了性能。RAM与计算规模成线性关系，且计算资源的RAM中最多75%可作为计算缓存使用。当工作集能完全容纳在该缓存中时，绝大多数读取操作都可从内存中完成，因此保持快速且延迟稳定。当工作集超出缓存容量时，PostgreSQL必须从存储中获取未命中缓存的数据页，这比内存命中慢得多，并会导致应用程序感知到延迟波动。因此，确定计算规模本质上是选择一个缓存容量超过工作集的计算资源，同时为其他操作预留余量。尽管内存并非唯一随计算规模增长的资源，但也要权衡查询复杂度、并发量和延迟目标，因为高并发或对延迟敏感的工作负载在相同数据规模下需要比轻量级内部工具更大的余量。

数据库连接也需要特别关注。PostgreSQL的max_connections（并发连接的硬性上限）同样由计算规模决定，对于自动扩展的计算资源，其遵循特定规则：上限由最大CU和八倍最小CU中的较小值决定。因此提高最大CU只能增加最多八倍最小CU的连接数，超过该阈值后，较小的最小CU会限制更大最大CU的扩展空间。如果应用程序开启大量连接，可能达到此上限并开始拒绝新连接并报错。如果连接量是实际限制因素，应将其纳入最小CU的考量，并在Lakebase前部署连接池。连接池允许多个客户端连接共享PostgreSQL连接池，支持高达10,000个并发客户端连接。对于频繁开启连接的应用，连接池通常是更优解，且成本低于单纯通过扩大计算规模来提升连接上限。

您无需猜测这些参数。Lakebase Metrics仪表板会报告过去5分钟、15分钟和1小时窗口内的工作集大小，并直接与可用计算缓存并列显示，让您一目了然地判断热点数据是否能完全容纳在缓存中。结合缓存命中率、CPU、内存和连接利用率指标，可验证初始计算规模配置并进行调整。对于访问模式稳定的工作负载，将1小时工作集与可用计算缓存进行对比是特别有用的信号。当最小CU下工作集已能完全容纳在内存中时，自动扩展能带来最大收益，否则每次计算资源扩容时都需要支付冷缓存的性能代价。利用这些指标设置一个能容纳工作集的最小值和能吸收峰值的上限值。

#### 计算资源不足时的表现

资源不足通常不会直接表现为系统故障，更多时候会以容易误诊的症状出现：

• 响应延迟缓慢且不一致。当工作集不再适合缓存时，未命中缓存的读取操作将转至存储层。此时中位数延迟可能仍表现良好，但 p95 和 p99 延迟会显著上升并变得不稳定，因为性能现在取决于特定查询的数据是否恰好被缓存。

• 缓存命中率下降。这是工作集超出可用缓存容量的首要指标，通常在延迟明显恶化之前，命中率就开始下降。

• CPU 饱和和查询排队。计算资源不足时，负载下 CPU 会持续满负荷运行，导致查询等待、吞吐量停滞以及整体延迟上升。

• 连接错误。每种计算规模都有并发连接的上限；当客户端超过该限制时，新连接会被拒绝并返回“太多客户端”的错误，而不是优雅降级。

• 扩缩容或唤醒后的冷缓存惩罚。缩放至零后唤醒，或自动扩缩容首次扩容时，缓存会从空状态开始，需要重新预热。在此期间，您会看到一波较慢的查询，直到工作集重新被缓存。这也是为什么最小计算规模与最大计算规模同样重要。

优化您的 PITR 和快照策略

时间点恢复（PITR）持续维护历史记录，以便将数据库恢复到配置的恢复窗口（2-30 天）内的任意时间点。快照则是对主分支的离散时间点捕获，可手动创建或按每日、每周或每月的自动化计划创建。

由于 Lakebase 需要在整个恢复窗口期间保留更改的历史记录，PITR 存储会随着写入活动和恢复窗口长度的增加而增长。对于写入密集型应用，较长的 PITR 窗口可能导致显著的存储消耗。一种节省成本的方法是选择满足您的事故恢复需求的 PITR 窗口，并在需要长期恢复点时通过计划快照进行补充。

好消息是，PITR 和快照的定价均低于常规 Lakebase 分支存储。快照存储（0.090 美元/GB-月）比常规分支存储便宜约 74%，而 PITR 存储（0.200 美元/GB-月）便宜约 42%。计划快照尤其存储高效：计划中的第一个快照以完整快照形式存储，后续快照仅按增量更改计费。

使用 PITR 从意外事故（如误删或错误写入）中恢复，这些事故可能在您的恢复窗口内的任何时间发生。使用快照进行计划恢复点。例如，在执行高风险迁移或批量更新前手动创建快照，并使用计划快照进行常规的长期保护。

最终，请根据实际恢复需求配置恢复策略。保留超出需求的历史记录或恢复点会增加存储成本，但不会带来有意义的额外价值。

查找您的 Lakebase 成本

如上所述，Lakebase 成本分为三个部分：数据库计算、数据库存储，以及在使用 Synced Tables 时用于将数据从 Lakehouse 同步到 Lakebase 的无服务器流水线计算。

计算资源按时间内的 CU 使用量计费。使用自动扩缩容时，使用量会随着数据库在其配置范围内缩放时消耗的计算容量而变化。

存储包括数据库分支存储、时间点恢复（PITR）历史记录和快照存储。这些存储按其底层存储使用量分别计费。

同步表使用托管流水线将数据从Unity Catalog传输到Lakebase。用于同步的流水线计算资源与Lakebase数据库计算资源分开计费。

查看Lakebase计算和存储成本

Lakebase的计算和存储使用情况可在system.billing.usage中查看。通过product_features.lakebase.storage_type可进一步细分存储使用情况：

• BRANCH_DATA_STORAGE：非过期数据库分支的存储
• BRANCH_CHANGE_STORAGE：过期分支的变更数据存储
• BRANCH_HISTORY_STORAGE：用于PITR的历史数据存储

以下查询将使用情况与system.billing.list_prices关联，按有效列表价格估算每日成本。

Lakebase在计费系统表中分别暴露了计算和存储的SKU，存储类型字段提供了上述额外细分信息。

您可以在Lakebase UI的Project > Settings > UID下找到项目UID。如果已知项目名称，可通过编程方式列出项目并匹配status.display_name来获取uid。

查看同步表流水线成本

同步表流水线使用情况也可从system.billing.usage中查询。通过过滤底层流水线ID并关联到system.billing.list_prices，可估算流水线的每日成本。

这些查询使用使用期间的有效列表价格估算成本，不反映客户特定的合同折扣。

您可以通过在UI中打开同步表并复制Pipeline ID来找到流水线ID。编程方式上，可通过获取同步表并读取status.pipeline_id来实现：

综合应用

Lakebase从架构层面设计为成本高效，从共享存储和分支功能到自动扩展和无服务器计算均体现了这一特性。将这些内置效率与合理的配置相结合，包括规模设置、同步策略和恢复机制，您可以在保持成本可预测的同时，获得应用程序所需性能、可用性和开发体验。

订阅最新文章

订阅我们的博客，获取最新文章直接发送到您的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"