JP6584388B2 - Prioritizing I / O to database workload - Google Patents

Description

This application claims the benefit of US Patent Application No. 13,897,232, filed May 17, 2013, the disclosure of which is incorporated herein by reference in its entirety.

  A database management system ("DBMS") is a third party that hosts the DBMS on a data center server and provides the DBMS as a service to various entities such as corporations, universities, government agencies, and other types of customers. Can be operated by a provider. In order to host a DBMS and provide its services to various entities, providers typically maintain significant resources in hardware, software, and infrastructure. In addition, the provider may be charged various ongoing overheads related to the operation of the DBMS, such as power, maintenance costs, and technician salaries. Thus, in order to provide responsive services to various business entities, providers may attempt to maximize the capacity and utilization of hardware and other resources installed in their data centers.

  The drawings provided herein are for the purpose of illustrating example embodiments and are not intended to limit the scope of the disclosure.

1 is a block diagram illustrating a database management system that is exposed to end users through a web service and limits capacity consumption through the use of token allocation and consumption mechanisms. FIG. FIG. 6 is a flow chart illustrating provisioned capacity implementation using token allocation and consumption mechanisms. It is a figure which shows allocation to the token bucket of a token, and token consumption of several request types from a token bucket. FIG. 4 is a diagram illustrating token allocation to a plurality of token buckets classified according to request type and withdrawal of a token from the bucket based on processing of a corresponding request type. FIG. 6 shows the allocation of request types to multiple request classes and the association of the class with an acceptance policy that can control which token buckets determine acceptance and from which bucket tokens are drawn. 6 is a flowchart illustrating an embodiment for obtaining and applying an acceptance policy based on a classification of requests. FIG. 5 shows the allocation of request types to multiple request classes and the association of the class with an acceptance policy that coordinates request acceptance and token withdrawal from a hierarchically arranged token bucket. It is a figure which shows the subtraction of the token from the parent bucket in the token bucket of hierarchical arrangement | positioning. It is a figure which shows the subtraction of the token bucket from the child bucket in the token bucket of hierarchical arrangement | positioning. FIG. 6 illustrates a deduction of more tokens from a parent bucket than are available to that parent. FIG. 6 illustrates a deduction of more tokens from a child bucket than is available to either the child bucket or the parent bucket. It is a figure which shows the token bucket of the hierarchical arrangement | positioning in which two or more classes of equal priority share a parent bucket. FIG. 6 illustrates an example embodiment of a user interface for obtaining customer provided information regarding request classes, token buckets, and acceptance policies. FIG. 4 illustrates an example embodiment of a user interface for obtaining customer-provided information regarding request classes, token buckets, and acceptance policies, adapted to an approach that utilizes a hierarchical token bucket model. FIG. 10 is a flowchart showing steps for receiving capacity allocation and consent policy information in conjunction with a customer definition in a new table, creating a token bucket using the information, and applying a consent policy for each category. FIG. 11 is a block diagram illustrating an embodiment of a computing environment in which aspects of the present disclosure may be implemented.

  As described above, a provider can host a DBMS in a data center and provide access to the DBMS as a service to various entities. In this regard, the DBMS can be published through web services, web applications, remote procedure calls, and the like. These mechanisms and others may be referred to herein as services. In some embodiments, a DBMS may provide an integrated front end that exposes one or more of the services to an end user or customer of an entity. Through the service, end users may make requests that include various operations and queries performed by the DBMS using application programming interface ("API") calls to the service. The request may include, for example, an API call on behalf of the customer, as well as an action call on the DBMS on behalf of the customer.

  The provider may also request rewards from customers in return for using this capacity. However, the profitability of this effort may depend on the customer paying an amount in proportion to the capacity consumed for it. Capacity consumption limits are imposed on the customer and can be implemented by various techniques such as throttling, queuing and the like. If usage exceeds the amount provisioned to the customer, the request for service on behalf of the customer may be rejected or suspended. This can be inconvenient for the customer in various situations. For example, the service may be a component of an electronic commerce website or similar application, in which case it may fail if a request for the service is denied. However, not every request for service is necessarily as important to the customer. Various requests, such as displaying the contents of a shopping cart in electronic commerce or processing customer orders, may be high in importance but may not be otherwise. For example, certain types of requests that are relatively insignificant may include maintenance tasks, report generation, data digging, and the like. These tasks also consume a relatively large portion of capacity, which is prone to outages, blackout periods, or delays when the customer's provisioned capacity is exceeded.

  An end user may invoke an action on the DBMS by sending a request including the action identifier and one or more parameters. Any number of operations may be identified and may include various data definition and schema related instructions such as operations such as reading or writing data, performing queries on the data, and creating and deleting tables. The parameters that can be included with the request can be of any type, such as text values, enumerated values, integers, etc. The particular combination of parameters will vary based on the type of action being invoked.

  A DBMS is a software and hardware system for maintaining organized collection data. In a DBMS, data is typically organized by an association between key values and additional data. The nature of the association may be based on real-world relationships that exist in the collected data, or may be arbitrary. Various operations may be performed by the DBMS, including data definition, query, update, and management. Some DBMSs use a query language, such as Structured Query Language ("SQL"), to specify interactions with the database, others use APIs that include operations such as put () and get (). . Interaction with the database may also be based on various protocols or standards, such as Hypertext Markup Language (“HTML”) and Extensible Markup Language (“XML”). A DBMS may include various building elements such as a storage engine that operates to store data in one or more storage devices such as solid state drives.

  A provider may provide any number of DBMSs in its data center. A DBMS runs on any number of computing nodes, can be associated with various storage devices, and can be connected using various network facilities and topologies. Moreover, various DBMSs can be provided, including relational databases, object-oriented databases, unstructured query language (“NoSQL”) databases, and the like.

  As mentioned above, capacity consumption limits can be imposed on customers. In an embodiment, a customer may have a set level of capacity consumption. The level of customer capacity consumption can be limited by various estimation and measurement techniques. Due to the various computing resources that can be involved in processing the request, capacity consumption can be difficult to determine. However, various measurable quantities can serve as a reasonable surrogate for capacity consumption. In various embodiments, an amount, such as the amount of data sent to or received from a client application, can be used to estimate the capacity consumed by processing a particular request. For example, a query request may scan a database table to infer rows that conform to the constraints specified in the query. The number of rows returned can be a proxy for capacity consumption. For example, if a single row of data is returned, the query is limited in scope, so it is likely that it consumed less capacity than a query that returned multiple rows of data. More details of example embodiments are described below in connection with the drawings.

  As described above, in the exemplary embodiment, the provider provides one or more DBMSs in the data center and provides access to the various DBMSs via web services. FIG. 1 illustrates an environment for hosting provisioned web services and databases in a data center. End-user-side application 102 may be connected to elements in data center 100 by communication network 103, gateway 104, and router 106. Those skilled in the art will recognize that this network configuration is one of many possible configurations that can be incorporated into embodiments of the present disclosure.

  Web service 110 may provide various APIs that provide functions related to the operation of database 116. In some cases, the API may function as a lightweight wrapper built on a more complex database interface or protocol. For example, the illustrated API 111 may provide access to the query function of the database 116 through the use of an interface that follows the representational state transfer (“REST”) principle. The end-user application 102 can then call the API 111 using a relatively simple REST semantic rule to query the key value database without requiring an understanding of the technical details of the database 116.

  Web service 110 and database 116 may operate on various platforms, such as one or more computers, virtual machines or other forms of computing services, which may be collectively referred to as computing nodes. The operation of these nodes, as well as the associated storage devices, network infrastructure, etc. involve various expenses. These expenses include those related to hardware and software acquisition, maintenance, power, personnel, etc. Expenses can also include factors such as opportunity expenses that arise when the consumption of resources by one customer prevents others from using the service.

  The operations performed by the web service 110 and the database 116 on behalf of the customer can correlate with the consumption of the amount of capacity on a given computing node. This correlation may allow the hosting service provider to calculate the costs incurred by providing the service. For example, if a given customer calls a web service that utilizes 100 percent of the capacity of the compute node throughout the day, the cost of providing the service is acquired, maintained and operated on the compute node allocated over a 24-hour period. Can be the sum of the expenses.

  Thus, capacity consumption can be limited by various means such as the embodiment shown in FIG. The acceptance policy 108 includes a determination of whether the request should be processed. Broadly speaking, the purpose of the acceptance policy 108 may ensure that requests fulfilled on behalf of the customer are not allowed to exceed the provisioned amount of capacity. For example, a customer may be provisioned with 25 percent of the capacity of a computing node. The acceptance policy 108 then acts to limit the customer's capacity average consumption to 25 percent or less. In some embodiments, the peak usage can be allowed to exceed that amount for a limited period of time.

  When the customer's capacity is overused, the consent policy 108 may reject the incoming request. Depending on the nature of the request, this can have important consequences for the customer. For example, a customer may operate a shopping website that directs requests to the database 116 to retrieve the contents of the end user's shopping cart. If the request is rejected, it can result in an error message rather than a sale completion. On the other hand, several types of demands are met without significant consequences. Possible examples include maintenance tasks, report generation, etc. Accordingly, the acceptance policy 108 can be implemented to take into account the type of associated request when making an acceptance or rejection decision.

  Embodiments may use a token bucket model to limit capacity consumption. A token bucket can be thought of conceptually as a collection of tokens, each representing a unit of work performed by the bucket owner with authorization. Tokens can be added to the bucket at an accumulation rate that can be based, for example, on the level of service. When work is performed, a number of tokens corresponding to the amount of work performed are withdrawn from the bucket. If no token is obtained, the work is not performed. Using this approach, the amount of work that can be performed is limited by the rate at which tokens are added to the bucket over time.

  To prevent short-term overuse of capacity, a limit can be imposed on the maximum number of tokens added to the bucket. Any token added beyond that limit can be discarded.

  In connection with database operations, a token may be considered to represent a unit of expense associated with performing database operations. For example, the cost of a request to perform an operation on database 116 may correspond to the size of data returned when the operation is performed. The cost of performing an action when measured in tokens can be determined by dividing the size of the data by the size per token value.

  The requested action may be considered an expense with at least one token, but the overall expense may not be known until after the action is actually performed. In one embodiment, among many possible embodiments, the request may be granted when at least one token is available. This request can then be processed and the total cost of the request can be determined based on one or more measurements.

  In FIG. 1, tokens may be stored in a virtual container such as token bucket 112. A token bucket may be considered to represent an association between a unit of allowed capacity consumption represented by a token and an entity such as a customer or service. For example, when a customer creates a table on the database 116, the token bucket 112 can be associated with all operations performed on this table. In other embodiments, token buckets may be associated with table partitions, customers, computing nodes, etc.

  The token accumulation policy 114 may coordinate the addition of tokens into the token bucket 112. In an embodiment, the accumulation policy 114 includes an add rate and a maximum token capacity. For example, a policy may indicate that a given bucket should accumulate tokens at a rate of 20 per second, but no more than one hundred tokens should be allowed to accumulate.

  Tokens and token buckets can be represented by various structures. In the embodiment, the acceptance policy 108, the token bucket 112, and the token accumulation policy 114 are implemented by functionality modules such as a software library and an executable program. The module may represent token and token accumulation by recording the current token count, maximum token count, accumulation rate, and previous token addition time. When deciding whether to accept or reject a request, the module may first update the current token number based on the accumulation rate, the last time the token was added, and the current time. For example, when examining the data structure corresponding to a token bucket to determine if capacity is available, the number of new tokens accumulated is multiplied by the amount of time elapsed since the previous update. , A count of available tokens can be determined. This value can be added to the count of currently available tokens, but cannot exceed the maximum number of tokens allowed for the bucket. Other techniques for maintaining token buckets are also possible, such as those based on routinely called routines.

  FIG. 2 shows an embodiment of acceptance and token accumulation policy application. Although illustrated as an order of operations that begin at operation 200 and end at operation 216, those skilled in the art will appreciate that the illustrated operations are intended to illustrate embodiments, and that at least some of the illustrated operations may It will be appreciated that modification, omission, reordering, or execution in parallel may be performed.

  At act 202, a request to perform a service is received. As an example, the request may include a database query. The cost of querying the database can be determined based on the amount of data returned by making the query, possibly measured by the number of bytes of data returned to the end user.

  Act 204 illustrates updating the count of available tokens. In an embodiment, the number of available tokens may be adjusted based on the time of the last update, the token accumulation rate, and the current time. The maximum number of available tokens can also be limited. If the request is accepted, the token is deducted from the current number of tokens. However, in various embodiments, the current token count is allowed to fall below zero, so tokens may not be available for deduction. Act 206 shows a determination of whether a token is available for deduction. In some embodiments, one token may be considered sufficient to accept the request, while others may attempt to estimate the number of tokens consumed by processing the request, i.e., capacity. As used herein, the term sufficient token or sufficient capacity may refer to one token, a fixed number of tokens, the number of tokens based on an estimate of capacity to be utilized by processing the request, etc. . If insufficient tokens are available, the request is rejected as shown at operation 208. Client applications and / or customers of the services they provide may be notified of the rejection.

  Act 210 indicates accepting the request when at least one token is available. As indicated by operation 212, the count of available tokens may be deducted by 1, and the request may be processed. Once the request has been processed, the number of available tokens can be adjusted further downward based on the actual cost of fulfilling the request, as indicated by operation 214. In various embodiments, it may be measured based on metrics such as the amount of data returned, CPU utilization, memory consumption, network bandwidth consumption, and the like.

  The embodiment illustrated by FIG. 2 allows the current token count in the bucket to fall below zero. A negative token balance may correspond to a blackout period during which a request according to the token bucket cannot be accepted. The length of the blackout period may depend on the current negative token count and token accumulation rate. For example, if the token accumulation rate is 10 per second and the number of available tokens is −100, the length of the blackout period may be 10 seconds.

  Certain types of requests, such as those involving maintenance, reporting, summarization, etc., can be data that is intensive and treated as expensive. Thus, these types of requests may result in long blackout periods, at which time no requests can operate, including those that are low in cost but high in importance. FIG. 3A shows an example of this type of situation. The total provisioned capacity assigned to a particular entity, such as a table, partition, computing node, etc., can be represented by token inflow 308, and tokens are added to token bucket 302 at that rate. For example, the long-term maintenance task 306 may be a data intensive task that results in a relatively large amount of token outflow 310. It may happen that each time a task is activated, the number of available tokens in the token bucket 302 is reduced to a negative number resulting in a blackout period. On the other hand, the query request 304 requires little data spill and can result in a relatively small amount of token spill 312. However, previously performed maintenance tasks may have resulted in a blackout period and query requests can be rejected even though they are low cost. It is convenient to avoid such a situation.

  FIG. 3B shows the allocation of provisioned capacity to two separate token buckets 314 and 316. Token inflows are allocated equally, as indicated by token inflow 308a and token inflow 308b. The cost of performing long-term maintenance tasks and queries remains constant, so token outflow rates 310 and 312 are unchanged. This arrangement prevents query requests from being blocked by performing long-term maintenance tasks. However, maintenance tasks are rarely required. If so, much of the capacity pre-stored in long-term tasks can be wasted.

  Request acceptance may be determined for tokens that may be deducted from more than one bucket based on more than one bucket. For example, in embodiments, request types may be assigned high, medium and low priority. High priority requests can be pulled from any bucket, medium requests can be pulled from two of the three buckets, and low priority requests can be pulled from just one bucket. Similar categories of requirements can be expressed as classes. These classes can be associated with an acceptance policy. An acceptance policy is an indication of which token bucket should be used to determine whether a request should be accepted, and a technique for withdrawing tokens once the total cost of the token request is known Or it may include techniques.

  FIG. 4 illustrates an embodiment for allocating capacity based on request class and acceptance policy. Incoming requests may be made to belong to a request class, such as class “A” request 400, class “B” request 402, and class “C” request 404. An acceptance policy can be applied in this way to determine which buckets to intervene in accepting or rejecting a request and how to deduct tokens from these buckets.

  Each request class may be associated with an acceptance policy. The acceptance policy includes various logical and procedural mechanisms for token usage. One aspect of the acceptance policy includes determining whether to accept and process the request. Using FIG. 4 as an example, policy 406 may specify that class “A” request 400 should be granted if at least one token is available in bucket “Y” 414. The second policy 408 may specify that the class “B” request should be granted if the token is in either bucket “X” 412 or bucket “Y” 414. A third policy 410 for class “C” request 404 may indicate that the request should be granted based only on bucket “X” 412. These examples are illustrative and many other combinations are possible.

  In an embodiment, the request may be granted based on a variable or predefined token threshold. One embodiment includes granting the request only when the bucket has a number of tokens equal to the expected number of tokens that can be consumed. Another example includes using a moving average of previous expenses to set a minimum number of tokens. Numerous additional embodiments are possible.

  The acceptance policy also includes a determination of how the token is deducted. If the request is first granted, one or more tokens may be deducted from the bucket on which the grant was based. However, the total cost of the request may not be known until the request is at least partially processed. Thus, at some point after the request has been granted, a second token deduction may occur. A policy may identify one or more buckets to be deducted and may specify an allocation between buckets.

  In an embodiment, the token may be withdrawn from the same bucket for which acceptance has been determined. For example, if the request is granted based on the presence of a token in bucket “X” 412 shown in FIG. 4, the total token cost may also be deducted from bucket “X” 412. One reason for adopting this approach is that otherwise a bucket with a negative available token could fall further, extending the blackout period for requests that depend solely on that bucket. is there.

  Another embodiment first deducts from the bucket used to determine acceptance and then subtracts from one or more subsequent buckets. For example, once the request is granted based on the available tokens in bucket “X” 412, a portion of the total cost once determined can be subtracted from bucket “X” 412 and a portion can be subtracted from bucket “Y” 414. Can be. The amount deducted from the first bucket 412 may be determined to prevent the available token count from falling below a threshold such as zero. The remainder may be subtracted from the second bucket or the last bucket in the series of buckets, causing the available token count for that bucket to be less than zero. Accordingly, using this approach to process class “B” request 402 in FIG. 4 may cause the token count available for bucket “Y” 414 to be negative. However, the count for bucket “X” 412 will not be negative due to class “B” request 402. This approach is advantageous because it may prevent blackout periods for class “C” requests 404 that may otherwise be caused by processing class “B” requests 402.

  FIG. 5 illustrates an embodiment for obtaining and applying an acceptance policy. Although shown as an order of operations starting at operation 500 and ending at operation 516, those skilled in the art will appreciate that the illustrated operations are intended to be exemplary and modify at least some of the illustrated operations. It will be appreciated that they may be omitted, reordered, or performed in parallel.

  The process for applying the acceptance policy may include receiving a request, as indicated by operation 502. The class to which the request belongs can then be determined. This can be done through various means. In an embodiment, the API associated with the request invocation may allow one or more parameters that identify the class. One embodiment includes a text parameter that specifies the class to which the request corresponds. However, using numerical values to identify the request class is advantageous when considering various performances.

  In some embodiments, requests can be classified based on their type. For example, write requests can be classified separately from read requests. In other embodiments, the requests are analyzed to determine their potential expenses, and similar expense level requests are assigned to the same class.

  The class of requirements may be based on factors in addition to or instead of those specified in the request parameters. For example, a given customer, identifier, or security role can be associated with a request class. The customer or role may be available from the situation in which the request is invoked or may be specified as a parameter in the request. Other possible factors include the internet protocol address of the source of the request, the particular API being called, etc. In addition, configurations or other mechanisms can be used to define classification rules. For example, a configuration associated with a customer, web service, API or other entity may be associated with the request. Various default rules, possibly specific to the configuration, may also apply. Default values are applicable when no other classification rule is applicable. Embodiments allow default values to be overridden. Embodiments also allow certain default values to be fixed values so that they cannot be overridden.

  Once the request class is determined, a corresponding acceptance policy can be received, obtained, or otherwise prepared for the application, as indicated by operation 504. This includes access to records describing acceptance policies, such as a list of buckets from which tokens can be drawn. Records can be stored, for example, in a database and embedded in code resources, configuration files, etc. In some embodiments, the structure representing the bucket may be part of the policy description, in other words, the bucket and policy definition may include a unified structure. Some embodiments may be applied by omitting this step and selecting a suitable execution path in the instructions that perform the various techniques described herein.

  The request may be accepted or rejected by operation 506. The acceptance policy may describe one or more buckets that will be checked against available tokens. In some embodiments, criteria compliance may be required for multiple tokens or at least tokens above a threshold level. In some embodiments, when the token count is negative, the request may be allowed to be allowed, and the policy description may indicate a negative threshold value that does not accept the lower request.

  Act 506 also includes subtracting at least one token. The number of tokens deducted may be the same as the amount of tokens used to determine whether the request should be granted. Thus, no other request will be granted based on the same token or set of tokens. Embodiments may also synchronize access to the buckets to prevent multiple requests from being granted based on the same token or set of tokens.

  Once granted, the request may be processed as indicated by operation 508. The total cost of the request can be determined based at least on the processing of the request. In various embodiments, the size of the data returned to the service client may be used. For example, if the request is a database query, the token cost can be derived from the total size of data returned to the client after the query is executed. In other embodiments, various performance metrics may be collected while the request is processed and used as a basis for expense determination.

  In various embodiments, once the request has been fulfilled, operational costs may be deducted. This step may be performed according to a consent policy, as indicated by operation 514. The acceptance policy may describe various techniques for deducting token expenses, such as distributing among multiple buckets, or deducting expenses from the bucket used to determine the acceptance. Various other policies can be employed

  In some embodiments, token buckets may have a hierarchical relationship. This approach allows for convenient management of selected acceptance policies, since it allows a prioritization scheme to be defined with a one-to-one mapping between request classes and token buckets. Hierarchical token buckets can be conveniently defined by specifying a parent-child relationship between token buckets along with their respective maximum token capacities. FIG. 6A illustrates an embodiment using an example of a hierarchical token bucket. Two token buckets are shown. Bucket “X” 608 is the parent bucket of “Y” 610 and has a maximum capacity of 30 tokens. Bucket “Y” 610 is a child of parent “X” 608 and has a maximum capacity of 5 tokens. Tokens are shared in a hierarchical fashion between buckets, and child buckets can access their parent tokens. Thus, when both token buckets 608 and 610 are at maximum capacity, there are 30 tokens shared between them.

  In FIG. 6A, class “A” request 600 is associated with bucket “Y” 610 based on the application of class “A” policy 604. Similarly, class “B” requests are associated with bucket “X” 608 based on class B policy 606. The acceptance policy may include a one-to-one mapping between the request class and the bucket, which determines whether the request should be accepted and which token bucket, or bucket, the token is deducted from. Can be used. The acceptance policy may also include additional elements such as the minimum number of available tokens required to accept the request. Various methods and techniques described herein with respect to non-hierarchical approaches may also be applied to hierarchical approaches.

  The request may be granted based on the availability of at least one token in the token bucket mapped to the request class. For example, class “A” request 600 may be granted when bucket “Y” 610 has an available token. Similarly, class “B” request 602 may be granted when bucket “X” 608 has an available token. Some embodiments may require that more than one token be available, eg, based on the estimated cost of processing the request.

  The token (s) required for acceptance can be deducted when the request is granted for processing. In an embodiment, 1 may be subtracted when accepting the request. Once the remaining cost is known, it can be deducted from the same bucket used to determine acceptance.

  FIG. 6B is a diagram illustrating operation 650 of subtracting two tokens from bucket “X” 608. The state before the subtraction of the buckets “X” 608 and “Y” 610 is indicated by an element 651 in the drawing, and the state after the subtraction is indicated by an element 652. As a result of the token being subtracted from bucket “X” 608, there are 28 token counts. The token available for “Y” 610 is unchanged.

  In FIG. 6C, operation 660 shows subtracting two tokens from bucket “Y” 610. The state before subtraction is indicated by an element 661 in the figure. The state after deduction indicates that two tokens have been deducted in both buckets “X” 608 and “Y” 610, as indicated by element 662. This approach reflects sharing available tokens between two buckets in a floor style. When a request is granted or processed based on the available tokens in the child bucket, the token can be deducted from each of the child bucket and its parent. In addition, in various embodiments, a token must be available in both child buckets and each of its parents in order for the request to be granted. In FIG. 6C, since both bucket “Y” 610 and its parent bucket “X” 608 have at least one token, the request may be granted based on state 661 prior to deduction. On the other hand, embodiments grant a parent bucket, such as bucket “X” 608, to process the request even if there are insufficient tokens in the child bucket.

  Operation 670 in FIG. 6D shows subtracting a larger number of tokens from bucket “X” 608 than is available. Before deduction, as indicated by element 671, token bucket “X” 608 has 30 tokens available to it. After subtracting 35 tokens, the total number is reduced to minus 5, as indicated by post-subtraction state 672. FIG. 6D shows bucket “Y” 610 as having 5 tokens available to it after deduction. For requests where consent depends on bucket “Y” 610, an embodiment may require that at least one token be present in parent bucket “X” 608. Thus, in these embodiments, requests that depend on bucket “Y” 610 are not granted until the number of tokens available for both bucket “X” 608 and bucket “Y” 610 exceeds zero. I will. However, embodiments may not reduce the number of tokens in a child bucket when a token is deducted from its parent. In embodiments, it may still require at least one token to be present in each of the child bucket's parents. However, preventing a child's token count from going negative can help prevent blackout periods for services associated with the child bucket.

  Factors that determine the length of the blackout period due to various factors include the degree to which the token count in the child bucket and its parent is negative, and the refill rate of the child and parent bucket. For example, in FIG. 6D, a request that depends on bucket “Y” 610 may not be granted until at least one token is available in both bucket “X” 608 and bucket “Y” 610. The rate at which bucket “X” 608 is refilled with tokens may thus affect the length of the blackout period seen in requests that depend on bucket “Y” 610. However, bucket “X” 608 may be assigned a proportionally higher accumulation rate than that assigned to bucket “Y” 610.

  FIG. 6E illustrates an operation 680 of subtracting more tokens from the bucket “Y” 610 than are available to it. Prior to subtraction, bucket “Y” 610 has 5 tokens available to it, as shown in element 681 as part of the figure. After subtracting 35 tokens, bucket “Y” 610 has minus 30 tokens available to it, while bucket “X” 608 remains minus 5 tokens. This state is indicated by element 682 and reflects the subtraction from the child bucket “Y” 610 on which the consent is based and from its parent bucket “X” 608.

  Hierarchical token bucket embodiments may employ various techniques, algorithms, data structures, and the like. In an embodiment, a record may be used to track the number of tokens available in the parent token bucket. The number of tokens available to that child can then be determined based on a set of rules, algorithms, etc. For example, the number of tokens available for the child token bucket may be determined based on the number of tokens available for the parent token bucket and the maximum number of tokens that the child token bucket can store.

  The token bucket hierarchy may store new tokens as a group. Using the token bucket shown in FIG. 6A as a reference point, the token accumulation rate may be associated with a hierarchical structure that includes buckets “X” 608 and “Y” 610. When tokens are added to the hierarchical structure, the number of tokens available for both buckets “X” 608 and “Y” 610 may increase to their respective maximum values.

  FIG. 6F shows a hierarchical arrangement of token buckets when two or more request classes share buckets with equal priority. Class “A” request 6000 may be directed to bucket “X” 6010 and class “B” request 6002 may be directed to bucket “Y” 6012. Parent bucket “P” 6008 may have a total capacity of 100, corresponding to bucket “X” 6010 receiving an allocation of 80 tokens per second and bucket “Y” 6012 receiving an allocation of 20 tokens per second. The maximum capacity of the buckets may be the same as their respective token allocation rate.

  An acceptance policy may be defined for the arrangement shown in FIG. 6F where child buckets share equal priority. The acceptance policy can proceed as follows. Upon arrival of a request corresponding to class “A” request 6000, bucket “Y” 6012 may be referenced for token availability. The request can be granted if at least one token is available. The count of available tokens in bucket “Y” 6012 and parent bucket “P” may be decremented upon acceptance and again upon request processing, respectively. If insufficient tokens are available in bucket “Y” 6012, the request may be granted if there is at least one token in parent bucket “P” 6008. The token may be deducted from the parent bucket “P” 6008 upon acceptance and upon processing of the request again. Class “B” request 6002 may be similarly processed by a class defining class “B” policy 6006 in a manner similar to class “A” policy 6004 and is adjusted for differences in token allocation rates.

  This approach results in a request from each class to access those provisioned capacities, but additional capacities can be utilized if the sibling bucket is not fully utilizing the provisioned capacities. For example, if only class “A” requests 6000 are issued, a maximum of 100 tokens per second will be available to process them. If the workload is mixed and the class “A” request 6000 consumes 10 tokens per second, the class “B” request 6002 can consume a maximum of 90 tokens per second.

  Aspects of the acceptance policy can be defined by the provider's customers. The definition can be accomplished by customer interaction with a user interface provided by the service provider. For example, a web page may allow a user to define each bucket from which classes and tokens can be deducted. The user may also set various additional parameters, such as a minimum token amount for each class of request.

  Various embodiments may provide a means for managing policies that adjust input / output priorities, which may include, for example, defining request classes, token buckets, acceptance policies, and the like. In FIG. 7A, the user interface 700 may include a portion of the order of user interface pages presented to the user during creation of the hosted database table. The user interface part of the preceding step 701 may represent a button, hyperlink, or similar element for navigating to a previous part of the user interface wizard for defining the provided database table. The user interface element of table creation 702 may indicate that the user has provided parameters to the table creation process and that the table should be created. The illustrated user interface elements are intended to be general examples of techniques for providing such an interface and should not be construed to limit the scope of the present disclosure.

  User interface 700 may include one or more policy definitions 704a, 704b, and 704c, which are parameters that indicate the relationship between the request class and one or more buckets from which tokens may be retrieved, and possibly It can be used to supply various other elements of the acceptance policy. For example, policy definition element 704a may include a class display 706a, a primary bucket display 708a, and a secondary bucket display 710a. The class display 706a may include various parameters describing the class, which may include a class name and one or more request types. In some embodiments, request classes and request types are predefined by the providing service provider. A number of additional class displays, such as a policy definition 704b that includes a class display 706b, a primary bucket display 708b, and a secondary bucket display 710b, and a policy definition 704c that includes a class display 706c, a primary bucket display 708c, and a secondary bucket display 710c. May be presented on the user interface 700.

  Primary bucket element 708a and secondary bucket element 710a indicate token buckets that include a portion of the acceptance policy, along with their respective priorities. For example, the token bucket indicated by 708a will be first referenced in applying an admission decision for a request corresponding to the class identified by the class indication 706a. The token bucket identified by secondary token bucket 710a will be referenced second. Policy definitions 704a, 704b, and 704c may refer to the same token bucket, or overlapping sets of token buckets.

  FIG. 7B is an illustrative embodiment of a user interface for defining an acceptance policy employing a hierarchical token bucket. User interface 750 includes a portion of a table definition process that employs user interface elements of preceding step 751 and table creation 752 to navigate to other steps in the process and indicate that the process should be completed. obtain.

  The user interface 750 may include one or more policy definitions 754a, 754b, and 754c that allow a customer to provide parameters for creating acceptance policies and hierarchical token buckets. For example, the policy definition 754a may include a user interface element with a bucket name 756a that indicates the name of the token bucket. In some embodiments, this may be a drop box or other user interface element that includes a predefined bucket name. Request class 760a may include a combo box, list box, or other user interface element that allows a request class to be assigned to the bucket indicated by bucket name 756a. The user interface element of child token bucket 758a may be used to identify one or more child token buckets, such as bucket “Y” 610 shown in FIG. 6A. This can be a list box or other user interface element that allows one or more child token buckets to be selected. In some embodiments, a parent token bucket may be specified in place of one or more child token buckets. User interface 750 allows a number of additional policy definitions to be defined. For example, the user interface 750 also defines or edits a policy definition 754b that includes a bucket name 756b, a request class 760b, and a child bucket 758b, and a policy definition 754c that includes the bucket name 756c, the request class 760c, and a child bucket 758c. User interface elements may be included.

  FIGS. 7A and 7B are both shown to provide user interface elements for identifying a token bucket, such as primary bucket 708a in FIG. 7A and bucket name 756a in FIG. 7B. However, user interfaces 700 and 750 may use alternative representations for directly or indirectly identifying token buckets and corresponding request classes. For example, the user interface 700 may present a high, medium or low priority selection that may be associated with a request class. The relationship between buckets can be estimated from the priority level selected by the user. A similar approach may be employed for the user interface 750.

  In an embodiment, a user interface similar to that shown in FIGS. 7A and 7B may be employed, allowing the customer to continue to edit request classes, buckets, relationships between buckets, etc. One example involves changing the definition of a table. The customer may make various modifications to the database table definition, for example, by adding additional columns. The modified table can be associated with different usage patterns. Thus, the customer may also specify changes in capacity, acceptance policy, number of buckets, etc. assigned to the table. Various user interface elements or APIs may be used to provide relevant information.

  The example user interface shown in FIGS. 7A and 7B may be implemented using a variety of technologies, including thick clients, n-tiers, or other architectures. In an embodiment, a web server operating within the hosting provider's data center serves a hypertext markup language (“HTML”) form to the customer's browser. Upon form submission, the web service API in the hosting provider's data center receives and processes information supplied by the customer.

  FIG. 8 is a flowchart illustrating a process for creating a database table with associated token buckets and acceptance policies. Although shown as an order of operations starting at operation 800 and ending at operation 814, those skilled in the art will recognize that at least some of the illustrated operations may be modified, omitted, reordered, or performed in parallel. It will be. For example, the information indicated by operations 802-808 may be received simultaneously at the host provider data center.

  Act 802 shows receipt of information indicating a table definition. Embodiments of the present disclosure may allocate capacity per table, or per partition if the defined table includes more than one partition. A partition can include sub-partitions of a table, each of which can be maintained by a DBMS running on one or more computing nodes. Since capacity can be allocated per table or per partition, acceptance policies and token buckets can be similarly defined.

  Act 804 illustrates receiving information indicating one or more request classes. These classes may be defined by the user via a user interface such as that shown in FIGS. 7A and 7B, for example. In other embodiments, the hosting provider may predefine the request class. In an embodiment, the request classes are labeled as “high”, “medium”, and “low”.

  Act 806 indicates receipt of information indicating the bucket to be created. In some embodiments, the information may include a bucket listing or count, and in others, the information may be estimated. For example, a one-to-one correspondence between request classes and token buckets can be estimated. In an embodiment, three token buckets may be formed to correspond to the “high”, “medium”, and “low” request classes.

  At act 808, information indicative of one or more acceptance policies may be received. This information may include a mapping between request classes and buckets, and may include information indicating the order in which the buckets are referenced to determine acceptance, how to reduce tokens, and so forth. The information may be combined with other information referenced by operations 802-806. Certain aspects of the information may be determined a priori or used to estimate other aspects of the information received at operations 802-806. For example, in some embodiments, a policy description that references a bucket may be used to infer that the referenced bucket is to be created.

  In operation 810, a partitioning scheme may be determined. A provided table or other service may be allocated among multiple computing nodes. Thus, embodiments may determine other aspects of partitioning the table, such as determining how many and which computing nodes are involved and how to allocate the data maintained by the table. For services that do not include a table, this may include determining how to allocate the workload handled by each partition.

  Based on the partitioning scheme, capacity may be assigned to various partitions or computing nodes. Capacity per customer may be allocated equally between partitions, for example, or based on the amount of expected workload handled by a partition or computing node. For example, if the first partition is expected to handle three quarters of the table workload, it may be assigned three quarters of capacity.

  The allocation of capacity per customer to a segment may include an allocation to a segment of a percentage of the total production of tokens. For example, based at least in part on the customer's service tier, it may be determined that the customer should be assigned a given token amount per second. Continuing the previous example, three quarters of that capacity can be allocated to one partition or computing node and the remaining one quarter can be allocated to another partition. This is indicated by operation 810.

  The capacity per customer assigned to a partition may be finely allocated to the token bucket created for that partition, as indicated by operation 812. Continuing with the previous example, assuming that three-quarters of the total capacity corresponds to a token generation rate of 75 tokens per second, a count of 75 tokens per second is added to the token bucket associated with that partition or computing node. Can be assigned. If there are three token buckets for that partition, each may be allocated 25 tokens per second.

  Once determined, the token allocation rate per bucket can be used to create, initialize, or represent a token bucket. In various embodiments, bucket creation may include initialization of various data structures, such as records including maximum token capacity, current capacity, token allocation rate, and previous addition time. Many other embodiments are possible. For example, in some embodiments, there may not be a one-to-one correspondence between logically defined buckets and data structures stored in memory.

  The operations shown in FIG. 8 are also adapted to allow updates. For example, operation 802 may include receiving information indicating a change in the definition of an existing table. In addition, information regarding request classes, bucket definitions and relationships, acceptance policies, partitioning schemes, etc. may be received following their initial definitions, and corresponding entities and relationships are updated accordingly.

  FIG. 9 is an illustration of an example distributed computing environment in which aspects of the invention may be implemented. Various users 900a can interact with various client applications running on any type of computing device 902a and are executed on various computing nodes 910a, 910b, and 910c within the data center 920. And the communication network 904. Alternatively, the client application 902b can communicate without user intervention. Communication network 904 may include any combination of communication technologies, including the Internet, wired and wireless local area networks, fiber optic networks, satellite communications, and the like. Any number of network protocols may be employed.

  Communication with processes running on the computing nodes 910a, 910b, and 910c operating within the data center 920 may be provided via a gateway 906 and a router 908. A number of other network configurations may also be employed. Although not explicitly shown in FIG. 9, it provides various authentication mechanisms, web service layers, business objects or other middle tiers to communicate with processes executed on computing nodes 910a, 910b, and 910c. Can communicate. Some of these middle tiers may themselves include processes that run on one or more of the computing nodes. The computing nodes 910a, 910b, and 910c and the processes executed thereon may also communicate with each other via the router 908. Alternatively, a separate communication path can be employed. In some embodiments, the data center 920 may be configured to communicate with additional data centers, and computing nodes and computing nodes on which the processes executed thereon operate in other data centers and Enable communication with the process.

  The computing node 910a is shown to reside on physical hardware that includes one or more processors 916, one or more memories 918, and one or more storage devices 914. The process at the compute node 910a can be run in conjunction with an operating system or alternatively as a bare metal process that interacts directly with physical resources, such as a processor 916, memory 918 or storage device 914. Can be done.

  Computing nodes 910b and 910c are shown to run on a virtual machine host 912 that may provide shared access to various physical resources, such as physical processors, memory and storage devices. Any number of virtualization mechanisms may be employed to provide computing nodes.

  The various computing nodes shown in FIG. 9 may be configured to provide web services, database management systems, business objects, monitoring and diagnostic facilities, and the like. A computing node may refer to various types of computing resources such as personal computers, servers, clustered computing devices, and the like. When implemented in a hardware form, a computing node generally has one or more memories configured to store computer readable instructions, and one or more configured to read instructions and execute them. Associated with the processor. A hardware-based computing node may also include one or more storage devices, network interfaces, communication buses, user interface devices, and the like. Computing nodes also include virtualized computing resources, virtualized bare metal environments, etc., such as virtual machines implemented with or without a hypervisor. The created virtualization-based computing node has virtualized access to hardware resources as well as non-virtualized access. A computing node may be configured to execute an operating system as well as one or more application programs. In some embodiments, the computing node may also include a bare metal application program.

  Each of the processes, methods, and algorithms described in the previous sections can be embodied by a code module executed by one or more computers or computer processors and thereby be fully or partially automated. The code module is stored on any type of non-transitory computer readable medium or computer storage device, such as a hard drive, solid state memory, optical disk, and / or the like. The processes and algorithms may be implemented in part or in whole for application specific circuitry. The results of the disclosed processes and process steps may be stored permanently or otherwise in any type of non-transitory computer storage device, such as, for example, volatile or non-volatile storage device.

  The various features and processes described above can be used independently of each other or can be combined in various ways. All possible combinations and subcombinations are intended to be within the scope of this disclosure. In addition, certain methods or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular order, and the blocks or states associated therewith can be performed in any other suitable order. For example, the described blocks or states may be performed in an order other than those specifically disclosed, or multiple blocks or states may be combined into a single block or state. The illustrated blocks or states may be performed sequentially, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed exemplary embodiments. The example systems or components described herein may be configured differently than those described. For example, elements may be added to, removed from, or rearranged relative to the disclosed exemplary embodiments.

  Various elements are shown to be stored in a memory or storage device while in use, and these elements or portions thereof are between memory and other storage devices for memory management and data integrity purposes. It will also be appreciated that can be forwarded on. Alternatively, in other embodiments, some or all of the software modules and / or systems may execute in the memory of another device and communicate with the illustrated computing system via computer-to-computer communication. Further, in some embodiments, some or all of the systems and / or modules may be implemented with one or more application specific integrated circuits (ASICs), standard integrated circuits, controllers (eg, Controller and / or embedded microcontroller), field programmable gate array (FPGA), complex programmable logic device (CPLD), etc., including but not limited to, at least partially in firmware and / or hardware, etc. It can be realized or provided in other ways. Some or all of the modules, systems, and data structures may also be on a computer-readable medium (eg, software, such as a hard disk, memory, network, or portable media article that can be read by a suitable drive via a suitable connection. Can be stored (as instructions or structured data). The systems, modules, and data structures can also be generated data signals (eg, as part of a carrier wave or other analog or digital propagation signal) on various computer readable transmission media, including wireless based media and wired / cable based media. ) And may take various forms (eg, as single or multiple analog signals, or as multiple individual digital packets or frames). Such a computer program product may take other forms in other embodiments. Accordingly, the present invention may be implemented with other computer system configurations.

