精华内容
参与话题
问答
  • 数据同步-全量和增量

    千次阅读 2018-12-26 11:36:27
    因为公司的需求人员说的含糊其词的,原先我以为是关于本身业务的,但是 昨天赶上当当的满100-50我在挑书看到了... 数据同步一般分为两种方式:全量和增量。 1.1 全量 全量,这个很好理解。就是每天定时(避开...

    因为公司的需求人员说的含糊其词的,原先我以为是关于本身业务的,但是 昨天赶上当当的满100-50我在挑书看到了技术书里面有一章是介绍的是数据同步这个概念,于是上网搜关于这种的资料。

    参考https://www.cnblogs.com/big1987/p/8522884.html

    1.同步方式

     数据同步一般分为两种方式:全量和增量。

    1.1  全量

    全量,这个很好理解。就是每天定时(避开业务高峰期)或者周期性全量把数据从一个地方拷贝到另外一个地方;

    全量的话,可以采用直接全部覆盖(使用“新”数据覆盖“旧”数据);或者走更新逻辑(覆盖前判断下,如果新旧不一致,就更新);

     

    1.2 增量

    增量的基础是全量,就是你要使用某种方式先把全量数据拷贝过来,然后再采用增量方式同步更新。

     

    展开全文
  • 遇到的需求:两个服务器上的两个不同类型的数据库,分别是源pg库--&...全量同步使用的java的定时任务,多线程的方式进行同步,发现某一天同步任务执行不完的情况,修改为增量同步方案。 增量同步要求...

    遇到的需求:两个服务器上的两个不同类型的数据库,分别是源pg库-->目标库的MySQL

    数据量:4亿条数据。

    同步方案:同步每日新增和修改,删除的数据条。

    由于之前同步是全量同步,每天都需要定时全量同步,不仅时间消耗长,也影响下游业务(查询慢,有时还会锁表)。全量同步使用的java的定时任务,多线程的方式进行同步,发现某一天同步任务执行不完的情况,修改为增量同步方案。

    • 增量同步要求:
    1. 有一个每天同步的执行时间点 - >截取点(每天都是从这个最新截取点开始同步)我取的是非空字段(更新时间UPDATE_DATE),因为新增和修改都会自动更新这个时间点,可以确保大于上一个截取点的数据是没有同步的(包含新增和修改数据)。
    2. 删除的数据(分为两种):逻辑删除和物理删除其中逻辑删除可以使用最新截取点开始查询出标志出删除行的唯一ID;物理删除需要在源库上做一个触发器,删除的数据存到另个表中,在同步这个表即可。

    这种增量设计涉及到的表结构:

    1. pg库
      1. test----要同步的业务表
      2. test_del---物理删除记录表
      3. min_updatedate--同步结束的最大时间
      4. max_updatedate--同步的最大时间(取得是任务开始时的时间,后期排查问题使用,此表可用可不用,)
    2. mysql
      1. test
      2. test_del
      3. min_updatedate

    任务顺序:

    1. 第一个任务:同步min_updatedate(需要有一个默认的一条记录)。mysql --> pg库
    2. 第二个任务:首先以当前pg 库 当前时间点 ,插入一条记录 ; 同步业务表;   where  update_date> min_updatedate  and  update_date<max_updatedate   (由于使用了多线程的方式,中间可以把时间分成多个时间片段,可以减少单线程拉去的数据量过大,出现服务oo;虽然这样也会出现某个时间段出现大量数据(思路有限))。同步完数据,需要在mysql 数据库 min_updatedate 表中 插入一条业务表中最大更新时间记录(select max(update_date) from test )。

     

     

     

    展开全文
  • 最近在工作中遇到一个比较棘手的问题,客户端从服务端同步数据的问题。 背景简介:客户端有N个,客户端上的同步时间,各不相同。同步的时候,是一次获取10条数据,多批次获取。即分页获取。 在代码中存在两种同步的...

    由于markdown的样式太丑了,懒得再调整了,我另外再贴一个github的博客该文的 github链接

    前言

    最近在工作中遇到一个比较棘手的问题,客户端从服务端同步数据的问题。
    背景简介:客户端有N个,客户端上的同步时间,各不相同。同步的时候,是一次获取10条数据,多批次获取。即分页获取。
    在代码中存在两种同步的方式:

    1. 全量同步。同步过程是从服务端拉取全部的数据;依赖具有唯一约束ID来实现同步。只适用于数据量小的表,浪费网络流量。
    2. 增量同步。从服务器拉取大于客户端最新时间的数据;依赖于时间戳,问题时间戳不唯一存在相同时间点下面多条数据,会出现数据遗漏,也会重复拉取数据,浪费网络流量。

    本文的所使用到的解决办法,就是结合了唯一ID时间戳,两个入参来做增量同步。本文也只做逻辑层面的说明。

    模拟场景

    表结构:ID 具有唯一约束, Name 姓名, UpdateTime 更新时间;现在问题的关键是ID为3,4,这两条时间点相同的数据。
    假如一次只能同步一条数据,如何同步完ID 2后,再同步 ID 3。

    ID Name UpdateTime
    1 张三 2018-11-10
    2 李四 2018-12-10
    3 王五 2018-12-10
    4 赵六 2018-11-20
    5 金七 2018-11-30

    解决思路

    生成新的唯一标识

    通过 UpdateTime 和 ID 这两种数据,通过某种运算,生成新的数。而这个新的数具备可排序唯一;同时还要携带有IDUpdateTime的信息。
    简单表述就是,具有一个函数f: f(可排序A,可排序唯一B) = 可排序唯一C 。 C 的唯一解是 A和B。RSA加密算法

    我想出了一个方法,也是生活中比较常用的方法:

    1. 先把 UpdateTime 转变成数字。如: 字符串 2018-12-10 -> 数字 20181210;
    2. 然后 UpdateTime 乘以权重,这个权重必须大于ID的可能最大值。如: 20181210 * 100 = 2018121000,Max(ID)<999
    3. 然后再把第二部的结果,加上唯一键ID。如: 2018121000 + 3 = 2018121003。

    这个时候,2018121003 这个数,既包含了UpdateTimeID的信息,又具有可排序唯一性。用它作为增量更新的判断点,是再好不过的了。
    但是它具有很大的缺点:数字太大了,时间转化成数字,目前还是用的是级别,如果换成毫秒级别呢。还有ID可能的最大值也够大了,如果是int64那就更没得搞了。

    这个方法理论上可行,实际中不可用基本不可行,除非找到一种非常好的函数f;
    PS: 我的直觉告诉我: 极可能存在这种函数,既满足我的需要,又可以克服数字很大这个问题。只是我目前不知道。

    数据库表修改(不推荐)

    修改数据内容

    修改数据内容,使 UpdateTime 数据值唯一。缺点也比较明显:

    1. 脚本操作数据的情况下,或者直接sql更新。可能会,造成时间不唯一;
    2. 只是适用在数据量小,系统操作频率小的情况下。因为毫秒级别的时间,在绝大多数软件系统中,可以认为是唯一;
    3. 尤其是老旧项目,历史遗留数据如何处理。

    增加字段

    还有一种办法,就是在数据库中,增加一个新的字段,专门用来同步数据的时候使用。
    比方说,增加字段 SyncData int 类型。如果 UpdateTime 发生了改变,就把它更新为 SyncData = Max(SyncData) + 1;
    也就是说, SyncData 这个字段的最大值一定是最新的数据,SyncData的降序就是 更新时间的降序。SyncData更新时间顺序充分不必要条件

    总的来说,这种办法是比较好的,但缺点也比较明显:

    1. 需要修改表结构,并且额外维护这个字段;
    2. 新增或者更新的时候,会先锁表,找出这个表的最大值,再更新,资源浪费明显。
    3. 如果表的数据量比较大,或者更新比较频繁时候。时间消耗较大。

    我的解决方法

    分页提取数据的可能情况

    首先,先来分析一下,一次提取10条数据,提取的数据,存在的可能情况。再次说明前提,先时间倒序,再ID倒序。Order By UpdateTime DESC, ID DESC
    可能情况如下图,可以简化为三种:

    1. 情景1。当前获取的数据中包含了,所有相同时间点的数据;图1,图5
    2. 情景2。当前获取的数据中包含了,部分相同时间点的数据;图2,图3,图4,图6,图7
    3. 情景3。当前获取的数据中包含了,没有相同时间点的数据;图···

    其中情景1情景3,可以把查询条件变为:WHERE UpdateTime > sync_time LIMIT 10
    但是情景2的情况不能使用大于>这个条件。假如使用了大于>这个条件,情景2就会变成情景1情景3图3这种情况。不是包含部分了,需要额外特别处理。
    注:图3的结束点 ]不重要,下面情景5有解释。
    同步数据的可能性

    情景2部分情况,提取的起始点

    提取的起始点:也就是说图中[左中括号的位置,需要准确定位这个位置。
    至于结束点:图中]右中括号的位置是在哪里。这个就不重要了,因为下一次的分页提取的起始点,就是上一次的结束点。只需要关注起始点就足够了。

    而根据起始点,又可以把情景2,再做一次简化:

    1. 情景4。起始点相同时间点集合内的;图2,图4,图6,图7
    2. 情景5。起始点不在相同时间点集合内的;图3,

    针对情景4。这个时候,时间戳sync_time一个入参就不够了,还额外需要唯一键ID来准确定位。可以把查询写作:WHERE UpdateTime = sync_time AND ID > sync_id LIMIT 10
    如果查询的行数 等于 10,则是图4;小于 10,则是图2,图6,图7的情况。

    针对情景5。依旧可以使用:WHERE UpdateTime > sync_time LIMIT 10

    完整的分页过程

    完整的分页过程的步骤:
    一、先用起始点来过滤:WHERE UpdateTime = sync_time AND ID > sync_id LIMIT 10,查询结果行数N。如果 N=10图4的情况,则结束,并且直接返回结果。如果 0<= N <10 ,则进行第二步,其中N=0图1图3图5图···的情况;

    二、再用时间戳查询:WHERE UpdateTime > sync_time LIMIT 10-N,查询结果行数 M ,0<= M <=10-N;这个阶段,是否同一个时间点都不重要了。只需要按着顺序已排序的数据就可以了;

    三、把一和二的结果集合并,一并返回。

    四、重复步骤一二三,直到,分页获取的最后一条数据的ID,是服务端数据库中最新的ID;(防止存在,恰好这十条是所需要获取的最后十条)。

    服务端中最新ID获取:Select Id From myTable Order by UpdateTime desc,ID desc Limit 1;

    经验总结

    寻找关键信息,以及具有指标意义的数据,或者数据的组合

    • 最开始,我只执着于 UpdateTime 这个数据,甚至提出去数据库中,修改历史数据,再把 UpdateTime 加上唯一约束(以前也没有听说过在 UpdateTime 这个字段上面加唯一约束)。并且这种办法,局限性有很强,不可以通用。
    • 主键ID唯一,但是它不具有时间属性。只适用于全部更新。
    • 把他们两个结合起来,才算是打开了新的思路。

    拆分问题,简化问题

    • 把 UpdateTime 和 ID 组合使用时。妄图在一个sql里面来实现。发现无论怎么改,都会存在逻辑上面的问题;
    • 没有拆分化简的时候,如果用存储过程来写的话,会非常非常复杂;
    • 直到,我在脑袋里面,模拟出来可能的情况后。也就是上面的图片同步数据的可能性,慢慢归类,简化后;才发现。问题没有那么难,仅仅是起始点这一个小小的问题。

    使用逻辑分析哲学归纳

    • 在分析数据的意义和性质的时候,偶然间使用到了归纳的方法;也就是唯一可排序;跳出了具体字段,使用场景的框架束缚,而去考虑这两种性质怎么结合的问题;
    • 在逻辑分析的时候,先用排列组合,算出多少种可能性;在脑中勾画出图形,把性质相同的可能性合并化简;
    • 在化简的过程中,不要仅仅着眼于查询的对象,也要去化简查询的方法;有点绕,打个比方,既要优化最终产品,也要去优化制作工艺;

    最后,我认为我最近的逻辑分析能力,好像有比较大的提升。

    • 直接得益于,常见的24种逻辑谬误的了解,【转】逻辑谬误列表(序言),在平常的生活中,说话做事,也就有了逻辑方面的意识;
    • 间接可能得益于台大哲学系苑举正,苑老师讲话的视频。其实我很早以前,高中时候就喜欢哲学,《哲学的基本原理》这么枯燥的书,我居然认认真真仔仔细细的边读边想的看了三四遍。只是那时好多完全不懂,好多似懂非懂。十多年后虽然什么都不记得了,但是好像又懂了。。。感觉太玄了。。。

    转载于:https://www.cnblogs.com/BenAndWang/p/10125142.html

    展开全文
  • 业务提出这样一个需求,需要将oracle数据库(简称A库)中的70多张业务表迁移并同步到另一个oracle库(简称B库)下,这70多张业务表都是按月创建的分区表,目前每个张有20万张记录,以每5分钟的频率新增一条记录,...

    前言

    今天是一个特别的日子,端午佳节,祝大家节日安康,这两天和开发人员接到一个事情,虽然功能基本实现了,但仔细想想后还是有一些遗留问题,现在重新梳理一下,节后彻底解决,所以就有了下面这篇文章

    项目需求

    业务方提出这样一个需求
    1、需要将oracle数据库(简称A库)中的70多张业务表迁移并同步到另一个oracle库(简称B库)下,
    2、A库下70多张业务表都是按月创建的分区表,目前每个张有20万条记录,以每5分钟的频率新增一条记录
    3、业务表有明确的时间字段,这里只需按最新时间将新增的记录同步是B库下,同时从这70多张业务表上取出最新一条记录的部分字段作展示。
    4、整个增量同步完成到从这70多张业务表,每张表上取出最新一条记录的部分字段需要在5分钟以内完成。
    注意:
    同一张表有可能多次查询,每次只取两个字段。
    B库上同时运行oracle数据库和5个kettle同步任务

    大致实现思路与方法

    1、业务表结构和数据迁移实现方法有很多,比如kettle,datax,navicat,这里不是再详述
    数据迁移:见https://blog.csdn.net/weixin_41561946/article/details/106957890
    2、在B库单独建立一个视图或是存储过程,实现部分字段的获取操作,供后端获取。
    前者只需要单独建立一张视图即可,分别从这70多表业务表取出想要的数据即可,后者需要单独建立一张表,通过存储过程获取最新的数据,再通过job每隔几分钟去调用一下,结果数据需要在一分钟内完成
    3、增量同步的实现方式,kettle,datax,dblink.。
    kettle实现增量同步比较简单,可以按一张表创建一个作业,最后用一个大作业把这些表作业给统一起来。
    datax需要进行一些编码来实现
    dblink实现起来非常简单,存储过程+job即可完成

    四种方案可供实现

    这里需要考虑同步操作与数据处理(相应业务字段的获取)是单独处理,还是联动处理?分别有几下四种解决方案可供选择
    同步操作与数据处理联动处理
    1、通过kettle建立多个大作业加存储过程调用实现
    按一张表创建一个作业,最后用一个或多个大作业来实现统一调用,增量同步执行完成后,调用存储过程,将需要的字段单独存放在一个业务表中,供后端提取。
    优点:
    原环境已经有kettle同步作业了,能够实现统一管理
    需要的字段能提前处理好,而不是在用的时候重新生成
    缺点:
    需要考虑生成的业务表的数据量问题,清理老数据
    同步频率高,kettle任务的频繁调用可能会导致操作系统资源不断创建和回收,增加操作系统压力

    2、通过dblink方式+存储过程实现
    创建dblink连接方面,通过存储过程实现A库下相关表的最新记录获取并插入到B库的表中,完成后再调用生成业字段的存储过程存放一个业务表中,供后端提取
    优点:
    不需要kettle来需要同步操作,节省了操作系统内存
    需要的字段能提前处理好,而不是在用的时候重新生成
    缺点:
    同步作业不能实现统一管理
    同步操作与数据处理单独处理
    3、对于kettle实现增量数据同步+视图
    与方案1的差别在于,不是用通过存储过程去生成数据,直接从70多张业务表提取数据
    优点:
    不需要编写存储过程和考虑存储过程调用问题
    数据需要实时查询
    不需要生成额外的业务表并考虑旧数据清除问题
    缺点:
    当70多张业务表数据量大了过后,通过视图查询可能会比较慢
    4、通过dblink方式+存储过程实现+视图
    与方案2的差别在于,不是用通过存储过程去生成数据,直接从70多张业务表提取数据
    优点:
    只需要考虑5分钟以内把70多张表新记录同步来即可
    通过视图实时查询
    不需要kettle来需要同步操作,节省了操作系统内存,
    缺点:
    同步作业不能实现统一管理
    当70多张业务表数据量大了过后,通过视图查询可能会比较慢

    方案确定

    方案一:通过kettle建立多个大作业加存储过程调用实现

    总结

    1、不管是用视图还是业务表存储最新数据,都需要先考虑同步问题,所以同步任务的执行时间是关键
    2、基于kettle同步时,一个大作业里多放几个作业,哪到底放几个作业呢,因为一个作业对应一张表同步,需要测试一张表同步时花费多少时间来决定
    3、kettle作业多了几后,频繁调用会导致操作系统资源紧张,容易出来OOM
    4、kettle同步作业最好单独那一台机器来运行
    5、做事情多考虑几个方案

    展开全文
  • logstash全量和增量同步数据到mysql

    千次阅读 2019-04-23 22:55:24
    一、场景 在mysql数据同步到ES中,发现第一次同步时需要全量的...2、支持每次全量同步或按照特定字段(如递增ID、修改时间)增量同步; 3、同步频率可控,最快同步频率每分钟一次(如果对实效性要求较高,慎用);...
  • 使用Kettle实现数据实时增量同步

    万次阅读 多人点赞 2018-05-30 16:16:20
    本文介绍了使用Kettle对一张业务表数据(500万条数据以上)进行实时(10秒)同步,采用了时间戳增量回滚同步的方法。关于ETL和Kettle的入门知识大家可以阅读相关的blog和文档学习。 1. 时间戳增量回滚同步 ...
  • 大数据增量同步实现方案

    万次阅读 2017-10-26 18:18:57
    目前做的项目使用阿里 DataX 作为不同数据源数据同步的实现工具。数据的批量一次性导入比较简单,对于增量数据需要对不同场景设计不同的方案。 会变的数据增量同步
  • kettle的使用手册及个人实现的数据增量同步(支持多种数据库的增量同步) 文档地址:https://download.csdn.net/download/wyazyf/10705252
  • 定时数据增量同步,具体同步哪些表,需要可配置; 节约工作量,最大限度上不改变当前表结构、业务流程控制等等; 增量操作包含insert、update;delete使用逻辑删除,等价于update 常见应用场景:业主的应用基本...
  • kettle实现数据增量同步方案

    千次阅读 2019-12-12 14:37:29
    基于数据库的变更日志同步(oracle redo\mysql binlog),速度很快,对数据库性能影响很小,适合大量数据同步的场景 缺点: 同步表变更字段、新增表,需要修改数据库服务器上的很多配置文件,比较繁琐,在exact、...
  • 说明:由于本人的实际情况是不能修改线上对数据引擎的支持,并且只是为了同步部分表,因此没必要将两个库做主从,因此采用以下的方式进行解决对于跨服务器同步增量数据的问题,本可以使用:select * into outfile ...
  • 在两个ORACLE数据库之间实现数据增量同步
  • 我们在选择VPS、服务器架设项目之后,所有的项目、网站数据都需要我们自行备份和维护,即便有些服务商有提供管理型服务器,但是数据自行备份和管理才是较为靠谱的。无论是网站,还是其他项目,数据的备份方式有很多...
  • 增量同步数据

    千次阅读 2017-10-28 16:21:01
    增量数据同步 参考《oracle dba工作笔记》 1、sql增量抽取 select * from worker where operation_date>=to_date('2015-10-25','yyyy-mm-dd') and operation_date=to_date('2015-10-25','yyyy-mm-dd') and operation...
  • 首先安装Elasticsearch,参考... 同步我们需要用到logstash工具,下载logstash 将下载的logstash-7.2.0.tar解压 tar -zxvflogstash-7.2.0.tar 将mysql的连接库jar包放到logstash-7.2.0/confi...
  • kettle增量方案全量比对取增量-根据唯一标示
  • 数据入的MySQL集群是不可更改的,如何再高效的将数据写入kafka呢? A),在表中存在自增ID的字段,然后根据ID,定期扫描表,然后将数据入kafka。 B),有时间字段的,可以按照时间字段定期扫描入ka...
  • 使用Kettle同步mysql数据增量同步,两个数据库数据同步
  • 基于MYSQL的Binlog增量数据同步服务

    千次阅读 2016-08-10 16:45:31
    基于MYSQL日志增量数据同步原理: - 1、DBAsync伪装自己为mysql slave,向mysql master发送dump协议 - 2、mysql master收到dump请求,开始推送binary log给DBAsync - 3、DBAsync解析binary log,将数据改动同步到...
  • DataX 数据全量,增量同步方案

    万次阅读 热门讨论 2019-04-26 23:38:42
    增量更新总体思路:从目标数据库读取一个最大值的记录,可以是DataTime 或者 RowVersion 类型,然后根据这个最大值对源数据库要同步的表进行过滤,然后再进行同步即可。 由于DataX 支持多种数据库的读写,一种...

空空如也

1 2 3 4 5 ... 20
收藏数 74,075
精华内容 29,630
关键字:

数据增量同步