CN116610680B - 高频库和使用高频库的数据分级存储和查询方法和系统 - Google Patents

Abstract

本申请涉及一种更新包括高频商户名单和相应交易数据的高频库的方法，包括：记录商户的历史查询日志；对所述商户的历史查询记录进行统计学分析，并输出多个维度的统计结果数据；使用基于所述多个维度的统计结果数据和包括配置参数的配置文件的高频商户判断算法，对所述多维度的统计结果数据进行综合计算以确定所述商户是否为高频商户：根据确定的结果更新所述高频商户名单。本申请还涉及使用高频库的数据分级存储和查询方法以及数据分级交易系统。

Description

高频库和使用高频库的数据分级存储和查询方法和系统

技术领域

本申请涉及数据存储领域，尤其是针对使用了高频库的海量清算数据的自动化分级存储和查询方案。

背景技术

随着互联网的发展，特别是互联网金融和支付行业的蓬勃发展，线上交易系统需要处理和存储的数据越来越庞大。特别是在节假日和促销期间，线上交易的数量猛增，导致交易系统需要处理和存储的数据也成倍增加。这就很容易导致交易系统的严重延迟、无响应、甚至崩溃，并且还容易导致成本的增加。

具体而言，当前技术领域对海量数据的存储，一般使用分布式数据库产品的形式。即当数据库中某个表数据量巨大时，由于单个数据库性能有限，无法满足对该表读写的性能要求，于是将该表的数据分散存储在多个数据库中，降低对单表的读写性能压力。

以扫码收单业务场景为例，在产生一笔交易后，后台系统将该交易记录存入数据库，再将该笔交易推送到商户的app上。app收到该笔交易推送后，向后台系统发起主动查询，实时更新当日收款金额。因交易记录表数据量庞大，通常采用分布式数据库存储这些交易数据，这可以有效解决海量数据存储的问题。

但是，商户app端为保证当日收款金额的实时性，在每收到一笔交易推送后，需要发起一次查询。然而在巨大的并发交易量下，后台系统无法满足同时发起的海量查询请求，具体表现为，这些并发查询请求经常导致分布式数据库假死甚至直接宕机，从而，严重影响系统稳定性及用户体验。

因此，存在一种需求，希望能够提供一种能够在出现巨大的并发交易量时还能够及时存储和查询海量交易数据的方案。

发明内容

本申请涉及一种使用了高频库的海量清算数据的自动化分级存储和查询方案。

根据本申请的第一方面，提供了一种更新包括高频商户名单和相应交易数据的高频库的方法，包括：记录商户的历史查询日志；对所述商户的历史查询记录进行统计学分析，并输出多个维度的统计结果数据；使用基于所述多个维度的统计结果数据和包括配置参数的配置文件的高频商户判断算法，对所述多维度的统计结果数据进行综合计算以确定所述商户是否为高频商户：根据确定的结果更新所述高频商户名单。

根据本申请的第二方面，提供了一种使用如第一方面所述的高频库的数据分级存储的方法，包括：从用户层的用户接收交易数据；直接将所述交易数据存储到位于数据层的分布式数据库中；对所述交易数据进行解析以获取相应的商户号；通过确定所述商户号是否在所述高频库中的高频商户名单中来判断商户是否是高频商户：如果所述商户是高频商户，则将所述交易数据也存储到所述高频库中；如果所述商户不是高频商户，则所述方法结束。

根据本申请的第三方面，提供了一种使用如第一方面所述的高频库的数据分级查询的方法，包括：从业务层的业务系统接收交易查询请求；对所述交易查询请求进行解析以获取包括商户号和查询时间的查询条件；通过确定所获取的商户号是否在所述高频库中的高频商户名单中来判断商户是否是高频商户：如果所述商户不是高频商户，则将所述交易查询请求转发给包含了全量交易数据的分布式数据库；如果所述商户是高频商户，则判断所述查询时间是否满足所述高频库中的所述商户的起始时间参数：如果所述查询时间满足所述起始时间参数，则将所述交易查询请求转发给所述高频库；如果所述查询时间不满足所述起始时间参数，则将所述交易查询请求转发给所述分布式数据库。

