CN105431815B - 用于数据库工作负荷的输入-输出优先化 - Google Patents

Abstract

一种数据库管理系统可由第三方提供商操作，所述第三方提供商将所述系统托管在数据中心，并且将对所述系统的访问提供给代表各种实体的终端用户。可施加对总容量消耗的限制，但当容量消耗超过那些限制时，可造成服务中断。可对在所述系统上执行操作的请求进行分类。所述请求分类可与用于准入或拒绝所述请求的策略相关联。表示可用于执行所述操作的请求的容量的一个或多个令牌桶可用于确定以准入所述请求，且基于执行所述操作的成本而被更新。

Description

用于数据库工作负荷的输入-输出优先化

相关申请的交叉引用

本申请要求2013年5月17日提交的第13,897,232号美国专利申请的权益，其公开内容以引用的方式全文并入本文。

发明背景

数据库管理系统(“DBMS”)可由第三方提供商操作，第三方提供商将DBMS托管在数据中心中的服务器上，并且提供DBMS作为对各种实体(诸如企业、高校、政府机关和其它类型的客户)的服务。为了托管DBMS并将服务提供到各种实体，提供商通常维护硬件、软件和基础设施中的重要资源。此外，提供商可承担与操作DBMS相关的各种持续成本，诸如电力、维护成本和技术人员的薪水。相应地，为了将响应服务提供到各种实体，提供商可尝试使安装在其数据中心处的硬件和其它资源的容量和利用率最大化。

附图简述

在本文中提供的附图被设计来图示示例实施方案，且不旨在限制本公开的范围。

图1是描绘通过网络服务暴露于终端用户并且通过对令牌分配和消耗机制的使用而限制容量消耗的数据库管理系统的框图。

图2是描绘使用令牌分配和消耗机制执行所供应的容量的流程图。

图3A是描绘令牌到令牌桶的分配以及消耗来自令牌桶的令牌的多个请求类型的图示。

图3B是描绘将令牌分配到根据请求类型进行分类的多个令牌桶并且基于处理相应的请求类型而从桶提取令牌的图示。

图4是将请求类型划分成多个请求类别并且使所述类别与准入策略相关联的图示，准入策略可控制确定准入哪个令牌桶以及从哪个桶或哪些桶提取令牌。

图5是描绘用于基于请求的分类而获取并应用准入策略的实施方案的流程图。

图6A是描绘将请求类型划分成多个请求类别并且使所述类别与准入策略相关联的图示，准入策略管理来自令牌桶的分级布置的请求准入和令牌提取。

图6B是描绘从令牌桶的分级布置中的父桶扣除令牌的图示。

图6C是描绘从令牌桶的分级布置中的子桶扣除令牌桶的图示。

图6D是描绘从父桶扣除比可用于父桶的令牌多的令牌的图示。

图6E是描绘从子桶扣除比可用于子桶或父桶的令牌多的令牌的图示。

图6F是描绘令牌桶的分级布置的图示，其中具有相同优先级的一个或多个类别共享父桶。

图7A是描绘用于获取与请求类别、令牌桶和准入策略有关的客户提供的信息的用户界面的说明性实例的图示。

图7B是描绘适用于利用分级令牌桶模型的方法、用于获取与请求类别、令牌桶和准入策略有关的客户提供的信息的用户界面的说明性实例的图示。

图8是描绘用于接收容量分配和准入策略信息连同客户的新建表的定义并且使用所述信息创建令牌桶以及在每个分区的基础上应用准入策略的步骤的流程图。

图9是描绘可实践本公开的方面的计算环境的实施方案的框图。

具体实施方式

如上所述，提供商可将DBMS托管在数据中心中，并且提供对DBMS的访问作为对各种实体的服务。在这方面，DBMS可通过网络服务、网络应用、远程程序调用等被暴露。这些机制和其它在本文中可被称为服务。在一些实施方案中，DBMS可提供将一个或多个服务暴露于实体或客户的终端用户的集成前端。通过所述服务，终端用户可进行包括将通过使用对服务的应用编程接口(“API”)调用而在DBMS上执行各种操作和查询的请求。例如，请求可包括代表客户对API的调用，以及代表客户对DBMS上的操作的调用。

提供商还可能要求来自客户的付款以作为使用该容量的交换。然而，努力的盈利性可取决于客户支付与代表其本身消费的容量成比例的量。可对客户施加容量消耗的限制，并且通过各种技术(诸如节流、排队等)执行。当使用超过供应给客户的量时，可拒绝或暂停代表客户针对服务的请求。在多种情况下，这可能对客户不利。例如，服务可以是电子商务网站或类似应用的组件，如果针对服务的请求被拒绝，则其可能不具有功能。然而，也许并非所有服务的请求对客户而言同样重要。虽然各种请求(诸如展示电子商务购物车的内容或处理客户订单)可能非常重要，但是其它请求可能不重要。例如，重要性相对低的某些类型的请求可包括维护任务、报告生成、数据挖掘等。这些任务还可能碰巧消耗相当大部分的容量，且因此更可能导致在已超过客户的被供应容量时造成的中断、阻断期或延迟。

终端用户可通过发送包括操作的识别符和一个或多个参数的请求而调用DBMS上的操作。可识别任何数量的操作，并且可包括诸如读取或写入数据、执行关于数据的查询以及各种数据定义和模式相关的指令(诸如创建并删除表)的操作。可随请求包含的参数可以是任何类型的，诸如文本值、枚举值、整数等。参数的特定组合将根据被调用的操作的类型而不同。

