CN106407190A - 一种事件记录查询方法及装置 - Google Patents

Abstract

本申请公开了一种事件记录查询方法及装置。一种事件记录查询方法包括：接收用户的事件记录查询请求，确定该请求所对应的查询事件及查询时间范围；根据所述用户的查询事件的历史发生次数统计值，估算所述查询时间范围对应的查询数据量；确定数据库当前可承受的最大单次查询数据量Max；将所述查询请求拆分为N个查询子请求；利用所述N个查询子请求向数据库发起查询。应用上述方案，使得数据库收到的单次查询数据量不会超过自身承受能力，减少不稳定情况的发生。另一方面，查询结果也可以根据所拆分的子请求分多次响应，避免因单次查询数据量过大而导致数据返回超时。

Description

一种事件记录查询方法及装置

技术领域

本申请涉及数据库应用技术领域，尤其涉及一种事件记录查询方法及装置。

背景技术

计算机和互联网技术的发展，为人们带来了前所未有的便捷，目前这些技术已经渗透到人们日常生活的各个方面，典型的应用例如网络社交、网络交易、网络娱乐等。对于提供互联网服务的企业而言，用户数量和使用频率的增长，必然导致各类相关数据的增长，因此对数据管理技术也提出了更高的要求。

在应用服务系统运行过程中，外部用户的每一次操作行为或系统内部的每一次操作处理，都可以称为一个事件。一般来说，系统除了实现基本功能之外，还会以日志的方式，全部或选择性地将事件的相关信息(包括发生时间和具体内容等)写入数据库，以满足后续的各类查询需求，例如事件清单输出、数据统计分析、甚至用于故障定位等等。常见的应用场景包括网上交易记录查询、银行卡金额变动记录查询等等。

对于轻量级的事件记录查询请求，不会影响到数据库的正常读写操作，数据库一般可以很快给出响应。然而如果一次查询请求对应的数据量过大，则整个查询过程会给数据库带来很大压力，严重时甚至会影响到数据库的正常读写操作，进而影响到应用侧基本功能的正常运行。此外，由于数据库难以迅速给出查询结果，对于应用侧而言，可能会当作数据返回超时处理，造成数据查询功能实际不可用，不仅影响用户感受，还可能导致用户反复重试，从而进一步加剧对数据库的影响。

发明内容

本申请提供一种事件记录查询方法及装置，以解决大数据量查询对数据库的影响问题，技术方案如下：

本申请提供一种事件记录查询方法，该方法包括：

接收用户的事件记录查询请求，确定该请求所对应的查询事件及查询时间范围；

根据所述用户的查询事件的历史发生次数统计值，估算所述查询时间范围对应的查询数据量；

确定数据库当前可承受的最大单次查询数据量Max；

将所述查询请求拆分为N个查询子请求，使得每个查询子请求分别对应于所述查询时间范围内的不同时间段、且每个时间段对应的查询数据量不大于Max，其中N为不小于1的整数；

利用所述N个查询子请求向数据库发起查询。

本申请还提供一种事件记录查询装置，该装置包括：

请求接收模块，用于接收用户的事件记录查询请求，确定该请求所对应的查询事件及查询时间范围；

数据量估算模块，用于根据所述用户的查询事件的历史发生次数统计值，估算所述查询时间范围对应的查询数据量；

数据库性能确定模块，用于确定数据库当前可承受的最大单次查询数据量Max；

请求拆分模块，用于将所述查询请求拆分为N个查询子请求，使得每个查询子请求分别对应于所述查询时间范围内的不同时间段、且每个时间段对应的查询数据量不大于Max，其中N为不小于1的整数；

查询模块，用于利用所述N个查询子请求向数据库发起查询。

本申请所提供的时间记录查询方案，根据数据库当前的实际查询响应能力，将查询数据量较大的查询请求拆分为多个子请求，使得数据库收到的单次查询数据量不会超过自身承受能力，减少不稳定情况的发生。另一方面，查询结果也可以根据所拆分的子请求分多次响应，避免因单次查询数据量过大而导致数据返回超时。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

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

图1是本申请的事件记录查询方法的一种流程示意图；

图2是本申请的事件记录查询系统的结构示意图；

图3是本申请的事件记录查询方法的第二种流程示意图；

图4是本申请的事件记录查询装置的一种结构示意图；

图5是本申请的事件记录查询装置的第二种结构示意图。

具体实施方式

