网站建设的难处,网站建设个人网银,h5响应式网站是什么,wordpress分享微信插件下载从广泛意义上说#xff0c;全球许多企业每天都需要通过频繁的数据批量处理与加载#xff0c;来定期将数据从一个数据库迁移到另一个数据库(或数据仓库)。这类定期批量加载的工作#xff0c;往往既耗费时间#xff0c;又会消耗原始系统的大量处理能力。因此#xff0c;管理…从广泛意义上说全球许多企业每天都需要通过频繁的数据批量处理与加载来定期将数据从一个数据库迁移到另一个数据库(或数据仓库)。这类定期批量加载的工作往往既耗费时间又会消耗原始系统的大量处理能力。因此管理员只能在业务运行的间歇期间运行数据的批量传输与复制作业否则会产生严重的效率影响。而显然这与24x7的不间断业务需求是背道而驰的。
近年来变更数据捕获(Change Data CaptureCDC)已成为了在高速数据流通环境中各种关系型数据库、云端数据库、以及数据仓库之间进行低延迟、高可靠性且可扩展式数据复制的理想化解决方案。
什么是变更数据捕获?
CDC是指从源数据库捕获到数据和数据结构(也称为模式)的增量变更近乎实时地将这些变更传播到其他数据库或应用程序之处。通过这种方式CDC能够向数据仓库提供高效、低延迟的数据传输以便信息被及时转换并交付给专供分析的应用程序。
在数据不断变化且无法中断与在线数据库连接的情况下对于各种时间敏感(time-sensitive)类信息的复制往往也是云端迁移的重要组成部分。与批量复制相比变更数据的捕获通常具有如下三项基本优势
CDC通过仅发送增量的变更来降低通过网络传输数据的成本。CDC可以帮助用户根据最新的数据做出更快、更准确的决策。例如CDC会将事务直接传输到专供分析的应用上。CDC最大限度地减少了对于生产环境网络流量的干扰。
变更数据捕获的方法
目前业界有多种CDC方法可用于跟踪和传输变更的数据您可以根据应用程序的实际要求及其对于性能下降的容忍度从中进行选取。下面我将向您介绍四种不同的CDC方法所涉及到的技术、工作原理、以及它们各自的优缺点。
时间戳或版本号跟踪Delete 操作不友好
数据库设计者可以在需要跟踪的数据表中设定某一列来代表最后被修改的时间戳或版本号。例如我们通常可以将这些列命名为LAST_UPDATE、DATE_MODIFIED、以及VERSION_NUMBER等。那些在上一次数据捕获之后增加了时间戳的任何行都将被视为发生了修改。而在基于版本号的跟踪方法中变更一旦发生所有具有最新版本号的数据都被视为发生了修改。
在实际应用中您可以结合版本和时间戳两个维度来跟踪数据库表中的数据。例如您可以设定一条逻辑--“捕获自2021年6月22日以来相对于3.4版发生了变更的所有数据”。
优点
简单易懂。数据库设计者可以自定义应用程序的逻辑构建。不需要任何外部的工具。
缺点
给数据库增加了额外的开销。需要额外的CPU资源来扫描表中的数据变更并需要预留资源以确保 LAST_UPDATE列能够可靠地追踪所有资源表。被删除的行不会存在于LAST_UPDATE中。如果没有其他脚本来跟踪此类删除的话DML语句(例如“DELETE”)将不会被传递到目标数据库处。容易出错并可能导致数据出现一致性问题。
表的差异与增量大数据量不友好
这种CDC方法使用诸如表增量(table delta)之类的实用程序或tablediff去比较两个表中的数据以发现不匹配的行。据此您可以使用其他的脚本将源表的差异同步到目标表上。
虽然该方法在管理已删除行的方面比时间戳CDC的效果更好但是它在发现差异时所需要的CPU资源较为显著。而且此类开销会随着数据数量的增加而呈线性增加。此外针对源数据库或生产环境的分析查询也可能会降低应用本身的性能。对此您可以定期将数据库导出至暂存环境中进行比较。不过随着数据量的增加此类传输的成本也会呈指数级增长。
表差异的另一个问题是它无法捕获数据的临时性变更。例如假设有人更新了某个字段但随后又将其变更回了原始值。那么如果您只是运行一个简单比较的话将无法捕获到这个变更事件。而由于diff方法本身存在着延迟因此也无法实时执行。
优点
可使用各种原生的SQL脚本来获取变更数据的准确视图。
缺点
由于此方法会用到数据源的三个副本原始数据、先前快照和当前快照因此整体存储需求会有所增加。在那些具有繁重事务负载的应用程序中无法得到很好的扩展。注意表差异和时间戳CDC方法都不适用于真实的生产环境。因此对于大型数据集我建议您使用如下两种CDC方法。其实基于触发器和事务日志的变更数据跟踪方法只是出于相同目的的两种不同的服务方式。 基于触发器的CDC增加了触发器的开销 我们需要为参与数据复制的每个表创建三个触发器当数据记录发生如下特定事件时则会触发相应的操作
将新的记录插入数据表时触发的是INSERT触发器。数据记录发生变更时触发的是UPDATE触发器。数据记录被删除时触发的是DELETE触发器。
“事件历史”的影子表被存储在数据库本身并由各种状态改变事件的序列所组成。每当对象的状态发生变化时新的事件都会被附加到该序列中。据此有关变更记录的信息也会被转移到“事件历史”的影子表中。最后根据历史表中的各个事件变更会被传输到目标数据库中。
下面展示了一个简单的历史表 由于源数据库中的每个表都需要一个触发器因此在有变更发生时在操作表上运行触发器的开销也会随之增加。不过由于基于触发器的CDC是工作在SQL级别上的因此许多用户会趋向于使用该方法。
优点
非常可靠且详尽。影子表可以提供所有事务的不可变详细日志。
缺点
每次插入、更新或删除数据行时都需要对数据库进行多次写入此举降低了数据库的性能。
DBA和数据工程师应当持续关注并测试那些被添加到生产环境中的各种触发器的性能进而决定是否可以容忍此类额外产生的开销。 事务日志CDC 日志文件读取不友好 众所周知数据库虽然主要会将事务日志用于备份和恢复目的但它们也可被用于将变更复制到目标数据库或数据湖中。而在基于事务日志的CDC系统中数据流不会被持久性存储。它们会使用Kafka去捕获变更并将变更推送到目标数据库中。
可见基于事务日志的CDC和基于触发器的CDC之间的主要区别在于每个变更都将进入由数据库引擎所生成的事务日志中。也就是说数据库引擎会使用本机事务日志(也称为重做日志)来存储所有数据库的事件以便在发生故障时可以恢复数据库。它们无需执行任何应用程序级别的变更或扫描影子表。因此与基于触发器的CDC相比从事务日志中恢复数据虽然更为复杂但是会更加可行。
优点
由于每个事务都不需要额外的查询因此它对生产环境中的数据库系统的影响最小。无需变更生产环境中数据库系统的架构或添加额外的数据表。
缺点
由于大多数数据库并不记录它们的事务日志格式也不会在新的版本中公布对其实施的变更因此DBA解析数据库的内部日志格式会较为困难。DBA有时需要在数据库的每个新版本中去解析变更数据库的日志逻辑。由于日志文件通常会被数据库引擎予以归档因此CDC软件必须在此之前读取日志或者能够读取已归档的日志。创建可扫描的事务日志所需要的额外日志级别可能会增加少量的性能开销。当CDC应用程序发送数据时目标数据库可能会意外地变得不可访问。它们必须缓冲未发送的数据直到目标数据库重新联机上线。当然如果未能完成该步骤则可能导致数据的丢失或重复。同样如果源与目标之间的传输连接出现中断系统也可能会发生故障进而导致数据的丢失、记录的重复、以及需要从初始数据处重新启动加载。
基于触发器与事务日志的比较
总的说来基于触发器的CDC和事务日志CDC都是可用于构建反应式分布式系统的数据库设计模型。其中基于触发器的CDC使用自己的事件日志作为真实的数据来源而事务日志CDC则依赖底层数据库的事务日志作为真实来源。
触发器可作为每个数据库事务的一部分以捕获实时发生的事件。对于每次插入、更新或删除都会由某个触发器去触发记录的变更。另一方面事务日志CDC则可以独立于事务运行。它使用重做日志文件来记录的变更。由于CDC操作在发生时不会直接与数据库中的每个事务相关联因此其性能会有所提升。
在实际应用中各种常见的DBSync产品和DBConvert Studio都会使用基于触发器的数据库同步CDC方法。不过对于集群数据库而言基于触发器的方法可能会比使用MySQL的二进制日志、或PostgreSQL的事务日志要相差许多。毕竟MySQL在其官网上已声称“在启用二进制日志的情况下服务器的运行性能可能会被略微拖慢。但是二进制日志在方便复制与恢复操作等方面的好处通常超过性能上的微降。”(https://dev.mysql.com/doc/refman/8.0/en/binary-log.html)
小结
综上所述CDC是现代数据架构的重要组成部分可被用于将事务数据从源系统传输到数据流中。我们需要它支持实时的事务数据且不会对源系统造成重大的负载。它既不需要改变源应用程序又要保证仅传输最少量的数据。因此CDC更适合大体量的数据集。将来我们会在那些强调数据分析和历史数据比较的企业级数据仓库中看到CDC的广泛使用。 参考
CDC是个啥它是如何工作的-51CTO.COM
