CN115640280A

CN115640280A - 数据迁移方法及装置

Info

Publication number: CN115640280A
Application number: CN202211286205.1A
Authority: CN
Inventors: 王若川; 赵永刚
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2022-10-20
Filing date: 2022-10-20
Publication date: 2023-01-24

Abstract

本公开提供了一种数据迁移方法及装置，涉及数据处理领域，尤其涉及智能搜索和大数据领域。具体方案为：获取新增的交互行为数据，将新增的交互行为数据分别写入源数据库和目标数据库，以分别更新源数据库和目标数据库中的交互数据。针对多个对象中的第一对象，在源数据库中获取第一对象的第一对象交互数量，以及在目标数据库中获取第一对象的第二对象交互数量。根据第一对象交互数量和第二对象交互数量的差值，将源数据库中的第一对象交互数量导入至目标数据库中。获取将新增的交互行为数据首次写入目标数据库的第一时刻，并根据第一时刻，将源数据库中存储的交互关系、对象标识集合，导入至目标数据库。本公开的技术方案可以提升数据迁移的效率。

Description

数据迁移方法及装置

技术领域

本公开涉及数据处理中的智能搜索和大数据领域，尤其涉及一种数据迁移方法及装置。

背景技术

出于业务需要的目的，在一些场景下可以对数据进行迁移。在数据迁移的过程中，通常是将源数据库中的数据迁移至目标数据库中，

为了不依赖数据快照实现数据迁移，需要提供一种高效准确的数据迁移方法。

发明内容

本公开提供了一种数据迁移方法及装置。

根据本公开的第一方面，提供了一种数据迁移方法，包括：

获取新增的交互行为数据，并将所述新增的交互行为数据分别写入源数据库和目标数据库，以分别更新所述源数据库和所述目标数据库中存储的交互数据，所述交互数据包括如下中的至少一种：对象交互数量、对象与用户的交互关系、对象标识集合；

针对多个对象中的第一对象，在所述源数据库中获取所述第一对象的第一对象交互数量，以及在所述目标数据库中获取所述第一对象的第二对象交互数量；

根据所述第一对象交互数量和所述第二对象交互数量的差值，将所述源数据库中的第一对象交互数量导入至所述目标数据库中；

获取将所述新增的交互行为数据首次写入所述目标数据库的第一时刻，并根据所述第一时刻，将所述源数据库中存储的交互关系、对象标识集合，导入至所述目标数据库。

根据本公开的第二方面，提供了一种数据迁移装置，包括：

提交模块，用于获取新增的交互行为数据，并将所述新增的交互行为数据分别写入源数据库和目标数据库，以分别更新所述源数据库和所述目标数据库中存储的交互数据，所述交互数据包括如下中的至少一种：对象交互数量、对象与用户的交互关系、对象标识集合；

获取模块，用于针对多个对象中的第一对象，在所述源数据库中获取所述第一对象的第一对象交互数量，以及在所述目标数据库中获取所述第一对象的第二对象交互数量；

第一导入模块，用于根据所述第一对象交互数量和所述第二对象交互数量的差值，将所述源数据库中的第一对象交互数量导入至所述目标数据库中；

第二导入模块，用于获取将所述新增的交互行为数据首次写入所述目标数据库的第一时刻，并根据所述第一时刻，将所述源数据库中存储的交互关系、对象标识集合，导入至所述目标数据库。

根据本公开的第三方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面所述的方法。

根据本公开的第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行第一方面所述的方法。

根据本公开的第五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序，所述计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得电子设备执行第一方面所述的方法。

根据本公开的技术解决了数据迁移需要依赖数据库快照，导致数据迁移的效率低下，且资源浪费的问题。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1为本公开实施例提供的数据迁移示意图；

图2为本公开实施例提供的搜索结果页的实现示意图；

图3为本公开实施例提供的数据迁移方法的流程图；

图4为本公开实施例提供的对象交互数量的实现示意图；

图5为本公开实施例提供的交互关系的实现示意图；

图6为本公开实施例提供的对象标识集合的实现示意图；

图7为本公开实施例提供的数据迁移方法的流程图二；

图8为本公开实施例提供的更新数据库中的对象交互数量的实现示意图一；

图9为本公开实施例提供的更新数据库中的对象交互数量的实现示意图二；

图10为本公开实施例提供的数据读取请求的流程图三；

图11为本公开实施例提供的取模数值和读取接口的对应关系示意图；

图12为本公开实施例提供的数据库接口的示意图；

图13为本公开实施例的数据迁移装置的结构示意图；

图14是用来实现本公开实施例的数据迁移方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

为了更好的理解本公开的技术方案，下面对本公开所涉及的相关技术进行进一步的详细介绍。

随着业务的不断发展，相应的会产生大量的数据。而且，出于一些业务需求的目的，在一些场景下需要对数据进行迁移。

比如说可以结合图1进行理解，图1为本公开实施例提供的数据迁移示意图。

如图1所示，在源数据库中可以存储有数据，而数据迁移通常是将源数据库中存储的数据，从源数据库迁移到目标数据库。

在一种可能的实现方式中，比如说可以存在一个处理设备，源数据库和目标数据库之间的数据迁移可以是这个处理设备控制进行的。

下面可以结合图2对本公开中提供的数据迁移方法，所适用的一种应用场景进行说明，图2为本公开实施例提供的搜索结果页的实现示意图。

在智能搜索的应用场景下，用户通过搜索引擎搜索信息。比如说可以结合图2进行理解，假设用户可以在搜索引擎中输入待搜索的关键字，例如是图2所示的“1+1等于2吗”。

在用户向搜索引擎提交该关键字之后，搜索引擎就可以针对该关键字进行搜索，并向终端设备返回多条搜索结果，最终显示在终端设备的图形用户界面上。

其中，一条搜索结果可以表现为一个搜索结果卡片，比如说在图2的示例中，针对用户搜索的关键字，在对应的搜索结果页中包括多个搜索结果卡片，也就是图2所示的搜索结果卡片201、搜索结果卡片202、搜索结果卡片203。

之后用户比如说可以点击需要的搜索结果卡片，以查看搜索结果卡片对应的详细网页内容。

以及可以理解的是，目前在很多网页中，都提供了交互控件，以使得用户可以在网页上，针对网页所展示的内容进行相应的交互操作。其中交互控件比如说可以是点赞控件、点踩控件、评论控件等等。那么相应的，用户就可以在网页上，针对当前网页上所展示的内容进行点赞、点踩、评论等交互操作。

在实际实现过程中，具体的交互控件的设置，以及用户可以进行的交互操作，都可以根据实际需求进行选择和设置，本实施例对此不做限制。

同时，可以理解的是，通常用户要点击搜索结果卡片，打开搜索结果卡片对应的具体网页内容之后，才能看到该网页内容的交互信息，比如说点赞数、点踩数、评论数等等。

然而，为了提升用户体验，考虑可以提供一种方式，就是在搜索结果卡片中就增加交互因子，以使得用户在搜索结果卡片中就可以获取到网页内容的交互信息。此处的交互因子比如说可以是图2中，在搜索结果卡片中所展示的点赞数、点踩数等等。

比如说图2中的搜索结果卡片201中，展示有201对应的回答的点赞数是234，点踩数是5。搜索结果卡片202和搜索结果卡片203类似。

基于上述介绍可以确定的是，如果可以在搜索结果卡片上展示交互因子，可以在搜索结果卡片中为用户提供更多的信息。

