在数据爆发式增长的时代,记录数据变化和演变,探究内在规律并运用到生产实践中,驱动业务的增长成为这个时代主旋律。本文就如何记录数据变化,处理数据变化谈谈自己的理解
所要更改的属性,始终保持最新值,即覆盖重写,但是该技术破坏了历史情况。需要借助其他的方式才能进行处理,这点我们在本文下面会讲到。
当发生属性的变化时候,不修改原来的行,而是增加新的记录行。所以原先表的设计时候,主键更加需要具备一般意义的类型,因为会出现多行共同描述一个对象,共同描述一个对象的相同成员(属性)。采用这种方式最少需要三个额外的列:行有效的时间戳,行失效的时间戳,当前行的标识。
对原先修改的值,不变。对新变化的值,采用新增一列,来记录。这种运用场合有限,eg,freeschema类型的数据库,且变化频度有限且低的场合。
增加新的表,用来记录变化。这种一般用在源表数据量大,且属性变化较快的表,新表要维护一个属性和源表的映射。优点是对源表无侵入性修改,对写是友好的。而查询需要连表查询,会有一定的影响
### 1.5. 增加新表,同时对源表进行重写
增加新的表,用来记录变化,同时对原表的需要修改的记录进行重写,即新表纯粹就是用来记录变化的历史,优点是对源表查询是只需要查询源表,写入速度会有一定影响
在变化数据的存储
一节中,我们谈到了对变化数据存储。从方式2-5都可以对历史进行捕获。如果一个系统对原先变化数据有处理需求,在系统设计之初可以参考上面的方式。从源头开始设计会对后面的数据处理带来极大便利。如果是现有系统,且设计之初没有考虑对变化数据的处理。可以借助下面几种方式。
在1.1的基础之上,增加一个行变化的有效标记位。让下游系统可以进行捕获。优点需要修改的地方较为简单:1.对数据库物理设计调整,2.现有应用系统的业务逻辑进行简单调整
update source_table
set update_col=col_value,valid=1
where pk_col=pk_col_value
需要考虑的地方:
方式1:ORACLE作为一个商用数据提供了,完整系统描述的元数据。通过读取元数据表来记录来查询所有的更改的操作。通过下面的语句
-- SQL_FULLTEXT操作的sql语句
-- COMMAND_TYPE 命令类型,2-insert,6-update,7-delete
-- ROWS_PROCESSED 影响的行数
-- last_load_time 最近一次执行的时间
-- first_load_time 第一次执行的时间
select SQL_FULLTEXT,DISK_READS,BUFFER_GETS,ROWS_PROCESSED,COMMAND_TYPE,CPU_TIME,USER_IO_WAIT_TIME,
PHYSICAL_READ_REQUESTS,PHYSICAL_READ_BYTES,last_load_time from V$SQL
Where SQL_FULLTEXT like '%TBL_TEST%' and COMMAND_TYPE in(2,6,7)and ROWS_PROCESSED>0
方式2:利用表的触发器,通过每次写且触发触发器的动作完成更新动作的识别和解析。现有开源框架-databus,oracle的解析原理就是采用这种方式
sqlserver也有类似的表结构sys.dm_exec_sql_text
oracle方式1,sqlserver的方式,利用这些方式的优点,1.完全重用现有技术,利用jdbc,select查询操作,就可以找到所有修改。2.保证库内扩展性同时,不对系统现有设计产生影响。因为对所有的表更新操作,都在v$sql中都可以找到,不需在接入数据时,对单个表进行重新设计和业务处理,所有更新查询都使用一套sql。缺点:1.需要不断轮训v$sql ,延迟在秒,分钟级别。看系统设置。2. 需要v$sql的权限,一般是管理员权限。
oracle 方式2的缺点,触发器使用会增加系统的开销,影响系统的吞吐量,特别是在频繁的更新(update,insert,delete)情况。触发器使用需要对表做谨慎评估
借助binlog的明文日志,需要设置下面俩个选项
set binlog_rows_query_log_events=1
set binlog_format=ROW
在my.cnf中配置
log-bin=binlog的目录和binlog文件前缀
所有更新的操作都会明文打印到log-bin设置的文件下。借助kafka connector-filesystem source 将binlog明文sql传输到kafka中。
通过对数据库日志的挖掘,完成解析,现有的开源框架OpenReplicator,databus,mysql的解析就是借助OpenReplicator,完成对binlog的解析。
上述俩种方式的共同优点,只需要要开启binlog打印,对系统负担小,下游程序不会对现有系统产生冲击此外,使用简单型日志,还有解析明文sql,由于采用sql的通用标准,解析程序具有较好的通用性,对于后期维护负担小,而复杂解析型SQL,随着软件版本的升级binlog的解析也需要不断升级,后续维护成本较高
在变化数据的捕获
一节中,我们对事前没有考虑存储历史变更的情况,如何捕获变化数据做了分享。综合上面几种方式的优缺点,
小结:采用这种方案主要是基于以下几点考虑:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。