使用开源技术进行数据库复制指南

图片来源

Jason Baker。CC BY-SA 4.0。

在不断发展的数据世界中，一个问题经常出现：如何才能无缝复制呈指数增长且来自越来越多来源的数据？本文解释了一些基础开源技术，这些技术可能有助于将数据库复制任务商品化到数据仓库、数据湖或其他数据库中。

一种流行的复制技术是变更数据捕获 (CDC)，这是一种模式，允许快速识别、捕获源数据库中行级别的数据更改，并实时交付到目标数据仓库、数据湖或其他数据库。使用 CDC，只有自上次复制以来发生更改的数据（按插入、更新和删除操作分类）才在范围内。这种增量设计方法使 CDC 比其他数据库复制模式（例如全数据库复制）效率更高。使用全数据库复制，将扫描整个源数据库表（可能包含数百万行）并将其复制到目标数据库。

开源 CDC

Debezium 是一个开源分布式 CDC 平台，它利用 Apache Kafka 来传输数据更改。它持续监控数据库，确保将每个行级别的更改都以与提交到数据库的完全相同的顺序发送到目标数据库。但是，在 DIY 复制项目中使用 Debezium 可能会非常繁重。它需要深入了解与源系统和目标系统、Kafka 和 Debezium 内部结构相关的概念。例如，只需查看 Debezium MySQL 连接器所需的所有详细信息。

Airbyte 是一个开源数据集成引擎，允许您将数据整合到数据仓库、数据湖和数据库中。Airbyte 利用 Debezium 并完成所有繁重的工作。实际上，在 Airbyte 中，Debezium 作为嵌入式库运行。这种工程设计允许在不需要使用 Apache Kafka 或其他语言运行时的情况下使用 Debezium。这个视频展示了如何在几分钟内使用 CDC 和 Airbyte 复制 PostgreSQL 数据库。开源代码可用于 Postgres、MySQL 和 MSSQL，并将很快用于所有其他支持它的主要数据库。

数据库有哪些典型的 CDC 用例？

数据库位于当今数据基础设施的核心，并且适用几种不同的用例。

1. 消除跨事务数据库和网络的开销

通过部署 CDC，可以持续流式传输数据更改，而不会给源数据库系统带来不必要的开销。这意味着数据库可以专注于执行为其设计的更有价值的任务，从而为应用程序带来更高的吞吐量和更低的延迟。借助 CDC，只有增量数据更改通过网络传输，从而降低数据传输成本，最大限度地减少网络饱和，并消除微调系统以处理峰值批量流量的需求。

2. 保持事务数据库和分析数据库同步

随着数据以惊人的速度生成，从数据中提取洞察力是组织成功的关键。CDC 从事务数据库捕获实时数据更改，并定期将这些更改发送到分析数据库或数据仓库，在其中可以分析这些更改以提取更深入的洞察力。例如，假设您是一家在线旅行公司。您可以在数据库层（假设使用 PostgreSQL）捕获实时在线预订活动，并将这些事务发送到您的分析数据库，以了解更多关于客户购买模式和偏好的信息。

3. 将数据从遗留系统迁移到下一代数据平台

随着向云数据库实例迁移以实现遗留数据库系统现代化的转变，将数据迁移到这些较新的平台已变得比以往任何时候都更加重要。借助 CDC，数据会定期同步，使您可以按照自己的节奏实现数据平台现代化，同时在过渡期间维护遗留数据平台和下一代数据平台。此设置确保了灵活性，并且可以保持业务运营而不会遗漏任何环节。

4. 为应用程序预热动态数据缓存

缓存是提高应用程序性能的标准技术，但必须预热（或加载数据）数据缓存才能使其生效。使用预热的数据缓存，应用程序可以快速访问数据，绕过核心数据库。例如，对于执行大量数据查找的应用程序，此模式非常有利，因为将此查找数据加载到缓存中可以减轻核心数据库的读取工作负载。使用 CDC，可以始终动态更新数据缓存。例如，可以在初始预热周期中将数据库中的选择性查找表加载到缓存中。对查找表数据进行的任何未来修改都将以增量方式传播以更新缓存。

存在哪些 CDC 实现？应该选择哪个数据库？

CDC 已经存在很长时间了，多年来，在其他产品中涌现出几种不同的广泛使用的实现。但是，并非所有 CDC 实现都是相同的，您需要选择正确的实现才能清楚地了解数据更改。我在下面的列表中总结了其中一些实现以及使用每种实现的挑战

修改日期

此方法跟踪表中每行的元数据，包括谁创建了行、谁最近修改了行以及行何时创建和修改。

挑战:

由于已删除行的 date_modified 字段不再存在，因此不容易跟踪数据删除。
需要额外的计算资源来处理 date_modified 字段。如果在 date_modified 字段上使用索引，则索引将需要额外的计算和存储资源。

二进制差异

此实现计算当前数据和先前数据之间的状态差异。

挑战:

当数据量很大时，计算状态差异可能很复杂且无法很好地扩展。
需要额外的计算资源，并且无法实时完成。

数据库触发器

此方法需要创建数据库触发器，其中包含用于管理同一表或单独的记账表中的元数据的逻辑。

挑战:

触发器必须为每个事务触发，这可能会减慢事务工作负载。
数据工程师必须编写额外的复杂回滚逻辑来处理事务失败的情况。
如果修改了表架构，则必须使用最新的架构更改手动更新触发器。
不同数据库系统之间的 SQL 语言差异意味着触发器不易移植，可能需要重写。

基于日志

此实现直接从数据库日志和日记文件读取数据，以最大限度地减少捕获过程的影响。由于每个事务数据库产品中都存在数据库日志和日记文件，因此体验是透明的。这意味着它不需要在数据库对象或在数据库之上运行的应用程序方面进行任何逻辑更改。

挑战:

如果目标数据库系统关闭，则需要保持源数据库系统日志完整，直到同步发生。
绕过日志文件的数据库操作将不会被捕获。对于大多数关系数据库用例来说，这是一个极端情况，因为日志是保证 ACID 行为所必需的。
- 例如，TRUNCATE 表语句可能不会记录数据，在这种情况下，可能需要通过查询提示或配置强制记录日志。

当涉及到生产数据库时，选择是明确的：基于日志的 CDC 是前进的方向，因为它具有可靠性、在大数据量下扩展的能力以及易用性，而无需任何数据库或应用程序更改。