根据本申请的第四方面，提供了一种使用如第一方面所述的高频库的数据分级交易系统，包括：在业务层的业务系统，被配置用于接收来自用户层的用户处的交易请求或接收来自商户处的交易查询请求；在数据层处的分布式数据库，被配置用于存储全量的交易数据；在数据层处的所述高频库，被配置用于存储高频商户名单和相应交易数据；在SQL转发层中的SQL解析器，被配置用于：对所述交易请求或交易查询请求进行解析；通过确定解析出的商户号是否在所述高频库的高频商户名单中来判断商户是否是高频商户；以及根据所述判断结果来将所述交易请求或交易查询请求分别转发至所述分布式数据库和所述高频库中的一者或两者。

根据本申请的第五方面，提供了一种存储有计算机可执行指令的计算机存储介质，当计算机执行所述计算机可执行指令时，使得所述计算机执行如第一方面所述的方法。

根据本申请的第六方面，提供了一种计算机系统，包括用于执行如第一方面所述的方法的装置。

提供本概述以便以简化的形式介绍以下在详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。

附图说明

为了描述可获得本发明的上述和其它优点和特征的方式，将通过参考附图中示出的本发明的具体实施例来呈现以上简要描述的本发明的更具体描述。可以理解，这些附图只描绘了本发明的各典型实施例，并且因此不被认为是对其范围的限制，将通过使用附图并利用附加特征和细节来描述和解释本发明，在附图中：

图1示出了未使用本申请的方案的传统交易平台的示意性系统层次结构。

图2示出了基于图1中的传统交易平台的传统交易处理流程。

图3示出了根据本申请的一个实施例的一种使用高频库的数据分级交易系统的示意性层次结构。

图4示出了根据本申请的一个实施例的一种使用高频库的数据分级存储的方法的示意性流程图。

图5介绍下根据本申请的一个实施例的一种使用高频库的数据分级查询的方法的示意性流程图。

具体实施方式

本发明可被应用于金融，支付等行业，以及其它需要对海量数据进行实时极高频率访问的领域。

为了便于理解和比较，在图1中先介绍了未使用本申请的方案的传统交易平台的示意性系统层次结构。

如图所示，该图自上而下可分为用户层、业务层及数据层，用户层包括多种商户可使用的客户端，业务层包括多个业务处理系统，数据层为存储全量交易数据的分布式数据库。

基于图1中的传统交易平台的传统交易处理流程如图2所示。首先，用户层处的消费者发起交易请求至业务层，在业务层的各个业务系统（在本示例中为“后台系统”）接收到该请求后，先将所述交易请求数据存储到数据层处的分布式数据库，再将该笔交易的收款通知推送到商户处，例如商户的app上。商户的app在收到该笔交易收款通知的推送后，向后台系统发起主动查询。后台系统在接收到该主动查询后向数据层处的分布式数据库发送查询当日收款记录的请求，而分布式数据库根据该请求向后台系统返回当日收款记录以实时更新当日收款金额。

从图1和图2中不难发现，来自用户层的查询请求被直接提供给了存储全量交易数据的分布式数据库。由于所述分布式数据库存储了全量数据，因此，每个数据查询都会引起对分布式数据库的一次访问操作。当存在海量并发查询请求时，这就很容易导致分布式数据库的假死甚至直接宕机。

为了克服现有的分布式数据库中存在的上述缺陷，申请人提供了一种支持实时同步和高访问频率的使用了高频库的数据分级存储和查询的方法和系统。

首先，在图3中示出了根据本申请的一个实施例的一种使用高频库的数据分级交易平台的示意性层次结构。

所述层次结构包括：

在业务层的业务系统，被配置用于接收来自用户层的用户处的交易请求或接收来自商户处的交易查询请求；

在数据层处的分布式数据库，被配置用于存储全量的交易数据；

在数据层处的高频库，被配置用于存储高频商户名单和与之相关联的交易数据；

在SQL转发层中的SQL解析器，被配置用于：对所述交易请求或交易查询请求进行解析；通过确定解析出的商户号是否在所述高频库的高频商户名单中来判断商户是否是高频商户；以及根据所述判断结果来将所述交易请求或交易查询请求分别转发至所述分布式数据库和所述高频库中的一者或两者。

与图1中的传统的交易平台的示意性系统层次结构相比，本发明所提供的系统层次结构在数据层中新增了一个高频库。并且在业务层的业务系统和数据层的分布式数据库之间新增了一个SQL转发层，在该层中实现了一个SQL解析器。

所述高频库是指用于存储高频数据的数据库。高频数据是指需要高频率读取的数据，例如扫码收单场景中，商户需要频繁查询当天交易记录，以实时更新统计当日收款金额，因此可将当天交易记录作为高频数据。具体而言，所述高频库包括了被高频查询的高频商户名单和其相关联的交易数据。因此，所述高频库是全量交易的分布式数据库的一个子集。