可以理解的是，要在搜索结果卡片上展示交互因子，就需要获取该搜索结果卡片对应的网页结果的交互数据。比如说针对图2中所示的搜索结果卡片201，要首先获取该搜索结果卡片201对应的回答的点赞数量和点踩数量，才能够最终在搜索结果卡片上进行展示。

然而，检索并展示搜索结果卡片的业务方，和搜索结果卡片所对应的实际网页内容的业务方，并不是同一个业务方。

比如说检索并展示搜索结果卡片的业务方，此处称为中台业务方。再比如说图2中的201和202实际上对应的都是“xx知道”的网页，假设将该网页对应的业务方称为知道业务方。

其中，针对知道业务方，其数据库中存储有交互数据，比如说交互数据可以包括每一个回答的点赞数量、点踩数量。

那么为了在搜索结果页中展示交互因子，就需要将知道业务方存储的交互数据，迁移到中台业务方，这样才能保证中台业务方可以实现交互因子的展示。

因此在这种应用场景下，知道业务方的数据库就可以理解为源数据库，中台业务方的数据库就可以理解为目标数据库。

再比如说，图2中的203实际上对应的是“xx新闻”的网页，假设该网页对应的业务方称为新闻业务方。

类似的，针对新闻业务方，其数据库中存储有交互数据，比如说交互数据可以包括每一条新闻的点赞数量、点踩数量。

那么为了在搜索结果页中展示交互因子，就需要将新闻业务方存储的交互数据，迁移到中台业务方，这样才能保证中台业务方可以实现交互因子的展示。

因此在这种应用场景下，新闻业务方的数据库就可以理解为源数据库，中台业务方的数据库就可以理解为目标数据库。

基于上述介绍可以理解的是，正是因为一些业务的需求，因此会存在一些数据需要迁移的情况。在实际实现过程中，数据迁移并不限于上述介绍的场景，凡是需要将交互数据从源数据库迁移到目标数据库的应用场景下，均可以采用本公开提供的数据迁移方法，因此本实施例对数据迁移方法的具体应用场景不做限制。

在上述介绍内容的基础上，下面对目前相关技术中进行数据迁移的可能的实现方式首先进行说明。

可以理解的是，数据通常存储在源数据库中，源数据库中已经存储的数据可以理解为存量数据。以及数据迁移是需要耗费一定的时间的，而在数据迁移的过程中，本身的业务并没有停止，比如说用户还是持续的在进行点赞、点踩、评论、取消点赞、取消点踩、删除评论等一系列交互行为。因此源数据库中所存储的存量数据是不停的在发生变化的。

那么如果直接将源数据库中的存量数据迁移至目标数据库中，就有可能出现源数据库中的数据和目标数据库中的数据不一致的情况。比如说某一条回答的点赞数量是234，假设该点赞数量在时刻1从源数据库迁移到目标数据库。

然而，在时刻1之后，某一个用户又针对该回答进行了点赞，也就是说该回答的点赞数量变为了235。但是该回答的点赞数量已经迁移到目标数据库了，这样就导致源数据库中存储的数据和目标数据库中存储的数据不一致的情况。

为了克服这个问题，通常需要针对源数据库中的存量数据，取某个时刻的数据库快照。其中，数据库快照可以理解为数据库的只读静态视图，也就是说将存量数据在某个时刻的具体数据内容记录下来，这样就得到了不会变化的存量数据。

之后，可以将保存的数据库快照导入至目标服务器，以及将快照时刻之后所产生的增量数据也全部提交给目标服务器。在存量数据迁移完成之前，目标服务器仅仅是对增量数据进行保存，因为还没有得到全部的存量数据，无法进行融合处理。在数据库快照导入完成之后，再根据增量数据的提交时间，将增量数据和存量数据进行融合，从而得到正确的数据。

此处的按照提交时间进行融合，是因为在数据迁移的过程中，可能针对一个回答会发生很多的交互动作，比如说同一个用户针对这个回答，可能点了赞，可能又取消了赞，最终可能又点了赞，那么最终的数据就要以最后一个增量数据所对应的状态为准，才能保证记录的数据是正确的。

然而，可以理解的是，在取某个时刻的数据库快照之后，通常需要将数据库快照保存在一个数据库中，这样才能够将该时刻的数据内容保存下来。

目前，相关技术中通常都是将数据库快照保存在从库中，然而从库通常都是用来做数据同步的。为了保存数据库快照，就需要将从库的数据同步暂停，转而用来保存数据库快照。同时需要按秒级别的精确时间定位日志，这样的操作是比较耗时且复杂的。

以及，存量数据的导入通常都是比较耗时的，在存量数据导入之后，从库就会很长时间都没有进行数据同步了，因为中间空缺了很长时间的数据同步，此时从库已经无法再继续进行数据同步了，这样就会导致资源的不可逆的浪费。

因此基于上述介绍可以确定的是，为了保证源数据库和目标数据库中的数据一致性，通常需要依赖源数据库的从库来保存某个时刻的数据库快照。然而，保存数据库快照的从库，在存量数据导入之后就不可用了，因此会造成资源的浪费。同时，要将数据库快照写入从库，实际上也是一次数据复制的过程，这个过程也是比较耗时且复杂的。

以及，目前还存在一些业务方存在自己的离线数据平台，在离线数据平台中可以保存每天的数据库快照。则例如可以从离线数据平台中获取数据库快照，以实现存量数据的迁移。

但是，因为离线数据平台取数据库快照的时间之后，将数据库快照写入离线数据平台还需要花费很久的时间，目标数据库并不能确定离线数据平台什么时候完成数据库快照的导入，因此其如果任意选择一个时间开始进行存量数据的迁移，还是有可能出现数据不一致的情况。并且，并不是每一个业务方都会存在自己的离线数据平台，因此这种实现方式的适用性较低。

基于上述介绍可以确定的是，目前的相关技术中在进行数据迁移的时候，通常都需要依赖数据库快照，以保证源数据库和目标数据库中的数据是一致的。然而这种实现方式一定要占用额外的从库，因此会出现数据迁移的过程复杂耗时，并且有可能导致从库不可用，进而出现资源浪费的问题。

针对上述介绍的技术问题，本公开提出了如下技术构思：之所以在进行数据迁移的过程中，要依赖数据库快照，是因为源数据库中的存量数据会发生更新，如果不确定某个时刻固定的存量数据的话，就可能出现源数据库和目标数据库中的数据不一致的情况。而本公开的技术方案中，并不依赖数据库快照，而是在将源数据库中有效的存量的交互数据迁移到目标数据库之外，还会将新增的交互行为数据分别写入到源数据库和目标数据库中，以对源数据库和目标数据库中的交互数据分别进行更新，因此可以有效保证源数据库和目标数据库中的数据是一致的。

在上述介绍内容的基础上，下面结合具体的实施例对本公开所提供的数据迁移方法进行介绍。在介绍之前，首先对本公开中各实施例的执行主体进行介绍。基于上述介绍可以确定的是，源数据库和目标数据库之间的数据迁移可以是处理设备控制完成的。其中处理设备比如说可以是服务器、处理器、芯片等等具备数据处理功能的设备。本实施例对处理设备的具体实现不做特别限制，只要其可以具备数据处理的功能，并且可以和源数据库、目标数据库进行数据交互即可。

