千万级数据迁移,oracle 亿级数据迁移

　　java基础教程栏目介绍万亿级数据应该迁移的方法。

　　如何解决写爬虫IP受阻的问题？立即使用。

背景

　　星爷《大话西游》里面有一句非常著名的台词：“曾经有一份真挚的感情摆在我面前，我没有珍惜。失去了才后悔。世界上最痛苦的事莫过于此。如果上天能再给我一次机会，我会对哪个女孩说三个字：我爱你。如果我必须增加这份爱。在我们开发人员眼里，这种感觉就跟我们数据库里的数据一样。我们希望一万年不变，但往往事与愿违。随着公司的不断发展，业务的不断变化，我们对数据的要求也在不断变化。大概有以下几种情况：

　　分库分表:随着业务的快速发展，单机数据库压力越来越大，数据量也越来越大。这时通常采用数据库分离的方法来解决这个问题，将数据库的流量平均分配到不同的机器上。在单机数据库到子数据库的过程中，我们需要完全迁移我们的数据，这样才能成功地使用我们在子数据库中的数据。更换存储介质:一般来说，我们迁移之后，存储介质还是一样的。比如之前用的单机Mysql，数据库分区后就变成了多机的Mysql。我们的数据库表的字段没有改变，所以迁移相对简单。有时候我们不能通过划分数据库和表来解决所有的问题。如果我们需要大量复杂的查询，此时使用Mysql可能不是一个可靠的解决方案。然后我们需要更换查询的存储介质，比如使用elasticsearch。这种迁移会稍微复杂一点，涉及到不同存储介质的数据转换。切换新系统:一般公司在快速发展中，会有很多为了速度而重复建设的项目。当公司持续到一定时间，往往这些项目会被合并，成为一个平台或者中间平台，比如我们的一些会员系统，电商系统等等。这时候往往会出现一个问题，就是旧系统中的数据需要迁移到新系统中。这一次，情况更加复杂。有可能不仅存储介质变了，项目语言也不一样了。从更高层的角度来看，部门可能不一样，所以这种数据迁移难度更大，风险也更大。在实际业务发展中，我们会根据不同的情况制定不同的迁移方案。接下来，让我们讨论如何迁移数据。

数据迁移

　　数据迁移实际上不是一蹴而就的。每次数据迁移都需要很长时间，可能是一周或几个月。一般来说，我们的数据迁移过程基本上类似于下图：

　　首先，我们需要批量迁移我们数据库中的现有数据，然后我们需要处理新增的数据。我们需要将这部分数据实时写入原始数据库，然后写入我们的新存储。在这个过程中，我们需要不断地检查数据。当我们验证基本问题不严重的时候，我们会把流切断，直到流完全切断，这样就不需要做数据检查和增量数据迁移了。

存量数据迁移

　　首先说一下如何做股票数据迁移。在开源社区四处搜索后，我们发现没有太容易使用的工具。目前阿里云的DTS提供股票数据迁移。DTS支持异构和异构数据源之间的迁移，基本支持业界常见的数据库如Mysql、Orcale、SQL Server等。DTS更适合我们之前提到的前两种场景。一个是数据库分离的场景。如果使用阿里云的DRDS，可以直接通过DTS将数据迁移到DRDS，另外就是异构数据的场景。无论是Redis还是ES，DTS都支持直接迁移。

　　那么DTS股票迁移是怎么做的呢？其实比较简单，大概就是以下几个步骤：

　　当启动存量迁移任务时，我们得到当前需要迁移的最大id和最小id，并设置一个段，比如10000。从最小id开始，每次查询DTS服务器10000个数据，交给DTS处理。下面的sql: select * from table _ name其中id curid和id curid10000复制代码3。当id大于或等于maxId时，股票数据迁移任务结束。

　　当然，我们在实际迁移过程中可能不会用到阿里云，或者在我们的第三种场景中，需要做大量的数据库字段之间的转换，这是DTS不支持的，所以我们可以模仿DTS的做法，通过批量读取数据来迁移数据。这里需要注意的是，我们在批量迁移数据的时候，需要控制分段的大小和频率，防止影响我们正常的在线操作。

增量数据迁移

　　存量数据的迁移方案有限，但增量数据迁移方法都是花。一般来说，我们有以下方法：

　　DTS:阿里云的DTS是一站式服务。它提供增量数据迁移以及存量数据迁移，但需要按量收费。双写服务：比较适合不需要系统切换的迁移，即只改变存储但系统不变，比如数据库分区和表分区，redis数据同步等。这种方法比较简单，要迁移的数据可以同步写入代码中。但由于不是同一个数据库，无法保证交易，可能导致数据迁移时数据丢失。这个过程会通过后续的数据验证来解决。MQ异步编写：这可以应用于所有场景。当数据被修改时，会发送一条MQ消息，消费者会在收到这条消息后更新数据。有点类似于上面的双写，只是把对数据库的操作改成了MQ异步，出问题的概率会小很多。我们可以使用canal或者其他一些开源如databus来监听binlog，监听binlog的方式和上面的message MQ一样，只是我们省略了发送消息的步骤。这种方法基本上是开发量最小的方法。我们应该使用这些方法中的哪一种？我个人推荐监控binlog的做法。监控binlog降低了开发成本。我们只需要实现消费者逻辑，数据就能保证一致性。因为是被监控的binlog，所以不用担心之前的双写不是事务问题。