通过设立一个高频库来存储涉及高频商户的交易数据，可以将短时间范围内的高频率查询请求分流到高频库中来处理，从而，降低了存储了全量数据的分布数据库的查询负载，并且提高了查询的速度和效率。

另外所述高频库既可以放置在高速缓存中，也可以存储在普通硬盘上。如果所述高频库包含的数据量大（例如某些大型交易平台一天的交易数据量就有几百G，高频商户的数目相应地也很多），则考虑到成本问题，可以选择将高频库放在普通硬盘上。对于小交易平台，由于其数据量有限，则可以使用高速缓存来存储所述高频库，这可以带来处理速度的提升。

所述SQL转发层被配置为维护存储在所述高频库中的该高频商户名单，并且来自业务系统的所有sql查询请求，均通过该层转发。

具体而言，所述SQL转发层主要包含以下功能：

1）使用SQL解析器解析业务系统发送的sql，提取sql中的商户号及交易查询时间；

2）新增数据时，根据高频商户名单判断是否需要同步存储到高频库；

3）将sql查询请求转发至全量库或高频库进行查询；

4）异步记录历史查询信息，为后面定时更新高频商户名单提供数据支撑；

5）根据历史查询信息，定时更新高频商户名单。

应该理解，尽管在本方案中描述了使用SQL的交易请求和对应的解析器，但实际上也可以根据实际需求，使用别的数据库语言来实现本申请的方案，这些都属于本申请的保护范围。

因此，为了实现本申请的方案，首先就要在数据层新设立（更新）一个高频库，也即高频商户名单。

区分高频商户的策略通常是基于商户的应用登录缓存来判断。一种示例的判断策略如下：

1）商户登录后，将商户基本数据加入缓存，并设置缓存有效期；

2）商户缓存在超过有效期后失效；

3）商户在有效期内进行其它操作，读到缓存时，重新设置缓存的有效期，缓存在新设的有效期到期后失效。

通常情况下，应用的绝大部分功能都需要读取商户的登录缓存。如果商户比较活跃，缓存有效期经常重新设置，可保证其缓存一直不过期。反之，不活跃的商户，其缓存因超过有效期而失效。

为了确保高频商户名单的时效性，可以定期对高频商户名单进行更新。例如。高频商户名单可以每小时、每天、每周更新一次。更新的周期主要根据用户的实际需求而定。所述更新可以包括以下几个步骤：

1.记录商户的历史查询日志；

2.对商户的历史查询记录进行统计学分析，输出多个维度的统计结果数据；

3.使用一套基于多个维度的统计结果数据和包括配置参数的配置文件的高频商户判断算法，通过对多维度的统计结果数据进行综合计算以确定该商户是否为高频商户；

4.根据确定的结果更新所述高频商户名单。

在了解了高频商户名单的更新原理之后，下面就其步骤进行具体描述。

1. 记录历史查询日志

对于收到的每条sql查询，都记录下该次查询的商户号、查询时间、查询的交易时间、查询的库（例如0：全量库；1：高频库）。其中，商户号和查询时间可以通过解析sql查询来提取；而是否查询高频库的字段则可以通过sql分发算法（例如调用queryFromHighFrequency函数）来获取。在表1中例示了历史查询记录中用到的字段和其描述以及计算方法。

2. 统计分析历史查询日志

通过分析例如7天内的历史日志，来输出两组统计学数据。一组是全局统计维度的结果数据，统计范围包括7天内所有日志；另一组各个商户独有的商户统计维度的结果数据，统计范围为各个商户7天内的所有日志。全局性统计维度字段列表的示例可参见下表2，商户统计维度字段列表的示例可参见下表3。

3. 判断是否为高频商户

判断商户是否为高频商户，除了需要用到多维度的统计结果数据外，还需要用到配置文件中的配置数据。技术人员可以通过修改配置文件中的各字段数据的值来调整高频商户的评判标准。配置文件支持表4中的配置项：

应该理解，表4中的配置参数和其值都是作为示例说明给出的。用户可以根据自己的实际需要对其进行修改。

在获得了统计维度数据和包括配置参数的配置文件之后，就可以根据例如下述高频商户判断算法来确定高频商户：

1.对于mchnt.totalCount小于配置cfg.minQueryNum的商户，不作为高频商户；

