一种自适应资源分配方法及装置与流程

本申请属于信息处理技术领域，尤其涉及一种自适应资源分配方法及装置。

背景技术：

在线交易库，一般指的是存放在线交易OLTP(Online Transaction Processing，联机事务处理)数据的数据库，该在线交易库提供的是在线交易服务，对请求的响应时间十分敏感。

数据仓库，一般指的是以提供在线数据分析OLAP(Online Analytical Processing，联机分析处理)和商业智能(BI，Business Intelligence)功能为目的数据库，相对于在线交易库来说，数据仓库一次请求访问的数据量很大，对响应时间不是特别敏感。

数据库系统通常用来满足两个大的方面的业务需求：1、满足关键的在线交易型业务的需求，需要支持完整的具备ACID(原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability)特性的事务、具有非常短的请求响应时间和较大的吞吐率；2、满足数据挖掘和商务智能等分析型业务需求，分析型业务对事务的要求比较弱，但是单个请求访问的数据量很大(百千万行、上亿行)，语句复杂，执行单个请求消耗的资源多，响应时间也相对较长，需要几分钟到若干小时不等。由于数据仓库中的数据通常定期从在线交易库中导入，所以数据仓库的时效性比在线交易库要差一些。

当前在大多数企业中，上述两个数据库系统(在线交易库和数据仓库)是独立的，通过ETL系统和工具，定期将在线交易库中的数据导入到数据仓库中进行分析。随着业务发展的要求，越来越多的用户希望在一个数据库系统能够同时支持在线交易业务和分析型业务，减少数据的搬迁和冗余的存储，同时能够实时分析最新的交易数据。

在线交易库和数据仓库的融合带来了一个问题，由于系统资源的总量有限而分析型查询请求又总是会消耗大量的系统资源，对在线交易应用产生很大的影响，例如：引起对延时十分敏感的在线交易事务超时或者积压，对核心业务造成损失。

为了解决这个问题，部分数据库厂商也提供了解决方案。一个被广泛采用的方案是进行用户资源管理，为不同的用户静态设置不用的资源池，该资源池包括CPU(Central Processing Unit，中央处理器)、内存、IOPS(Input/Output Operations Per Second，每秒读写操作次数)等资源。在一个部署混合业务的数据库系统中，为交易型业务和分析型业务各自使用不同的用户，配置不同的资源池。通过这种方案，在实现得比较好的系统中，这两类业务就能基本做到资源使用互相不影响。

上述静态预配置资源方案虽然能够部分解决不同类型业务相互影响的问题，但是缺点也很明显。

第一，管理员无法合理地在不同业务间进行资源分配。但是，资源合理分配需要对两类业务执行时的资源消耗有准确的度量。由于业务的复杂和多变，对资源的消耗通常不是一个稳定的值，而是一个随着时间周期不断变化的值，一个浅显的例子就是每类业务都有高峰期和低谷期，以业务高峰时的值来确定该类业务的分配和以低谷时的值来确定该类业务的分配显然会是两个截然不同的值。

第二，预置的资源配额也不利于资源的充分利用，以在线交易型业务和分析型业务为例，这两类业务有很明显的时间周期特性，除了促销等特殊时点外，在线交易型业务的高峰期通常在白天，深夜通常是低谷期；但分析型业务往往是做周期性统计的，例如日结或者月结，高峰期大多数在夜间。

因此，多数情况下无法事先确定在线交易型业务和分析型业务的实际资源使用情况，并且这两种类型的业务都会有高峰期和低谷期，且峰谷期对资源的需求截然不同，对系统管理员来说，很难做到预先设定合理的资源配额。

针对传统的静态预配置资源方案无法根据资源使用情况实时调整资源配额的问题，目前尚未提出有效的解决方案。

技术实现要素：

本申请目的在于提供一种自适应资源分配方法及装置，可以自适应地调整不同时间段内的不同类型业务的资源配额，以达到既保证核心业务能够稳定运行，又能充分利用系统资源的目的。

本申请提供一种自适应资源分配方法及装置是这样实现的：

一种自适应资源分配方法，所述方法包括：统计一个周期内每个业务语句的请求时间、实际执行时间和响应时间；根据所述请求时间，确定每个业务语句所属的所述一个周期的不同时间段；根据每个时间段内每个业务语句的所述实际执行时间和所述响应时间，确定每个业务语句的类型，并调整下一个周期的同一时间段内不同类型业务语句的资源配额。