The above matters can be further understood in view of the following supplementary notes.
1. A system for prioritizing capacity consumption of a database management system,
One or more computing nodes configured to operate a database management system;
One or more memories having computer-readable instructions stored thereon, wherein at the time of execution, the system includes information indicating at least a request class, and requests to perform operations performed on behalf of the customer on the database management system. Let
Selecting a first token bucket having an associated first capacity indication from one or more data structures comprising a plurality of token buckets based at least in part on the request class;
Determining that the first capacity indication indicates a capacity to perform an action on behalf of the customer;
Performing the operation and updating the first capacity indication based at least in part on the capacity utilized by performing the operation;
One or more memories having computer-readable instructions stored thereon;
A system comprising:
2. When executed by a computing device, the system at least
Receiving information indicating an association between the request class and the first token bucket;
The system of claim 1, further comprising one or more memories having computer-readable instructions stored thereon.
3. When executed by a computing device, the system at least
Updating a second capacity indication associated with a second token bucket of the plurality of token buckets based at least in part on the capacity utilized by performing the operation;
The system of claim 1, comprising one or more memories having stored thereon computer readable instructions.
4). When executed by a computing device, the system at least
Determining that a second capacity indication associated with a second token bucket of the plurality of token buckets indicates a lack of capacity to perform an action on behalf of the customer;
The system of claim 1, further comprising one or more memories having computer-readable instructions stored thereon.
5. A computer-implemented method for prioritizing capacity consumption, comprising:
Receiving a request on one or more computing nodes to perform an operation performed on behalf of a customer, the request including information indicating a request class;
Selecting a first data structure including a first capacity indication from a plurality of data structures based at least in part on the request class;
Determining that the first capacity indication indicates the capacity of one or more computing nodes to perform operations on behalf of the customer;
Performing actions,
Updating the first capacity indication based at least in part on the capacity utilized to perform the operation;
Including the method.
6). The method of claim 5, wherein the operation is performed by one or more of a web service, a website, and a database management system.
7. The method according to appendix 5, wherein the information indicating the request class includes a parameter.
8). The method according to appendix 5, wherein the information indicating the request class includes a configuration value.
9. The method of claim 5, further comprising one or more of a customer identifier, a security role, and an application programming interface.
10. Receiving information indicating a mapping between the request class and the first capacity indication;
The method according to appendix 5, further comprising:
11. Determining that the second capacity indication from the plurality of data structures indicates a lack of capacity to perform the action on behalf of the customer;
The method according to appendix 5, further comprising:
12 Updating the second capacity indication from the plurality of data structures based at least in part on the capacity utilized to perform the operation;
The method according to appendix 5, further comprising:
13. The first capacity indication and the one or more additional capacity indications from the plurality of data structures may include one or more memory locations in the plurality of data structures that indicate the capacity to perform operations on behalf of the customer, The method according to appendix 5, which is shared.
14 The method of claim 5, wherein the first capacity indication corresponds to a subset of the total capacity of the one or more computing nodes.
15. The method of claim 5, wherein the first capacity indication includes a count of capacity units available to perform actions on behalf of the customer.
16. The method of claim 15, wherein the count is increased based at least in part on the rate of accumulation of the allocated capacity.
17. A non-transitory computer readable storage medium that, when executed by a computing device, has at least a computing device,
Receiving a request to perform an operation on one or more computing nodes, including information indicating a request class;
Selecting a first data structure including a first capacity indication from a plurality of data structures based at least in part on the request class;
Determining that the first capacity indication indicates a capacity sufficient to allow the operation for processing to perform the operation, and wherein the first capacity indication is at least equal to the capacity utilized to perform the operation. Update based on part,
A non-transitory computer readable storage medium having instructions stored thereon.
18. The computer-readable storage medium according to appendix 17, wherein the information indicating the request class includes a parameter.
19. When executed by a computing device, the system at least
Determining that a second data structure of the plurality of data structures indicates a lack of capacity to perform the operation;
18. The computer readable storage medium according to appendix 17, wherein further instructions are stored above.
20. When executed by a computing device, the system at least
Updating the second capacity display from the plurality of data structures when the first capacity display indicates a lack of capacity to perform the operation;
18. The computer readable storage medium of appendix 17, wherein further instructions are stored above and the update is based at least in part on the capacity utilized to perform the operation.
21. 18. The computer readable storage medium of appendix 17, wherein the first capacity indication includes a count of units of capacity available to perform the operation.
22. 24. The computer readable storage medium of claim 21, wherein the count is increased based at least in part on an accumulation rate of the allocated capacity.
23. A system for prioritizing capacity consumption,
One or more computing nodes;
One or more memories having stored thereon computer readable instructions, wherein when executed by a computing device, the system has at least:
Receiving information indicating one or more request classes,
Receiving information indicating a mapping between one or more request classes and one or more data structures with a first capacity indication;
A subset of the total capacity for performing operations on one or more computing nodes is assigned to a first capacity indication, and the first capacity indication performs operations on one or more computing nodes To perform an action when it is decided to show available capacity to
One or more memories having computer-readable instructions stored thereon;
A system comprising:
24. One or more memories having stored thereon computer readable instructions, wherein when executed by a computing device, the system has at least:
24. The system of clause 23, further comprising one or more memories having stored thereon computer readable instructions for receiving information indicative of instructions for creating a database table on behalf of a customer.
25. One or more memories having stored thereon computer readable instructions, wherein when executed by a computing device, the system has at least:
Receiving information indicating an instruction for correcting the database table, and receiving information indicating an instruction for correcting the capacity allocated to the database table;
24. The system of clause 23, further comprising one or more memories having computer readable instructions stored thereon.
26. One or more memories having stored thereon computer readable instructions, wherein when executed by a computing device, the system has at least:
25. The system of claim 24, further comprising one or more memories having stored thereon computer readable instructions for determining a subset of the total capacity based at least in part on the number of database table partitions.
27. One or more memories having stored thereon computer readable instructions, wherein when executed by a computing device, the system has at least:
Sending a user interface instruction including an instruction to allow the customer to accept input,
24. The system of clause 23, further comprising one or more memories having computer readable instructions stored thereon.

  In particular, conditional phrases used herein, such as “can”, “could”, “might”, “may”, “eg”, etc., unless otherwise specifically stated or otherwise. Unless otherwise understood within the context of use, it is generally intended to convey that certain embodiments include certain features, elements and / or steps, but not other embodiments. Accordingly, such conditional language means that features, elements and / or steps are in any way required for one or more embodiments, or that one or more embodiments require these features, elements And / or is not generally intended to imply that it necessarily includes logic to determine whether a step is included or performed in any particular embodiment. The terms “comprising”, “including”, “having” and the like are synonymous and are used comprehensively without restriction and do not exclude additional elements, features, functions, operations, etc. . Also, the term “or” is used in its generic meaning (and not in its exclusive meaning), for example, when connecting lists of elements, the term “or” Means one, some, or all of the elements in the list.

  Although certain example embodiments have been described, these embodiments have been presented by way of example and are not intended to limit the scope of the invention disclosed herein. Accordingly, nothing in the preceding description is intended to imply that any particular feature, characteristic, step, module, or block is necessary or essential. Indeed, the novel methods and systems described herein may be embodied in various other forms, and various omissions, substitutions, and modifications in the form of the methods and systems described herein may be made. This can be done without departing from the spirit of the invention disclosed herein. The appended claims and their equivalents are intended to cover such forms or modifications as would fall within the specific scope and spirit of the invention as described herein. .