对于数据库而言，一个重要的性能指标是可承受的最大单次查询数据量，影响该性能的因素包括CPU、内存、数据结构等多方面。实际应用中，如果一次查询请求所对应的数据量超过了这个最大值，就可能影响其他正常的读写操作，导致数据库不稳定。

以网上交易平台为例，不同类型的用户，交易笔数相差很大。有些用户是普通买家，那么很有可能一年的交易记录条数小于100，有些用户属性是个人卖家，交易记录可能月均在几百笔到几千笔。有些用户属性是大型卖家，例如一些平台商、机构等，那么他的交易记录可能在月均千万笔以上。无论是哪种类型的用户都有查询交易记录的需求，以便进行对账或发货处理等。用户进行查询时，一般会选择一个时间跨度范围。普通买家用户的查询请求，即便时间跨度很长(例如几年)，也不会有很大的数据量；但是一个大型卖家用户的查询请求，即便跨度很短，也可能超过数据库可承受的最大单次查询数据量，造成数据库不稳定。

针对上述问题，本申请提供的方案是，根据数据库当前的实际查询响应能力，将查询数据量较大的查询请求拆分为多个子请求，从而减少不稳定情况的发生。

为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

图1所示，为本申请提供的一种事件记录查询方法的流程图，该方法可以包括以下步骤：

S101，接收用户的事件记录查询请求，确定该请求所对应的查询事件及查询时间范围；

S102，根据所述用户的查询事件的历史发生次数统计值，估算所述查询时间范围对应的查询数据量；

S103，确定数据库当前可承受的最大单次查询数据量Max；

S104，将所述查询请求拆分为N个查询子请求，使得每个查询子请求分别对应于所述查询时间范围内的不同时间段、且每个时间段对应的查询数据量不大于Max，其中N为不小于1的整数；

S105，利用所述N个查询子请求向数据库发起查询。

上述方法对应的执行主体，在本申请中称为一种事件记录查询装置，如图2所示系统，该装置100在逻辑上位于用户200和数据库300之间，基本交互流程为：接收用户的查询请求、向数据库请求数据、接收数据库返回的数据、将数据返回至用户。从物理位置来看，该装置位于网络侧，具体可以位于数据库服务器中，也可以位于与数据库服务器相互独立的应用服务器中，本申请对此并不需要进行限定。

在S101，用户根据自己的需求，在终端设备上进行查询操作，向网络侧发出查询请求。

用户可以在查询时指定查询的对象事件类型，例如在网上支付系统中，用户可以指定查询交易记录、信用卡还款记录、汇款记录、积分兑换记录等等，如果用户不做指定，则以当前所使用查询功能所对应的缺省设置为准，例如查询全部类型事件记录。

另外，用户还可以在查询时指定查询的时间范围，即指定查询起始时间点T1和结束时间点T2，根据具体应用场景的不同，该功能可以精确到不同的时间粒度，例如日、小时、甚至分钟等。如果用户不做指定，则以当前所使用查询功能所对应的缺省设置为准，例如查询全部有效时间的记录，或者查询最近一个月的记录，等等。

事件记录查询装置接收到用户查询请求后，对请求进行解析，确定用户需要查询的事件类型。以及需要查询的时间范围[T1,T2]，以供后续步骤使用。

确定查询时间范围[T1,T2]后，一种较为直接的确定查询数据量的方法是：直接访问数据库，确定在[T1,T2]时段所对应的数据量，尽管这种方式仅需要数据库返回一个数据量统计值，但是仍然需要与数据库进行交互并且占用数据库的资源。针对该问题，本申请采用根据用户历史行为估算本次查询数据量的方式，从而避免额外占用数据库的资源。

在S102，确认用户需要查询的事件类型后，需要进一步获取该用户该类型事件的历史发生次数，从而对本次查询所对应的数据量进行估算。

进行估算的基本思路是：根据用户的历史行为，估算在[T1,T2]可能对应的数据量。假设某用户在单位统计时段Ts时长内的事件历史发生次数统计值为Cs，则在[T1,T2]时段内事件发生的次数估算值Ce为：Ce＝Cs*(T2-T1)/Ts。

为了满足估算的需求，需要预先对特定的统计值进行记录，或者预先(例如在系统相对空闲的时段)从数据库或者该数据库的备份库中获取这些统计值并保存。根据实际的应用场景，可以从多个不同方面选取需要记录或获取的统计值，例如：

可以选用不同历史时段范围的数据统计值，例如最近一年、全部有效历史时间，等等；

可以选取不同的统计时间粒度，例如以“日”为单位进行统计、以“月”为单位进行统计等；