一种自适应资源分配装置，所述装置包括：统计单元，用于统计一个周期内每个业务语句的请求时间、实际执行时间和响应时间；划分单元，用于根据所述请求时间，确定每个业务语句所属的所述一个周期的不同时间段；类型确定单元，用于根据每个时间段内每个业务语句的所述实际执行时间和所述响应时间，确定每个业务语句的类型；调整单元，用于调整下一个周期的同一时间段内不同类型业务语句的资源配额。

通过本申请提供的自适应资源分配方法及装置，系统能够根据运行期间接收到的业务请求类型及不同类型业务请求的负载情况，自适应地调整不同时间段内不同类型业务的资源配比，以达到既保证核心业务(例如交易型业务)能够稳定运行，又能充分利用系统资源的目的。

附图说明

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

图1是本申请提出的自适应资源分配方法的一种实施例的方法流程图；

图2是本申请所述自适应资源分配装置一种实施例的结构示意图；

图3是本申请所述类型确定单元一种实施例的结构示意图；

图4是本申请所述调整单元一种实施例的结构示意图；

图5是应用本申请所述自适应资源分配方案的系统的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

关于本文中所使用的“第一”、“第二”、…等，并非特别指称次序或顺位的意思，也非用以限定本发明，其仅为了区别以相同技术用语描述的元件或操作。

对于交易型业务和分析型业务的资源分配，由于多数情况下无法事先确定二者的实际资源使用情况，因此系统管理员很难做到预先设定合理的资源配额。在系统实际运作过程中，交易型业务和分析型业务有较好的时间周期互补性，相对于静态预配置资源分配方案，更佳的方案是系统能够根据业务的周期性动态调整资源分配，在交易型业务的高峰期，需要将资源更多地配置给交易型业务，限制分析型业务使用的资源总量；在交易型业务的低谷期，可以将资源更多地配置给分析型业务，有利于充分利用资源，快速完成分析任务，拿到供决策使用的分析结果。基于此，本申请提供了一种自适应资源分配方法及装置。

下面结合附图对本申请所述的自适应资源分配方法及装置进行详细的说明。图1是本申请提出的自适应资源分配方法的一种实施例的方法流程图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块结构。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例提供的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法或模块结构连接进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图1所示，本申请提供的自适应资源分配方法的一种实施例可以包括：

步骤S102，统计一个周期内每个业务语句的请求时间、实际执行时间和响应时间。

步骤S104，根据上述请求时间，确定每个业务语句所属的一个周期的不同时间段；即通过判断每个业务语句的请求时间位于哪个时间段内，就确定该业务语句属于该时间段。

步骤S106，根据每个时间段内每个业务语句的实际执行时间和响应时间，确定每个业务语句的类型，并调整下一个周期的同一时间段内不同类型业务语句的资源配额。

通过上述自适应资源分配方法，系统能够根据运行期间接收到的业务请求类型及不同类型业务请求的负载情况，自适应地调整不同时间段内不同类型业务的资源配比，以达到既保证核心业务(例如交易型业务)能够稳定运行，又能充分利用系统资源的目的。

对于上述周期和上述时间段的时长设定，一般情况下，可以设定一个周期是一天，分为24个时间段，一个时间段是一个小时。另外，还可以设定一个周期是一周，一个时间段是一天；或者，设定一个周期是一个月，一个时间段是一天；或者，设定一个周期是一年，一个时间段是一个月。当然，也可以基于实际需求设定一个周期和相应时间段的具体时长，本申请对此不做限制。一般情况下，周期和相应时间段的时长越短，系统自适应分配资源的准确率越高。

在本申请中，业务语句的类型可以包括：交易型业务语句和分析型业务语句。当然，也可以包括其他类型的业务语句，具体可基于实际需求进行设定，如果需要自适应调整其他类型业务语句的资源配额，具体实现同样可采用上述自适应资源分配方法。本申请主要以交易型业务语句和分析型业务语句这两种类型的业务语句为例进行说明。

在划分好每个业务语句所属的时间段之后，可以根据每个时间段内每个业务语句的实际执行时间，确定每个业务语句的类型，具体可以通过以下优选实施方式实现：判断每个时间段内每个业务语句的实际执行时间是否大于执行时间阈值；如果是，则判定该业务语句是分析型业务语句；如果否，则判定该业务语句是交易型业务语句。通过上述优选实施方式，可以简单快捷准确地确定业务语句的类型，上述执行时间阈值的数值可根据实际情况进行设定或调整。

