CN104598459B - 数据库处理、数据访问方法及系统 - Google Patents

Abstract

本申请公开了数据库处理、数据访问方法及系统，其中，所述数据库处理方法包括：确定在特定时间段内待迁移的目标数据以及所述目标数据对应的应用；将所述目标数据临时迁移到目标存储区；将所述目标数据的标识信息通知给所述应用，以便所述应用在产生对数据的访问操作时，根据所述标识信息识别所述目标数据，并到所述目标存储区访问所述目标数据。通过本申请，能够在可能会出现存储资源不足的情况时，避免由于争抢存储资源而造成系统性能下降。

Description

数据库处理、数据访问方法及系统

技术领域

本申请涉及数据库技术领域，特别是涉及数据库处理、数据访问方法及系统。

背景技术

一般而言，互联网应用系统在为用户提供业务或者服务的过程中，都需要数据库的支持。例如，电子商务交易平台中，需要在数据库中保存卖家用户上传的商品对象的描述、库存信息，等等。但在实际应用中，数据库操作经常出现瓶颈问题。

例如，在数据库系统中，为了保证事务的ACID特性（原子性、一致性、隔离性、持久性），一般都采用锁机制，包括主流的Oracle、MySQL、SQL Server等，各类数据库采用的锁理论也基本一致。引入锁机制之后，在同一时间点只有一个会话可以操作同一条数据。这样，假设并发产生了10个会话都需要操作该数据，则只有其中一个会话能够获得锁，其他9个会话都处于锁等待状态。也就是说，更新同一条数据的操作都是串行的，在数据库访问量很大的情况下，会使得整体性能以及服务能力降低。

因此，迫切需要本领域技术人员解决的技术问题就在于：如何在可能会出现存储资源不足的情况时，避免由于争抢存储资源而造成系统性能下降。

发明内容

本申请提供了数据库处理、数据访问方法及系统，能够在可能会出现存储资源不足的情况时，避免由于争抢存储资源而造成系统性能下降。

本申请提供了如下方案：

一种数据库处理方法，包括：

确定在特定时间段内待迁移的目标数据以及所述目标数据对应的应用；

将所述目标数据临时迁移到目标存储区；

将所述目标数据的标识信息通知给所述应用，以便所述应用在产生对数据的访问操作时，根据所述标识信息识别所述目标数据，并到所述目标存储区访问所述目标数据。

一种数据访问方法，包括：

接收通知消息，所述通知消息中携带有被临时迁移到目标存储区的目标数据的标识信息；

当产生对数据的访问操作时，根据所述标识信息识别待访问的数据是否为所述目标数据；

如果是，则根据预置的目标存储区的地址及端口号，连接到所述目标存储区访问所述目标数据。

一种数据库处理系统，包括：

目标数据确定单元，用于确定在特定时间段内待迁移的目标数据以及所述目标数据对应的应用；

第一数据迁移单元，用于将所述目标数据临时迁移到目标存储区；

通知单元，用于将所述目标数据的标识信息通知给所述应用，以便所述应用在产生对数据的访问操作时，根据所述标识信息识别所述目标数据，并到所述目标存储区访问所述目标数据。

一种数据访问系统，包括：

通知消息接收单元，用于接收通知消息，所述通知消息中携带有被临时迁移到目标存储区的目标数据的标识信息；

目标数据识别单元，用于当产生对数据的访问操作时，根据所述标识信息识别待访问的数据是否为所述目标数据；

连接单元，用于如果是，则根据预置的目标存储区的地址及端口号，连接到所述目标存储区访问所述目标数据。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，在系统可能会出现存储资源不足的情况时，可以临时将部分数据迁移到目标存储区，并将这部分数据的标识信息通知给各个应用，这样，应用就可以识别出已经被迁移的数据，进而在产生的对这部分数据的访问请求时，就会被引流到目标存储区。相当于一部分访问请求是在原来的数据库中进行，而另一部分访问请求则是在目标存储区中进行，从而避免由于争抢存储资源而造成系统性能下降。

另外，结合具体的应用场景，本申请实施例可以实现将热点数据与非热点数据隔离，避免少量的热点数据影响到大量的非热点数据的处理。另外，待迁移的目标数据也可以是当数据库的访问量比较大、数据库资源不足时，数据库中任意的一部分数据，将这部分数据临时迁移到其他存储区，当访问量恢复到日常水平时，还可以再迁移回原来的数据库，相当于实现了数据库的动态扩容或缩容，并且这种扩容或缩容可以是非对称的。

再者，本申请实施例还可以实现底层存储的异构，可以将目标数据迁移到不同于源数据库存储结构的其他数据库中，灵活性得到提高。另外还可以将目标数据迁移到缓存中，进一步提高系统的性能。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的数据库处理方法的流程图；

图2是本申请实施例提供的数据访问方法的流程图；

图3是本申请实施例提供的数据库处理系统的示意图；

