OLTP成本高？可将已结算数据卸载到ClickHouse

分布式 Postgres 帮不上忙

共享存储和分片系统旨在随数据量和工作负载实现线性扩展。

对于分片的 PostgreSQL 系统，只要在 schema 上投入一些精力，随着你投入更多资金，就能实现数据量和事务能力接近线性的扩展。

在现实世界中，由于额外的协调成本和偶发的多阶段跨分片提交，大多数应用获得的收益会递减。

共享存储解决方案会产生更多基础设施成本来处理工作负载，因为分布式系统中越来越多的部分需要冗余。这些额外成本随后通过在存储侧进行激进的多租户打包来分摊。

即使将额外的优化和更廉价的对象存储考虑在内，对于生产工作负载，这些系统的成本通常也高于简单的 OSS 部署。

大多数数据不再变化。但它的 OLTP 账单不会停。

不同业务领域的许多应用以不同方式对待活跃变化的数据和已沉淀的数据。活跃状态和近期行经常用于写入新事务，被用户和集成系统读取。在某个时间窗口或活跃度标准过去之后——数据基本保持只读，访问频率很低，但仍需要保留。

以下是一些来自不同业务应用领域的示例：

• 上一期对账单之前的金融交易被保留以供不频繁访问或审计
• 超过退货窗口的零售购买变为只读，但仍需要用于历史查看
• 超过可修改窗口后的社交活动仍可供浏览
• 已停用客户的租户元数据变为只读

在所有这些示例中，一旦数据从变更密集状态转为已沉淀状态，对 ACID 的需求就消退了。不过，只要数据仍保存在 OLTP 存储中，就会产生相关成本。

Postgres 负责写入，ClickHouse 负责记忆

ClickHouse 是一个 SQL 数据库引擎。它可以处理你的应用需要数据库来处理的任何 SQL 工作负载。

ClickHouse 并未针对高频 ACID 事务进行优化，而这彻底改变了经济性：

• 存储： 列式压缩通常可将数据集缩减 10–30 倍。
• 基础设施： Postgres 方案依赖大型高性能磁盘或层层缓存，成本约为可比的 ClickHouse Cloud 设置的 5 倍。
• 索引： 索引在后台基于大批量行构建，因此更新它们每条记录消耗的 CPU 要少几个数量级。
• 聚合： 得益于专门构建的索引结构、更简单的并发模型以及与写入之间没有缓存争用，汇总和分析查询的运行成本约低 100 倍。

代价是：

• 单行读取更慢： 从列数据重建完整行可能需要数百毫秒。
• 最终一致性： 读取可能看到最多约一秒前的值。

很少有应用能接受这一点用于活跃变化的数据。但一旦数据沉淀下来，为什么要支付 5–10 倍的成本来让它随时准备迎接永远不会到来的更新呢？

它的工作方式如下：

• 写入和新行读取仍留在 Postgres 中。
• ClickHouse 为已沉淀数据的读取提供服务，大多数需要聚合的查询，以及偶尔的写入。
• 对于两个数据层，ClickHouse 都为实时分析查询和数据仓库提供最佳经济性。

额外好处：更少的索引、更轻的维护，意味着更低的 PostgreSQL 计算成本。

（Janitor AI 首席执行官在 CH South Bay Meetup 上分享了将已沉淀数据卸载到 ClickHouse 的成功案例）

使用 2 个数据库构建应用、保持数据同步并将系统复杂性控制在可控范围内是一项艰巨的任务。ClickHouse cloud 正是为了让这一切变得简单而构建。

ClickHouse Cloud 上的 Postgres + ClickHouse。

我们在 ClickHouse 的使命是为分析工作负载和事务工作负载提供同类最佳的性价比。

ClickHouse Cloud 上的统一 OLTP+OLAP 技术栈经过优化，可充分利用 Postgres 和 ClickHouse 的优势，并提供无缝的集成体验：

• 用于 Postgres 数据的本地 NVME 存储为 OLTP 工作负载提供快 2 倍至 10 倍的事务和更高的吞吐量。
• WalShadow——我们最新的原生 CDC 选项，可在数毫秒内将数据复制到 ClickHouse，且不会对 Postgres 性能和稳定性造成代价。
• pg_clickhouse 是同类最佳的 Postgres FDW。你的应用可以继续使用 Postgres 协议，同时释放 ClickHouse 的经济性。为你节省前期工程成本。

你今天就可以在 ClickHouse Cloud 上构建这一模式，并将提供已沉淀数据服务的成本降低一个数量级。我们路线图上的下一步是提供完全托管的体验，为你将已沉淀数据卸载到 ClickHouse。

试试看吧！