可以选取不同类型的统计值，例如单位统计时段内发生次数的平均值、单位统计时段内发生次数的最大值等等。其中，选取最大值进行估计属于比较保守的估计算法，可以有效降低引发数据库稳定性问题的概率。

此外，“最大值”对应的单位统计时段Ts可以是静态的，即基于自然的时间划分，例如从每个自然月的交易量中，选取交易量最大的一个作为最大值用作估计；Ts也可以是动态的，即不以自然的时间划分作为统计时段，假设统计时段对应的时长为Ts，则在时间轴上任意连续的Ts时长都可以作为统计时段，例如以一个长度为30天的滑动时间窗口在所有交易记录中进行统计，选取在滑动过程中的窗口内的最大交易量作为最大值用作估计。相对而言，静态最大值统计实现简单，但是对于一些突发的数据变化不够敏感，动态最大值则能有效地解决该问题，从而进一步降低了引发数据库稳定性问题的概率。

在S103，数据库当前可承受的最大单次查询数据量Max由数据库服务器的硬件配置(CPU、内存等)、软件配置(软件执行效率、数据结构，单条数据的数据量)以及实际负载等多方面因素决定。在本申请方案实际应用时，可以设定一个相对固定的数值，直接读取该值即可使用。当然，也可以实时对数据库当前可承受的最大单次查询数据量Max进行估算，具体的估算方法与本申请方案关系相对独立，这里不做详细说明。

需要说明的是，S103与S101-102在执行顺序上并没有特别的要求。进一步在S104，根据S102得到的本次查询数据量估算值以及S103得到的MAX值，对最初接收到的查询请求进行拆分，得到若干个查询子请求。

原则上，这里并不要求每个查询子请求平均分配全部的查询数据量，只要每个子请求对应的数据量估算值均不大于Max即可，实际拆分时，可采用以下算法：

首先计算需要查询的次数N，N为整数，可通过对Ce/Max的值向上取整得到。

然后对时间范围[T1,T2]进行N切分：

令Delta＝1/N*(T2-T1)，则N个分片对应的时间范围分别为：

[T1+0*Delta,T1+1*Delta]；

[T1+1*Delta,T1+2*Delta]；

[T1+2*Delta,T1+3*Delta]；

……

[T1+(N-1)*Delta,T2]。

需要说明的是，这里对每个分片对应的时间范围均取了闭区间，这是为了结合具体的查询应用需求，当然如果实际的查询功能支持，也可以对每个分片对应的时间范围取半开半闭区间。此外，由于N是向上取整，因此最后一个分片的右端点直接取T2而不是T1+N*Delta，也就是说，最后一个分片的时间跨度是小于等于其他分片的。

当然，以上方案仅用于示意性说明，实际的切分方法并不限于以上公开的一种，例如，可以令第一个分片的时间跨度小于等于其他分片，等等。另外，作为一种特殊但是很常见的情况，允许N＝1，实际情况相当于最初的查询请求对应的数据量估算值没有超过MAX，这种情况无需进行拆分处理。

在S105，利用N个查询子请求向数据库发起查询。相当于将一个原本时间跨度为[T1,T2]的查询，分为N个查询多次请求数据库，使得数据库收到的单次查询数据量不会超过数据库的承受能力。另一方面，查询结果也可以根据所拆分的子请求分多次响应，避免因单次查询数据量过大而导致数据返回超时。

在上述事件记录查询方法中，是动态地根据查询数据量估算值以及数据库当前可承受的最大单次查询数据量，对查询请求进行拆分，在实际应用中，还有其他两种处理逻辑可以采用：一方面，对于一些事件发生频率很低的用户，实际没有必要对查询请求动态进行拆分(或者说没有必要拆分)，可以直接按照某种预定的规则进行拆分即可；另一方面，对于一些事件发生频率特别高的用户，可能会导致拆分后的子请求数量过多，这种情况下，更合适的方式对这类查询请求做延时处理。下面将结合图3所示的流程图，对上述处理逻辑进行详细说明：

S201，接收用户的事件记录查询请求，确定该请求所对应的查询事件及查询时间范围。

本步骤与S101类似，这里不做重复说明。

S202，判断所述用户的查询事件的历史发生次数统计值的大小；

在本实施例中，对于用户的查询请求提供三种处理逻辑，具体触发哪种处理逻辑，则根据用户查询事件的历史发生次数统计值Cs的大小进行判断。Cs的含义可参见前面的实施例，这里不再重复说明。