图4是本申请实施例提供的数据访问系统的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，在必要的时候，可以将源数据库中的一些数据迁移到其他的存储区，之后又可以将数据迁移回源数据库，从而实现动态的数据库扩容或缩容，达到从整体上提高系统性能及服务能力的目的。下面对具体的实现方式进行详细的介绍。

实施例一

参见图1，本申请实施例一首先提供了一种数据库处理方法，该方法可以包括以下步骤：

S101：确定在特定时间段内待迁移的目标数据以及所述目标数据对应的应用；

首先需要说明的是，在本申请实施例提供的技术方案中，可以提供一个“运维平台”，利用该运维平台实现对数据库动态的扩容或缩容，因此，图1中所述各个步骤的执行主体就可以是该运维平台。当然，“运维平台”只是一个形象化的名词，在实际应用中，也可以用其他的名称，但只要通过执行本申请实施例中各个步骤来实现对数据库的处理方案，都属于本申请的保护范围。当然，为了便于描述，本申请实施例中均以“运维平台”为例进行介绍。

运维平台在确定待迁移的目标数据时，具体需要作为目标数据被迁移的数据，也可以根据实际的情况而定。

例如，在实际应用中，可能存在以下情况：数据库中可能会存在一些热点数据（例如，热卖商品对象的库存记录，由于参加营销活动等原因造成其更新次数远高于其他数据），针对这种热点数据，同时可能会有10个以上的会话。由于锁机制的存在，如果有多个热点数据出现在同一个数据库中，将会导致大量的会话处于等待状态，只有少数会话可以正常操作，这样势必导致数据库性能的急剧下降。测试数据显示，如果同一个数据库中出现32个以上的热点数据时，则单库的TPS（每秒处理事务数）相对于没有热点数据时要降低3至5倍。

因此，在本申请实施例中，就可以将上述热点数据确定为待迁移的目标数据。也就是说，为了保证热点数据不会影响其他大量的非热点数据，可以建立一种将热点数据临时迁移到别的存储区（例如，OceanBase数据库集群，或者其他的临时增加的MySQL数据库）的机制，对热点数据使用专门的数据存储物理资源，以起到对热点数据进行隔离的作用。这样既能保证热点数据有充足的物理资源，也能保证热点数据的资源争用不会影响非热点数据的处理，有利于保证整个系统的业务稳定性。

例如，在电子商务交易平台中，经常会出现一些临时性的营销活动，不同的营销活动可能造就不同的热卖商品库存（也即，使得热点商品的库存信息成为热点信息）。因此，可以在活动前临时将热卖商品库存迁移到独立的数据库上，以保证营销活动的顺利进行。比如在大型促销活动前，可以分析哪些商品是大型促销活动的主打商品，根据促销活动的优惠力度及库存量等综合评估其影响，提前进行准热卖商品库存的迁移工作。另外，还可能会有关于某商品对象的专项营销活动，在这种活动中，待迁移的热点数据是很容易识别的。当然，也可以通过历史成交数据的分析，统计出热门商品对象的类别等信息，进行辅助决策，以提升营销活动中热卖商品的准确度。在营销活动后可以数据迁回到原来的数据库，以节约硬件资源成本。

换言之，可以将数据库中的热点数据确定为待迁移的目标数据。具体在确定哪些数据是热点数据时，如前述例子中所述，可以运维平台可以根据系统中的一些数据等进行自动分析。例如，对于即将参加某项营销活动的业务对象而言，一般会在数据库中为业务对象打上特殊的标识，因此，具体在确定待迁移的目标数据时，可以首先通过识别数据库中业务对象的特定标识，确定热点业务对象，然后根据热点业务对象确定预置时间段内将被高并发访问的热点业务数据，将这种热点业务数据确定为待迁移的目标数据。例如，将热点商品对象的库存信息作为热点业务数据，等等。

当然，为了避免系统的误判，还可以对系统的分析结果进行人工核查，在人工核查通过之后，再作为待迁移的热点数据。另外，在具体实现时，也可以通过后台提供界面等形式，允许运维平台的工作人员手动指定热点数据。例如，工作人员可以根据人工分析的方式，获知哪些商品可能会热卖，然后通过操作界面提交该商品的ID等信息，相应的，运维平台就可以将该商品的库存记录确定为热点数据，准备进行迁移。

需要说明的是，在本申请实施例中，对于热点业务数据这种待迁移的目标数据，是在这种业务数据真正成为热点之前识别出来的，这相当于是对热点数据的一种预测，也即，在高并发的访问到来之前，就先将数据迁移到其他存储区。

