比较 ClickHouse 和 PostgreSQL
为什么使用 ClickHouse 而不是 Postgres？
简而言之：因为 ClickHouse 专为快速分析而设计，特别是 GROUP BY 查询，作为一个 OLAP 数据库，而 Postgres 是一个 OLTP 数据库，专为事务性工作负载而设计。
OLTP，或在线事务处理数据库，旨在管理事务信息。这些数据库的主要目标，Postgres 是一个经典例子，是确保工程师可以提交一个更新块到数据库，并确信它——作为一个整体——要么成功，要么失败。具有 ACID 属性的这种类型的事务保证是 OLTP 数据库的主要关注点和 Postgres 的巨大优势。鉴于这些要求，OLTP 数据库在用于大型数据集的分析查询时通常会遇到性能限制。
OLAP，或在线分析处理数据库，旨在满足这些需求——管理分析工作负载。这些数据库的主要目标是确保工程师能够有效地查询和聚合大量数据集。像 ClickHouse 这样的实时 OLAP 系统允许在数据实时摄取时进行此分析。
有关 ClickHouse 和 PostgreSQL 更深入的比较，请参阅 此处。
要查看 ClickHouse 和 Postgres 在分析查询中的潜在性能差异，请参阅 在 ClickHouse 中重写 PostgreSQL 查询。
迁移策略
从 PostgreSQL 迁移到 ClickHouse 时，正确的策略取决于您的用例、基础设施和数据需求。通常，实时变更数据捕获 (CDC) 是大多数现代用例的最佳方法，而手动批量加载后定期更新适用于更简单的场景或一次性迁移。
以下部分描述了两种主要的迁移策略：实时 CDC 和 手动批量加载 + 定期更新。
实时复制 (CDC)
变更数据捕获 (CDC) 是保持两个数据库之间表同步的过程。对于大多数从 PostgreSQL 迁移而言，它是最高效的方法，但它更复杂，因为它以接近实时的速度处理从 PostgreSQL 到 ClickHouse 的插入、更新和删除操作。对于实时分析至关重要的用例来说，它是理想的选择。
可以使用 ClickPipes（如果您使用的是 ClickHouse Cloud）或 PeerDB（如果您在本地运行 ClickHouse）在 ClickHouse 中实现实时变更数据捕获 (CDC)。这些解决方案处理实时数据同步的复杂性，包括初始加载，通过捕获 PostgreSQL 的插入、更新和删除操作并在 ClickHouse 中复制它们来实现。这种方法确保 ClickHouse 中的数据始终是最新的和准确的，而无需手动干预。
手动批量加载 + 定期更新
在某些情况下，更直接的方法，例如手动批量加载后定期更新，可能就足够了。此策略适用于一次性迁移或不需要实时复制的情况。它涉及通过直接 SQL INSERT 命令或导出和导入 CSV 文件将数据从 PostgreSQL 加载到 ClickHouse。初始迁移后，您可以定期通过以固定间隔从 PostgreSQL 同步更改来更新 ClickHouse 中的数据。
批量加载过程简单而灵活，但缺点是没有实时更新。一旦初始数据进入 ClickHouse，更新将不会立即反映，因此您必须安排定期更新以同步来自 PostgreSQL 的更改。这种方法适用于不太敏感于时间的应用场景，但会在 PostgreSQL 中的数据更改与这些更改出现在 ClickHouse 中之间引入延迟。
选择哪种策略？
对于大多数需要在 ClickHouse 中获取最新、最新数据的应用程序，建议使用 ClickPipes 进行实时 CDC。它提供持续的数据同步，设置和维护最少。另一方面，对于更简单、一次性迁移或实时更新不重要的工作负载，手动批量加载并定期更新是一种可行的选择。
