Kafka Connect JDBC与Debezium CDC
JDBC连接器和Debezium SQL Server CDC连接器（或任何其他关系数据库连接器）之间有什么区别？何时应该选择一个
，寻找一种在两个关系数据库之间进行同步的解决方案？
不确定此讨论是否应该针对CDC与JDBC连接器，而不是
Debezium SQL Server CDC连接器，甚至不是Debezium，期待
以后进行编辑，取决于给出的答案（尽管我的情况是关于SQL
Server接收器）。
回答：
Debezium仅用作源连接器，记录所有行级更改。
Debezium文档说：
Debezium是一组分布式服务，用于捕获
数据库中的更改，以便您的应用程序可以查看这些更改并对
它们做出响应。Debezium将每个数据库表中的所有行级更改记录在
更改事件流中，应用程序只需读取这些流即可以发生
更改的顺序查看更改事件。
用于SQL Server的Debezium Connector首先记录数据库的快照，然后将行级更改的记录发送到Kafka，每个表发送到不同的Kafka主题。
用于SQL Server文档的Debezium连接器说：
Debezium的SQL Server连接器可以监视和记录SQL Server数据库架构中的行级更改。
第一次连接到SQL Server数据库/群集时，它将读取所有架构的一致快照。该快照完成后，连接器将继续流式传输提交到SQLServer的更改，并生成相应的插入，更新和删除事件。每个表的所有事件都记录在一个单独的Kafka主题中，应用程序和服务可以轻松使用它们。
Kafka Connect JDBC
Kafka Connect JDBC可用作Kafka的源连接器或接收器连接器
，支持任何带有JDBC驱动程序的数据库。
JDBC连接器文档说：
您可以使用Kafka Connect JDBC源连接器
通过JDBC驱动程序将任何关系数据库中的数据导入ApacheKafka®主题。您可以
使用JDBC接收器连接器
，通过JDBC驱动程序将数据从Kafka主题导出到任何关系数据库。JDBC连接器支持
各种各样的数据库，而每个数据库都不需要自定义代码。
他们有一些有关在Microsoft SQL
Server上安装的规范，我发现与本次
讨论无关。
因此，如果JDBC连接器同时支持源和接收器，而Debezium仅支持
源（不提供接收器），我们可以理解，为了
使用JDBC驱动程序（接收器）将数据从Kafka写入数据库，使用JDBC连接器是可行的
（包括SQL）服务器）。
现在，应仅将比较范围缩小到“源”字段。
乍看之下，JDBC Source Connector
文档还不多说
：
通过定期执行SQL查询并
为结果集中的每一行创建输出记录来加载数据。默认情况下，数据库
中的所有表都被复制，每个表都复制到其自己的输出主题。监视数据库中的新
表或删除表，并自动进行调整。从表中复制数据时，
连接器可以通过指定
应使用哪些列来检测新数据或修改后的数据来仅加载新行或修改后的行。
为了进一步了解它们之间的差异，在这个
Debezium博客中，该博客使用Debezium MySQL Connector作为源，并使用JDBC Connector
作为接收器，其中有关于两者之间差异的解释，
通常告诉我们Debezium提供了以下记录：
有关数据库更改的更多信息，而JDBC连接器提供的记录
更侧重于将数据库更改转换为简单的
插入/更新命令：
Debezium MySQL连接器旨在专门捕获数据库
更改，并提供
除每一行的新状态之外的有关这些事件的尽可能多的信息。同时，Confluent JDBC Sink
连接器旨在根据消息
的结构将每个消息简单地转换为数据库插入/向上插入。因此，两个
连接器的消息结构不同，但是它们还使用
不同的主题命名约定和代表已删除
记录的行为。
此外，它们具有不同的主题命名和不同的删除方法：
Debezium对代表
其管理的每个表的目标主题使用完全限定的命名。命名遵循模式[逻辑名称]。[数据库
名称]。[表名称]。Kafka Connect JDBC连接器使用简单名称
[table-name]。
…
当Debezium连接器检测到行被删除时，它将创建两个事件
消息：一个delete事件和一个逻辑删除消息。删除消息
在前字段中包含一个信封，其中包含已删除行的状态，在后
字段中为空。逻辑删除消息包含与删除
消息相同的密钥，但是整个消息值均为空，并且Kafka日志压缩
利用该消息知道可以使用相同的
密钥删除任何较早的消息。许多接收
器连接器，包括Confluent的JDBC Sink连接器，都不希望收到这些消息，如果
看到任何一种消息，它们都将失败。
这个Confluent博客详细解释了CDC和
JDBC连接器的工作方式，它（JDBC连接器）
每隔固定的时间间隔执行一次对源数据库的查询，这不是一个可扩展的解决方案，而CDC的
频率更高，从数据库事务日志流式传输：
连接器通过在JDBC上对源
数据库执行查询来工作。这样做是为了拉入所有行（批量）或
自上次以来已更改的行（增量）。该查询
以poll.interval.ms中定义的间隔执行。根据所涉及的数据量，
物理数据库设计（索引等）以及
数据库上的其他工作负载，这可能不是最可扩展的选择。
…
正确完成后，CDC基本上可以使您将每个事件从
数据库流式传输到Kafka。概括地说，关系数据库使用事务日志
（根据DB的风格也称为binlog或重做日志），
数据库中的每个事件都写入该日志中。更新一行，插入一行，删除一行-
所有这些都进入数据库的事务日志。CDC工具通常
通过利用此事务日志以极低的延迟和低
影响来提取数据库（或其中的架构/表
）中发生的事件来工作。
该博客还陈述了CDC和JDBC连接器之间的区别，主要是
说JDBC连接器不支持同步已删除的记录，因此适合
原型制作，而CDC适合更成熟的系统：
JDBC连接器无法获取已删除的行。因为，您如何查询
不存在的数据？
…
我对CDC与JDBC的一般指导是JDBC非常适合用于原型设计和
精细的小批量工作负载。使用JDBC连接器时要考虑的事项：
不会提供真正的CDC（捕获删除记录，需要记录
版本之前/之后的延迟）检测新事件的延迟
持续轮询源数据库的影响（并将其与所需的延迟进行平衡），除非
您从表中，您需要具有
可用于发现新记录的ID和/或时间戳。如果您不拥有该架构，
这将成为一个问题。
tl; dr结论
Debezium和JDBC连接器之间的主要区别是：
Debezium仅用作Kafka源，而JDBC Connector可用作Kafka源和接收器。
对于来源：
JDBC连接器不支持同步已删除的记录，而Debezium支持。
JDBC连接器每隔固定的时间间隔查询数据库，这不是一个非常可扩展的解决方案，而CDC从数据库事务日志中流式传输的频率更高。
Debezium为记录提供了有关数据库更改的更多信息，而JDBC连接器提供的记录更侧重于将数据库更改转换为简单的插入/更新命令。
不同的主题命名。
以上是 Kafka Connect JDBC与Debezium CDC 的全部内容， 来源链接： utcz.com/qa/408830.html