2.对于mchnt.totalCount 小于全局性统计维度 global.in90PercentCount的商户，不作为高频商户；

3.对于 mchnt.in24hPercent 小于配置cfg.minIn24hPercent的商户，不作为高频商户；

4.对于mchnt.in48hPercent小于配置cfg.minIn48hPercent的商户，不作为高频商户；

5.对于mchnt.in72hPercent小于配置cfg.minIn72hPercent的商户，不作为高频商户；

6.对于mchnt.totalCount 大于全局性统计维度 global.in25PercentCount 的商户，作为高频商户；

7.对于不满足上述所有条件的商户，进行评分，评分计算公式如下：

8.将7中计算得到的分数score与配置cfg.minScore判断，大于配置的，作为高频商户，否则不作为高频商户。

应该理解，所述判断规则、算法和公式只是出于说明的目的给出，并不是要将本申请局限于此。技术人员可以根据自己交易平台的特点对所述判断规则、算法和公式进行适当的修改，这都属于本申请的保护范畴。

4 更新高频商户名单

通过执行步骤3已经可以确定商户是否为高频商户，据此，需要进一步更新高频商户名单。高频商户名单可具有3个字段，包括商户唯一标识的商户号，起始时间，状态。字段详细介绍见下表：

对不同的商户，存在下述几种更新情况：

1.该商户为高频商户，且高频商户名单中已存在该商户：不作处理；

2.该商户为高频商户，且高频商户名单中不存在该商户：将该商户加入高频商户名单，mchntCd字段即为该商户的商户号，beginTime字段的值为当前时间加10分钟缓冲期，status字段的值为正常状态0；

3.该商户不是高频商户，且高频商户名单中不存在该商户：不作处理；

4.该商户不是高频商户，且高频商户名单中存在该商户：先将名单中的status字段更新为无效状态1，然后删除高频库中该商户的数据，最终将该商户从名单中删除。

下面提供用于实现更新所述高频库的高频商户名单的方法的示例代码，以便于技术人员更好地理解。应该理解，所述代码和代码中设定的阈值仅仅是出于说明的目的给出的，并不是要将所述更新高频商户名单的方法局限于此。技术人员完全可以根据自身的需要对其进行修改。

/>

/>

使用高频商户名单

高频商户名单主要有两种用途：

1）存储交易数据时的数据同步。

有新的交易数据需要入库存储时，通过高频商户名单判断该数据在存储到分布式数据库的全量库的同时是否需要被同步到高频库。所述数据同步可以包括下述步骤：

1.获取该数据的商户号;

2.通过商户号获取该商户的高频商户名单数据，即beginTime和status数据；

3.如果该商户不在高频商户名单内：不同步到高频库；

4.如果该商户在高频商户名单内，且名单的status状态为有效状态0：同步到高频库；

其余情况均不同步到高频库。

2）查询交易数据时的sql查询分发。

收到sql查询时，通过高频商户名单判断是从分布式数据库（全量库）还是从高频库进行查询。所述sql查询分发可以包括下述步骤：

1.解析sql，获取sql中的商户号sql.mchntCd及查询时间sql.queryTime;

2.通过sql.mchntCd获取该商户的高频商户名单数据，即beginTime和status数据；

3.如果该商户不在高频商户名单内：从全量库查询；

4.如果该商户在高频商户名单内，且名单的status状态为有效状态0，且查询时间在名单的beginTime范围内：从高频库查询；

其余情况从（分布式数据库）全量库查询。

下面结合图4中的根据本申请的一个实施例的一种使用高频库的数据分级存储的方法的示意性流程图来进行具体说明，在其中涉及到了使用高频库的数据同步。

如图所示，当所述数据存储方法开始之后，首先，在步骤402，业务层的业务系统从用户层的用户接收交易请求。例如，用户可以通过自己的手机上的购物APP发起一笔对商品的交易请求，所述交易请求可以包括下述交易数据：订单号（流水号）、商户号、交易金额、交易时间、结算日期、用户账户信息（例如用户ID、银行卡信息……）等等。

在接收到所述交易数据之后，在步骤404中，直接将所述交易数据存储到位于数据层的分布式数据库中以实现全量数据存储。

随后，就是判断是否要在高频库处执行数据同步操作，包括：

在步骤406处，所述SQL转发层的SQL解析器对交易请求进行解析，以获取与之相关联的商户号。

在步骤408处，SQL解析器通过确定所获取的商户号是否在高频库中所存储的高频商户名单中来判断商户是否是高频商户。

