推荐：使用NSDT场景编辑器助你快速搭建可编辑的3D应用场景

在本文中，我将定义 CDC 数据复制，简要讨论最常见的用例，然后讨论常见技术及其权衡。最后，我将提供一些我作为数据集成公司Dataddo的首席执行官和创始人所学到的一般实现见解。

CDC 数据复制是一种在两个数据库之间实时或近乎实时地复制数据的方法，其中仅复制新添加或修改的数据。

它是快照复制的替代方法，快照复制涉及一次又一次地将一个数据库的整个快照移动到另一个数据库。快照复制可能适用于需要随着时间的推移保留其数据的单个快照的组织，但它非常占用大量处理，并且会留下很大的财务足迹。对于不需要这样做的组织，CDC可以节省大量付费处理时间。

可以实时或小批量（例如每小时）捕获数据更改并将其传送到新目的地。

此图说明了基于日志的 CDC，其中红色行是新添加的数据。

值得一提的是，CDC并不是一个新过程。然而，直到最近，只有大型组织才有工程资源来实施它。新的是越来越多的托管工具选择，使其成本低廉，因此它新近受欢迎。

本文没有足够的篇幅来涵盖 CDC 数据复制的所有用例，但以下是最常见的三个用例。

任何运行专有数据收集系统的组织都可能拥有一个生产数据库，用于存储来自此系统的关键信息。

由于生产数据库是为写入操作而设计的，因此它们在将数据投入盈利用途方面没有多大作用。因此，许多组织希望将数据复制到数据仓库中，在那里他们可以运行复杂的读取操作以进行分析和商业智能。

如果您的分析团队需要近乎实时的数据，CDC 是向他们提供数据的好方法，因为它会在更改时快速将更改交付到分析仓库。

当您从一种数据库技术迁移到另一种数据库技术时，CDC 也很有用，并且您需要在停机时保持所有内容可用。一个典型的例子是从本地数据库迁移到云数据库。

与迁移案例类似，CDC 是一种高效且可能具有成本效益的方法，可确保在其中一个物理位置停机时，您的所有数据始终在多个物理位置可用。

CDC有三种主要的技术，每种技术都有自己的优点和缺点。

CDC 实施涉及灵活性、保真度、延迟、维护和安全性之间的权衡。

基于查询的CDC非常简单。使用此技术所做的只是编写一个简单的选择查询以从特定表中选择数据，然后是一些条件，例如“仅选择昨天更新或添加的数据”。假设您已经配置了辅助表的架构，则这些查询将获取此更改的数据，并生成包含该数据的新二维表，该表可以插入到新位置。

• 高度灵活。允许您定义要捕获的更改以及如何捕获这些更改。这样可以更轻松地以非常精细的方式自定义复制过程。

• 减少开销。仅捕获满足特定条件的更改，因此它比捕获数据库所有更改的 CDC 便宜得多。

• 更易于故障排除。如果出现任何问题，可以轻松检查和纠正单个查询。

• 复杂的维护。必须维护每个单独的查询。例如，如果您的数据库中有几百个表，您可能还需要这么多查询，而维护所有这些查询将是一场噩梦。这是主要缺点。

• 更高的延迟。依赖于轮询更改，这可能会在复制过程中引入延迟。这意味着您无法使用选择查询实现实时复制，并且需要计划某种批处理。如果您需要使用较长的时间序列（例如客户行为）分析某些内容，这可能不是什么大问题。

我们目前使用的大多数数据库技术都支持集群，这意味着您可以在多个副本中运行它们以实现高可用性。此类技术必须具有某种二进制日志，该日志捕获对数据库的所有更改。在基于日志的 CDC 中，更改是从日志而不是数据库本身读取的，然后复制到目标系统。

• 低延迟。数据更改可以非常快速地复制到下游系统。

• 高保真度。日志捕获对数据库的所有更改，包括数据定义语言 （DDL） 更改和数据操作语言 （DML） 更改。这使得跟踪已删除的行成为可能（这在基于查询的 CDC 中是不可能的）。

• 更高的安全风险。需要直接访问数据库事务日志。这可能会引起安全问题，因为它需要广泛的访问级别。

• 灵活性有限。捕获对数据库的所有更改，这限制了定义更改和自定义复制过程的灵活性。在自定义要求很高的情况下，必须对日志进行大量后处理。

通常，基于日志的 CDC 很难实现。有关详细信息，请参阅下面的“见解”部分。

基于触发器的CDC是前两种技术之间的混合。它涉及定义用于捕获表中某些更改的触发器，然后将其插入到新表中并在新表中进行跟踪。正是从这个新表中将更改复制到目标系统。

• 灵活性。允许您定义要捕获的更改以及如何捕获这些更改（如在基于查询的 CDC 中），包括已删除的行（如在基于日志的 CDC 中）。

• 低延迟。每次触发触发器时，它都算作一个事件，并且可以实时或近乎实时地处理事件。

• 极其复杂的维护。就像基于查询的 CDC 中的查询一样，所有触发器都需要单独维护。因此，如果您有一个包含 200 个表的数据库，并且需要捕获所有表的更改，则总体维护成本将非常高。

作为一家数据集成公司的首席执行官，我在实施 CDC 方面拥有丰富的经验。以下是我在此过程中学到的一些东西。

基于日志的 CDC 特别复杂。这是因为所有日志——例如 MySQL 的 BinLog、Postgres 的 WAL 、Oracle 的 Redo Log、Mongo DB 的 Oplog——虽然在概念上相同，但实现方式不同。因此，您需要深入研究所选数据库的低级参数才能使事情正常工作。

您需要确定如何在目标目标中准确插入、更新和删除数据。

一般来说，插入很容易，但音量在口述方法中起着重要作用。无论您是使用批量插入、数据流还是决定使用文件加载更改，您都将始终面临技术权衡。

为了确保正确更新并避免不必要的重复，您需要在表顶部定义一个虚拟键，该键告诉您的系统应该插入什么以及应该更新什么。

为了确保正确删除，您需要有一些故障保护机制，以确保错误的实现不会导致删除目标表中的所有数据。

如果您只传输几行，事情会很容易，但如果是这种情况，那么您可能不需要CDC。因此，一般来说，我们可以预期CDC的工作需要几分钟甚至几小时，这将需要可靠的监测和维护机制。

这可能是一篇单独文章的主题。??但是，简而言之，我可以说每种技术都有不同的方法来引发异常和呈现错误。因此，您应该定义一个策略，以便在连接失败时执行的操作。是否应该重试？您应该封装事务中的所有内容吗？

在内部实施 CDC 数据复制非常复杂，并且非常特定于案例。这就是为什么它传统上不是一种流行的复制解决方案，也是为什么很难就如何实现它提供一般建议的原因。近年来，Dataddo、Informatica、SAP Replication Server 等托管工具显著降低了可访问性的门槛。

正如我在本文开头提到的，CDC有可能为公司节省大量财务资源：

• 其主数据库主要由不经常更改的数据组成（即每日更改仅占其中数据的相对一小部分）

• 谁的分析团队需要近乎实时的数据

• 不需要随着时间的推移保留其主数据库的完整快照

然而，没有完美的技术解决方案，只有权衡。这同样适用于 CDC 数据复制。那些选择实施CDC的人将不得不不平等地优先考虑灵活性，保真度，延迟，维护和安全性。

原文链接：CDC 数据复制：技术、权衡、见解 (mvrlink.com)

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。