在前述情况下，是根据数据本身的特点（是否为热点数据）来决定将哪些数据临时迁移到其他存储区，在实际应用中，还可能存在这种情况：数据库日常的访问量比较稳定，但是，一旦出现节假日等特殊时期时，会出现访问量突然大幅增大，节假日过后，访问量又恢复到日常的水平。针对这种情况，如果数据库资源能够满足日常的访问需求，但当访问量短时间内突然增大时，经常会出现数据库资源不足的现象，也是的系统性能下降。虽然可以通过对数据库进行扩容的方式来解决数据库资源不足的问题，但是，现有技术中的数据库扩容只能成倍的增加数据库实例，例如，从32实例增加到64实例，成本会很高，而且也不一定需要增加这么多的数据库实例。另外，现有技术中一旦对数据库进行扩容之后，就很难再缩容，因此，在大多数的日常状态下，会存在数据库资源浪费的问题。

也就是说，上述情况下，数据库的特点是：在一些特定的时间段内，访问量会非常大，并且几乎是所有数据的访问量都比平时要大，不存在明显的热点数据与非热点数据的区别。针对这种情况，在本申请实施例中，也可以通过将一些数据临时迁移到其他存储区的方式，来提高系统的性能。也就是说，从整个数据库角度来看，数据库的总访问量在时间上一般可以体现出一定的规律性，因此，就可以根据这种规律性，预测出数据库的总访问量出现激增的时间段，进而就可以在该时间段将一些数据迁移到其他存储区。具体实现时，可以通过对数据库的历史访问记录进行分析，确定数据库可能会出现高并发访问的时间段，在该时间段到来之前的某时间点，就可以将数据库中的部分数据迁移到目标存储区。同样，当该时间段结束之后，还可以将这些数据迁移回原来的数据库，避免造成资源浪费。

总之，在本申请实施例中，待迁移的目标数据可以是数据库中的热点数据（当然这种热点数据一般也具有时间性，也即，在某一段时间内是热点数据，在其他时间可能就不是热点数据），将这种热点数据迁移到其他存储区，相当于将热点数据与非热点数据进行隔离，避免少量的热点数据影响到大量的非热点数据的处理。另外，待迁移的目标数据也可以是在数据库整体的访问量比较大、数据库资源不足的时间段内，数据库中任意的一部分数据，将这部分数据临时迁移到其他存储区，当访问量恢复到日常水平时，还可以再迁移回原来的数据库，相当于实现了数据库的动态扩容或缩容。

当然，在确定了待迁移的目标数据之后，还需要确定出目标数据对应的应用。也就是说，一般会有哪个或者哪些应用会访问该目标数据，这样在后续的步骤S103中，就可以将目标数据被迁移到目标存储区的消息通知给这些应用。具体实现时，目标数据与应用之间的对应关系可以是预先确定好的，直接利用这种对应关系进行确定即可。

S102：将所述目标数据临时迁移到目标存储区；

在确定了待迁移的目标数据之后，就可以将这些目标数据迁移到目标存储区。关于具体的数据迁移操作，相当于是将目标数据保存到目标存储区。当然，为了系统的可靠性起见，避免数据迁移过程的失败等造成整个业务的失败，一般情况下，可以在原来的数据库中保留该目标数据。在这种情况下，数据迁移的过程，相当于是从原来的数据库拷贝一份目标数据，复制到目标存储区中。当然，如果数据迁移过程以及目标存储区的可靠性都能得到保证，也可以不必在原来的数据库中保留目标数据。在实际应用中，一般可以采用在源数据库中保留目标数据的方式。

需要说明的是，数据迁移需要一段时间，例如，一般是10ms，为了保证源数据库与目标存储区中的目标数据之间的一致性，按照传统的实现方式，一般是在停机之后再对数据进行迁移，完成迁移之后再重新启动。但是，这势必会影响到正常的运行，因此，在本申请实施例中，如果需要在源数据库中也保留目标数据，则在数据迁移开始之前，可以首先将源数据库中的目标数据“冻结”，也即设置为只可读不可写的状态，然后再进行数据迁移。也就是说，在从数据迁移完成之前，如果有应用需要查询该目标数据，则可以从源数据库中获得查询结果，但是如果有应用需要修改该目标数据，则源数据库将不会支持这种修改。将目标数据成功迁移到目标存储区之后，还可以将源数据库与目标存储区中的数据进行一致性比对，如果一致，再将源数据库中该目标数据的状态置为可读可写的状态。

关于目标存储区，一般情况下，可以是在原来的数据库基础上新增的数据库，也即将目标数据迁移到新增的其他数据库中。这里需要说明的是，新增的其他数据库可能是多个，并且一个数据库中可能存在多个表，此时，在将目标数据迁移到这些数据库时，需要首先确定好应该将当前的目标数据迁移到哪个数据库中的哪张表。具体实现时，可以根据目标数据的ID、新增数据库的数目、每个数据库中包含的表的数目这些信息来确定。例如，假设新增的数据库一个为6个，每个数据库中有5个表，则共有30个表；各个数据库可以从0开始进行编号，也即分别为0、1、2、3、4、5号数据库，30个表也可以从0开始顺序编号，分别为0、1、2......29号表，其中，编号为0、6、12、18、24的表位于编号为0的数据库中，编号为1、7、13、19、25的表位于编号为1的数据库中，以此类推。在需要为某待迁移的目标数据选择目标数据库以及目标表时，可以首先将目标数据的ID对30进行取模运算，所得结果作为目标表的编号，再将目标表的编号对数据库数目6进行取模运算，所得结果作为目标数据库的编号。例如，假设某目标数据的ID是00015，则（00015mod30）=15，因此，应该将该目标数据存储到编号为15的表中，同时，由于（15mod6）=3，也就是说，可以将该目标数据存储到编号为3的数据库、编号为15的表中。当然，也可以采用其他的分库分表方式。