如果商户号在高频商户名单中（即提供交易数据的商户是高频商户），则流程进入到步骤410，把该交易数据也存储到高频库中，并且存储流程至此结束。

如果商户号不在高频商户名单中（即提供交易数据的商户不是高频商户），则流程直接结束，即所述交易数据仅仅存储在分布式数据库中，而不会存储到高频库中。

下面给出实现上述数据同步操作的示例代码：

至此，所述数据分级存储的方法的流程结束。

通过上述存储流程，本申请可以实现将涉及高频商户的交易数据同时存储到传统的分布式数据库和新增加的高频库中。换句话说，通过执行本申请所述的方案，分布式数据库存储有包含所有商户的全量交易数据，而高频库仅仅存储了属于高频商户名单中的高频商户的交易数据。

在利用上述使用高频库的数据分级存储方法存储了交易数据之后，下面根据图5介绍下根据本申请的一个实施例的一种使用高频库的数据分级查询的方法的示意性流程图。

如图所示，当所述数据查询方法开始之后，首先，在步骤502，SQL转发层中的SQL解析器从业务层的业务系统接收到例如来自商户的交易查询请求（诸如sql查询）。

随后，在步骤504，所述SQL解析器对该查询请求进行解析以获取查询条件。例如，从所述查询请求中提取出的商户号及查询时间字段。

接着，流程可进入步骤508，所述SQL解析器通过确定所提取的商户号是否在高频库中所存储的高频商户名单中来判断商户是否是高频商户。

如果商户号不在高频商户名单中（即发起查询请求的商户是普通商户），则流程行进至步骤516，在此，SQL解析器将该交易查询请求转发给包含了全量库的分布式数据库，而不是高频库。并且在步骤518，在分布式数据库中执行所述查询请求并返回查询结果。

如果商户号在高频商户名单中（即发起查询请求的商户是高频商户），则流程行进至步骤510，在此再次判断交易查询请求的查询条件中限定的查询时间是否满足高频库中的该商户的起始时间参数。高频库里一般只存两三天的数据，商户查询时，查询的时间范围有可能要查几天前的记录，这就可能存在尽管要查询的商户是高频商户，但需要查询的时间却超出了高频库中所记录的时间。为了防止这种情况下出现，如在表5中所示，所述高频商户名单中包含了一个“beginTime”字段，该字段表示高频库中存储了从beginTime开始至今，该商户的所有交易记录。因此，可以通过将交易查询请求的查询时间与高频库中的该商户的“beginTime”字段进行比较，来确定要查询的数据所属时间是否在beginTime内。

如果sql请求查询了属于beginTime以外的数据，即，查询时间不满足高频库的起始时间，则由于高频库中不包含该部分超出范围的数据，只能去分布式数据库的全量库中进行查询，也即流程应该行至步骤516，在此，SQL解析器将该交易查询请求转发给包含了全量库的分布式数据库，而不是高频库。

如果sql请求查询了属于beginTime内的数据，即，交易查询请求的查询时间满足高频库中的该商户的起始时间，则流程进入到步骤512，SQL解析器将该交易查询请求转发给高频库，而不是分布式数据库。并且在步骤514，在高频库中执行所述查询请求并返回查询结果。

下面给出实现上述判断步骤508和510的示例代码：

至此，所述所述数据分级查询的方法的流程结束。

在一个实施例中，所述数据分级查询方法还可包括可选步骤506，在该可选步骤506中，异步记录此次商户的查询信息，以用于后续更新高频商户名单。也就是说通过该步骤，越是被频繁查询的商户在高频库的高频商户名单中保存的时间就越长。

通过设立一个高频库来存储涉及高频商户的交易数据，可以将短时间范围内的高频率查询请求分流到高频库中来处理，从而，降低了存储了全量数据的分布数据库的查询负载，并且提高了查询的速度和效率。

本申请的优点：

在本申请的方案中，在业务系统和数据库之间，新增一层SQL转发层， SQL转发层中实现一个SQL解析器，用于解析并提取sql查询请求中的商户号和查询条件，并据此来判定是经该查询请求转发给高频库还是分布式数据库。该创新点可显著降低分布式数据库的处理负担，减少各个业务系统的升级改造工作量，为各个业务系统快速升级改造提供有力支撑；

另外，本申请还记录了商户的历史查询信息，基于对商户历史查询信息的分析，可以较准确地辨别哪些商户是高频商户，提高高频库的分流量，显著降低分布式数据库的查询压力。