在确定了每个业务语句的类型之后，可以根据每个时间段内每个业务语句的实际执行时间和响应时间，调整下一个周期的同一时间段内不同类型业务语句的资源配额，具体可以通过以下优选实施方式实现：

第一步，将每个时间段内所有交易型业务语句的实际执行时间求和，得到每个时间段内的第一实际执行时间和；将每个时间段内所有交易型业务语句的响应时间求和，得到每个时间段内的第一响应时间和；

第二步，将每个时间段内所有分析型业务语句的实际执行时间求和，得到每个时间段内的第二实际执行时间和；将每个时间段内所有分析型业务语句的响应时间求和，得到每个时间段内的第二响应时间和；

第三步，根据第一实际执行时间和、第一响应时间和、第二实际执行时间和、第二响应时间和，调整下一个周期的同一时间段内交易型业务语句和分析型业务语句的资源配额。

对于第三步的具体操作，可以通过以下优选实施方式实现：

判断第一响应时间和是否大于第一实际执行时间和，如果是，则判定交易型业务语句的资源配额过小，将分析型业务语句的资源配额减少，例如：将分析型业务语句的资源配额降低为预设的分析型业务语句的最低资源配额。

判断第二响应时间和是否大于第二实际执行时间和，如果是，则判定分析型业务语句的资源配额过小，将交易型业务语句的资源配额减少，例如：将交易型业务语句的资源配额降低为大于或等于以下二者的最大值：预设的交易型业务语句的最低资源配额、第一实际执行时间和实际消耗的资源配额。

其中，分析型业务语句的最低资源配额和交易型业务语句的最低资源配额的数值，可根据实际需求进行设定或调整。

通过上述优选实施方式，可以实现系统根据不同类型业务语句的负载情况自适应调整不同类型业务语句的资源配额，并且资源配额调整操作的准确度较高，能够充分利用系统资源，保证不同类型业务的顺利运行，避免资源浪费。

需要说明的是，在不同的应用场景下，不同类型的业务的重要程度可能不同，例如在大促销时，需要优先保证交易型业务的顺利运行。因此，本申请提供了一种优选实施方式，即对交易型业务语句和分析型业务语句进行优先级排序；其中，交易型业务语句的优先级高于分析型业务语句；在特定场景下，如果预设时间内交易型业务语句的请求量超出阈值，则将分析型业务语句的资源配额降为零，直至交易型业务语句的请求量低于上述阈值。上述阈值的数值可根据实际需求进行设定或调整。通过上述优选实施方式，可以基于不同类型业务的重要程度来对不同类型的业务语句进行优先级排序，从而保证在某些特定场景下某类型业务的优先运行。一般情况下，交易型业务语句和分析型业务语句的优先级是由系统管理员设置的，管理员根据该系统主要支撑的业务类型来进行优先级的排序。

另外，在系统资源不足时，也可以根据不同类型业务的优先级选择优先保证某类业务的运行。基于此，本申请提供了一种优选实施方式，即对交易型业务语句和分析型业务语句进行优先级排序；在系统资源低于资源阈值时，优先为优先级高的业务语句分配资源配额，和/或，将优先级低的业务语句的资源配额降为零。

基于与上述自适应资源分配方法相同的发明构思，本申请提供一种自适应资源分配装置，如下面实施例所述。由于该自适应资源分配装置解决问题的原理与自适应资源分配方法相似，因此该自适应资源分配装置的实施可以参见自适应资源分配方法的实施，重复之处不再赘述。

图2是本申请所述自适应资源分配装置一种实施例的结构示意图，如图2所示，所述装置可以包括：

统计单元10，用于统计一个周期内每个业务语句的请求时间、实际执行时间和响应时间。统计单元10是自适应资源分配装置中统计时间信息的部分，可以是软件、硬件或二者的结合，例如可以是完成时间信息采集功能的输入输出接口、处理芯片等元器件。

划分单元20，用于根据上述请求时间，确定每个业务语句所属的一个周期的不同时间段。划分单元20是自适应资源分配装置中时间段划分操作部分，可以是软件、硬件或二者的结合，例如可以是完成时间段划分功能的输入输出接口、处理芯片等元器件。

类型确定单元30，用于根据每个时间段内每个业务语句的上述实际执行时间和上述响应时间，确定每个业务语句的类型。类型确定单元30是自适应资源分配装置中时间段划分操作部分，可以是软件、硬件或二者的结合，例如可以是完成时间段划分功能的输入输出接口、处理芯片等元器件。