下面结合图3至图6进行说明，图3为本公开实施例提供的数据迁移方法的流程图，图4为本公开实施例提供的对象交互数量的实现示意图，图5为本公开实施例提供的交互关系的实现示意图，图6为本公开实施例提供的对象标识集合的实现示意图。

如图3所示，该方法包括：

S301、获取新增的交互行为数据，并将新增的交互行为数据分别写入源数据库和目标数据库，以分别更新源数据库和目标数据库中存储的交互数据，交互数据包括如下中的至少一种：对象交互数量、对象与用户的交互关系、对象标识集合。

基于上述介绍可以确定的是，在数据迁移的过程中，用户的交互行为还在持续的进行，因此会不停的产生新增的交互行为数据。

本实施例中可以获取新增的交互行为数据，在一种可能的实现方式中，本实施例中的交互行为数据可以指示某个用户针对某个对象进行了某种交互行为。

此处的用户比如说可以采用相应的用户标识来指示。以及本实施例中的对象比如说可以是上述介绍的回答、新闻、视频等等，比如说可以将对象理解为网络中的内容，其中对象同样可以采用相应的对象标识来指示。以及本实施例中的交互行为比如说可以包括点赞、点踩、评论、取消点赞、取消点踩、删除评论等等，本实施例对具体的交互行为不做限制。

比如说在一个示例中，一条交互行为数据可以包括：用户1、回答A、点赞。该交互行为数据就可以指示用户1针对回答A进行了点赞操作。在实际实现过程中，交互行为数据的具体实现方式可以根据实际需求进行选择和设置。

以及可以理解的是，本实施例中的数据迁移方法比如说可以是依托于一些程序来实现的，在程序开始运行之后，数据迁移方法就开始执行了。那么在一种可能的实现方式中，在程序开始运行之后所产生的交互行为数据，都可以理解为是新增的交互行为数据，也就是说新产生的增量数据。

可以理解的是，新增的交互行为数据会影响源数据库中所存储的存量数据，比如说新增的交互行为数据指示某个用户针对某个回答进行了点赞操作，那么源数据库存储的存量数据中，就需要针对该回答的点赞数量加 1。

因此本实施例中需要将新增的交互行为数据写入到源数据库中，以更新源数据库中所存储的交互数据，从而可以保证源数据库中所存储的交互数据是正确的。

同时，本实施例中还会将新增的交互行为数据写入到目标数据库中。在数据迁移方法开始执行之后，源数据库中所存储的存量数据就会开始写入至目标数据库了。因此目标数据库中可能存储了一部分的交互数据，此时将新增的交互行为数据写入到目标数据库中，可以针对目标数据库中存储的交互行为数据也进行相应的更新。

可以理解的是，比如说将新增的交互行为数据写入到目标数据库中的时候，针对某个回答的点赞数量的存量数据，如果已经写入到目标数据库中，那么目标数据库就可以是针对写入的存量数据进行更新。如果说针对某个回答的点赞数量的存量数据，还没有写入到目标数据库中，那么目标数据库存储的该回答的点赞数量就是0，目标数据库就是针对点赞数量0 进行更新。

在本实施例中，交互数据可以包括如下中的至少一种：对象交互数量、对象与用户的交互关系、对象标识集合。

比如说可以结合图4理解对象交互数量，如图4所示，对象交互数量比如说可以包括对象的点赞数量、点踩数量、评论数量。比如说在图4的示例中，一个回答可以理解为一个对象，其中回答A的点赞数量是234，回答A的点踩数量是5，回答A的评论数量是125。其余的回答类似。

再比如说可以结合图5理解对象与用户的交互关系，如图5所示，一条对象与用户的交互关系，比如说可以包括用户对某个对象进行了某个交互行为的记录。比如说在图5的示例中，一个回答可以理解为一个对象，其中第一条交互关系就指示了，用户1针对回答A进行了点赞操作。其余的交互关系类似。

再比如说可以结合图6理解对象标识集合，如图6所示，对象标识集合比如说可以包括用户交互过的对象的对象标识。比如说用户点赞过的回答的标识、用户点踩过的回答的标识、用户评论过的回答的标识。比如说在图5的示例中，用户1点赞过的回答包括回答A和回答B，用户1点踩过的回答包括回答C，其余的情况类似。

以及在可选的实现方式中，对象标识集合比如说可以包括用户交互过的所有对象的对象标识。或者，为了节省数据库的空间，对象标识集合还可以是用户交互过的最近N个对象的对象标识，比如说用户最近2000条的点赞记录对应的对象标识等等，其可以根据实际需求进行选择和设置。

可以理解的是，无论是在源数据库中还是在目标数据库中，都会以上述介绍的形式进行交互数据的存储，而新增的交互行为数据就会是交互数据发生变化，因此无论是源数据库还是目标数据库，都需要根据新增的交互行为数据，对存储的交互数据进行更新。

其中，交互数据的更新可以是本实施例中的处理设备完成的，或者数据库具备数据处理功能的话，还可以是数据库自行完成的，本实施例对此不做限制。

S302、针对多个对象中的第一对象，在源数据库中获取第一对象的第一对象交互数量，以及在目标数据库中获取第一对象的第二对象交互数量。

上述S301实际上介绍的是在数据迁移开始运行之后，新产生的增量输入如何提交给源数据库和目标数据库。然而，在数据迁移中，较为重要的还是将源数据库中所存储的存量数据导入至目标数据库中。

因此在本实施例中，可以根据源数据库中所存储的对象交互数量，和目标数据库中所存储的对象交互数量，将源数据库中所存储的对象交互导入至目标数据库。这里可以理解为是对象交互数量对应的存量数据的迁移。

同时可以理解的是，本实施例中并没有依赖数据库快照，因此源数据库中的存量数据是有可能发生变化的，但是因为我们将新增的交互行为数据分别写入了源数据库和目标数据库。

因此即使源数据库中的存量数据在发生变化，其无非是以下两种情况：

第一种情况是源数据库中的存量数据，在导入目标数据库以前发生变化。那么这种情况下，源数据库中的对象交互数量发生了变化，但是对象交互数量还没有同步给目标数据库，那在后续导入存量数据的时候，直接将变化后的对象交互数量导入至目标数据库，保证源数据库和目标数据库中存储的对象交互数量是一致的即可。

第二种情况是源数据库中的存量数据，在导入目标数据库以后发生了变化。因为本实施例中会将新增的交互行为数据同时写入源数据库和目标数据库，并且对源数据库和目标数据库中所记载的对象交互数量都进行了更新，因此也可以保证源数据库和目标数据库中所记载的对象交互数量是一致的。

以及可以理解的是，在源数据库中存储有多个对象的对象交互数量，针对目标数据库也类似。同时，针对多个对象的对象交互数量的迁移方式都是类似的，下面以多个对象中的第一对象为例进行介绍，可以理解的是，第一对象可以是多个对象中的任意一个对象。

在一种可能的实现方式中，针对多个对象中的第一对象，可以在源数据库中获取第一对象的第一对象交互数量，以及在目标数据库中获取第一对象的第二对象交互数量。

S303、根据第一对象交互数量和第二对象交互数量的差值，将源数据库中的第一对象交互数量导入至目标数据库中。

在获取到第一对象交互数量和第二对象交互数量之后，例如可以确定第一对象交互数量和第二对象交互数量的差值，之后可以根据这个差值，将源数据库中的第一对象交互数量导入至目标数据库中。

比如说可以将这个差值反馈给目标数据库，以使得目标数据库根据差值对目标数据库中的第二对象交互数量进行融合，从而实现将源数据库中的第一对象数量导入至目标数据库中。