虽然以上描述了不同的实施例，但应当理解的是它们只是作为示例而非限制。（诸）相关领域的技术人员将领会，在不偏离如所附权利要求书所定义的本发明的精神和范围的情况下，可以在形式和细节方面进行各种修改。因此，此处所公开的本发明的宽度和范围不应被上述所公开的示例性实施例所限制，而应当仅根据所附权利要求书及其等同替换来定义。

Claims (9)

1.一种使用高频库的数据分级交易的方法，包括：

将全量的交易数据存储在数据层处的分布式数据库中；

将高频商户名单和相应交易数据存储在数据层处的高频库中；

在业务层的业务系统处，接收来自用户层的用户处的交易请求或接收来自商户处的交易查询请求；

在SQL转发层中的SQL解析器处：

对所述交易请求或交易查询请求进行解析；

通过确定解析出的商户号是否在所述高频库的高频商户名单中来判断商户是否是高频商户；以及

根据判断结果来将所述交易请求或交易查询请求分别转发至所述分布式数据库和所述高频库中的一者或两者；

其中所述高频库通过下述步骤更新：

记录商户的历史查询日志；

对所述商户的历史查询记录进行统计学分析，并输出多个维度的统计结果数据；

使用基于所述多个维度的统计结果数据和包括配置参数的配置文件的高频商户判断算法来确定所述商户是否为高频商户：

根据确定的结果更新所述高频商户名单；

其中，所述根据确定的结果更新所述高频商户名单包括：

如果确定所述商户是高频商户且所述商户已经在所述高频商户名单中，则不对所述高频商户名单进行操作；

如果确定所述商户是高频商户且所述商户不在所述高频商户名单中，则将所述商户加入到所述高频商户名单；

如果确定所述商户不是高频商户且所述商户在所述高频商户名单中，则从所述高频商户名单中移除所述商户；

如果确定所述商户不是高频商户且所述商户不在所述高频商户名单中，则不对所述高频商户名单进行操作。

2.如权利要求1所述的方法，其特征在于，所述多个维度的统计结果数据包括：全局统计维度的结果数据和商户统计维度的结果数据。

3.如权利要求1所述的方法，其特征在于，所述方法还包括：定期对所述高频商户名单进行更新。

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

从用户层的用户接收交易数据；

直接将所述交易数据存储到位于数据层的分布式数据库中；

对所述交易数据进行解析以获取相应的商户号；

通过确定所述商户号是否在所述高频库中的高频商户名单中来判断商户是否是高频商户：

如果所述商户是高频商户，则将所述交易数据也存储到所述高频库中；

如果所述商户不是高频商户，则所述方法结束。

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

从业务层的业务系统接收交易查询请求；

对所述交易查询请求进行解析以获取包括商户号和查询时间的查询条件；

通过确定所获取的商户号是否在所述高频库中的高频商户名单中来判断商户是否是高频商户：

如果所述商户不是高频商户，则将所述交易查询请求转发给包含了全量交易数据的分布式数据库；

如果所述商户是高频商户，则判断所述查询时间是否满足所述高频库中的所述商户的起始时间参数：

如果所述查询时间满足所述起始时间参数，则将所述交易查询请求转发给所述高频库；

如果所述查询时间不满足所述起始时间参数，则将所述交易查询请求转发给所述分布式数据库。

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

异步记录此次商户的查询信息，以用于后续更新所述高频商户名单。

7.一种使用如权利要求1所述的数据分级交易的方法的数据分级交易系统，包括：

在业务层的业务系统，被配置用于接收来自用户层的用户处的交易请求或接收来自商户处的交易查询请求；

在数据层处的分布式数据库，被配置用于存储全量的交易数据；

在数据层处的所述高频库，被配置用于存储高频商户名单和相应交易数据；

在SQL转发层中的SQL解析器，被配置用于：

对所述交易请求或交易查询请求进行解析；

通过确定解析出的商户号是否在所述高频库的高频商户名单中来判断商户是否是高频商户；以及

根据判断结果来将所述交易请求或交易查询请求分别转发至所述分布式数据库和所述高频库中的一者或两者。

8.一种存储有计算机可执行指令的计算机存储介质，当计算机执行所述计算机可执行指令时，使得所述计算机执行如权利要求1-6中任一项所述的方法。

9.一种计算机系统，包括用于执行如权利要求1-6中任一项所述的方法的装置。