需要说明的是，在本申请实施例中，上述新增的数据库可以与源数据库具有相同的存储结构，或者也可以是不同的存储结构。例如，目标数据所在的源数据库是Mysql数据库，可以将目标数据临时迁移到Oracle数据库中，等等。这相当于实现了底层存储的异构。而这种异构可以使得整个业务系统更加灵活。例如，在现有技术中，一般只有一些在更新上具有一定特征的数据才会存储在Oracle数据库中，如虚拟商品对象的相关数据、用户的卡号、密码等。对于应用而言，只能从具体的业务角度出发，来判断当前访问的数据符合什么特征，然后再选择到哪种数据库中访问。因此，假如有一种数据既不是虚拟商品对象的数据，也不满足其他的特征，则无法存储到Oracle数据库中，即使强行存储到Oracle数据库中，应用也不会知晓需要到Oracle数据库中去访问这些数据，因为对于应用而言，这并不符合规则。

但是，在本申请实施例中，即使一个数据不符合存储到Oracle数据库的特征，也可以将其存储到Oracle数据库中，因为后续在步骤S103中，运维平台会将迁移到目标存储区的目标数据的标识信息通知给系统中的各个应用，各个应用就可以根据这种标识信息，来获知目标数据是保存在源数据库中，还是目标存储区。

需要说明的是，对于源数据库与目标数据库异构的情况，在进行数据迁移的过程中，可以尽量保证表结构的一致，以避免数据出错。另外，对于应用而言，一般对于数据库操作会进行封装，这种封装使得同一个应用可以无差别地访问多种类型的数据库，因此，即使将目标数据迁移到与源数据库异构的其他类型的数据库中，也不会影响到应用的正常访问。当然，对于应用而言，连接到不同类型的数据库时，采用的连接方式可能会不同，因此，在这种源数据库与目标数据库异构的情况下，运维平台还可以将目标数据库的存储结构信息通知给各个应用，以便应用能够使用对应的方式连接到目标数据库。

另外，在本申请实施例中，目标存储区还可以是指缓存，也就是说，可以直接将目标数据迁移到缓存中。例如，针对前文所述的热点数据，在实际应用中，还可能出现比较极端的情况，如，电子商务交易平台中，有些商品对象可能参加“秒杀”等活动，此时，参加这种活动的商品对象的数据会在极短的时间内产生非常高的访问量。在本申请实施例中，就可以将这种极端的热点数据直接迁移到缓存中。由于缓存对访问请求的响应要高于数据库，因此，可以进一步提高系统性能。当然，秒杀活动结束之后，还可以将数据从缓存迁移回源数据库中，以释放缓存。

这里需要说明的是，缓存中一般是由Key-Value的形式保存数据，而关系型数据库中，数据的一条记录往往由多个字段的信息组成，因此在将目标数据从源数据库迁移到缓存的过程中，可以从各个字段中选取出需要关注的内容，以Key-Value的形式加入到缓存中。另外，本申请实施例中的将目标数据临时迁移到缓存中，与应用读取了某数据之后，在缓存中保存以供后续访问，是不同的。对于后者，将数据加入缓存，是应用产生的行为，并且是以访问为前提的，也即，只有被应用访问过的数据才可能会加入到缓存中，其目的是，后续再访问相同的数据时，可以直接从缓存中读取，以提高效率。但是，对于前者而言，是本申请实施例中的运维平台主动将目标数据加入到缓存中，对于应用而言，即使是首次访问该数据，也可以直接从缓存中读取到。

总之，在将目标数据迁移到目标存储区时，目标存储区可以是其他数据库，甚至还可以是缓存，其他数据库可以是与源数据库同构的数据库，还可以是异构的数据库。因此，在提高系统性能、避免造成资源浪费的同时，还提高了底层存储的灵活性。

S103：将所述目标数据的标识信息通知给所述应用，以便所述应用在产生对数据的访问操作时，根据所述标识信息识别所述目标数据，并到所述目标存储区访问所述目标数据。

在将目标数据迁移到目标存储区之后，本申请实施例中的运维平台还需要进行的一项重要操作，就是要把目标数据的标识信息通知给挂载到数据库上的各个应用。应用可以根据这些标识信息来判断哪些数据已经被迁移到目标存储区，针对已经被迁移到目标存储区的数据，就可以到目标存储区中访问，而不用到源数据库中访问。也正是因为运维平台会将目标数据的标识信息通知给各个应用，因此，即使不进行对称的扩容，也即不是成倍的扩展数据库实例，也能够使得应用能够正常的实现对数据的访问。