为了对三种处理逻辑进行区分，这里需要预先设置两个阈值C1和C2，其中C1＜C2，三种处理逻辑如下：

如果Cs的大小位于C1和C2之间，则触发S203-S204分支，动态地根据查询数据量估算值以及数据库当前可承受的最大单次查询数据量，对查询请求进行拆分并查询。此分支相当于前一实施例中的S102-S105，这里不再重复说明。

如果Cs小于C1，则触发S205-S204分支，其中S205与S203的区别在于，不需要动态计算拆分方案，而是可以直接根据某个预设的时间段长度将查询请求拆分为N个查询子请求。实际意义则是：如果某用户在单位统计时段Ts时长内的事件历史发生次数统计值Cs较小，则认为该用户的查询请求基本不可能对数据库造成冲击，可以直接采用某种相对固定的拆分方式例如按照自然月拆分，甚至不做拆分(对应的预设时间段长度为任意，N＝1)等等，从而减少动态运算导致的资源消耗。拆分完成后，仍执行S205。

如果Cs大于C2，则触发S206分支，对查询请求进行延时查询处理。这是考虑到如果Cs过大，则该用户所查询的数据量级也会非常大，仅是拆分处理就要消耗大量的系统资源，而且子请求数量过多也可能会影响数据库的稳定性。因此针对这种情况，需要做延时查询处理。这里的“延时”是相对于前两个处理分支而言，即查询请求发送至数据库后，不要求数据库立刻响应，例如可以将查询请求放入等候队列，待数据库服务器资源空闲时再做处理。根据数据库的具体情况，延时的时间可能是几个小时，也可能更长。另外，这里发给数据库的查询请求，既可以是拆分后的多个子请求，也可以是完整的初始查询请求，本申请对此并不需要进行限定。

在本申请的一种具体实施方式中，对于延时查询处理，可以对数据库的备份库发起查询，备份库与主库(即前述的数据库)的数据是定期同步的，由于不要求立刻返回查询结果，因此可以在同步完成之后再向备库发起查询，既保证数据的准确性，又不会影响到主库的其他正常读写操作。实际应用中，很多备份库是支持分布式处理的，这种情况下，针对备份库发起的查询操作，可以利用Hadoop集群以Map-Reduce方式实现，从而更高效地解决海量数据的处理问题。

在一些系统中，对于查询请求是有一定返回时间要求的，如果数据库不能按时返回数据，对于应用侧而言，会当作数据返回超时处理，造成数据查询功能实际不可用。考虑到延时查询处理几乎必然会导致超时，因此在本申请的一种实施方式中，对于延时查询请求，可以设置一个特殊的延时响应标识，表明该查询请求不需要立刻处理，避免应用侧把这种情况当作数据返回超时处理。

当然，从用户使用感受的角度考虑，进行延时查询处理时，还应向用户发出适当的提示，例如在确定需要进行延时查询处理后，告知用户：由于查询数据量过大无法立刻返回查询结果。如有需要，还可以进一步告知用户可以在什么时间来下载查询结果，或者在查询完成后，直接将查询结果以文件形式发给用户，或者以短信或即时消息等方式告知用户到指定地址下载。

以上介绍了三种事件记录的查询处理逻辑，可以理解的是，在实际应用中，并不要求三种处理逻辑同时使用，本领域技术人员可以根据实际需求，独立选择三种处理逻辑中的一部分，本申请对此并不需要进行限定。

相应于上述方法实施例，本申请还提供一种事件记录查询装置，参见图4所示，该装置可以包括：

请求接收模块210，用于接收用户的事件记录查询请求，确定该请求所对应的查询事件及查询时间范围；

数据量估算模块220，用于根据所述用户的查询事件的历史发生次数统计值，估算所述查询时间范围对应的查询数据量；

数据库性能确定模块230，用于确定数据库当前可承受的最大单次查询数据量Max；

请求拆分模块240，用于将所述查询请求拆分为N个查询子请求，使得每个查询子请求分别对应于所述查询时间范围内的不同时间段、且每个时间段对应的查询数据量估算值不大于Max，其中N为不小于1的整数；

查询模块250，用于利用所述N个查询子请求向数据库发起查询。

根据本申请的一种具体实施方式，所述历史发生次数统计值，可以包括：

单位统计时段内发生次数的平均值

或

单位统计时段内发生次数的最大值。

根据本申请的一种具体实施方式，所述数据量估算模块220，具体可以用于：