调整单元40，用于调整下一个周期的同一时间段内不同类型业务语句的资源配额。调整单元40是自适应资源分配装置中资源配额调整部分，可以是软件、硬件或二者的结合，例如可以是完成资源配额调整功能的输入输出接口、处理芯片等元器件。

基于上述自适应资源分配装置，系统能够根据运行期间接收到的业务请求类型及不同类型业务请求的负载情况，自适应地调整不同时间段内不同类型业务的资源配比，以达到既保证核心业务(例如交易型业务)能够稳定运行，又能充分利用系统资源的目的。

对于上述周期和上述时间段的时长设定，一般情况下，可以设定一个周期是一天，分为24个时间段，一个时间段是一个小时。另外，还可以设定一个周期是一周，一个时间段是一天；或者，设定一个周期是一个月，一个时间段是一天；或者，设定一个周期是一年，一个时间段是一个月。当然，也可以基于实际需求设定一个周期和相应时间段的具体时长，本申请对此不做限制。一般情况下，周期和相应时间段的时长越短，系统自适应分配资源的准确率越高。

在本申请中，业务语句的类型可以包括：交易型业务语句和分析型业务语句。当然，也可以包括其他类型的业务语句，具体可基于实际需求进行设定。

在划分好每个业务语句所属的时间段之后，可以根据每个时间段内每个业务语句的实际执行时间，确定每个业务语句的类型，具体可以通过以下优选实施方式实现：所述装置还可以包括：阈值设置单元，用于设置执行时间阈值。执行时间阈值的数值可根据实际情况进行设定或调整。图3是本申请所述类型确定单元一种实施例的结构示意图，如图3所示，上述类型确定单元30可以包括：判断模块31，用于判断每个时间段内每个业务语句的实际执行时间是否大于执行时间阈值；第一处理模块32，用于在上述判断模块31的判断结果为是的情况下，判定该业务语句是分析型业务语句；第二处理模块33，用于在上述判断模块31的判断结果为否的情况下，判定该业务语句是交易型业务语句。通过上述优选实施方式，可以简单快捷准确地确定业务语句的类型。

图4是本申请所述调整单元一种实施例的结构示意图，如图4所示，上述调整单元40包括：第一计算模块41，用于将每个时间段内所有交易型业务语句的实际执行时间求和，得到每个时间段内的第一实际执行时间和；第二计算模块42，用于将每个时间段内所有交易型业务语句的响应时间求和，得到每个时间段内的第一响应时间和；第三计算模块43，用于将每个时间段内所有分析型业务语句的实际执行时间求和，得到每个时间段内的第二实际执行时间和；第四计算模块44，用于将每个时间段内所有分析型业务语句的响应时间求和，得到每个时间段内的第二响应时间和；资源调整模块45，用于根据第一实际执行时间和、第一响应时间和、第二实际执行时间和、第二响应时间和，调整下一个周期的同一时间段内交易型业务语句和分析型业务语句的资源配额。

对于上述资源调整模块45，可以包括：第一调整子模块，用于判断第一响应时间和是否大于第一实际执行时间和，如果是，则判定交易型业务语句的资源配额过小，将分析型业务语句的资源配额减少，具体地，将分析型业务语句的资源配额降低为预设的分析型业务语句的最低资源配额；第二调整子模块，用于判断第二响应时间和是否大于第二实际执行时间和，如果是，则判定分析型业务语句的资源配额过小，将交易型业务语句的资源配额减少，具体地，将交易型业务语句的资源配额降低为大于或等于以下二者的最大值：预设的交易型业务语句的最低资源配额、第一实际执行时间和实际消耗的资源配额。其中，分析型业务语句的最低资源配额和交易型业务语句的最低资源配额的数值，可根据实际需求进行设定或调整。

通过上述优选实施方式，可以实现系统根据不同类型业务语句的负载情况自适应调整不同类型业务语句的资源配额，并且资源配额调整操作的准确度较高，能够充分利用系统资源，保证不同类型业务的顺利运行，避免资源浪费。

需要说明的是，在不同的应用场景下，不同类型的业务的重要程度可能不同，例如在大促销时，需要优先保证交易型业务的顺利运行。因此，本申请提供了一种优选实施方式，上述装置还可以包括：第一优先分配单元，用于对交易型业务语句和分析型业务语句进行优先级排序；其中，交易型业务语句的优先级高于分析型业务语句；在特定场景下，如果预设时间内交易型业务语句的请求量超出阈值，则将分析型业务语句的资源配额降为零，直至交易型业务语句的请求量低于阈值。通过上述优选实施方式，可以基于不同类型业务的重要程度来对不同类型的业务语句进行优先级排序，从而保证在某些特定场景下某类型业务的优先运行。