以及需要说明的是，在源数据库中存储有多个对象的对象交互数量，针对每一个对象的对象交互数量实际上都会进行上述处理，从而可以实现将源数据库中存量的对象交互数量导入至目标数据库中。

S304、获取将新增的交互行为数据首次写入目标数据库的第一时刻，并根据第一时刻，将源数据库中存储的交互关系、对象标识集合，导入至目标数据库。

除了上述介绍的对象交互数量的存量数据的迁移之外，源数据库中存储的交互关系和对象标识集合的存量数据，也需要迁移到目标数据库中。

可以理解的是，交互关系指示的是某一个用户针对某一个对象进行了某一项交互操作。那么新增的交互行为数据可能存在以下两种情况：第一种是新增的交互行为数据指示某一个用户针对某一个对象取消了某一项交互操作，比如说取消点赞、删除评论等等，则需要删除掉对应的交互行为数据。

第二种情况是新增的交互行为数据指示某一个用户针对某一个对象进行了某一项交互操作，则需要增加对应的交互行为数据。

因此，新增的交互行为数据实际上就是会影响交互关系的有无，那么可以理解的是，在将新增的交互行为数据首次写入目标数据库之后，没有发生过更新的存量的交互关系都是有效的；而在新增的交互行为数据首次写入目标数据库之后，发生了更新的存量的交互关系都已经在源数据库和目标数据库中都进行了相应的更新。

因此本实施例中可以获取将新增的交互行为数据首次写入目标数据库的第一时刻，并且根据第一时刻，将源数据库中存储的交互关系，导入至目标数据库中，以完成交互关系的有效存量数据的迁移。以及无效的存量数据也通过上述介绍的新增的交互行为数据完成了迁移。

以及本实施例中的对象标识集合也类似，用户是否针对某个对象进行过交互行为，其也是会随着新增的交互数据发生变化的，因此同样可以根据第一时刻，将源数据库中存储的对象标识集合，存储到目标数据库中，以完成对象标识集合的有效存量数据的迁移。以及无效的存量数据也通过上述介绍的新增的交互行为数据完成了迁移。

基于上述介绍的内容，还需要说明的是，本公开中会存在存量数据的迁移操作，还存在增量数据的写入操作。其中增量数据在写入到目标数据库和源数据库之后，就直接对目标数据库和源数据库中的交互数据进行更新了，也就是说无需等待存量数据迁移完成，就能进行增量数据的处理。因此本实施例中的存量数据的迁移和增量数据的写入是同步进行的，不存在先后顺序。因此上述步骤S301～S303的实现顺序可以根据实际需求进行确定，本实施例并不限制各个步骤之间的执行顺序。

本公开实施例提供的数据迁移方法，包括：获取新增的交互行为数据，并将新增的交互行为数据分别写入源数据库和目标数据库，以分别更新源数据库和目标数据库中存储的交互数据，交互数据包括如下中的至少一种：对象交互数量、对象与用户的交互关系、对象标识集合。针对多个对象中的第一对象，在源数据库中获取第一对象的第一对象交互数量，以及在目标数据库中获取第一对象的第二对象交互数量。根据第一对象交互数量和第二对象交互数量的差值，将源数据库中的第一对象交互数量导入至目标数据库中。获取将新增的交互行为数据首次写入目标数据库的第一时刻，并根据第一时刻，将源数据库中存储的交互关系、对象标识集合，导入至目标数据库。通过根据源数据库中存储的交互对象数量和目标数据库中存储的交互对象数量的差值，将源数据库中的交互对象数量反馈给目标数据库，从而可以实现将源数据库中有效的存量交互数据，迁移到目标数据库。此外，本实施例中还会将新增的交互行为数据分别写入到源数据库和目标数据库，并且分别更新源数据库和目标数据库中所存储的交互数据，可以保证针对数据更新的情况是在源数据库和目标数据库中都进行了记录的，因此可以在不依赖数据库快照的前提下，有效完成数据迁移，并且保证源数据库和目标数据库中的数据是一致的，以提升数据迁移的效率，并且避免数据库资源浪费。

为使读者更深刻地理解本公开的实现原理，现结合附图7-图9对图 3所示的实施例进行进一步细化。图7为本公开实施例提供的数据迁移方法的流程图二，图8为本公开实施例提供的更新数据库中的对象交互数量的实现示意图一，图9为本公开实施例提供的更新数据库中的对象交互数量的实现示意图二。

如图7所示，该方法包括：

S701、获取新增的交互行为数据，并将新增的交互行为数据分别写入源数据库和目标数据库，以分别更新源数据库和目标数据库中存储的交互数据，交互数据包括如下中的至少一种：对象交互数量、对象与用户的交互关系、对象标识集合。

其中，S701的实现方式与上述介绍的S301的实现方式类似，此处不再赘述。

在一种可能的实现方式中，本实施例中在将新增的交互行为数据写入到源数据库和目标数据库的时候，可以是独立写入的。比如说可以针对源数据库设置有第一通道，针对目标数据库设置有第二通道。此处的通道比如说可以理解为消费队列。

则比如说可以将新增的交互行为数据写入源数据库对应的第一通道，以使得源数据库从第一通道中获取新增的交互行为数据；以及，将新增的交互行为数据写入源数据库对应的第二通道，以使得源数据库从第二通道中获取新增的交互行为数据。

通过不同的通道将新增的交互行为数据分别写入到源数据库和目标数据库，可以保证无论哪一个数据库发生数据写入的异常，都不影响另一个数据库的数据写入，从而可以有效的提升增量数据写入的正确性和稳定性。

S702、针对多个对象中的第一对象，在源数据库中获取第一对象的第一对象交互数量，以及在目标数据库中获取第一对象的第二对象交互数量。

为了更好的理解存量的对象交互数量的迁移，下面先结合图8和图9对根据新增的交互行为数据对源数据库和目标数据库中的对象交互数量进行更新的可能的实现方式进行介绍。

在一种可能的实现方式中，参见图8，假设源数据库中存储的回答A的点赞数量是234，以及目标数据库中存储的回答A的点赞数量是0，也就是说源数据库中存量的对象交互数量还没有迁移到目标数据库中。假设在图8 的这种情况下，存在一条新增的交互行为数据，指示用户1针对回答A进行了点赞。

则需要将源数据库和目标数据库中回答A的点赞数量分别加1，则得到图8所示的结果，源数据库中存储的回答A的点赞数量变成了235，目标数据库中存储的回答A的点赞数量变成了1。

在另一种可能的实现方式中，参见图9，假设源数据库中存储的回答A 的点赞数量是234，以及目标数据库中存储的回答A的点赞数量也是234，也就是说源数据库中存量的对象交互数量已经迁移到目标数据库中了。假设在图9的这种情况下，存在一条新增的交互行为数据，指示用户1针对回答 A进行了点赞。

则需要将源数据库和目标数据库中回答A的点赞数量分别加1，则得到图9所示的结果，源数据库中存储的回答A的点赞数量变成了235，目标数据库中存储的回答A的点赞数量也变成了235。

上述图8和图9只是简单的介绍了更新源数据库和目标数据库中的对象交互数量的两种情况，实际上的更新情况是数量非常多的，但是其实现原理与上述介绍的是类似的。