判断所述用户的查询事件的历史发生次数统计值是否不小于C1、且不大于C2，如果是，则进一步估算所述查询时间范围对应的查询数据量；

其中C1和C2分别为预设的第一阈值和第二阈值。

根据本申请的一种具体实施方式，所述请求拆分模块240，还可以用于：

在所述用户的查询事件的历史发生次数统计值小于C1的情况下，直接根据预设的时间段长度将所述查询请求拆分为N个查询子请求。

参见图5所示，根据本申请的一种具体实施方式，所述事件记录查询装置还可以包括：

延时查询模块260，用于在所述用户的查询事件的历史发生次数统计值大于C2的情况下，对所述查询请求进行延时查询处理。

根据本申请的一种具体实施方式，所述延时查询模块260，具体可以用于：

向所述数据库的备份库发起查询。

或者

为所述查询请求设置延时响应标识。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

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

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

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (14)

1.一种事件记录查询方法，其特征在于，该方法包括：

接收用户的事件记录查询请求，确定该请求所对应的查询事件及查询时间范围；

根据所述用户的查询事件的历史发生次数统计值，估算所述查询时间范围对应的查询数据量；

确定数据库当前可承受的最大单次查询数据量Max；

将所述查询请求拆分为N个查询子请求，使得每个查询子请求分别对应于所述查询时间范围内的不同时间段、且每个时间段对应的查询数据量不大于Max，其中N为不小于1的整数；

利用所述N个查询子请求向数据库发起查询。

2.根据权利要求1所述的方法，其特征在于，所述历史发生次数统计值，包括：

单位统计时段内发生次数的平均值

或

单位统计时段内发生次数的最大值。

3.根据权利要求1所述的方法，其特征在于，所述根据所述用户的查询事件的历史发生次数统计值，估算所述查询时间范围对应的查询数据量的步骤，包括：

判断所述用户的查询事件的历史发生次数统计值是否不小于C1、且不大于C2，如果是，则进一步估算所述查询时间范围对应的查询数据量；

其中C1和C2分别为预设的第一阈值和第二阈值。

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

在所述用户的查询事件的历史发生次数统计值小于C1的情况下，直接根据预设的时间段长度将所述查询请求拆分为N个查询子请求；

利用所述N个查询子请求向数据库发起查询。

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

在所述用户的查询事件的历史发生次数统计值大于C2的情况下，对所述查询请求进行延时查询处理。

6.根据权利要求5所述的方法，其特征在于，所述对所述查询请求进行延时查询处理的步骤，包括：

向所述数据库的备份库发起查询。

7.根据权利要求5所述的方法，其特征在于，所述对所述查询请求进行延时查询处理的步骤，包括：

为所述查询请求设置延时响应标识。

8.一种事件记录查询装置，其特征在于，该装置包括：

请求接收模块，用于接收用户的事件记录查询请求，确定该请求所对应的查询事件及查询时间范围；

数据量估算模块，用于根据所述用户的查询事件的历史发生次数统计值，估算所述查询时间范围对应的查询数据量；

数据库性能确定模块，用于确定数据库当前可承受的最大单次查询数据量Max；

请求拆分模块，用于将所述查询请求拆分为N个查询子请求，使得每个查询子请求分别对应于所述查询时间范围内的不同时间段、且每个时间段对应的查询数据量不大于Max，其中N为不小于1的整数；

查询模块，用于利用所述N个查询子请求向数据库发起查询。

9.根据权利要求8所述的装置，其特征在于，所述历史发生次数统计值，包括：

单位统计时段内发生次数的平均值

或

单位统计时段内发生次数的最大值。

10.根据权利要求8所述的装置，其特征在于，所述数据量估算模块，具体用于：

判断所述用户的查询事件的历史发生次数统计值是否不小于C1、且不大于C2，如果是，则进一步估算所述查询时间范围对应的查询数据量；

其中C1和C2分别为预设的第一阈值和第二阈值。

11.根据权利要求10所述的装置，其特征在于，所述请求拆分模块，还用于：

在所述用户的查询事件的历史发生次数统计值小于C1的情况下，直接根据预设的时间段长度将所述查询请求拆分为N个查询子请求。

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

延时查询模块，用于在所述用户的查询事件的历史发生次数统计值大于C2的情况下，对所述查询请求进行延时查询处理。

13.根据权利要求12所述的装置，其特征在于，所述延时查询模块，具体用于：

向所述数据库的备份库发起查询。

14.根据权利要求12所述的装置，所述延时查询模块，具体用于：

为所述查询请求设置延时响应标识。