DBMS是用于维护数据的组织集合的软件和硬件系统。在DBMS中，数据通常由关键值与附加数据之间的关联组织。关联性质可基于存在于数据的集合中的现实世界的关系，或者其可以是任意的。各种操作可由DBMS执行，包括数据定义、查询、更新和管理。一些DBMS使用查询语言(诸如结构化查询语言(“SQL”)提供与数据库的交互，而其它使用包含诸如put()和get()等的操作的API。与数据库的交互还可基于各种协议或标准，诸如超文本标记语言(“HTML”)和可扩展标记语言(“XML”)。DBMS可包括各种架构组件，诸如用于将数据存储在一个或多个存储装置(诸如固态驱动)上的存储引擎。

提供商可将任何数量的DBMS托管在其数据中心内。DBMS可在任何数量的计算节点上进行操作，并且可与各种存储装置相关联，以及使用广泛多样的联网设备和拓扑结构进行连接。此外，可托管各种DBMS，包括关系数据库、面向对象的数据库、非结构化查询语言(“NoSQL”)数据库等。

如上所述，可对客户施加容量消耗的限制。在实施方案中，客户可能具有设定的容量消耗水平。客户的容量消耗水平可通过各种估计和测量技术来限制。因为在处理请求中可能涉及的广泛多样的计算资源，所以容量消耗可能难以确定。然而，各种可测量的数量可用作容量消耗的合理代理。在各种实施方案中，可采用数量(诸如发送到或接收自客户端应用的数据量)来估计通过处理某个请求而消耗的容量。例如，查询请求可扫描数据库表，以便确定符合查询中指定约束条件的行。所返回的行数可以是用于容量消耗的代理。例如，如果返回单行数据，则查询可能在范围上受到限制，且因此可能比产生被返回的许多数据行的查询消耗更少容量。以下结合附图描述了示例实施方案的更多细节。

如上所述，在示例实施方案中，提供商将一个或多个DBMS托管在数据中心内，并且通过网络服务提供对各种DBMS的访问。图1描绘将供应的网络服务和数据库托管在数据中心内的环境。终端用户应用102可通过通信网络103、网关104和路由器106连接到数据中心100内的元素。本领域的普通技术人员将明白，该网络配置是可能并入本公开的实施方案的许多可能的配置中的一个。

网络服务110可提供各种API，API提供与数据库116的操作相关的功能。在一些情况下，API可用作建立在更复杂的数据库界面或协议上的轻量级包装程序。例如，所描绘的API 111可能通过使用秉承表述性状态转移(“REST”)原则的界面提供对数据库116的查询功能的访问。然后，终端用户应用102可使用相当简单的REST语义来调用API 111，以查询关键值数据库，而无需理解数据库116的技术细节。

网络服务110和数据库116可在多种平台上进行操作，诸如一个或多个计算机、虚拟机或其它形式的计算服务，这些可统称为计算节点。这些节点以及相关联的存储装置、网络基础设施等的操作涉及各种成本。这些成本包括与硬件和软件获取、维护、电力、人员等相关的那些成本。所述成本还包括诸如当一个客户的资源消耗阻止另一客户利用服务时所产生的机会成本的因素。

代表客户由网络服务110和数据库116执行的操作可与给定的计算节点上的容量的消耗相关。该相关性可允许托管服务提供商计算通过提供服务所产生的成本。例如，如果给定的客户调用利用计算节点的百分之百的容量一整天的网络服务，则提供服务的成本可以是有关二十四小时按比例分配的计算节点的获取、维护以及操作成本的总和。

相应地，可通过各种方式(诸如图1中描绘的实施方案)限制容量的消耗。接受策略108涉及确定是否应处理请求。一般而言，接受策略108的目标可能是为了确保代表客户执行的请求不被允许超过容量的供应量。例如，客户可被供应计算节点的百分之二十五的容量。然后，接受策略108可用于将该客户的平均容量消耗限制到不超过百分之二十五。在一些实施方案中，可允许有限时段内峰值使用上升高于该量。

当客户的容量已被过度使用时，接受策略108可拒绝传入的请求。取决于请求的性质，这可能会有对客户而言很重要的后果。例如，客户可能运行购物网站，该网站将请求引导到数据库116以检索终端用户的购物车的内容。如果请求被拒绝，则可能会导致错误消息而非完成销售。另一方面，一些类型的请求可被推迟而不会造成严重后果。可能的实例包括维护任务、报告生成等。相应地，可实施接受策略108，以解释在做出允许或拒绝决定时被调用的请求的类型。

实施方案可采用令牌桶模型来限制容量消耗。从概念上讲，可将令牌桶视为令牌的集合，其中的每一个表示桶的拥有者被授权执行的工作单位。可以累积速率将令牌添加到桶，这例如可基于服务的水平。当工作被执行时，从桶提取相当于被执行的工作量的令牌数量。如果令牌不可用，则工作可不被执行。使用该方法，随着时间推移，可被执行的工作量由令牌被添加到桶的速率限制。

为了防止近期对容量的过度利用，可对可添加到桶的令牌的最大数量施加限制。可丢弃超过该限制添加的任何令牌。

在数据库操作的上下文中，令牌可被视为表示与执行数据库操作相关的成本单位。例如，在数据库116上执行操作的请求的成本可与当执行操作时返回的数据的大小对应。执行操作的成本(如在令牌中测量)可通过将数据大小除以每个令牌值的大小来确定。

所请求的操作可被认为花费至少一个令牌，但是可能要到操作已被实际执行之后才知道全部成本。在许多可能的实施方案中的一个实施方案中，当至少一个令牌可用时，可准入请求。然后，可处理所述请求，且基于一个或多个测量的数量而确定请求的总成本。

在图1中，令牌可累积在虚拟容器中，诸如令牌桶112。令牌桶可被认为表示所允许的容量消耗的单位(由令牌表示)与诸如客户或服务的实体之间的关联。例如，当客户在数据库116上创建表时，令牌桶112可与在所述表上执行的所有操作相关联。其它实施方案可使令牌桶与表分区、客户、计算节点等相关联。

令牌累积策略114可管理令牌到令牌桶112的添加。在实施方案中，累积策略114包括添加速率和最大令牌容量。例如，策略可能指示给定的桶应以每秒二十的速率累积令牌，但是指示应该允许累积不超过一百个令牌。

令牌和令牌桶可以由各种结构表示。在实施方案中，接受策略108、令牌桶112和令牌累积策略114由功能模块(诸如软件库、可执行程序等)实施。模块可通过记录令牌的当前数量、令牌的最大数量、累积的速率和最后一次令牌添加时间来表示令牌和令牌累积。当确定是否允许或拒绝请求时，模块可首先基于累积速率、令牌被添加的最后时间和当前时间来更新令牌的当前数量。例如，当与令牌桶对应的数据结构被检查以确定容量是否可用时，累积的新令牌的数量可通过将累积速率乘以自从对可用令牌的计数的最近更新后已消逝的时间量而确定。可将该值增加到当前可用的令牌的计数，但是不允许超过桶中所允许的令牌的最大数量。用于诸如基于定期调用的例程的那些而维持令牌桶的其它技术也是可能的。

图2描绘应用接受策略和令牌累积策略的实施方案。虽然被描绘为始于操作200和结束于操作216的操作的序列，但是本领域的普通技术人员将理解，所描绘的操作旨在说明实施方案，以及所描绘的操作中的至少一些可被更改、省略、重新排序或并行执行。

在操作202，接收执行服务的请求。作为实例，请求可包括数据库查询。数据库查询的成本可基于由执行查询所返回的数据的量而确定、可能由返回到终端用户的数据的字节的数量衡量。

操作204描绘更新可用令牌的计数。在实施方案中，可用令牌的数量可基于最后更新时间、令牌累积速率和当前时间来调整。还可限制可用令牌的最大数量。当请求被准入时，从令牌的当前计数扣除令牌。然而，因为各种实施方案可允许当前令牌计数降到零以下，所以可能存在没有令牌用于扣除的情况。操作206描绘确定令牌是否可用于扣除。一些实施方案可认为一个令牌足以准入请求，然而其它实施方案可尝试估计处理请求将消耗的令牌的数量，即容量。如在本文中使用，术语足够令牌或足够容量可指的是一个令牌、固定数量的令牌、基于对通过处理请求将利用的容量的估计的一定数量的令牌等。如果没有足够的令牌可用，则请求被拒绝，如由操作208描绘。可将拒绝通知给托管服务的客户端应用和/或客户。

操作210描绘当至少一个令牌可用时准入请求。可用令牌的计数可减少一个，并且处理所述请求，如由操作212描绘。一旦请求已被处理，可用令牌的数量可基于执行请求的实际成本而进一步向下调整，如由操作214描绘。在各种实施方案中，实际成本可基于诸如返回的数据量、CPU利用率、存储器消耗、网络带宽消耗等的度量来测量。

由图2描绘的实施方案可允许目前在桶中的令牌的计数下降到零以下。负令牌平衡可对应于阻断期，在该阻断期期间，取决于所述令牌桶的请求可能不被准入。阻断期的长度可取决于当前负的令牌计数，以及令牌累积的速率。例如，如果令牌累积速率是每秒十，以及可用令牌的数量为-100，则阻断期的长度可能是十秒。

某些类型的请求，诸如涉及维护、报告、总结等的那些请求，可以是数据密集型的，且作为高成本处理。这些类型的请求可因此导致长久的阻断期，在这阻断期期间，任何请求(包括低成本但高重要性的那些请求)可能无法运行。图3A描绘这种情况的实例。分配到特定实体(诸如表、分区、计算节点等)的总供应容量可由令牌流入308、将令牌添加到令牌桶302的速率表示。例如，长时间运行的维护任务306可能是数据密集型任务，其导致相当大量的令牌流出310。可能的情况是，每次任务运行时，令牌桶302中的可用令牌的数量下降到负数，且阻断期随之发生。另一方面，查询请求304可能需要少量数据流出，并且导致相当少量的令牌流出312。然而，之前执行的维护任务可能已经导致阻断期，以及查询请求可能被拒绝(尽管它们成本低)。这可能有利于避免此类情况。

图3B描绘将供应容量划分成两个单独的令牌桶314和316。同样地，如令牌流入308a和令牌流入308b描绘的那样划分令牌流入。执行长期运行的维护任务和查询的成本保持恒定，且因此令牌流出速率310和312保持不变。该布置防止查询请求被执行长期运行的维护任务阻止。然而，可能的情况是，很少调用维护任务。如果是，则保留给长期运行的任务的许多容量可能会浪费。

可基于一个以上的桶并且针对可从一个以上的桶扣除的令牌来确定请求准入。例如，实施方案可将请求类型划分为高优先级、中等优先级和低优先级。高优先级请求可能能够从任何桶提取，中等优先级请求从三个桶中的两个提取，以及低优先级请求仅从一个桶提取。类似请求类型的分类可被描述为类别。然后，这些类别可与准入策略相关联。准入策略可包括应使用哪些令牌桶以确定请求是否应被准入的指示，和用于一旦请求的总成本已知，则用于提取令牌的技术或方法。

图4描绘用于基于请求类别和准入策略分配容量的实施方案。传入的请求可被分类为属于请求的类别，诸如类别“A”请求400、类别“B”请求402和类别“C”请求404。然后，可应用准入策略以确定在准入或拒绝请求时涉及哪些桶，以及应如何从那些桶中扣除令牌。

请求的每个类别可与准入策略相关联。策略可涉及与令牌的使用相关的各种逻辑和程序机制。准入策略的一个方面涉及确定请求是否应被准入用于处理。使用图4作为实例，策略406可指定，如果桶“Y”414中至少一个令牌可用，则应准入类别“A”请求400。第二策略408可指定，如果令牌存在于桶“X”412或桶“Y”414中，则应准入类别“B”请求。用于类别“C”请求404的第三策略410可指示，应单独基于桶“X”412来准入请求。这些实例是说明性的，且许多其它组合是可能的。

在实施方案中，可基于可变或预定义的令牌阈值来准入请求。一个实例涉及仅当桶具有与可被消耗的预测数量的令牌相等的令牌数量时才准入请求。另一实例涉及使用之前成本的移动平均数来设置令牌的最大数量。许多附加实施方案是可能的。

准入策略还可涉及确定如何扣除令牌。当请求首先被准入时，可从桶扣除一个或多个令牌，准入以此为基础。然而，请求的总成本不可知，直到请求已至少部分地被处理为止。因此，在请求已被准入之后的一段时间，第二令牌扣除可发生。策略可将一个或多个桶指定为扣除的目标，以及还可指定在桶之间的分布。

在实施方案中，可从确定准入的相同桶中扣除令牌。例如，如果基于桶“X”412中的令牌的存在而准入请求(图4中描绘)，则还可从桶“X”412扣除全部令牌成本。采用这种方法的一个原因在于，除此之外，具有负数个可用令牌的桶进一步下降，从而延长只依赖于所述桶的请求的阻断期。

另一实施方案首先从确定准入的桶扣除，且然后从一个或多个后续桶扣除。例如，如果基于桶“X”412中的可用令牌而允许请求，则总成本的一部分(一旦被确定)可从桶“X”412扣除，且一部分从桶“Y”414扣除。可确定从第一个桶412扣除的量，以防止可用的令牌计数下降低于诸如零的阈值。剩余部分可从一系列桶中的第二个桶或最后一个桶扣除，这可能导致该桶的可用令牌计数下降低于零。因此在图4中，使用这种方法处理类别“B”请求402可能导致桶“Y”414的可用令牌计数变成负的。然而，桶“X”412的计数由于类别“B”请求402而不会变成负的。这种方法可能是有利的，因为其可防止针对类别“C”请求404的阻断期，阻断期可通过处理类别“B”请求402造成。

图5描绘用于获取并应用准入策略的实施方案。虽然被描绘为始于操作500并结束于操作516的操作的系列，但是本领域的普通技术人员将理解，所描绘的操作旨在为说明性的，且所描绘的操作的至少一些可被更改、省略、重新排序或并行执行。

用于应用准入策略的过程可涉及接收请求，如由操作502描绘。然后，可确定请求所属的类别。这可通过多种方式来完成。在实施方案中，与请求调用相关联的API可允许识别类别的一个或多个参数。一个实例涉及文本参数，其命名请求所对应的类别。然而，由于各种性能考虑，使用数值来识别请求类别可能是有利的。

在一些实施方案中，请求可基于其类型进行分类。例如，写入请求可从读取请求单独分类出来。其它实施方案可分析请求以确定其潜在成本并将具有类似成本水平的请求指派到相同类别。

请求类别可以基于除了或代替在请求参数中指定的那些因素之外的因素。例如，给定的客户、识别符或安全角色可与请求类别相关联。客户或角色可从请求被调用的上下文中获得，或其可被指定为请求中的参数。其它潜在因素包括请求的源互联网协议地址、被调用的特定API等。此外，配置或其它机制可用于定义分类规则。例如，与客户、网络服务、API或其它实体相关联的配置可与请求相关联。还可应用可能在配置中指定的各种默认规则。当其它分类规则不适用时，可应用默认规则。实施方案可允许默认值被覆写。实施方案还可允许某些默认值是固定的，使得它们无法被覆写。

一旦已经确定请求的类别，对应的准入策略可被接收、获得或以其它方式准备用于应用，如由操作504描绘。这可能涉及访问描述准入策略的记录，诸如可提取令牌的桶的列表。例如，所述记录可存储于数据库中、嵌在代码资源、配置文件等中。在一些实施方案中，表示桶的结构可作为策略描述的一部分，或换言之，桶和策略定义可包括集成结构。一些实施方案可通过选择执行本文描述的各种技术的指令中的适当执行路径而省略该步骤并应用策略。

请求可被操作506准入或拒绝。准入策略可描述将被检查以查看可用令牌的一个或多个桶。一些实施方案可能需要多个令牌或使准入基于至少高于阈值水平的令牌。当令牌计数为负时，一些实施方案可允许请求被准入，以及策略描述可指示阈值负值，低于该阈值负值时，请求应不被准入。

操作506还可涉及扣除至少一个令牌。被扣除的令牌数量可与用于确定请求是否应该被准入的令牌的量相同。以此方式，另一请求将基于相同的令牌或令牌集而不被准入。实施方案还可同步到桶的访问，以便防止多个请求基于相同令牌或令牌集而被准入。

在被准入之后，请求可如由操作508描绘那样被处理。请求的总成本可至少部分基于处理请求来确定。在各种实施方案中，可使用返回到服务的客户端的数据大小。例如，如果请求是数据库查询，则可在执行查询之后从返回到客户端的数据的总大小得到令牌成本。在其它实施方案中，各种性能度量可被收集，同时请求被处理并用作成本确定的基础。

一旦请求已被执行，各种实施方案可扣除操作的成本。可按照准入策略执行该步骤，如由操作514描绘。准入策略可描述用于扣除令牌成本的各种方法，诸如在多个桶之间分布或从确定准入的桶扣除成本。可采用各种其它策略。

在一些实施方案中，令牌桶可具有分级关系。这种方法可允许对所选择的准入策略的方便管理，因为其允许使用请求类别与令牌桶之间的一对一映射来定义优先化方案。可通过指定令牌桶之间的父子关系以及各自最大令牌容量来方便地定义分级令牌桶。图6A是采用分级令牌桶的实例的实施方案的说明。其描绘了两个令牌桶。桶“X”608是“Y”610的父桶，且具有三十个令牌的最大容量。桶“Y”610是父“X”608的子桶，且具有五个令牌的最大容量。令牌以分级方式在桶之间共享，其中子桶具有对所有其父桶的令牌的访问。因此，当令牌桶608和令牌桶610二者处于最大容量时，它们之间共享30个令牌。

在图6A中，基于类别“A”策略604的应用，类别“A”请求600与桶“Y”610相关联。类似地，基于类别B策略606，类别“B”请求与桶“X”608相关联。准入策略可包括请求类别与桶(其可用于确定是否准入请求并且从哪个令牌桶或哪些桶提取令牌)之间的一对一映射。准入策略还可包括附加元素，诸如准入请求所需的可用令牌的最小数量。本文中描述关于非分级方法的各种方法和技术还可应用于分级方法。

可基于被映射到请求的类别的令牌桶中的至少一个令牌的可用性来准入请求。例如，当桶“Y”610具有可用令牌时，可准入类别“A”请求600。类似地，当桶“X”608具有可用令牌时，可准入类别“B”请求602。一些实施方案可能要求一个以上的令牌可用，例如，基于处理请求的估计成本。

当请求被准入用于处理时，可扣除需要用于准入的一个或多个令牌。实施方案可在准入请求之后扣除一个令牌。剩余成本(一旦知道)可从确定准入的相同令牌桶扣除。

图6B是描绘从桶“X”608扣除两个令牌的操作650的图示。桶“X”608和“Y”610的预扣除状态由图形元素651描绘，且扣除后状态由元素652描绘。从桶“X”608扣除令牌，从而导致令牌计数为二十八。可用于“Y”610的令牌保持不变。

在图6C中，操作660描绘从桶“Y”610扣除两个令牌。扣除之前的状态由图形元素661描绘。扣除之后的状态(如由元素662描绘)表明可用于桶“X”608和“Y”610二者的令牌已被减少两个。这种方法反应了在分级方式中的两个桶之间共享可用令牌。当基于可用于子桶的令牌准入或处理请求时，可从子桶和其父桶的每一个提取令牌。此外，各种实施方案可能要求，为了使请求被准入，令牌必须可用于子桶和其父桶的每一个中。在图6C中，可基于扣除之前的状态661准入请求，因为桶“Y”610及其父桶“X”608二者具有至少一个令牌。另一方面，如果子桶中没有足够的令牌，则实施方案可允许父桶(诸如桶“X”608)处理请求。

图6D中的操作670描绘从桶“X”608扣除超过可用数量的令牌数量。在扣除之前，如由元素671描绘，令牌桶“X”608具有可用于其的三十个令牌。在扣除三十五个令牌之后(如由扣除之后的状态672描绘)，其总数已被减少到负五。在扣除之后，图6D将桶“Y”610描绘成具有可用于其的五个令牌。对于其准入取决于桶“Y”610的请求，实施方案可能要求至少一个令牌存在父桶“X”608中。相应地，在这些实施方案中，取决于桶“Y”610的请求将不被准入，直到可用于桶“X”608和桶“Y”610的令牌数量上升高于零。然而，当从其父桶扣除令牌时，实施方案可能不减少子桶中的令牌数量。实施方案可能仍要求至少一个令牌存在于子桶的父桶中的每一个中。然而，防止子桶的令牌计数变成负可有助于防止与子桶相关联的服务的阻断期。

可确定阻断期的长度的因素包括子桶及其父桶中的令牌计数为负的程度、以及子桶和父桶各自的再填充速率。例如，在图6D中，取决于桶“Y”610的请求可能不被准入，直到至少一个令牌了用于桶“X”608和桶“Y”610二者为止。使用令牌再填充桶“X”608的速率可因此影响阻断期的长度，如取决于桶“Y”610的请求所见。然而，桶“X”608可被指派按比例高于指派给桶“Y”610的累积速率的累积速率。

图6E描绘从桶“Y”610扣除比可用于其的令牌多的令牌的操作680。在扣除之前，桶“Y”610具有可用于其的五个令牌，如在元素681处的图的部分所描绘。在扣除三十五个令牌之后，桶“Y”610具有可用于其的负三十个令牌，而桶“X”608被留下负五个令牌。由元素682描绘的该状态反应了从准入基于的子桶“Y”610扣除，并且从其父桶“X”608扣除。

分级令牌桶的实施方案可采用多种技术、算法、数据结构等。在实施方案中，记录可用于跟踪可用于父令牌桶的令牌数量。然后，可基于一组规则、算法等确定可用于其子桶的令牌数量。例如，可基于可用于父令牌桶的令牌数量和子令牌桶允许累积的令牌的最大数量来确定可用于子令牌桶的令牌数量。

令牌桶的分级可将新令牌累积为群组。使用图6A中描绘的令牌桶作为参考点，令牌累积速率可与包括桶“X”608和“Y”610的分级相关联。当令牌被添加到分级时，可用于桶“X”608和“Y”610二者的令牌数量可增加到其各自的最大值。

图6F描绘令牌桶的分级布置，其中两个或更多个请求类别共享具有相等的优先级的桶。类别“A”请求6000可针对桶“X”6010，且类别“B”请求6002可针对桶“Y”6012。父桶“P”6008可具有100的总容量，其对应于每秒接收80个令牌的分配的桶“X”6010和每秒接收20个令牌的分配的桶“Y”6012。桶的最大容量可与其令牌分配的各自速率相同。

准入策略可定义用于图6F中描绘的布置，其中子桶共享相等的优先级。准入策略可进行如下：在与类别“A”请求6000对应的请求达到之后，桶“Y”6012可查阅令牌的可用性。如果至少一个令牌可用，则可准入请求。在准入和再次处理请求之后，桶“Y”6012和父桶“P”中的可用令牌的计数可各自被减少。如果在桶“Y”6012中没有足够的令牌可用，则可在父桶“P”6008中存在至少一个令牌的情况下准入请求。在准入和再次处理请求之后，可从父桶“P”6008扣除令牌。可通过以类似于类别“A”策略6004的方式定义类别“B”策略6006而以类似方式处理别“B”请求6002，从而针对令牌分配速率方面的差异进行调整。

这种方法的结果涉及来自每个类别的请求具有对其供应容量的访问，但是如果同级桶未充分利用供应给其的容量，则能够利用附加容量。例如，如果仅发出类别“A”请求6000，则每秒将有高达100个令牌可用于处理它们。如果工作负荷被混合，且类别“A”请求6000每秒消耗十个令牌，则类别“B”请求6002每秒将能够消耗高达90个令牌。

准入策略的方面可由托管提供商的客户定义。定义可由客户与服务提供商提供的用户界面的交互来执行。例如，网页可允许用户定义类别和可提取令牌的各自桶。用户还可设置各种附加参数，诸如有关每个类别的请求的最小令牌量。

各种实施方案可提供用于管理控制输入/输出优先化的装置，其例如可包括定义请求类别、令牌桶、准入策略等。在图7A中，用户界面700可包括在托管的数据表的创建期间被呈现给用户的用户界面页的序列的部分。先前步骤701用户界面组件可表示按钮、超链接或类似元素，其用于导航到用于定义所托管的数据库表的用户界面向导中的前一个点。创建表702用户界面元素可指示用户已经完成将参数提供到表创建过程以及表应被创建。所描绘的用户界面元素旨在作为提供这种界面的方法的广义实例，且不应被理解为限制本公开的范围。

用户界面700可包含一个或多个策略定义704a、704b和704c，其可用于提供指示请求的类别与可提取令牌的一个或多个桶之间的关系的参数以及准入策略的可能的其它各种元素。例如，策略定义元素704a可包括类别指示706a、主桶指示708a和次桶指示710a。类别指示706a可包括描述类别的各种参数，其可包括类别名称和一个或多个请求类型。在一些实施方案中，请求类别和请求类型是由托管服务的提供商预定义。若干附加的类别指示可呈现在用户界面700中，诸如策略定义704b(包括类别指示706b、主桶指示708b和次桶指示710b)和策略定义704c(包括类别指示706c、主桶指示708c和次桶指示710c)。

主桶元素708a和次桶元素710a指示包括准入策略的部分的令牌桶以及其各自的优先级。例如，在应用有关落入类别指示706a指定的类别中的请求的准入决定中将首先查阅708a指示的令牌桶。其次将查阅由次令牌桶710a指定的令牌桶。策略定义704a、704b和704c可指的是相同的令牌桶，或指的是重叠的令牌桶集。

图7B描绘了用于定义采用分级令牌桶的准入策略的用户界面的说明性实施方案。用户界面750可包括表定义过程的部分，其采用先前步骤751和创建表752用户界面元素以导航到过程中的其它步骤并指示过程应被完成。

用户界面750可包括一个或多个策略定义754a、754b和754c，其允许客户提供用于创建准入策略和分级令牌桶的参数。例如，策略定义754a可包括桶名称756a用户界面元素，其指示令牌桶的名称。在一些实施方案中，这可能是包含预定义的桶名称的投递箱(dropbox)或其它用户界面元素。请求类别760a可包括组合框、列表框或其它用户界面元素，其允许请求类别被指派到桶名称756a指示的桶。子令牌桶758a用户界面元素可用于指定一个或多个子令牌桶，诸如图6A中描绘的桶“Y”610。这可能是列表框或其它用户界面元素，其允许一个或多个子令牌桶被选择。在一些实施方案中，可指定父令牌桶替代一个或多个子令牌桶。用户界面750可允许若干附加策略定义被定义。例如，用户界面750还包含用户界面元素，其用于定义或编辑策略定义754b(包括桶名称756b、请求类别760b和子桶758b)和策略定义754c(包括桶名称756c、请求类别760c和子桶758c)。

图7A和图7B二者被描绘为提供用户界面元素用于指定令牌桶，诸如图7A中的主桶708a和图7B中的桶名称756a。然而，用户界面700和750可使用替代表示以直接或间接地指定令牌桶和对应的请求类别。例如，用户界面700可呈现具有可与请求类别相关联的高、中等或低优先级的选择。可从用户选择的优先级别推测桶之间的关系。可在用户界面750中采用类似的方法。

实施方案可采用与图7A和图7B中描绘的那些用户界面类似的用户界面，以允许客户随后编辑请求类别、桶、桶之间的关系等。一个实例涉及改变表的定义。客户可对数据库表的定义做出各种修改，例如通过增加附加列的方式。经修改的表可与不同的使用模式相关联。相应地，客户还可指定被分配到表的容量、准入策略、桶的数量等的变化。各种用户界面元素或API可用于提供相关信息。

图7A和图7B中描绘的示例用户界面可使用广泛多样的技术(包括胖客户端、n层或其它架构)来实现。在实施方案中，在托管提供商的数据中心中进行操作的网络服务器将超文本标记语言(“HTML”)形式用于客户的浏览器。在提交该形式之后，托管提供商数据中心内的网络服务API接收并处理由客户提供的信息。

图8是描绘用于创建与令牌桶和准入策略相关联的数据库表的过程的流程图。虽然被描绘为始于操作800并结束于操作814的操作的序列，但是本领域的普通技术人员将理解，所描绘的操作中的至少一些可被更改、省略、重新排序或并行执行。例如，可在托管提供商数据中心处同时接收由操作802-808指示的信息。

操作802描绘接收指示表定义的信息。如果被定义的表涉及一个以上的分区，则本公开的实施方案可在每个表的基础上或在每个分区的基础上分配容量。分区可包括表的细分，每个细分可由在一个或多个计算节点上操作的DBMS维护。因为可在每个表的基础上或在每个分区的基础上分配容量，所以可在类似的基础上定义准入策略和令牌桶。

操作804描绘接收指示请求的一个或多个类别的信息。这些类别可由用户例如通过用户界面(诸如在图7A和图7B中描绘的那些)进行定义。在其它实施方案中，托管提供商可预定义请求类别。在实施方案中，将请求类别标记为“高”、“中等”和“低”。

操作806描绘接收指示应被创建的桶的信息。在一些实施方案中，信息可包括将被创建的桶的列表或计数，而在其它实施方案中，可推测信息。例如，可推测请求类别与令牌桶之间的一对一对应关系。在实施方案中，可创建三个令牌桶，以与“高”、“中等”和“低”请求类别对应。

在操作808，可接收指示一个或多个准入策略的信息。该信息可包括请求类别与桶之间的映射关系，并且可包括指示应查阅桶以确定准入的顺序的信息、扣除令牌的方法等。该信息可与操作802-806提及的其它信息组合。信息的某些方面可被推测地确定，或可用于推测在操作802-806中接收到的信息的其它方面。例如，在一些实施方案中，提及桶的策略描述可用于推测出应创建所提及的桶。

在操作810，可确定分区方案。可在多个计算节点中划分将被托管的表或其它服务。相应地，实施方案可确定涉及多少个计算节点和哪些计算节点，以及用于划分表的其它方面(诸如确定如何划分由表维护的数据)。对于不涉及表的服务，这可涉及确定如何划分由各自分区处理的工作负荷。

基于分区方案，可将容量分配到各个分区或计算节点。例如，每个客户的容量可在分区之间均匀地划分，或其可基于期望分区或计算节点处理的工作负荷的量而划分。例如，如果第一分区被期望处理表的四分之三的工作负荷，则其可被分配四分之三的容量。

将每个客户的容量分配到分区可涉及将令牌生成的总量的一部分指派给分区。例如，其可至少部分基于客户的服务层而确定，在所述客户的服务层他每秒应被分配给定量的令牌。继续之前的实例，可将四分之三的所述容量分配到一个分区或计算节点，以及将剩余的四分之一分配到另一个分区。这由操作810描绘。

可将被指派到分区的总的每个客户的容量细分配到将在所述分区上创建的令牌桶，如由操作812描绘。继续先前实例，如果四分之三的总容量与以每秒七十五个令牌的速率的令牌生成对应，则可将每秒总共七十五个令牌分配到与所述分区或计算节点相关联的令牌桶。如果所述分区有三个令牌桶，则每个令牌桶每秒可被分配二十五个令牌。

一旦确定，每个桶的令牌分配速率可用于创建、初始化或以其它方式表示令牌桶。在各种实施方案中，创建桶可包括初始化各种数据结构，诸如包括最大令牌容量、当前容量、令牌分配速率和最后添加时间的记录。许多其它实施方案是可能的。例如，在一些实施方案中，在逻辑定义的桶与存储于存储器中的数据结构之间可能不存在一对一的对应关系。

图8中描绘的操作还可适用于允许更新。例如，操作802可包括接收指示现有表的定义的变化的信息。此外，继其初始定义之后，可接收与请求类别、桶定义和关系、准入策略、分区方案等相关的信息，且相应地更新对应的实体和关系。

图9是描绘可实践本发明的方面的分布式计算环境的实例的图示。各种用户900a可与在任何类型的计算装置902a上进行操作的各种客户端应用交互，以通过通信网络904与在数据中心920内的各种计算节点910a、910b和910c上执行的过程通信。替代地，客户端应用902b可在没有用户干预的情况下进行通信。通信网络904可包括通信技术(包括互联网、有线和无线局域网、光纤网络、卫星通信等)的任何组合。可采用任何数量的网络协议。

可经由网关906和路由器908提供与在数据中心920内进行操作的计算节点910a、910b和910c上执行的过程的通信。还可采用许多其它网络配置。虽然图9中未明确描绘，但是可提供各种认证机制、网络服务层、业务对象或其它中间层来调解与在计算节点910a、910b和910c上执行的过程的通信。这些中间层中的一些本身可包括在计算节点中的一个或多个上执行的过程。计算节点910a、910b和910c和在其上执行的过程还可经由路由器908彼此通信。替代地，可采用单独的通信路径。在一些实施方案中，数据中心920可被配置来与附加的数据中心通信，使得计算节点和在其上执行的过程可与在其它数据中心内进行操作的计算节点和过程进行通信。

计算节点910a被描绘成驻留在包括一个或多个处理器916、一个或多个存储器918和一个或多个存储装置914的物理硬件上。计算节点910a上的过程可结合操作系统一起执行，或替代地可执行为与诸如处理器916、存储器918或存储装置914的物理资源直接交互的裸机过程。

计算节点910b和910c被描绘成在虚拟机主机912上进行操作，其可提供对诸如物理处理器、存储器或存储装置的各种物理资源的共享访问。可采用任何数量的虚拟机制以托管计算节点。

图9中描绘的各种计算节点可被配置来托管网络服务、数据库管理系统、业务对象、监控和诊断设施等。计算节点可以指的是各种类型的计算资源，诸如个人计算机、服务器、集群计算装置等。当以硬件形式实施时，计算节点通常与被配置来存储计算机可读指令的一个或多个存储器以及被配置来读取并执行所述指令的一个或多个处理器相关联。基于硬件的计算节点还可包括一个或多个存储装置、网络界面、通信总线、用户界面装置等。计算节点还可包括虚拟计算资源，诸如使用或不使用管理程序实施的虚拟机、虚拟化裸机环境等。基于虚拟化的计算节点可具有对硬件资源的虚拟化访问，以及非虚拟化访问。计算节点可被配置来执行操作系统以及一个或多个应用程序。在一些实施方案中，计算节点还可包括裸机应用程序。

在之前章节中描述的过程、方法和算法中的每一个可体现在由一个或多个计算机或计算机处理器执行的代码模块中，或通过代码模块全部或部分地自动化。代码模块可存储在任何类型的非暂时性计算机可读介质或计算机存储装置上，诸如硬盘驱动、固态存储器、光盘和/或类似装置。处理器和算法可在特定于应用的电路中部分地或完全实现。所公开的过程和过程步骤的结果可被持久或以其它方式存储在任何类型的非暂时性计算机存储装置中，诸如易失性存储装置或非易失性存储装置。

上述各种特征和过程可独立于彼此而使用或可以各种方式组合。所有可能的组合和子组合旨在落在本公开的范围内。此外，在一些实施方式中，可省略某些方法或过程块。本文中描述的方法和过程也不限于任何特定序列，以及与此相关的块或状态可以适当的其它序列执行。例如，所述块或状态可按与具体公开的顺序不同的顺序执行，或多个块或状态可组合在单个块或状态中。示例块或状态可串联、并联或以某个其它方式执行。块或状态可添加到所公开的示例实施方案，或从所述示例实施方案移除。本文中描述的示例系统和组件可不同于所述方式来配置。例如，元素可添加到所公开的示例实施方案，从所述示例实施方案移除，或与所公开的示例实施方案相比，元素可被重新布置。

也将理解，各个项目在使用时被图示为存储在存储器中或存储装置上，以及这些项目及其部分可在存储器与其它存储装置之间转移，以用于存储器管理和数据完整性的目的。替代地，在其它实施方案中，软件模块和/或系统中的一些或全部可在另一装置上的存储器中执行，并且经由计算机间通信与图示的计算系统通信。另外，在一些实施方案中，系统和/或模块中的一些或全部可以其它方式实施或提供，这些方式诸如至少部分地以固件和/或硬件的方式，包括但不限于：一个或多个专用集成电路(ASIC)、标准集成电路、控制器(例如，通过执行适当的指令并包括微控制器和/或嵌入式控制器)、现场可编程门阵列(FPGA)、复杂可编程逻辑装置(CPLD)等。模块、系统和数据结构中的一些或全部还可存储(例如，作为软件指令或结构化数据)在计算机可读介质上，诸如硬盘、存储器、网络或通过适当的驱动器或经由适当的连接读取的便携式介质物件。系统、模块和数据结构也可作为产生的数据信号(例如，作为载波或其它模拟或数字传播信号的一部分)在多种计算机可读传输介质(包括基于无线和基于有线/电缆介质)上传输，并且可采取多种形式(例如，作为单一或多路模拟信号的一部分，或作为多个离散数字包或帧)。在其它实施方案中，这种计算机程序产品还可采取其他形式。相应地，本发明可使用其它计算机系统配置来实践。

可鉴于以下条款进一步理解上述内容：

1.一种用于优先化数据库管理系统的容量消耗的系统，所述系统包括：

一个或多个计算节点，其被配置来操作所述数据库管理系统；以及

一个或多个存储器，其上存储有计算机可读指令，所述计算机可读指令在被执行时促使所述系统至少：

接收请求以在所述数据库管理系统上执行操作，所述请求包括指示请求类别的信息、将代表客户执行的所述操作；

从包括多个令牌桶的一个或多个数据结构中选择第一令牌桶，所述选择至少部分基于所述请求类别，所述第一令牌桶具有相关联的第一容量指示符；

确定所述第一容量指示符指示代表所述客户执行所述操作的容量；

执行所述操作；以及

至少部分基于执行所述操作所利用的容量而更新所述第一容量指示符。

2.根据条款1所述的系统，其进一步包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

接收指示所述请求类别与所述第一令牌桶之间的关联的信息。

3.根据条款1所述的系统，其包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

至少部分基于执行所述操作所利用的所述容量而更新与所述多个令牌桶的第二令牌桶相关联的第二容量指示符。

4.根据条款1所述的系统，其进一步包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

确定与所述多个令牌桶的第二令牌桶相关联的第二容量指示符指示代表所述客户执行所述操作的容量的不足。

5.一种用于优先化容量消耗的计算机实施的方法，其包括：

接收请求以在一个或多个计算节点上执行操作，所述请求包括指示请求类别的信息、将代表客户执行的所述操作；

至少部分基于所述请求类别从多个数据结构中选择第一数据结构，其中所述第一数据结构包括第一容量指示符；

确定所述第一容量指示符指示代表所述客户执行所述操作的所述一个或多个计算节点的容量；

执行所述操作；以及

至少部分基于执行所述操作所利用的容量而更新所述第一容量指示符。

6.根据条款5所述的方法，其中在网络服务、网站和数据库管理系统中的一个或多个上执行所述操作。

7.根据条款5所述的方法，其中指示所述请求类别的所述信息包括参数。

8.根据条款5所述的方法，其中指示所述请求类别的所述信息包括配置值。

9.根据条款5所述的方法，其进一步还包括客户识别符、安全角色和应用编程界面中的一个或多个。

10.根据条款5所述的方法，其进一步包括：

接收指示所述请求类别与所述第一容量指示符之间的映射的信息。

11.根据条款5所述的方法，其进一步包括：

确定来自所述多个数据结构的第二容量指示符指示代表所述客户执行所述操作的容量的不足。

12.根据条款5所述的方法，其进一步包括：

至少部分基于执行所述操作所利用的所述容量而更新来自所述多个数据结构的第二容量指示符的第二状态。

13.根据条款5所述的方法，其中所述第一容量指示符和来自所述多个数据结构的一个或多个附加的容量指示符共享指示代表所述客户执行所述操作的容量的所述多个数据结构中的一个或多个存储器位置。

14.根据条款5所述的方法，其中所述第一容量指示符对应于所述一个或多个计算节点的总容量的子集。

15.根据条款5所述的方法，其中所述第一容量指示符包括可用于代表所述客户执行操作的容量单位的计数。

16.根据条款15所述的方法，其中所述计数是至少部分基于所分配的容量累积的速率而增加。

17.一种非暂时性计算机可读存储介质，其上存储有指令，所述指令在被计算装置执行时促使所述计算装置至少：

接收请求以在一个或多个计算节点上执行操作，所述请求包括指示请求类别的信息；

至少部分基于所述请求类别而从多个数据结构中选择第一数据结构，其中所述第一数据结构包括第一容量指示符；

确定所述第一容量指示符指示准入所述操作以进行处理的足够容量；

执行所述操作；以及

至少部分基于用于执行所述操作的容量而更新所述第一容量指示符。

18.根据条款17所述的计算机可读存储介质，其中指示所述请求类别的信息包括参数。

19.根据条款17所述的计算机可读存储介质，其上存储有进一步指令，所述进一步指令在被所述计算装置执行时促使所述计算装置至少：

确定来自所述多个数据结构的第二容量指示符指示执行所述操作的容量的不足。

20.根据条款17所述的计算机可读存储介质，其上存储有进一步指令，所述进一步指令在被所述计算装置执行时促使所述计算装置至少：

当所述第一容量指示符指示执行所述操作的容量的不足时，更新来自所述多个数据结构的第二容量指示符，其中所述更新是至少部分基于用来执行所述操作的所述容量。

21.根据条款17所述的计算机可读存储介质，其中所述第一容量指示符包括可用于执行所述操作的容量单位的计数。

22.根据条款21所述的计算机可读存储介质，其中所述计数是至少部分基于所分配的容量累积的速率而增加。

23.一种用于优先化容量消耗的系统，所述系统包括：

一个或多个计算节点；以及

一个或多个存储器，其上存储有计算机可读指令，所述计算机可读指令在被计算装置执行时促使所述系统至少：

接收指示一个或多个请求类别的信息；

接收指示所述一个或多个请求类别与一个或多个数据结构之间的映射的信息，其中所述数据结构包括第一容量指示符；

将在一个或多个计算节点上执行操作的总容量的子集分配到所述第一容量指示符；以及

在确定所述第一容量指示符指示可用于在所述一个或多个计算节点上执行所述操作的容量时，执行所述操作。

24.根据条款23所述的系统，其进一步包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

接收指示代表客户创建数据库表的指令的信息。

25.根据条款23所述的系统，其进一步包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

接收指示修改数据库表的指令的信息；以及

接收指示修改被分配到所述数据库表的容量的指令的信息。

26.根据条款24所述的系统，其进一步包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

至少部分基于所述数据库表的分区数量而确定总容量的所述子集。

27.根据条款23所述的系统，其进一步包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

向用户界面发送包括用于接受客户输入的指令的指令，所述客户输入包括指示所述映射的所述信息。

在本文中使用的条件性的语言，诸如，其中“能够”、“可”、“可能”、“可以”、“例如”等，除非另有特别规定，或根据所使用的上下文另有理解，通常旨在表达：某些实施方案包括，而其它实施方案不包括，某些特征、元素和/或步骤。因此，这种条件性的语言通常不旨在暗示：一种或多种实施方案以任何方式需要特征、元素和/或步骤；或者一种或多种实施方案需要包括如下逻辑，这种逻辑用于在具有或不具有操作者输入或提示的情况下决定这些特征、元素和/或步骤是否包括在任何特定的实施方案中或是否在任何特定的实施方案中执行。术语“包括”、“包含”、“具有”等是同义的并以开放式方式包含性地使用，并不排除附加的元素、特征、动作、操作等。此外，术语“或者”以包含式的含义(而不是以排他性的含义)使用，使得当与一系列元素相关联地使用时，术语“或者”意味着列表中的元素的一个、某些或者全部。

虽然已经描述了某些示例实施方案，但是这些实施方案仅通过实例的方式被呈现，且不旨在限制本文所公开的发明的范围。因此，前述描述绝不旨在暗示任何特定特征、特性、步骤、模块或块是必须的或不可或缺的。实际上，本文中描述的新颖方法和系统可以多种其它形式体现；另外，在不脱离本文公开的发明的精神的情况下，可对本文描述的方法和系统的形式做出各种省略、替换和变化。随附权利要求及其等同物旨在覆盖如将落在本文公开的某些发明的范围和精神内的此类形式或修改。

Claims (10)

1.一种用于优先化数据库管理系统的容量消耗的系统，所述系统包括：

一个或多个计算节点，其被配置来操作所述数据库管理系统；以及

一个或多个存储器，其上存储有计算机可读指令，所述计算机可读指令在被执行时促使所述系统至少：

接收请求以在所述数据库管理系统上执行操作，所述请求包括指示请求类别的信息、将代表客户执行的所述操作；

从包括多个令牌桶的一个或多个数据结构中选择与第一请求类别相关联的第一令牌桶，所述选择至少部分地基于所述请求类别，所述第一令牌桶具有相关联的第一容量指示符；

确定所述第一容量指示符指示足够用于代表所述客户执行所述操作的容量；

执行所述操作；以及

在执行了所述操作后，至少部分地基于执行所述操作所利用的容量而更新所述第一容量指示符和与所述多个令牌桶中的第二令牌桶相关联的第二容量指示符两者，

其中，所述第二令牌桶与优先级高于所述第一请求类别的第二请求类别相关联，并且所述第二令牌桶是所述第一令牌桶的父令牌桶。

2.根据权利要求1所述的系统，其进一步包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

接收指示请求类别与令牌桶之间的映射的信息。

3.根据权利要求1所述的系统，其进一步包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

接收指示修改数据库表的指令的信息；以及

接收指示修改被分配到所述数据库表的容量的指令的信息。

4.根据权利要求3所述的系统，其进一步包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

至少部分地基于所述数据库表的分区数量而确定所述一个或多个计算节点的总容量的子集，其中，所述第一容量指示符对应于所述总容量的子集。

5.根据权利要求2所述的系统，其进一步包括上面存储有计算机可读指令的一个或多个存储器，所述计算机可读指令在被计算装置执行时促使所述系统至少：

向用户界面发送包括用于接受客户输入的指令的指令，所述客户输入包括指示所述映射的所述信息。

6.一种用于优先化容量消耗的计算机实施的方法，其包括：

接收请求以在一个或多个计算节点上执行操作，所述请求包括指示请求类别的信息、将代表客户执行的所述操作；

至少部分地基于所述请求类别从包括多个令牌桶的多个数据结构中选择与第一请求类别相关联的第一令牌桶，其中所述第一令牌桶具有相关联的第一容量指示符；

确定所述第一容量指示符指示所述一个或多个计算节点的足够用于代表所述客户执行所述操作的容量；

执行所述操作；以及

在执行了所述操作后，至少部分地基于执行所述操作所利用的容量而更新所述第一容量指示符和与所述多个令牌桶中的第二令牌桶相关联的第二容量指示符两者；

其中，所述第二令牌桶与优先级高于所述第一令牌桶的第二请求类别相关联，并且所述第二令牌桶是所述第一令牌桶的父令牌桶。

7.根据权利要求6所述的方法，其中在网络服务、网站和数据库管理系统中的一个或多个上执行所述操作。

8.根据权利要求6所述的方法，其中所述第一容量指示符与来自所述多个数据结构的一个或多个附加容量指示符共享指示代表所述客户执行所述操作的容量的所述多个数据结构中的一个或多个存储器位置。

9.根据权利要求6所述的方法，其中所述第一容量指示符包括可用于代表所述客户执行操作的容量单位的计数。

10.根据权利要求9所述的方法，其中所述计数是至少部分地基于所分配的容量累积的速率而增加。