数据校验

　　以上提到的所有解决方案，虽然很多都是成熟的云服务(dts)或中间件(canal)，但都可能存在一定的数据丢失。数据丢失总体来说还是比较少的，但是检查起来非常困难。可能是dts或者canal不小心晃动了，也可能是接收数据时丢失了。既然没有办法避免我们的数据在迁移过程中丢失，我们就应该通过其他方式来纠正它。

　　一般来说，我们在迁移数据的时候，都会有一个数据验证的步骤，但是不同的团队可能会选择不同的数据验证方案：

　　在美团之前，我们会做一个双读，就是我们所有的读数都会从新的读，但是返回的还是旧的。这时候就需要对这部分数据进行核对了。如果有任何问题，我们可以发出警报，以手动或自动修复。这样我们常用的数据就可以快速修复，当然我们也会时不时的运行一次全量的数据检查，但是这种检查修复数据的时间是滞后的。现在经过ape辅导，我们不采用以前的方法了，因为虽然复读检查可以很快发现数据错误，但是对于这部分数据我们没有那么高的实时性检查，一个代码复读的开发还是略大一些，但是不能靠不及时的全额检查来保证，这就导致我们的数据检查时间非常长。我们采用了折中的方法，在和解中我们借鉴了T 1的一个思路。我们每天早上在旧数据库中获取昨天更新的数据，然后将其与我们新数据库中的数据进行比较。如果有任何数据不同或丢失，我们可以立即修复。当然，在实际开发过程中，我们还应该注意以下几点：

　　如何保证一个数据验证任务的正确性？验证任务本来是为了修正其他数据，但如果本身有问题，就失去了验证的意义。目前只能通过审查代码的方式来保证验证任务的正确性。验证任务时，需要注意日志的打印。有时候问题可能是所有数据直接出现问题造成的。然后验证任务可能会打印大量的错误日志，然后报警，可能会挂机或者影响别人的服务。这里，如果想简单点，可以把一些非手动报警变成warn。如果你想让它变得更复杂，你可以打包一个工具。如果某个错误打印了一段时间，超过了一定的量，就不用再打印了。验证任务应注意不要影响在线服务。通常验证任务会批量写很多查询语句，会导致批量表扫描。如果代码写得不好，很容易导致数据库挂起。

切流

　　当我们的数据检查基本没有错误的时候，说明我们的迁移程序比较稳定，那么可以直接使用我们的新数据吗？当然是做不到的。如果我们交换，顺利就好。如果出了问题，会影响到所有用户。

　　所以接下来需要做灰度，也就是切电流。不同业务流的维度会有所不同。对于用户维度，我们通常通过取userId的模块来截流。对于租户或者商户维度的业务，我们需要通过取租户id的模块来截流。这个截流需要制定一个截流方案，在什么时间段，要释放多少流量，在流量比较小的时候一定要截流。每次截断都需要详细观察日志，任何问题都应尽快解决。流量释放过程是一个从慢到快的过程。比如一开始是1%连续叠加，后来我们直接加10%或者20%。因为如果有问题，往往会在流量小的时候发现。如果小流量没有问题，那么后续的量可以快速增加。

注意主键ID

　　在数据迁移过程中，要特别注意主键id。在上面的双写方案中，还提到了双写时需要手动分配主键ID，防止ID生成顺序错误。

　　如果我们是因为子数据库、子表而进行迁移，就需要考虑到我们未来的主键id不可能是自增id，需要使用分布式Id。这里推荐美团开源的leaf。他支持两种模式：一种是雪花算法趋势在增加，但所有ID都是长的，适合一些支持长as ID的应用。还有号段模式，会根据你设置的一个基本id，从这个开始不断增加。而且基本上都是内存生成，性能也很快。

　　当然，我们仍然有需要迁移系统的情况。新系统中已经存在以前系统的主键id，因此需要映射我们的id。如果我们在迁移系统时已经知道将来要迁移哪些系统，我们可以使用保留方法。比如A系统的数据是1亿到1亿，B系统的数据是1亿到1亿。现在需要把A和B两个系统合并成一个新的系统，可以稍微估算一些缓冲，比如给A系统预留1.5亿到1.5亿，这样A系统就不需要映射了，B系统1.5亿到3亿。那我们可以

　　但是如果系统里没有预留板块做规划呢？您可以通过以下两种方式来实现：

　　需要添加一个表，以映射的方式记录旧系统的id和新系统的id。这个工作量还是比较大的，因为我们的迁移通常涉及几十个或者几百个表，记录成本还是很高的。如果id是long，我们可以很好的利用Long是64位，我们可以制定一个规则。我们新系统的id从一个相对较大的数开始，比如从一个大于Int的数开始，把小的Int部分留给我们旧系统进行Id迁移。比如上面1.5亿的数据，实际上只用了28位，我们的Int是32位。那么还有4位可用，可以代表16个系统进行迁移。当然，如果计划迁移更多的系统，您可以将新系统的id起点设置得更大。如下图

总结

　　最后简单总结一下这个套路，其实就是四个步骤。一个注意：存量，增量，检查，切流量，最后关注id。无论多大的数据，基本上按照这个套路迁移都不会有大问题。希望本文能对你后续的数据迁移工作有所帮助。

　　这就是数万亿数据应该迁移的方法的细节。更多请关注我们的其他相关文章！

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。