为了能够将目标数据的标识信息通知给应用时，运维平台可以维护一个目标数据名单（list），list中记录有已经迁移到目标存储区的目标数据的ID。当有新的目标数据迁移到目标存储区时，运维平台就可以将该目标数据的ID加入到list中，并将更新后的list推送给各个应用。应用在产生对数据的访问请求时，可以首先判断当前需要访问的数据的ID是否出现在该list中，如果是，则直接到目标存储区中访问即可。当然，当目标数据从目标存储区迁移回源数据库之后，运维平台可以将该目标数据的ID从list中清除，这样，当应用再产生对该数据的访问请求时，由于该数据已经不在list中，因此，就会自动到源数据库中访问该数据。

这种list的方式，对于目标数据是热点数据或者随机选取的数据的情况，比较适用。但是对于前文所述的按照一定的ID选取规则选择的待迁移数据而言，则可以直接将这种ID选取规则通知给各个应用。各个应用在产生对数据的访问请求时，可以判断当前需要访问的数据的ID是否符合该ID选取规则，如果符合，则证明该数据已经被临时迁移到目标存储区，因此直接到目标存储区中访问该数据即可。

需要说明的是，对于各个应用而言，目标存储区的地址、端口号等建立连接时所需的信息是已知的（例如可以是预先设置好的），因此，当应用判断出需要到目标存储区访问某数据时，直接根据目标存储区的地址、端口号等与该目标存储区建立连接即可完成对数据的访问。当然，这里还需要说明的是，如前文所述，目标存储区可能包括多个数据库，每个数据库中包括多个表，被迁移到目标存储区中的目标数据会分库分表进行存储。应用需要首先确定出待访问的数据在哪个数据库的哪个表，之后才能够与该数据库建立连接，到该表中访问该数据。应用确定目标数据所在的数据库以及表的方式，与运维平台在迁移数据时，为数据选择数据库以及表的方式是完全相同的。也就是说，只要已知运维平台是如何进行分库分表的，应用采用相同的方式就可以确定出当前访问的数据在哪个数据库的哪个表中。例如，同样可以目标数据的ID、新增数据库的数目、每个数据库中的表的数目，通过取模运算等方式，确定目标数据所在的目标数据库以及目标表。

如前文所述，为了提高系统的可靠性，在将目标数据迁移到目标存储区的同时，在源数据库中还会保留该目标数据。而在目标数据成功迁移到目标存储区之后，应用已经能够到目标存储区访问该目标数据，包括对目标数据的查询、修改等等。当然，为了进一步提高系统的可靠性，在目标数据成功迁移到目标存储区之后，还可以启动数据同步系统，也即，将目标存储区中产生的关于目标数据的更新，同步更新回源数据库中。这样，一旦目标存储区发生宕机等故障，应用能够从源数据库中获取到目标数据的最新状态。当然，由于这种从目标存储区向源数据库的数据更新，仅仅是为了提高系统的可靠性，因此，为了提高效率，这种从目标存储区向源数据库的数据更新过程也可以是异步进行的。具体实现时，由于目标存储区中的目标数据在更新的过程中，会产生对应的日志，日志中记录了每次更新发生的先后顺序以及更新前后的值，因此，可以根据目标存储区的日志信息，将目标存储区产生的关于目标数据的更新，更新到源数据库中。这种异步更新的过程，可以是在目标存储区的目标数据每产生一次数据更新时，就进行一次，或者，也可以是每隔一段时间，将这段时间内产生的更新，顺序地更新回源数据库。需要说明的是，虽然针对同一目标数据的访问请求在同一时刻可能产生多个，但是由于锁机制的存在，针对同一目标数据的更新操作却是按照先后顺序执行的，而日志文件中会记录下这一先后顺序关系，因此，在按照日志中记录的顺序以及更新前后的值，对源数据库中的目标数据进行更新时，虽然是异步进行的，但是却可以保证更新后数据的准确性。

最后需要说明的是，如前文所述，在本申请实施例中，目标数据仅是临时的迁移到目标存储区，当目标数据不再是热点数据，或者假期等特殊时间段已经过去，就可以将目标数据迁移回源数据库。迁移回源数据库的过程相当于是将数据迁移到目标存储区的逆过程。例如，首先将目标存储区的目标数据冻结，然后将其复制到源数据库，检验无误后，就可以将目标数据从目标存储区删除。同时，还可以将目标数据的ID从list中删除。

总之，在本申请实施例中，在系统可能会出现存储资源不足的情况时，可以临时将部分数据迁移到目标存储区，并将这部分数据的标识信息通知给各个应用，这样，应用就可以识别出已经被迁移的数据，进而在产生的对这部分数据的访问请求时，就会被引流到目标存储区。相当于一部分访问请求是在原来的数据库中进行，而另一部分访问请求则是在目标存储区中进行，从而避免由于争抢存储资源而造成系统性能下降。