因此可以理解的是，在源数据库中存储有多个对象的对象交互数量，针对目标数据库也类似。同时，针对多个对象的对象交互数量的迁移方式都是类似的，下面以多个对象中的第一对象为例进行介绍，可以理解的是，第一对象可以是多个对象中的任意一个对象。

比如说在图8的示例中，第一对象可以是回答A，以及假设是针对更新后的点赞数量进行获取，那么在源数据库中获取的第一对象交互数量就可以是“235”，以及在目标数据库中获取的第二对象交互数量就可以是“1”。

再比如说在图9的示例中，第一对象可以是回答A，以及假设是针对更新后的点赞数量进行获取，那么在源数据库中获取的第一对象交互数量就可以是“235”，以及在目标数据库中获取的第二对象交互数量就可以是“235”。

S703、将第一对象交互数量和第二对象交互数量的差值，确定为目标差值。

在获取到第一对象交互数量和第二对象交互数量之后，例如可以确定第一对象交互数量和第二对象交互数量的差值，并且将这个差值确定为目标差值。

比如说在图8的示例中，目标差值就是234。再比如说在图9的示例中，目标差值就是0。

S704、将目标差值导入至目标数据库，以根据目标差值对第二对象交互数量进行更新，更新后的第二对象交互数量和第一对象交互数量相同。

在确定目标差值之后，实际上就确定了目标数据库中存储的对象交互数量，和源数据库中存储的对象交互数量的差异，之后可以将目标差值导入到目标数据库中，以根据目标差值对第二对象交互数量进行更新之后的第二对象交互数量和源数据库中的第一对象交互数量是相同的。

比如说在图8的示例中，确定的目标差值是234，那么将目标差值234 导入至目标数据库之后，根据目标差值和目标数据库中的第二对象交互数量进行融合，此处的融合比如说可以是加和处理，因此就可以确定目标数据库中更新后的第二对象交互数量也是235，这样就实现了源数据库中记录的回答A的点赞数量和目标数据库中记录的回答A的点赞数量是相同的。

再比如说在图9的示例中，确定的目标差值是0，那么将目标差值0导入至目标数据库之后，根据目标差值和目标数据库中的第二对象交互数量进行融合，此处的融合比如说可以是加和处理，因此就可以确定目标数据库中更新后的第二对象交互数量仍然是235，这样就保证了源数据库中记录的回答A的点赞数量和目标数据库中记录的回答A的点赞数量是相同的。

基于上述介绍可以理解的是，无论是将存量数据导入至目标数据库之前，存量数据发生更新，还是将存量数据导入至目标数据库之后，存量数据发生更新，都可以保证数据迁移完成之后，源数据库中和目标数据库中所存储的对象交互数量都是一致的。因此本实施例中可以实现增量数据和存量数据同步迁移，并且保证源数据库和目标数据库中的数据还是一致的，因此也就无需依赖数据库快照进行数据迁移。

同时，还可以进一步理解的是，上述介绍的是，将第一对象交互数量和第二对象交互数量的差值导入至目标数据库中，以对目标数据库中的第二对象交互数量进行更新，这是一种可能的实现方式，比如说可以适用于目标数据库中的数据处理接口是具体进行的是数据融合操作的情况。在这种实现方式中，将差值同步给目标数据库，以使得目标数据库对差值和本身存储的第二对象交互数量进行融合，可以有效的保证更新后的第二对象交互数量和第一对象交互数量是一致的，同时还可以有效的保证在目标数据库中所写入的增量数据是被充分利用了的。

或者在另一种可能的实现方式中，还可以将源数据库中的第一对象交互数量直接导入至目标数据库中，以将目标数据库中的第二对象交互数量直接更新为第一对象交互数量，也可以有效的保证源数据库中和目标数据库中所存储的对象交互数量是一致的。

以及在本实施例的一种可能的实现方式中，在向目标数据库导入存量的对象交互数量的时候，因为各个对象的对象交互数量不存在先后关系，只需要保证最终数据迁移完成之后，因此比如说可以采用多进程来进行存量的对象交互数量的导入，因此可以有效的提升存量数据的迁移速度。

S705、将第一对象对应的迁移状态标记为已迁移。

在将第一对象所对应的对象交互数量迁移完成之后，比如说可以将第一对象所对应的迁移状态标记为已迁移。

可以理解的是，针对每一个对象的对象交互数量都会进行上述介绍的迁移操作。在一种可能的实现方式中，在源数据库中的各个对象所对应的迁移状态均标记为已迁移的时候，就可以确定对象交互数量的迁移完成。

S706、针对多条交互关系中的第一交互关系，获取源数据库中第一交互关系对应的第一更新时刻；若第一更新时刻早于第一时刻，则将第一交互关系导入至目标数据库。

以及本实施例中还需要进行交互关系的存量数据的迁移，基于上述介绍可以确定的是，本公开中将新增的交互行为数据首次写入到目标数据库的时刻称为第一时刻，其中第一时刻可以理解为是增量数据开始写入目标数据库和源数据库的时刻。

以及本实施例中在将新增的交互行为数据写入到源数据库和目标数据库的时候，还会针对源数据库和目标数据库中的交互数据进行更新。具体的，就会对交互关系和对象标识集合进行更新。

那么在一种可能的实现方式中，针对源数据库中的每一条交互关系都对应有各自的更新时刻。可以理解的是，交互关系的更新，要不然就是交互关系的生成，要不然就说交互关系的删除，因此此处的更新时刻比如说可以理解为交互关系的生成时刻。

在源数据库中存储有多条交互关系，针对每一条交互关系的处理方式都是类似的，因此下面以多条交互关系中的第一交互关系为例进行说明，其中第一交互关系可以是多条交互关系中的任意一条。

其中，针对多条交互关系中的第一交互关系，可以获取源数据库中的第一交互关系所对应的第一更新时刻。

在一种可能的实现方式中，若第一更新时刻早于第一时刻，则可以确定第一交互关系是在增强数据写入之前就存在，并且在增量数据写入之后也没有发生更新，也就是说新增的交互行为数据并没有影响到这一条交互关系，那么第一交互关系就是有效的，因此可以将第一交互关系导入至目标数据库中。

此处比如说可以结合一个具体的示例进行说明，比如说某一条交互关系是“用户1针对回答A进行了点赞”，以及假设这一条交互关系是10月7 日16点59分59秒创建的，那么这一条交互关系的更新时刻就是10月7日 16点59分59秒。

再比如说增量数据是从10月8日24点00分00秒开始写入源数据库和目标数据库中的，那么可以确定第一时刻就是10月8日24点00分00秒。

那么基于当前的这个情况可以确定的是，这一条交互关系在10月7日 16点59分59秒之后，并未发生更新过，保持着“用户1针对回答A进行了点赞”的这个状态，那么也就是说新增的交互行为数据并没有影响到这一条交互关系，因此这条交互关系就是有效的，因此可以将这条交互关系导入至目标数据库中。

再比如说还有另一种情况，就是用户取消了针对某个对象的某项交互操作，如果说这个取消动作对应的更新时刻是在第一时刻之前，那么这一项取消操作所对应的交互关系就已经被删除了，无需再进行迁移操作。

在另一种可能的实现方式中，若第一更新时刻晚于第一时刻，则可以确定第一交互关系是在增强数据写入之后才存在，也就是说新增的交互行为数据影响到了这一条交互关系，那么第一交互关系就是无效的，因此这样的交互关系无需导入至目标数据库中，这个会通过增量数据的写入更新交互关系的时候，记录在目标数据库中。