Claims (13)

A database management system program for managing capacity consumption,
The program runs on one or more computing nodes having one or more memories in which computer readable instructions are stored,
The computer readable instructions, when executed by the one or more computing nodes, at least in the database management system,
Receiving a request for performing an operation performed on behalf of a customer on the database management system, the request including information indicating a request class;
Selecting a first token bucket having an associated first capacity indication from one or more data structures including a plurality of token buckets based at least in part on the request class;
Determining that the first capacity indication indicates sufficient capacity to perform the operation;
When the first capacity display indicates to be sufficient to the capacitive, and performing the operation,
A step of the capacity that is utilized by the step of performing the operation, and pull out from the first token bucket, to update the first capacity display,
Deriving the used capacity from a second token bucket of the plurality of token buckets and associating with the second token bucket based at least in part on the capacity used by performing the operation Updating the displayed second capacity indication;
Let
The second token bucket is a parent bucket that shares a token with the first token bucket.
program. The computer readable instructions, when executed by the one or more computing nodes, at least in the database management system,
Receiving information indicating an association between the request class and the first token bucket;
The program according to claim 1. The computer readable instructions, when executed by the one or more computing nodes, at least in the database management system,
Performing a step of determining that a second capacity indication associated with a second token bucket of the plurality of token buckets indicates a lack of capacity to perform the operation for the customer;
The program according to claim 1. A computer-implemented method for managing capacity consumption, the method comprising:
Receiving a request to perform an operation performed on behalf of a customer on one or more computing nodes, the request including information indicating a request class;
Selecting a first token bucket having an associated first capacity indication from one or more data structures including a plurality of token buckets based at least in part on the request class;
Determining that the first capacity indication indicates sufficient capacity to perform the operation;
When the first capacity display indicates to be sufficient to the capacitive, and performing the operation,
A step of the capacity that is utilized by the step of performing the operation, and pull out from the first token bucket, to update the first capacity display,
Based on the capacity used by the step of performing the operation, the capacity used is derived from a second token bucket , and a second capacity indication associated with the second token bucket is displayed. A step to update,
Including
The second token bucket is a parent bucket that shares a token with the first token bucket.
Method. The operation is performed by one or more of a web service, a website, and a database management system.
The method of claim 4. Further comprising determining that a second capacity indication from the plurality of data structures indicates a lack of capacity to perform the operation for the customer;
The method of claim 4. The first capacity indication and the one or more additional capacity indications from the plurality of data structures indicate one or more of the plurality of data structures in the plurality of data structures indicating a capacity for performing the operation for the customer. Share memory locations,
The method of claim 4. The first capacity indication includes a count of capacity units available to perform actions for the customer;
The method of claim 4. The count is increased based at least in part on the accumulation rate of the allocated capacity;
The method of claim 8. A system program for managing capacity consumption,
The program runs on one or more computing nodes having one or more memories in which computer readable instructions are stored,
The computer readable instructions, when executed by the one or more computing nodes, at least in the system,
Receiving information indicating one or more request classes;
Receiving information indicative of a mapping between the one or more request classes and one or more data structures including a first capacity indication;
Selecting a first token bucket based on the information indicative of the mapping;
Allocating a subset of the total capacity for performing an operation on one or more computing nodes to the first capacity indication; and the first capacity indication is sufficient for the capacity to perform the operation. Determining to show that there is ,
When the first capacity display indicates to be sufficient to the capacitive, and performing the operation,
A step of the capacity that is utilized by the step of performing the operation, and pull out from the first token bucket, to update the first capacity display,
Based on the capacity used by the step of performing the operation, the capacity used is derived from a second token bucket , and a second capacity indication associated with the second token bucket is displayed. A step to update,
Let
The second token bucket is a parent bucket that shares a token with the first token bucket.
program. The computer readable instructions, when executed by the one or more computing nodes, at least in the system,
Receiving information indicative of instructions to modify a database table on the one or more computing nodes;
Modifying the capacity allocated to the database table based on the received information indicative of instructions;
To do,
The program according to claim 10. The computer readable instructions, when executed by the one or more computing nodes, at least in the system,
Determining the subset of total capacity based at least in part on the number of partitions in the database table;
The program according to claim 11. The computer readable instructions, when executed by the one or more computing nodes, at least in the system,
Sending a user interface instruction to the customer including instructions for causing the customer to input,
The program according to claim 10.

Images