实施例二

实施例一主要是从运维平台的角度对本申请实施例提供的数据库处理方法进行了详细的介绍。从实施例一中的介绍也可以看出，在整个实现的过程中，实际上应用侧的逻辑也需要进行一些改进。当然，在实际应用中，虽然各个应用可能是由第三方开发的，但是，为了保证数据的安全性，涉及到对数据库访问的逻辑，一般是由平台统一提供的。也就是说，当第三方开发的应用需要访问平台的数据库时，实际上是需要调用平台提供的数据库访问逻辑。因此，关于所述的对应用侧逻辑的改进，更准确的说，应该是对平台提供的数据库访问逻辑进行改进。本申请实施例二就是从数据库访问逻辑的角度进行介绍。

参见图2，本申请实施例二提供了一种数据访问方法，该方法可以包括以下步骤：

S201：接收通知消息，所述通知消息中携带有被临时迁移到目标存储区的目标数据的标识信息；

该通知消息就是实施例一中所述的运维平台在完成数据迁移之后发出通知的消息。

S202：当产生对数据的访问操作时，根据所述标识信息识别待访问的数据是否为所述目标数据；

S203：如果是，则根据预置的目标存储区的地址及端口号，连接到所述目标存储区访问所述目标数据。

其中，如果目标存储区为新增的多个数据库，每个数据库中包括多个表，则目标数据在目标存储区会分库分表保存，因此，应用可以根据目标数据的ID、新增数据库的数目、每个数据库中的表的数目，确定目标数据所在的目标数据库以及目标表，然后根据目标数据库的地址以及端口号，连接到目标数据库，访问目标表中的目标数据。当然，如果数据迁移的过程中，数据库存储结构发生了变化，例如从Mysql变成了Oracle数据库，则运维平台发生的通知消息中还包括有目标存储区的存储结构信息，应用在确定了目标存储区的地址及端口号之后，可以根据这种存储结构对应的数据库连接方式，连接到对应的数据库，实现对目标数据的访问。

需要说明的是，关于实施例二中的具体实现细节，在实施例一中也有相关的介绍，因此，这里不再赘述。

与本申请实施例一提供的数据库处理方法相对应，本申请实施例还提供了一种数据库处理系统，参见图3，该系统可以包括：

目标数据确定单元301，用于确定在特定时间段内待迁移的目标数据以及所述目标数据对应的应用；

第一数据迁移单元302，用于将所述目标数据临时迁移到目标存储区；

通知单元303，用于将所述目标数据的标识信息通知给所述应用，以便所述应用在产生对数据的访问操作时，根据所述标识信息识别所述目标数据，并到所述目标存储区访问所述目标数据。

具体实现时，目标数据确定单元301具体可以包括：

标识识别单元，用于通过识别数据库中业务对象的特定标识，确定热点业务对象；

热点数据确定单元，用于根据所述热点业务对象确定在预置时间段内将被高并发访问的热点业务数据，将所述热点业务数据确定为该时间段内待迁移的目标数据。

在这种情况下，所述通知单元303具体可以包括：

第一通知子单元，用于将所述目标数据的ID通知给应用。

在另一种具体的实现方式下，目标数据确定单元301具体可以包括：

数据库分析单元，用于通过对数据库的历史访问记录进行分析，确定所述数据库将出现高并发访问的时间段；

数据选取单元，用于在所述时间段到来之前，将数据ID符合预置的ID选取规则的数据确定为该时间段内待迁移的目标数据。

在这种情况下，所述通知单元303具体可以包括：

第一通知子单元，用于将所述目标数据的ID通知给应用；

或者，

第二通知子单元，用于将用于选择目标数据的ID选取规则通知给应用。

其中，所述第一数据迁移单元302具体可以用于：

将所述目标数据临时迁移到新增的数据库中。

其中，所述新增的数据库为多个，每个数据库中包括多个表，此时，第一数据迁移单元302可以包括：

确定子单元，用于根据所述目标数据的ID、新增数据库的数目、每个数据库中的表的数目，确定目标数据库以及目标表；

迁移子单元，用于将所述目标数据临时迁移到所述目标数据库的目标表中，以便所述应用在产生对目标数据的访问操作时，根据目标数据的ID、新增数据库的数目、每个数据库中的表的数目，确定目标数据所在的目标数据库以及目标表，并根据所述目标数据所在的目标数据库以及目标表访问所述目标数据。

另外，第一数据迁移单元302具体也可以用于：

将所述目标数据临时迁移到缓存中。

其中，所述目标存储区与所述目标数据所在的源存储区可以具有不同的存储结构，此时，该系统还可以包括：

存储结构信息通知单元，用于将所述目标存储区的存储结构信息通知给所述应用，以便所述应用到所述目标存储区访问所述目标数据时，根据所述存储结构信息与所述目标存储区建立连接。