在系统资源不足时，也可以根据不同类型业务的优先级选择优先保证某类业务的运行。基于此，本申请提供了一种优选实施方式，上述装置还可以包括：第二优先分配单元，用于对交易型业务语句和分析型业务语句进行优先级排序；在系统资源低于资源阈值时，优先为优先级高的业务语句分配资源配额，和/或，将优先级低的业务语句的资源配额降为零。

下面通过优选实施例和附图对本申请的技术方案进行更详细的介绍。

本申请的自适应资源分配方案主要包括以下几个部分：

1)系统初始化配置

系统管理员为系统配置初始参数，主要包括：

a.设置用以区分不同类型业务语句的判定依据。具体地，可以基于实际情况预设一个执行时间阈值(large_query_threshold)，如果业务语句的实际执行时间大于该执行时间阈值，则认为该业务语句是分析型业务语句，如果业务语句的实际执行时间小于该执行时间阈值，则认为该业务语句是交易型业务语句。

b.设置不同类型业务语句的优先级。具体地，可以根据不同类型业务语句的重要程度进行优先级的排序，从而在系统资源严重不足时，可优先处理优先级较高的业务语句和/或主动中断优先级较低的业务语句。一般情况下，对于混合型的系统，通常是交易型业务较为优先。

c.设置不同类型业务语句的最低资源配额(min_oltp_time/min_olap_time)。在系统运行中，根据历史数据统计情况，优先级较高的业务语句在低谷期使用的资源很少，因此可以适当降低优先级较高的业务语句的资源配额，但为了保障优先级较高的业务语句的服务质量，为其分配的资源配额也不会低于上述设置的最低资源配额。而在资源有限或者大促销等特殊场景下，可以将优先级较低的业务语句的资源配额降低为零。

2)收集运行统计信息

图5是应用本申请所述自适应资源分配方案的系统的结构示意图，如图5所示，系统运行过程中，在业务语句的执行过程中，执行器收集关于该业务语句的执行状态信息，该执行状态信息主要包括如下的内容：系统接收到这条业务语句请求的时间(T_start)、实际执行时间(T_actual)和响应时间(T_elapse)。其中，实际执行时间(T_actual)指的是调度器分配给这条业务语句的总的执行时间，如果没有用完调度器分配的时间，就执行结束，则实际执行时间指的是实际执行所使用的时间，响应时间(T_elapse)指的是从系统接收到这条业务语句到执行完成所持续的时间。

执行器收集上述信息后，将三元组(T_start，T_actual，T_elapse)汇报给统计分析模块，该统计分析模块的功能相当于上述自适应资源分配装置中的统计单元、划分单元和类型确定单元的功能。

需要说明的是，上述调度器指的是系统中承担调度前端发过来的请求的模块，调度器根据不同类型任务的资源配额情况，作出启动某个任务的执行、暂停甚至终止的决定。上述执行器指的是系统中实际完成前端请求任务的模块，在执行的过程中，会根据调度器的指示中断或者提前结束执行，在执行结束后，获取相应的执行状态信息。

3)数据统计分析及反馈

统计分析模块统计一个周期内的每个时间段(例如一天的每个小时)内的请求分布情况。首先，按照请求时间(T_start)对一天内的所有三元组进行分组获取每小时的请求集ReqSet(h0)，ReqSet(h1)，ReqSet(h23)；然后，针对每一个小时的请求集ReqSet(hi)里面的三元组，找出所有实际执行时间(T_actual)<执行时间阈值(large_query_threshold)值的元组，组成一个新的集合ReqSetOltp(hi)，这个集合就是每个时间段内所有的交易型业务语句的集合，剩下的就是每个时间段内所有分析型业务语句的集合ReqSetOlap(hi)。

分别对ReqSetOltp(hi)和ReqSetOlap(hi)这两个元组中的实际执行时间(T_actual)、响应时间(T_elapse)求和，分别得到四个时间值第一实际执行时间和TotalAtimeOltp(hi)、第一响应时间和TotalEtimeOltp(hi)、第二实际执行时间和TotalAtimeOlap(hi)、第二响应时间和TotalEtimeOlap(hi)。通过这四个时间值，就可以确定系统在这一个小时内的资源使用情况(可构建持续更新的资源分配表)，主要包括如下两种情况：