此处比如说可以结合一个具体的示例进行说明，比如说某一条交互关系是“用户1针对回答A进行了点赞”，以及假设这一条交互关系是10月9 日16点59分59秒创建的，那么这一条交互关系的更新时刻就是10月9日 16点59分59秒。

那么基于当前的这个情况可以确定的是，这一条交互关系是在增量数据开始写入之后，在10月9日16点59分59秒才生成的，也就是说这一条交互关系是根据新增的交互行为数据生成的。那么新增的交互行为数据除了会在源数据库中生成这条交互关系之外，也会在目标数据库中生成这条交互关系，因此源数据库中的这条交互关系就是无效的，也就无需将这条交互关系导入至目标数据库中。

再比如说还有另一种情况，就是用户取消了针对某个对象的某项交互操作，如果说这个取消动作对应的更新时刻是在第一时刻之后，那么这一项取消操作所对应的交互关系在源数据库和目标数据库中都进行了删除，同样无需再进行迁移操作。

可以理解的是，存量数据的迁移和增量数据的写入是同步发生的，因此某一条交互关系具体是不是有效的，可能是会发生变化的，因此本实施例中是针对多条交互关系依次迁移，在迁移到某条交互关系的时候，再实时的判断交互关系的更新时刻是否早于第一时刻，然后再确定是否要进行迁移。

S707、针对多个用户中的第一用户，获取源数据库中第一用户对应的第一对象标识集合对应的第二更新时刻；若第二更新时刻早于第一时刻，则将第一对象标识集合导入至目标数据库。

以及本实施例中还需要进行对象标识集合的存量数据的迁移，与交互关系的迁移类似，针对源数据库中的每一条对象标识集合都对应有各自的更新时刻。在一种可能的实现方式中，用户每进行一次交互行为，比如说点赞、取消点赞、评论、取消评论等等，用户所对应的对象标识集合都会重新生成一次，以保证用户的对象标识集合是正确的。

在源数据库中存储有多个用户的对象标识集合，针对每一个用户的对象标识集合的处理方式都是类似的，因此下面以多个用户中的第一用户为例进行说明，其中第一用户可以是多个用户中的任意一个。

其中，针对第一用户对应的第一对象标识集合，可以获取源数据库中的第一对象标识集合所对应的第二更新时刻。

在一种可能的实现方式中，若第二更新时刻早于第一时刻，则可以确定第一对象标识集合是在增强数据写入之前就存在，并且在增量数据写入之后也没有发生更新，也就是说新增的交互行为数据并没有影响到这一条对象标识集合，那么第一对象标识集合就是有效的，因此可以将第一对象标识集合导入至目标数据库中。

此处比如说可以结合一个具体的示例进行说明，比如说用户A的对象标识集合中包括“回答A、回答B、回答C”，以及假设这一条对象标识集合是10月7日16点59分59秒创建的，那么这一条对象标识集合的更新时刻就是10月7日16点59分59秒。

那么基于当前的这个情况可以确定的是，这一条对象标识集合在10月7 日16点59分59秒之后，并未发生更新过，保持着“用户A的点赞记录包括回答A、回答B、回答C”的这个状态，那么也就是说新增的交互行为数据并没有影响到这一条对象标识集合，因此这条对象标识集合就是有效的，因此可以将这条对象标识集合导入至目标数据库中。

在另一种可能的实现方式中，若第一更新时刻晚于第一时刻，则可以确定第一对象标识集合是在增强数据写入之后才新更新的，也就是说新增的交互行为数据影响到了这一条对象标识集合，那么第一对象标识集合就是无效的，因此这样的对象标识集合无需导入至目标数据库中，这个会通过增量数据的写入更新对象标识集合的时候，记录在目标数据库中。

此处比如说可以结合一个具体的示例进行说明，比如说用户A的对象标识集合中包括“回答A、回答B、回答C”，以及假设这一条对象标识集合是10月9日16点59分59秒创建的，那么这一条对象标识集合的更新时刻就是10月9日16点59分59秒。

那么基于当前的这个情况可以确定的是，这一条对象标识集合是在增量数据开始写入之后，在10月9日16点59分59秒才生成的，也就是说这一条对象标识集合是根据新增的交互行为数据生成的。那么新增的交互行为数据除了会在源数据库中生成这条对象标识集合之外，也会在目标数据库中生成这条对象标识集合，因此源数据库中的这条对象标识集合就是无效的，也就无需将这条对象标识集合导入至目标数据库中。

可以理解的是，存量数据的迁移和增量数据的写入是同步发生的，因此某一条对象标识集合具体是不是有效的，可能是会发生变化的，因此本实施例中是针对多条对象标识集合依次迁移，在迁移到某条对象标识集合的时候，再实时的判断对象标识集合的更新时刻是否早于第一时刻，然后再确定是否要进行迁移。

本公开实施例提供的数据迁移方法，在向源数据库和目标数据库中写入增量数据的时候，是采用独立的通道实现数据提交的，这样可以保证任意一个数据库的异常都不会影响另一个数据库的增量数据写入，从而可以有效的保证增量数据提交的稳定性和安全性。以及在进行存量的对象交互数量的迁移的时候，是针对源数据库中的每一个对象，获取其在源数据库中的第一对象交互数量，以及获取其在目标数据库中的第二对象交互数量，之后将第一对象交互数量和第二对象交互数量的差值同步给目标数据库，以使得目标数据库可以根据差值和目标数据库中存储的第二对象交互数量进行融合，从而保证目标数据库中存储的对象交互数量和源数据库中存储的对象交互数量是一致的。同时，在进行存量的交互关系和对象标识集合的迁移的时候，是将更新时刻在首次写入增量数据的时刻之前的交互关系和对象标识集合，确定为有效的数据，之后仅仅针对有效的存量数据进行迁移，而针对无效的存量数据，会通过增量数据的提交更新在目标数据库中，因此可以保证源数据库中和目标数据库交互关系和用户交互关系的存储也是一致的。同时可以确定的是，本实施例中的增量数据的提交和存量数据的提交是同步进行的，并且无需依赖数据库快照，因此可以快速并且不占用额外数据的前提下，有效的实现数据迁移。同时本实施例中对象交互数量、交互关系、对象标识集合也是不同维度的数据，其也可以进行同步提交，同时也不会造成数据错误和混乱，因此可以有效的提升数据迁移的速度和效率。

在上述介绍内容的基础上，可以理解的是，数据迁移的过程通常会持续一定的时间，因此在数据迁移的过程中，系统还是会接收到数据读取的请求，因此下面结合图10和图11对数据读取请求的处理方式进行说明。图10为本公开实施例提供的数据读取请求的流程图三，图11为本公开实施例提供的取模数值和读取接口的对应关系示意图。

如图10所示，该方法包括：

S1001、在接收到数据读取请求时，根据数据读取请求对应的请求标识，确定数据读取请求对应的目标读取接口，目标读取接口为第一读取接口或者第二读取接口。

在本实施例中，针对源数据库设置有第一读取接口，以及针对目标数据库也设置有第二读取接口，这两个读取接口都可以用于读取数据。

本实施例中可以接收数据读取请求，其中数据读取请求携带有请求标识，其中请求标识比如说可以是用户的登录账号，或者用户未登录的时候，请求标识比如说还可以是系统分配的临时用户标识。其中请求标识的具体实现方式可以根据实际需求进行选择和设置，本实施例对此不做限制。