为了提高系统的可靠性，还可以在所述目标数据所在的源数据库中保留所述目标数据，以便发生迁移故障时，所述应用从所述源数据库中访问所述目标数据。

为了保证数据的一致性，该系统还可以包括：

第一状态设置单元，用于在将所述目标数据迁移到目标存储区之前，将所述目标数据在源数据库中的状态置为只可读不可写状态；

第二状态设置单元，用于在在将所述目标数据成功迁移到目标存储区之后，将所述目标数据在源数据库中的状态置为可读可写状态。

另外，该系统还可以包括：

数据更新单元，用于将所述目标存储区产生的关于所述目标数据的更新，同步或异步更新到所述源数据库中。

其中，数据更新单元具体可以用于：

根据所述目标存储区的日志信息，将所述目标存储区产生的关于所述目标数据的更新，异步更新到所述源数据库中。

另外，该系统还可以包括：

第二数据迁移单元，用于接收到结束指令后，将所述目标存储区中的目标数据迁移回源数据库。

与本申请实施例二提供的数据访问方法相对应，本申请实施例还提供了一种数据访问系统，参见图4，该系统可以包括：

通知消息接收单元401，用于接收通知消息，所述通知消息中携带有被临时迁移到目标存储区的目标数据的标识信息；

目标数据识别单元402，用于当产生对数据的访问操作时，根据所述标识信息识别待访问的数据是否为所述目标数据；

连接单元403，用于如果是，则根据预置的目标存储区的地址及端口号，连接到所述目标存储区访问所述目标数据。

其中，所述目标存储区为新增的多个数据库，每个数据库中包括多个表；所述连接单元403包括：

根据目标数据的ID、新增数据库的数目、每个数据库中的表的数目，确定目标数据所在的目标数据库以及目标表；

根据所述目标数据库的地址以及端口号，连接到所述目标数据库，访问所述目标表中的所述目标数据。

所述通知消息中还携带有目标存储区的存储结构；所述连接单元403具体用于：

根据预置的目标存储区的地址及端口号，采用所述存储结构对应的连接方式，连接到所述目标存储区访问所述目标数据。

在本申请实施例中，在系统可能会出现存储资源不足的情况时，可以临时将部分数据迁移到目标存储区，并将这部分数据的标识信息通知给各个应用，这样，应用就可以识别出已经被迁移的数据，进而在产生的对这部分数据的访问请求时，就会被引流到目标存储区。相当于一部分访问请求是在原来的数据库中进行，而另一部分访问请求则是在目标存储区中进行，从而避免由于争抢存储资源而造成系统性能下降。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的数据库处理、数据访问方法及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (18)

1.一种数据库处理方法，其特征在于，包括：

确定在特定时间段内待迁移的目标数据以及所述目标数据对应的应用，所述目标数据包括热点数据，所述热点数据包括在预置时间段内将被高并发访问的热点业务数据；

将所述目标数据从源数据库临时迁移到目标存储区，以便将热点数据与非热点数据进行隔离；

将所述目标数据的标识信息通知给所述应用，以便所述应用在产生对数据的访问操作时，根据所述标识信息识别所述目标数据是否为热点数据，如果是，从所述目标存储区访问所述目标数据，否则，从所述源数据库进行数据访问；

在所述特定时间段结束后，将所述目标存储区中的目标数据迁移回源数据库。

2.根据权利要求1所述的方法，其特征在于，所述确定在特定时间段内待迁移的目标数据，包括：

通过识别数据库中业务对象的特定标识，确定热点业务对象；

根据所述热点业务对象确定在预置时间段内将被高并发访问的热点业务数据，将所述热点业务数据确定为该时间段内待迁移的目标数据。

3.根据权利要求2所述的方法，其特征在于，所述将所述目标数据的标识信息通知给应用，包括：

将所述目标数据的ID通知给应用。

4.根据权利要求1所述的方法，其特征在于，所述确定在特定时间段内待迁移的目标数据，包括：

通过对数据库的历史访问记录进行分析，确定所述数据库将出现高并发访问的时间段；

在所述时间段到来之前，将数据ID符合预置的ID选取规则的数据确定为所述时间段内待迁移的目标数据。

5.根据权利要求4所述的方法，其特征在于，所述将所述目标数据的标识信息通知给应用，包括：

将所述目标数据的ID通知给应用；

或者，

将用于选择目标数据的ID选取规则通知给应用。

6.根据权利要求1至5任一项所述的方法，其特征在于，所述将所述目标数据临时迁移到目标存储区，包括：

将所述目标数据临时迁移到新增的数据库中。

7.根据权利要求6所述的方法，其特征在于，所述新增的数据库为多个，每个数据库中包括多个表，所述将所述目标数据临时迁移到新增的数据库中，包括：

根据所述目标数据的ID、新增数据库的数目、每个数据库中的表的数目，确定目标数据库以及目标表；