a.第一种情况：第一响应时间和TotalEtimeOltp(hi)>第一实际执行时间和TotalAtimeOltp(hi)*(1+α)，其中α表示一个可接受的统计和计时的误差，下同。

这种情况表明系统用于执行交易型业务语句的资源不足，以至于某些请求没有及时地被执行或者执行过程中被中断，从而造成交易型业务语句总的响应时间显著地长于实际执行所需要的时间。

b.第二种情况：第二响应时间和TotalEtimeOlap(hi)>第二实际执行时间和TotalAtimeOlap(hi)*(1+α)。

这种情况表明系统用于执行分析型业务语句的资源不足，以至于某些请求没有及时地被执行或者执行过程中被中断，从而造成分析型业务语句总的响应时间显著地长于实际执行所需要的时间。

如果上述两种情况同时出现，则表明两种类型业务语句都没有被及时地响应，系统已经明显过载。可根据优先级的高低降低某一种类型业务语句的资源配额，或者按照相同或不同的比例降低两种类型业务语句的资源配额。

如果上述两种情况都没有出现，则表明系统的负载较轻，两种类型的业务语句都能顺利运行。

如果上述情况仅出现一种，则表明系统的资源分配使得某一类型的业务语句能够及时得到响应，而另一类型的业务语句没有得到足够的资源去执行。在这种情况下，结合系统在该时间段分配给两种类型业务语句的资源配额AssignTimeOltp(hi)，AssignTimeOlap(hi)，对下一个周期同一时间段(第二天的同一个小时)内的资源配额进行调整。

当前采用较为简单的调整策略是：当交易型业务语句的资源配额过小时，将分析型业务语句的资源配额减少；当分析型业务语句的资源配额过小时，将交易型业务语句的资源配额减少。

在系统具体实现时，可以选择更为精细地调整策略：a.交易型业务语句的资源配额不足时，可直接将分析型业务语句的资源配额降到预设的分析型业务语句的最低资源配额(min_olap_time)。B.分析型业务语句的资源不足时，将交易型业务语句的资源配额调降一定的比例(例如10％)，并且保证调整后的资源配额大于等于第二响应时间和实际消耗的资源配额TotalEOltp(hi)和预设的交易型业务语句的最低资源配额(min_oltp_time)中的最大值。

4)资源配额的调度

在下一个周期(例如第二天)，系统会根据由前一个周期(例如第一天)的对应时间段(以小时计)计算获取到的值，基于上述介绍的策略进行资源配额的调整，重新设定不同类型业务的资源占比。同时在执行的过程中又会将两个类型业务语句新的负载情况进行汇报和分析。

需要说明的是，对于类似于大促(例如：双11、双12)这样的场景，在交易型业务比分析型业务优先的情况下，系统根据实时统计信息判定持续一段时间(例如1分钟)的交易型业务语句的请求量是否超出阈值，可以直接降低或取消该时间段内分析型业务语句的资源配额，直至交易型业务语句的请求量恢复到正常水平。

在本申请中，不同类型的业务语句所享有的资源指的是为执行请求所需要的CPU(Central Processing Unit，中央处理器)、内存、存储及网络资源，本申请主要指的是CPU资源。类似的，对使用内存使用、IO使用、网络资源等其他系统资源作为考察对象实现的自适应的调整也同样适用于本申请的技术方案。

从以上的描述中可知，本申请提供了一种在系统管理员对系统进行初始化参数配置后(例如明确系统是以交易型业务为优先)，根据系统在过去某个时间段的不同类型业务语句的资源使用情况自适应地调整系统未来在该时间段的资源分配的方案。既保证核心业务能够稳定运行，又能充分利用系统资源。

本申请中各个实施例所涉及的上述描述仅是本申请中的一些实施例中的应用，在某些标准、模型、方法的基础上略加修改后的实施方式也可以实行上述本申请各实施例的方案。当然，在符合本申请上述各实施例的中所述的处理方法步骤的其他无创造性的变形，仍然可以实现相同的申请，在此不再赘述。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明的装置或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。当然，也可以将实现某功能的模块由多个子模块或子单元组合实现。

本申请中所述的方法、装置或模块可以以计算机可读程序代码方式实现控制器按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请所述装置中的部分模块可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

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

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请的全部或者部分可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、移动通信终端、多处理器系统、基于微处理器的系统、可编程的电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。