则在接收到数据读取请求的时候，可以根据数据读取请求中的请求标识，确定数据读取请求所对应的目标读取接口，其中目标读取接口可以是第一读取接口，也可以是第二读取接口。

在一种可能的实现方式中，比如说可以对请求标识进行取模，从而得到目标取模数值。

以及本实施例中还可以设置有取模数值和读取接口的对应关系，比如说可以结合图11进行理解，取模数值为0、1、2、3、4、5、6、7的时候，对应的读取接口是第一读取接口。取模数值为8和9的时候，对应的读取接口是第二读取接口。

则在确定目标取模数值之后，可以根据预先设置的对应关系，确定目标取模数值所对应的目标读取接口。比如说目标取模数值是4，则对应的就是第一读取接口。

可以理解的是，根据请求标识确定数据读取请求所对应的目标读取接口，实际上就是为了将数据读取请求进行分流，在此基础上，根据请求标识确定数据读取请求所对应的目标读取接口的实现方式可以根据实际需求进行选择和设置。

S1002、将数据读取请求发送给目标读取接口，以获取数据读取请求对应的目标数据。

在确定目标读取接口之后，就可以将数据读取请求发送给目标读取接口了，以从目标读取接口所对应的数据库中，获取数据读取请求所对应的目标数据。

以及在一种可能的实现方式中，上述介绍的取模数值和读取接口的对应关系，还可以定时的进行更新。

可以理解的是，本实施例中将数据从源数据库中迁移到目标数据库中，实际上目标数据库就是以后常用的数据库，因此本实施例中就需要将数据读取请求慢慢的切换到目标数据库，以从目标数据库中获取数据。

然而可以理解的是，在数据迁移的最开始，目标数据库中的数据量是比较少的，而源数据库中的数据一直都是齐全的，因此最开始的时候，只需要将很少一部分的数据读取请求切换至目标数据库。随着数据迁移过程的进行，再慢慢的增加数据读取请求切换至目标数据库的比重，直至最终数据迁移完成之后，再将所有的数据读取请求都迁移到目标数据库，以实现之后都从目标数据库中获取数据。

因此本实施例中可以以预设时长为单位，更新取模数值和读取接口的对应关系，其中更新过程包括，增加第二读取结果所对应的取模数值，减少第一读取接口所对应的取模数值。其中每次具体如何增加、如何减少，都可以根据实际需求进行选择和设置。

在一个可能的示例中，比如说最开始的时候，取模数值为0、1、2、3、 4、5、6、7，8，9的时候，对应的读取接口是第一读取接口。也就是说所有的数据读取请求都从源数据库中读取数据。

再比如说随着迁移过程的进行，对应关系变成了，取模数值为0、1、 2、3、4、5、6、7的时候，对应的读取接口是第一读取接口。取模数值为 8和9的时候，对应的读取接口是第二读取接口。

再比如说随着迁移过程的继续进行，对应关系变成了，取模数值为0、 1、2、3、4的时候，对应的读取接口是第一读取接口。取模数值为5、6、 7、8、9的时候，对应的读取接口是第二读取接口。

在最终数据迁移完成之后，对应关系就变成了，取模数值为0、1、2、 3、4、5、6、7，8，9的时候，对应的读取接口是第二读取接口。也就是说所有的数据读取请求都从目标数据库中读取数据。

并且在切流的过程中，若目标数据库发生任何的异常，则可以随时回退，也就是说调整取模数值和读取接口的对应关系，以从源数据库中读取数据，进而保证系统稳定性。

以及在一种可能的情况下，尽管数据读取请求是逐步的切换至目标数据库进行处理的，但是因为数据迁移过程中，目标数据库中的数据是不全的，因此可能出现在目标数据库中无法获取到数据读取请求对应的目标数据的情况。在出现这样的情况时，可以将数据读取请求再发送给源数据库的第一读取接口，以保证每一个数据读取请求都可以得到妥善处理。

以及在数据迁移完成之后，所有的数据读取请求都提交给目标数据库进行处理，在这种情况下，在目标数据库出现异常的时候，仍然可以再使用源数据库处理数据读取请求，以保证系统的鲁棒性。

本公开实施例提供的数据迁移方法，通过在数据迁移的过程中，在源数据库和目标数据库都设置有数据读取接口，然后将接收到的数据读取请求分流到源数据库和目标数据库进行处理，并且逐渐的增加分给目标数据库的数据读取请求的比重，从而可以实现数据读取接口的平滑切换。可以理解的是，若直接将数据读取接口切换至目标数据库，本身接口的切换会增加一定的耗时，并且切换过程中的流量过大以及没有回滚方案，则有可能导致数据处理异常的状况频发，而本实施例中进行数据接口的平滑切换，就可以有效的避免这个问题，进而保证系统稳定性。

在实现上述介绍的内容的过程中，其具体是通过程序运行实现的，在一种可能的实现方式中，比如说可以动态记录程序的运行位置，之后按运行内存大小，定时重启程序，再次启动时按上次断点位置继续导入，从而可以有效的解决运行时间过长导入内存异常问题，以及在依赖HipHop虚拟机(HipHop Virtual Machine，HHVM)进行程序运行的时候，可以解决 HHVM占用内存过大问题

其中，在hhvm启动程序时，比如说可以设置开启轻进程数量选项，从而减少导入数据时启动过多的进程，限制内存使用过大。

以及在一种可能的实现方式中，在调用目标数据库的存量数据导入接口的时候，比如说可以测试得出单进程在使用并发请求方法时，每秒查询率(Queries-per-second，qps)达到最大的1000，则例如可以要求qps大于1000时，可采用多进程方式满足。

其中，单进程并发请求时，并发请求的日志id为同一个，从而可以针对请求日志的同一个请求id区分不同请求。此处的并发请求就是指存量数据导入过程中不同类型的存量数据是并发处理的。

在上述介绍内容的基础上，比如说可以结合图12对本公开提供的数据迁移方法进行进一步的理解，图12为本公开实施例提供的数据库接口的示意图。

如图12所示，源数据库和目标数据库都设置有增量数据提交接口，则可以通过增量数据提交接口，将增量数据分别提交给源数据库和目标数据库，以对源数据库和目标数据库中的交互数据进行更新。

以及，目标数据库还是设置有存量数据导入接口，则可以通过该存量数据导入接口，将源数据库中的存量数据迁移至目标数据库中。在数据迁移过程中的具体实现方式，可以参照上述实施例的介绍，此处对此不再赘述。

综上所述，本公开实施例提供的数据迁移方法，能在大量级数据迁移过程中，不使用成本较高快照保存存量的方式，而是完成存量+增量数据的并行迁移，提升迁移效率，保障迁移数据准确度。在大流量读取接口的切换上，能保证流量逐步切换，且可以随时回退，以保证系统稳定性。

图13为本公开实施例的数据迁移装置的结构示意图。如图13所示，本实施例的数据迁移装置1300可以包括：提交模块1301、获取模块1302、第一导入模块1303、第二导入模块1304、处理模块1305。

提交模块1301，用于获取新增的交互行为数据，并将所述新增的交互行为数据分别写入源数据库和目标数据库，以分别更新所述源数据库和所述目标数据库中存储的交互数据，所述交互数据包括如下中的至少一种：对象交互数量、对象与用户的交互关系、对象标识集合；

获取模块1302，用于针对多个对象中的第一对象，在所述源数据库中获取所述第一对象的第一对象交互数量，以及在所述目标数据库中获取所述第一对象的第二对象交互数量；