将所述目标数据临时迁移到所述目标数据库的目标表中，以便所述应用在产生对目标数据的访问操作时，根据目标数据的ID、新增数据库的数目、每个数据库中的表的数目，确定目标数据所在的目标数据库以及目标表，并根据所述目标数据所在的目标数据库以及目标表访问所述目标数据。

8.根据权利要求1至5任一项所述的方法，其特征在于，所述将所述目标数据临时迁移到目标存储区，包括：

将所述目标数据临时迁移到缓存中。

9.根据权利要求1至5任一项所述的方法，其特征在于，所述目标存储区与所述目标数据所在的源存储区具有不同的存储结构，所述方法还包括：

将所述目标存储区的存储结构信息通知给所述应用，以便所述应用到所述目标存储区访问所述目标数据时，根据所述存储结构信息与所述目标存储区建立连接。

10.根据权利要求1至5任一项所述的方法，其特征在于，在所述目标数据所在的源数据库中保留所述目标数据，以便发生迁移故障时，所述应用从所述源数据库中访问所述目标数据。

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

在将所述目标数据迁移到目标存储区之前，将所述目标数据在源数据库中的状态置为只可读不可写状态；

在在将所述目标数据成功迁移到目标存储区之后，将所述目标数据在源数据库中的状态置为可读可写状态。

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

将所述目标存储区产生的关于所述目标数据的更新，同步或异步更新到所述源数据库中。

13.根据权利要求12所述的方法，其特征在于，所述将所述目标存储区产生的关于所述目标数据的更新，同步或异步更新到所述源数据库中，包括：

根据所述目标存储区的日志信息，将所述目标存储区产生的关于所述目标数据的更新，异步更新到所述源数据库中。

14.一种数据访问方法，其特征在于，包括：

接收通知消息，所述通知消息中携带有在预置时间段内被从源数据库临时迁移到目标存储区的目标数据的标识信息，并在所述预置时间段结束后，迁移回所述源数据库；所述标识信息用于识别所述目标数据是否为热点数据，所述热点数据被迁移到所述目标存储区后实现与所述源数据库中非热点数据的隔离，所述热点数据包括在预置时间段内将被高并发访问的热点业务数据；

当产生对数据的访问操作时，根据所述标识信息识别待访问的数据是否为所述目标数据；

如果是，则根据预置的目标存储区的地址及端口号，连接到所述目标存储区访问所述目标数据，否则，从所述源数据库进行数据访问；

在所述预置时间段结束后，从所述源数据库对所述目标数据进行访问。

15.根据权利要求14所述的方法，其特征在于，所述目标存储区为新增的多个数据库，每个数据库中包括多个表；所述根据预置的目标存储区的地址及端口号，连接到所述目标存储区访问所述目标数据，包括：

根据目标数据的ID、新增数据库的数目、每个数据库中的表的数目，确定目标数据所在的目标数据库以及目标表；

根据所述目标数据库的地址以及端口号，连接到所述目标数据库，访问所述目标表中的所述目标数据。

16.根据权利要求14所述的方法，其特征在于，所述通知消息中还携带有目标存储区的存储结构；所述根据预置的目标存储区的地址及端口号，连接到所述目标存储区访问所述目标数据，包括：

根据预置的目标存储区的地址及端口号，采用所述存储结构对应的连接方式，连接到所述目标存储区访问所述目标数据。

17.一种数据库处理系统，其特征在于，包括：

目标数据确定单元，用于确定在特定时间段内待迁移的目标数据以及所述目标数据对应的应用，所述目标数据包括热点数据，所述热点数据包括在预置时间段内将被高并发访问的热点业务数据；

第一数据迁移单元，用于将所述目标数据从源数据库临时迁移到目标存储区，以便将热点数据与非热点数据进行隔离；

通知单元，用于将所述目标数据的标识信息通知给所述应用，以便所述应用在产生对数据的访问操作时，根据所述标识信息识别所述目标数据是否为热点数据，如果是，从所述目标存储区访问所述目标数据，否则，从所述源数据库进行数据访问；

第二数据迁移单元，用于所述特定时间段结束后，将所述目标存储区中的目标数据迁移回源数据库。

18.一种数据访问系统，其特征在于，包括：

通知消息接收单元，用于接收通知消息，所述通知消息中携带有在预置时间段内被从源数据库临时迁移到目标存储区的目标数据的标识信息，并在所述预置时间段结束后，迁移回所述源数据库；所述标识信息用于识别所述目标数据是否为热点数据，所述热点数据被迁移到所述目标存储区后实现与所述源数据库中非热点数据的隔离，所述热点数据包括在预置时间段内将被高并发访问的热点业务数据；

目标数据识别单元，用于当产生对数据的访问操作时，根据所述标识信息识别待访问的数据是否为所述目标数据；

连接单元，用于如果是，则根据预置的目标存储区的地址及端口号，连接到所述目标存储区访问所述目标数据，否则，从所述源数据库进行数据访问；在所述预置时间段结束后，从所述源数据库对所述目标数据进行访问。