第一导入模块1303，用于根据所述第一对象交互数量和所述第二对象交互数量的差值，将所述源数据库中的第一对象交互数量导入至所述目标数据库中；

第二导入模块1304，用于获取将所述新增的交互行为数据首次写入所述目标数据库的第一时刻，并根据所述第一时刻，将所述源数据库中存储的交互关系、对象标识集合，导入至所述目标数据库。

在一种可能的设计中，所述第一导入模块1303具体用于：

将所述第一对象交互数量和所述第二对象交互数量的差值，确定为目标差值；

将所述目标差值导入至所述目标数据库，以根据所述目标差值对所述第二对象交互数量进行更新，更新后的第二对象交互数量和所述第一对象交互数量相同。

在一种可能的设计中，所述第一导入模块1303，还用于：

在所述将所述目标差值导入至所述目标数据库之后，将所述第一对象对应的迁移状态标记为已迁移；

其中，在所述源数据库中的各个对象所对应的迁移状态均标记为已迁移时，确定所述对象交互数量的迁移完成。

在一种可能的设计中，所述源数据库中存储有多条交互关系，以及存储有多个用户的对象标识集合；

所述第二导入模块1304具体用于：

针对所述多条交互关系中的第一交互关系，获取所述源数据库中所述第一交互关系对应的第一更新时刻；若所述第一更新时刻早于所述第一时刻，则将所述第一交互关系导入至所述目标数据库；以及，

针对所述多个用户中的第一用户，获取所述源数据库中所述第一用户对应的第一对象标识集合对应的第二更新时刻；若所述第二更新时刻早于所述第一时刻，则将所述第一对象标识集合导入至所述目标数据库。

在一种可能的设计中，所述提交模块1301具体用于：

将所述新增的交互行为数据写入所述源数据库对应的第一通道，以使得所述源数据库从所述第一通道中获取所述新增的交互行为数据；以及，

将所述新增的交互行为数据写入所述源数据库对应的第二通道，以使得所述源数据库从所述第二通道中获取所述新增的交互行为数据。

在一种可能的设计中，所述源数据库设置有第一读取接口，所述目标数据库设置有第二读取接口；

所述装置还包括：处理模块1305；

所述处理模块1305用于：

在接收到数据读取请求时，根据所述数据读取请求对应的请求标识，确定所述数据读取请求对应的目标读取接口，所述目标读取接口为所述第一读取接口或者所述第二读取接口；

将所述数据读取请求发送给所述目标读取接口，以获取所述数据读取请求对应的目标数据。

在一种可能的设计中，所述处理模块1305具体用于：

对所述请求标识进行取模，得到目标取模数值；

根据取模数值和读取接口的对应关系，确定所述目标取模数值对应的目标读取接口。

在一种可能的设计中，所述处理模块1305还用于：

以预设时长为单位，更新所述取模数值和读取接口的对应关系；

所述更新过程包括：

增加所述第二读取接口所对应的取模数值，减少所述第一读取接口所对应的取模数值。

本公开提供一种数据迁移方法及装置，应用于数据处理领域中的智能搜索和大数据领域，以达到提升数据迁移的效率，并且不浪费数据库资源的目的。

需要说明的是，本实施例中的人头模型并不是针对某一特定用户的人头模型，并不能反映出某一特定用户的个人信息。需要说明的是，本实施例中的二维人脸图像来自于公开数据集。

本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

根据本公开的实施例，本公开还提供了一种计算机程序产品，计算机程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一实施例提供的方案。

图14示出了可以用来实施本公开的实施例的示例电子设备1400的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图14所示，设备1400包括计算单元1401，其可以根据存储在只读存储器(ROM)1402中的计算机程序或者从存储单元1408加载到随机访问存储器(RAM)1403中的计算机程序，来执行各种适当的动作和处理。在RAM 1403中，还可存储设备1400操作所需的各种程序和数据。计算单元1401、ROM 1402以及RAM 1403通过总线1404彼此相连。输入/输出(I/O)接口1405也连接至总线1404。

设备1400中的多个部件连接至I/O接口1405，包括：输入单元1406，例如键盘、鼠标等；输出单元1407，例如各种类型的显示器、扬声器等；存储单元1408，例如磁盘、光盘等；以及通信单元1409，例如网卡、调制解调器、无线通信收发机等。通信单元1409允许设备1400通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1401可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1401的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1401执行上文所描述的各个方法和处理，例如数据迁移方法。例如，在一些实施例中，数据迁移方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1408。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1402和/或通信单元1409而被载入和/或安装到设备1400上。当计算机程序加载到RAM 1403并由计算单元1401执行时，可以执行上文描述的数据迁移方法的一个或多个步骤。备选地，在其他实施例中，计算单元1401 可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行数据迁移方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、复杂可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/ 或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入) 来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims

1.一种数据迁移方法，包括：

获取新增的交互行为数据，并将所述新增的交互行为数据分别写入源数据库和目标数据库，以分别更新所述源数据库和所述目标数据库中存储的交互数据，所述交互数据包括如下中的至少一种：对象交互数量、对象与用户的交互关系、用户所交互的对象的对象标识集合；

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一对象交互数量和所述第二对象交互数量的差值，将所述源数据库中的第一对象交互数量导入至所述目标数据库中，包括：

3.根据权利要求2所述的方法，其特征在于，所述将所述目标差值导入至所述目标数据库之后，所述方法还包括：

将所述第一对象对应的迁移状态标记为已迁移；

4.根据权利要求1-3任一项所述的方法，其特征在于，所述源数据库中存储有多条交互关系，以及存储有多个用户的对象标识集合；

所述根据所述第一时刻，将所述源数据库中存储的交互关系、对象标识集合，导入至所述目标数据库，包括：

5.根据权利要求1-4任一项所述的方法，其特征在于，所述将所述新增的交互行为数据分别写入源数据库和目标数据库，包括：

6.根据权利要求1-5任一项所述的方法，其特征在于，所述源数据库设置有第一读取接口，所述目标数据库设置有第二读取接口；

所述方法还包括：

7.根据权利要求6所述的方法，其特征在于，所述根据所述数据读取请求对应的请求标识，确定所述数据读取请求对应的目标读取接口，包括：

对所述请求标识进行取模，得到目标取模数值；

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

所述更新过程包括：

9.一种数据迁移装置，包括：

10.根据权利要求9所述的装置，其特征在于，所述第一导入模块具体用于：

11.根据权利要求10所述的装置，其特征在于，所述第一导入模块，还用于：

12.根据权利要求9-11任一项所述的装置，其特征在于，所述源数据库中存储有多条交互关系，以及存储有多个用户的对象标识集合；

所述第二导入模块具体用于：

13.根据权利要求9-12任一项所述的装置，其特征在于，所述提交模块具体用于：

14.根据权利要求9-13任一项所述的装置，其特征在于，所述源数据库设置有第一读取接口，所述目标数据库设置有第二读取接口；

所述装置还包括：处理模块；

所述处理模块用于：

15.根据权利要求14所述的装置，其特征在于，所述处理模块具体用于：

对所述请求标识进行取模，得到目标取模数值；

16.根据权利要求15所述的装置，其特征在于，所述处理模块还用于：

所述更新过程包括：

17.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-8中任一项所述的方法。

18.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-8中任一项所述的方法。

19.一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现权利要求1-8中任一项所述方法的步骤。