NZ621812B - Fair Scheduling For Mixed-Query Loads - Google Patents
Fair Scheduling For Mixed-Query LoadsInfo
- Publication number
- NZ621812B NZ621812B NZ621812A NZ62181214A NZ621812B NZ 621812 B NZ621812 B NZ 621812B NZ 621812 A NZ621812 A NZ 621812A NZ 62181214 A NZ62181214 A NZ 62181214A NZ 621812 B NZ621812 B NZ 621812B
- Authority
- NZ
- New Zealand
- Prior art keywords
- query
- job
- sub
- database management
- management system
- Prior art date
Links
- 230000004044 response Effects 0.000 claims description 5
- 101700083439 COL1 Proteins 0.000 claims 4
- 101700049353 COL2 Proteins 0.000 claims 4
- 238000000034 method Methods 0.000 description 35
- 230000000875 corresponding Effects 0.000 description 8
- 230000005540 biological transmission Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 6
- 230000000977 initiatory Effects 0.000 description 5
- 230000003287 optical Effects 0.000 description 5
- 238000007728 cost analysis Methods 0.000 description 2
- 235000003642 hunger Nutrition 0.000 description 2
- 230000002250 progressing Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000003068 static Effects 0.000 description 2
- 241001522296 Erithacus rubecula Species 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000001174 ascending Effects 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- RYGMFSIKBFXOCR-UHFFFAOYSA-N copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- 229910052802 copper Inorganic materials 0.000 description 1
- 239000010949 copper Substances 0.000 description 1
- 230000001808 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000002708 enhancing Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002452 interceptive Effects 0.000 description 1
- 230000037351 starvation Effects 0.000 description 1
- 235000010384 tocopherol Nutrition 0.000 description 1
- 230000001702 transmitter Effects 0.000 description 1
- 235000019731 tricalcium phosphate Nutrition 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24532—Query optimisation of parallel queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24535—Query rewriting; Transformation of sub-queries or views
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24542—Plan optimisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/951—Indexing; Web crawling techniques
Abstract
Disclosed is a computer-implemented method performed by one or more computing devices (100). The method includes obtaining a computer-executable query job and a cost estimate to execute the query job and, based on the cost estimate exceeding a threshold cost, determining to divide the query job into a plurality of computer-executable sub-query tasks. Each of the plurality of sub-query tasks is separately executed by a database management system (106). The database management system (106) initiates an execution of a first sub-query task of the plurality sub-query tasks, the first sub-query task including a result limiter that limits the number of results returned by the first subquery task. After the database management system (106) has finished executing the first sub-query task, a value of a last result returned is determined by the database management system (106) for the first sub-query task. The database management system (106) then initiates execution of a next sub-query task of the plurality of sub-query tasks, the next sub-query task including the determined value of the last result returned by the database management system (106) for the first sub-query task. a plurality of computer-executable sub-query tasks. Each of the plurality of sub-query tasks is separately executed by a database management system (106). The database management system (106) initiates an execution of a first sub-query task of the plurality sub-query tasks, the first sub-query task including a result limiter that limits the number of results returned by the first subquery task. After the database management system (106) has finished executing the first sub-query task, a value of a last result returned is determined by the database management system (106) for the first sub-query task. The database management system (106) then initiates execution of a next sub-query task of the plurality of sub-query tasks, the next sub-query task including the determined value of the last result returned by the database management system (106) for the first sub-query task.
Description
FAIR SCHEDULING FOR MIXED-QUERY LOADS
TECHNICAL FIELD
The present disclosure relates generally to scheduling computer-executable tasks for
execution by computing devices and, more specifically, to techniques for scheduling queries for
execution by database management systems.
BACKGROUND
Many database management systems are available to help users manage data. One
way such systems help users is to answer questions the users have about the data. In the context
of database management systems, questions are typically referred to as “queries” and answers
typically referred to as “results”. Users submit queries to database management systems and
receive answers to the queries in the form of results.
To answer queries, database management systems use computing resources such as
memory and processor resources. Different queries require different amounts of computing
resources to answer. For example, a query that returns 50,000 results may consume more
computing resources than one that returns 10 results.
Many database management systems have the ability to execute multiple queries at
the same time (i.e., concurrently). The process performed by a database management system of
determining the results of a query is often referred to as “executing” the query. Multiple queries
executed concurrently by a database management system can contend with each other for use of
the same computing resources. Many database management systems perform synchronization
and scheduling functions for the purpose of sharing computing resources amongst multiple
concurrent query executions.
Unfortunately, despite these synchronization and scheduling efforts, problems can
arise when database management systems execute multiple queries concurrently where some of
the queries are “high cost” queries and others are “low cost” queries. With this type of mixed
query-load, execution of the high cost queries can require use of so many computing resources
that they “starve” low cost queries of computing resources. The result may be that the database
management systems take a long amount of time to return answers to the low cost queries.
Overall, some database management systems handle mixed query loads in such a way that
latency of the low cost queries and the throughput of the query load are longer than users expect
them to be.
The approaches described in this section are approaches that could be pursued, but
not necessarily approaches that have been previously conceived or pursued. Therefore, unless
otherwise indicated, it should not be assumed that any of the approaches described in this section
qualify as prior art merely by virtue of their inclusion in this section.
[0006a] Mere reference to background art herein should not be construed as an admission that
such art constitutes common general knowledge in relation to the invention.
SUMMARY OF SOME EMBODIMENTS
[0006b] According to one aspect of the present invention, there is provided a computer-
implemented method performed by one or more computing devices, the method comprising:
obtaining a computer-executable query job and a cost estimate to execute the query job;
based on the cost estimate exceeding a threshold cost, determining to divide the query job
into a plurality of computer-executable sub-query tasks;
causing each of the plurality of sub-query tasks to be separately executed by a database
management system;
wherein causing each of the plurality of sub-query tasks to be separately executed by the
database management system includes:
causing the database management system to initiate execution of a first sub-query
task of the plurality sub-query tasks, the first sub-query task including a
result limiter that limits the number of results returned by the first sub-
query task;
after the database management system has finished executing the first sub-query
task, determining a value of a last result returned by the database
management system for the first sub-query task;
causing the database management system to initiate execution of a next sub-query
task of the plurality of sub-query tasks, the next sub-query task including
the determined value of the last result returned by the database
management system for the first sub-query task.
[0006c] According to another aspect of the present invention, there is provided one or more
computing devices comprising:
means for obtaining a computer-executable query job and a cost estimate to execute the
query job;
means for determining to divide the query job into a plurality of computer-executable
sub-query tasks based on the cost estimate exceeding a threshold cost;
means for causing each of the plurality of sub-query tasks to be separately executed by a
database management system;
wherein the means for causing each of the plurality of sub-query tasks to be separately
executed by the database management system comprises:
means for causing the database management system to initiate execution of a first
sub-query task of the plurality sub-query tasks, the first sub-query task
including a result limiter that limits the number of results returned by the
first sub-query task;
means for determining a value of a last result returned by the database
management system for the first sub-query task after the database
management system has finished executing the first sub-query task;
means for causing the database management system to initiate execution of a next
sub-query task of the plurality of sub-query tasks, the next sub-query task
including the determined value of the last result returned by the database
management system for the first sub-query task.
A fair scheduling system with methodology for scheduling queries for execution by a
database management system is described. In one embodiment, for example, a method is
described for scheduling a query job for execution by a database management system as
separately executable sub-query tasks. Each sub-query task can have a lower execution cost than
the execution cost of the query job as a whole. Further, each sub-query task can have the same or
approximately the same execution cost. The method may be performed multiply or concurrently
for multiple query jobs.
The method includes obtaining the query job and a cost estimate to execute the job.
As an example, the cost estimate may be a number of results the query job is expected to return.
The method further includes dividing the query job into a plurality of sub-query tasks
based on the cost estimate exceeding a predetermined threshold cost.
The method further includes enqueing a query job item representing the query job
onto the end (tail) of a job execution queue. When the query job item is enqueued, the job
execution queue can contain other previously enqueued query job items corresponding to
previously obtained query jobs.
After the query job item reaches the front (head) of the job execution queue which in
typical operation does not occur until all previously enqueued query job items have been
dequeued from the front of the job execution queue, the method further includes dequeing the
query job item from the front of the job execution queue.
After dequeing the query job item, the method initiates execution of the first sub-
query task of the query job by the database management system. After causing the database
management system to begin executing the first sub-query task of the query job, the method
determines whether there are more sub-query tasks of the query job to execute. If there are more
sub-query tasks to execute, then the method again enqueues the query job item onto the end of
the job execution queue. The dequeing of the query job item from the front of the job execution
queue, initiating execution of the next sub-query task of the query job, and enqueing the query
job item back onto the end of the job execution queue can be repeated until execution of all of
the sub-query tasks of the query job have been initiated.
If, after dequeing a query job item from the front of the job execution queue and
initiating execution of the last sub-query task, there are no more sub-query tasks to execute, then
the query job item is not enqueued again onto the end of the job execution queue.
In some embodiments, the method enforces a maximum number of query job items
that can be enqueued onto the job execution at the same time. In particular, a query job item for a
newly obtained query job is not enqueued onto the end of the job execution queue if the number
of query job items already in the job execution queue is at the maximum number. The query job
item is enqueued onto the job execution after an existing query job item is dequeued and the
method determines that there are no more sub-query tasks to execute for the query job
corresponding to the dequeued query job item. Since multiple query jobs can be obtained when
the number of query job items already in the job execution queue is at the maximum number, a
separate queue can be maintained to hold query job items for query jobs that are waiting to be
added to job execution queue. Enforcing the maximum number of query job items that can be
enqueued onto the job execution at the same time effectively limits the number of sub-query
tasks concurrently executed by the database management system and can avoid negatively
affecting throughput of query loads with a large number of high cost queries.
Further features of various embodiments of the invention, its nature and various
advantages will be more apparent from the accompanying drawings and the following detailed
description.
BRIEF DESCRIPTION OF THE DRAWINGS
is a block diagram illustrating a fair scheduling system, according to an
embodiment;
is a block diagram illustrating a possible database data model for storing
network access information, according to an embodiment;
and comprise a single flowchart illustrating operation of the fair
scheduling system according to an embodiment;
is a block diagram of a computer system upon which embodiments can be
implemented.
DETAILED DESCRIPTION
In the following description, for the purposes of explanation, numerous specific
details are set forth in order to provide a thorough understanding of the present invention. It will
be apparent, however, that the present invention may be practiced without these specific details.
In other instances, well-known structures and devices are shown in block diagram form in order
to avoid unnecessarily obscuring the present invention.
GENERAL OVERVIEW
Techniques are provided for fairly scheduling queries for execution by database
management systems. In one embodiment, the techniques involve obtaining a computer-
executable job and a cost estimate to execute the job. For example, the computer-executable job
can be a query and the cost estimate can be a number of results the query is expected to return.
Based on the cost estimate exceeding a threshold cost, the job is divided into a
sequence of computer-executable tasks. For example, if the query is expected to return 50,000
results and the threshold cost is 1,000 results, the query can be divided evenly into 50 sub-query
tasks each of which returns 1,000 results. The techniques further involve enqueing a job item
representing the job onto the end of a job execution queue. Other previously obtained jobs can be
similarly divided and job items representing those other jobs similarly previously enqueued onto
the end of the job execution queue.
After the job item for the job has reached the front of the job execution queue, the job
item is dequeued from the front of the job execution queue. After dequeing the job item, the
techniques further involve causing execution of the first task of the job to be initiated by a
database management system. After initiating execution of the first task, a determination is made
whether there are more tasks of the job to execute. If there are more tasks of the job to execute,
the job item for the job is re-enqueued onto the end of the job execution queue. If there are no
more tasks of the job to execute, then the job item is not re-enqueued. The dequeing, initiating
execution of the next task of the job, and re-enqueing of the job item repeats until all tasks of the
job have completed or the job is cancelled. The dequeing, initiating execution of the next task,
and re-enqueing can be similarly repeated for all job items in the job execution queue.
According to one aspect, the techniques involving dividing a query job into multiple
sub-query tasks where each sub-query task, when executed, returns a “page” of the results that
the query job would return if executed as a single task. For example, a query job that is expected
to return 50,000 results can be divided into 50 sub-query tasks where the first sub-query task
returns the first 1,000 results of the 50,000 results, the second sub-query task returns the next
1,000 results of the 50,000 results, etc. to the fiftieth sub-query task of that returns the last 1,000
results of the 50,000 results.
FAIR SCHEDULING SYSTEM
is a block diagram illustrating a fair scheduling system, according to an
embodiment. The system 100 includes one or more clients 102 operatively coupled to fair
scheduler 104. Fair scheduler 104 is operatively coupled to database management system 106
which is operatively coupled to database 108.
Clients 102 can be any set of one or more computing devices that submit query job
requests to fair scheduler 104. Examples of clients 102 include, but are not limited to, personal
computing devices, desktop computing devices, workstation computing devices, server
computing devices, mobile phones, tablets, laptops or any other phone or general-purpose
computing device that is executing software for submitting query job requests to fair scheduler
104. Clients 102 also may comprise processes or programs.
Clients 102 can be operated by users in which case the users can command clients
102 to submit query job requests to fair scheduler 104. Such commands can be caused by user
interactions with graphical user interfaces or command line interfaces, for example.
Alternatively, clients 102 can operate “unattended”. In this case, an automated process executing
on clients 102 can submit query job requests to fair scheduler 104. In addition, some clients 102
can be operated by users and other clients 102 can operate unattended. Thus, a mix of user-
operated and unattended clients 102 is possible. In some usage scenarios, multiple clients 102
submit multiple query job requests to the fair scheduler 104 at or about the same time.
Fair scheduler 104 can be any set of one or more computing devices configured to
perform any of the fair scheduling techniques described herein. Examples of fair scheduler 104
include, but are not limited to, personal computing devices, desktop computing devices,
workstation computing devices, server computing devices, or any other general-purpose
computing device that is executing software for performing any of the fair scheduling techniques
described herein.
Database management system 106 can be any set of one or more computing devices
used to execute queries against database 108. Examples of database management system 106
include, but are not limited to, personal computing devices, desktop computing devices,
workstation computing devices, server computing devices, or any other general-purpose
computing device that is executing database management software. The database management
software can be any database management software capable of supporting any of the fair
scheduling techniques disclosed herein. In one exemplary non-limiting embodiment, the database
management software is a version of Apache Cassandra. In another exemplary non-limiting
embodiment, the database management software is a version of Apache HBase.
Database 108 can be any set of one or more computing devices used to store data
against which the database management system 106 executes queries. Examples of database 108
include, but are not limited to, personal computing devices, desktop computing devices,
workstation computing devices, server computing devices, or any other general-purpose
computing device that is storing database data managed by database management system 106.
In some embodiments such as the embodiment of the clients 102, fair
scheduler 104, database management system 106, and database 108 are each separate sets of
computing devices. In other embodiments, one or more of clients 102, fair scheduler 104,
database management system 106, and database 108 are the same set of computing devices in
other embodiments. For example, client 102, fair scheduler 104, database management system
106, and database 108 can be the same computing device. Where more than one of clients 102,
fair scheduler 104, database management system 106, and database 108 are the same set of
computing devices, software components executing on the computing devices can execute as
part of the same process or the same set of processes or in different processes or different sets of
processes. For example, where the fair scheduler 104 and the database management system 106
are the same set of computing devices, software components for performing fair scheduling
techniques described herein and software components for executing queries against database 108
can execute as part of the same Java Virtual Machine (JVM) process or set of processes.
If executing in separate processes or separate sets of processes, software components
of clients 102, fair scheduler 104, and database management system 106 can communicate with
each other using any suitable inter-process communications mechanism including, but not
limited to, networking communications protocols such as, for example, Transmission Control
Protocol/Internet Protocol (TCP/IP). If executing in the same process, the software components
can communicate with each other through one or more Application Programming Interfaces
(APIs).
QUERY JOB REQUESTS
In an embodiment, clients 102 submit query job requests to the fair scheduler 104. A
query job request can contain values for query parameters and can contain a query execution cost
estimate, among other information. As discussed in greater detail below, the fair scheduler 104
can use the query parameter values and the cost estimate in the query job request when causing
sub-query tasks of query job to be executed by the database management system 106.
The query parameters can vary between different query jobs according to the
requirements of the implementation at hand. One non-limiting example of a query job is: get the
group of columns contained by a specified column family for a specified row of the column
family that satisfy a specified column name range predicate. An example of such a query job
expressed according a version of the Apache Cassandra Thrift API is:
get_slice("key" : key,
"column_parent" : {"column_family" : column_family},
"predicate" :
{ "slice_range" :
{ "start" : start_column_name,
"end" : end_column_name,
"reverse" : reverse,
"count" : count }
In the above-example query job, there are six query parameters: key,
column_family, start_column_name, end_column_name, reverse, and count.
Other query jobs may have more or less query parameters or different query parameters. In the
above-example query job, values for one or more of the six query parameters can be specified in
a query job request. Values for any other query parameters that are not specified in the query job
request can be provided by the fair scheduler. For example, a query job request can specify a
value for the key parameter and a value for the start_column_name parameter and the fair
scheduler 104 can provide values for the column_family, end_column_name, reverse,
and count query parameters, as just one example.
In the above-example query job, the value of the key query parameter uniquely
identifies a row in the column family specified by the value of the column_family parameter.
The columns of that row of that column family can be ordered by column name. The value of the
reverse parameter is a Boolean value. If the value of the reverse parameter is false, then
the column name range predicate of the above-example query job restricts results to columns
having a column name that is greater than or equal to the value of start_column_name
parameter and less than or equal to the value of the end_column_name parameter. If the value
of the reverse parameter is true, then the column name range predicate restricts results to
columns having a column name that is less than or equal to the value of
start_column_name parameter and greater than or equal to the value of the
end_column_name parameter. The value of the count parameter limits the number results to
the specified number of the columns that satisfy the column name range predicate.
EXAMPLE QUERY JOB REQUEST
For the purpose of providing clear examples, embodiments of the fair scheduling
techniques of the present disclosure are described hereinafter with respect to an example query
job request. However, the techniques are not limited to the example query job request.
The example query job request follows an example use case in which network access
information is stored in a column family of the database by network address of the accessing
network device and the time of the network access.
A possible data model 200 of a database 108 for storing the network access
information is illustrated in The data model 200 includes a column family 202. The
column family 202 contains one or more rows. Each row can be keyed by a unique key. For
example, key 204 can uniquely identify the first row of column family 202. Each row can
contain a set of zero or more ordered columns. Each column can have a name and a value.
Within a row, each column name can be unique. The columns of a row can be ordered by column
name according to an ordering scheme. Example ordering schemes include ASCII, UTF-8, Long,
UUID (lexical or time), date, a combination two or more of the foregoing ordering schemes, and
other ordering schemes. Different rows can have different numbers of columns. For example,
one row can have only one column and another row can have a billion or more columns.
Different column values may have different sizes. For example, one column value can be just a
few bytes in size while another column value can be 1 gigabyte or more in size.
For the use case of storing network access information, each key of the column
family 202 can be a network address. For example, key 204 may be an Internet Protocol (IP)
address such as “192.168.0.10”. The columns in a row of the column family 202 can store
information about network access involving the network address identified by the key of the row.
For example, each column of the row can correspond to a single network access event involving
the network address. For example, the name of the column within a row can be a unique
timestamp value (unique for a column name within the row) representing the date and time of the
network access event and the value of the column can be information about the network access
event such as information collected from network access logs, e-mail messages, call data records,
etc.
In a variation of on the example use case, each column of a row can correspond to
multiple network access events involving the network address. For example, the name of the
column within the row can be a unique timestamp value (unique for a column name within the
row) representing a range of time during which one or more network access events involving the
network address occurred. The name of the column can correspond to the starting time of the
range. Recalling that columns of a row can be stored in ascending order by column name, the
ending time of the range can be determined from the name of the next column in the row. The
value of the column can include one or more sub-values. The value can be variable length
encoded or otherwise encoded or compressed. Each sub-value can correspond to a single
network access event involving the network address. A sub-value corresponding to a network
access event can have three parts:
• An offset from the time in the column name. The time at which the corresponding
network access event occurred can be determined from the column name and the
offset;
• A pointer to a block of information containing information about one or more
network access events including the corresponding network address event. For
example, the pointer can be a key and a column name of another column family that
stores blocks of information about network access events.
• A sub-block identifier that identifies, within the block of information identified by the
pointer, sub-information about the corresponding network access event. For example,
the sub-block identifier can be a byte offset range or a line number range that
identifies the sub-information within the block of information.
Different query job requests can request different numbers of results. For example,
with the example use cases, the number of results returned can depend on the range of time
specified in the query job requests. For example, one query job request can request network
access information involving a specified network address for a range of time that spans days,
weeks, or months while another query job request can request network access information for a
range of time that spans minutes. The query job request for the larger span of time can return
tens of thousands of results or more while the query job request for the smaller span of time can
return only ten results of less. If the larger query job is executed by the database management
system 106 concurrently with the smaller query job, the latency of the smaller query job can be
negatively affected by the concurrent execution of the larger query job.
QUERY JOB COST ESTIMATE
As mentioned above, a query job request from a client 102 can include a cost estimate
for the database management system 106 to execute the query job. For example, the query job
request can specify the number of results the query job is expected to return. For example, for the
above example query job involving network access information, a query job request can specify
a number of columns that the query job is expected to return.
Alternatively, a query job request may not specify a query job cost estimate. In this
case, the fair scheduler 104 may generate a query cost estimate. Such estimate may be generated
in a number of different ways and the fair scheduler 104 is not limited to any particular way of
generating a query cost estimate. For example, the fair scheduler 104 may generate a query cost
estimate based on query parameters values specified in the query job request. For example, the
fair scheduler 104 may ask the database management system 106 for a cost estimate providing
the query parameter values for use by the database management system in generated the cost
estimate. The database management system may not completely execute the query job when
generating the estimate. The fair scheduler 104 may generate a query cost estimate in other ways
and embodiments are not limited to any particular way of generating a query cost estimate.
As yet another alternative, a final query cost estimate may be generated based on a
combination of a query cost estimate provided in a query job request and an preliminary query
cost estimate generated by the fair scheduler 104. The preliminary cost estimate may be
generated according to the approach in the previous paragraph, for example. For example, the
fair scheduler 104 may generate the final query cost estimate based on a mathematical
combination of the query cost estimate in the query job request and the preliminary query cost
estimate generated by the fair scheduler. This alternative can be performed by the fair scheduler
to reduce cost estimation errors relative the above approaches where only one of the query job
request or the fair scheduler 104 provides the cost estimate.
THRESHOLD COST
As indicated above, the query cost estimate for a query job is used by the fair
scheduler 104 to determine whether the query job should be broken down into separately
executable sub-query tasks. This determination can be made by comparing the query cost
estimate to a threshold cost. If the query cost estimate exceeds the threshold cost, then the fair
scheduler can cause the query job to be executed by the database management system 106 as
multiple sub-query tasks. If the query cost estimate is lower than the threshold cost, then the
query job can be executed as a single query task.
The threshold cost can be predefined. For example, a query job with a cost estimate
above 1,000 results can be broken up into multiple separately executable sub-query tasks. In this
case, if the cost estimate is at or below 1,000, the query job can be executed as a single task.
The threshold cost can be determined based on query execution metrics collected for
previously executed query jobs. Such metrics can include measured executions latencies of the
previously executed query jobs. Execution latency for a query job can be measured, for example,
as the time between:
• when the query job starts execution and when the first result of the query job is
returned,
• when the query job starts execution and when the last result of the query job is
returned,
• a mathematical combination of the above two execution latency metrics.
Query execution metrics collected for previously executed query jobs can also
include measured execution throughput. Measured execution throughput can be measured, for
example, as the number of query jobs that start and finish execution within a certain period of
time.
Collected query execution metrics can be used by the fair scheduler to adjust the
threshold cost on an ongoing basis.
DIVIDING QUERY JOBS
As mentioned above, the fair scheduler can divide the query job into multiple sub-
query tasks if the cost estimate for the query exceeds the threshold cost. In one approach, the fair
scheduler divides the query job evenly based on the cost estimate and the current threshold cost.
For example, if the cost estimate for a query job is 100,000 results and the current threshold cost
is 1,000 results, the fair scheduler can divide the query job into 100 sub-query tasks each
expected to return 1,000 results. By dividing each query job of a mixed-query load evenly, or
approximately evenly, as separately executable sub-query tasks that are executed in a round-
robin fashion through the job execution queue, the high cost query jobs of the mixed-load are
executed fairly with the low cost query jobs of the mixed-load thereby preventing the high cost
query jobs from starving the low cost query jobs for computing resources of the database
management system.
In other approaches, query jobs are divided unevenly. For example, a query job that
exceeds the threshold cost can be divided into multiple sub-query tasks where each successive
sub-query task is expected to return fewer and fewer results (or, alternatively, more and more
results).
PAGING QUERY RESULTS
The fair scheduler 104 can divide a query job into multiple sub-query tasks by using a
result limiter for each of the sub-query tasks. The result limiter limits the number of results that
the sub-query task returns when executed by the database management system 106. For example,
the count query parameter can be used in the following sub-query task to limit the number of
results returned when the sub-query task executed by the database management system 106 to at
most the specified number of results.
get_slice("key" : key,
"column_parent" : {"column_family" : column_family},
"predicate" :
{ "slice_range" :
{ "start" : start_column_name,
"end" : end_column_name,
"reverse" : reverse,
"count" : count }
If a sub-query task, when executed, actually returns the number of results specified as
the result limiter, then the fair scheduler 104 can determine that more results of the query job are
available. In this case, the fair scheduler 104 can configure the next sub-query task to get the
next set of results based on the last result returned by the previous sub-query task. For example,
given a threshold cost of 1,000 results and a query job request with a cost estimate of 10,000
results, the fair scheduler 104 can cause the database management system 106 to execute the
following sub-query task to obtain the first 1,000 results:
get_slice("key" : key,
"column_parent" : {"column_family" : column_family},
"predicate" :
{ "slice_range" :
{ "start" : start_column_name,
"end" : ‘’,
"reverse" : reverse,
"count" : 1000 }
In the above example sub-query task, the value ‘’ for the end sub-parameter
indicates to the database management system 106 that at most 1000 columns should be returned
from the row keyed by the value for the key parameter starting with the column in the row
having the name matching the value of the start_column_name parameter. If less than 1000
columns are returned by this sub-query task, then the query job is finished and no more sub-
query tasks need be executed for the query job. If this is the case, the query estimate of 10,000
columns was inaccurate by an order of magnitude. If, as expected, 1,000 columns are returned by
this sub-query tasks, then the next sub-query task for the query job can be configured based on
the name of the last column returned by the previous sub-query task. For example, assume the
parameter last_column_name holds as its value the name of the last column (e.g., the 1000
column) returned by the first sub-query task that returned the first 1,000 columns. The fair
scheduler 104 can cause the database management system to execute the following sub-query
task to obtain the next 1,000 results:
get_slice("key" : key,
"column_parent" : {"column_family" : column_family},
"predicate" :
{ "slice_range" :
{ "start" : last_column_name,
"end" : ‘’,
"reverse" : reverse,
"count" : 1001 }
Here, since name of the last column returned by the previous sub-query task is
provided as the value for the start parameter in this sub-query task, the first column returned
by this sub-query task will be the same as the last column returned by the previous sub-query
task. This is done to avoid inadvertently skipping columns between two consecutively executed
sub-query tasks for a query job. Accordingly, a value of 1001 is provided for the count
parameter to obtain the next 1,000 columns.
The above paging scheme assumes that the columns within a row are ordered by
column name and the names of the columns within the row are unique within the row. More
generally, the above paging scheme can be applied over a set of potential results in which each
potential result is ordered within the set by a unique value associated with the potential result.
METHOD OF OPERATION
The following description presents method steps that may be implemented using
computer-executable instructions, for directing operation of a device under processor control.
The computer-executable instructions may be stored on a computer-readable medium, such as
hard disk, CD, DVD, flash memory, or the like. The computer-executable instructions may also
be stored as a set of downloadable computer-executable instructions, for example, for
downloading and installation from an Internet location (e.g., Web server).
and comprise a single flowchart 300 illustrating overall operation of
the fair scheduling system, according to an embodiment. The method of operation starts at step
302, with the system obtaining a query job. How the system obtains the query job is not of
particular importance. For example, the system can obtain the query job in a query job request or
some other way. At a minimum the query job contains a specification of one or more query
parameters.
At step 304, the system obtains a cost estimate for the query job. As with the query
job, how the system obtains the cost estimate is not particularly important. For example, the cost
estimate may be specified in a query job request if the query job was obtained in a query job
request. As another example, the cost estimate may be obtained from a cost analysis of the query
job performed by the system. The cost analysis may be based on the query parameters specified
in the query job.
At step 306, the system obtains a threshold cost in some manner. The threshold cost
may be predetermined before step 302 (i.e., before the query job is obtained). Generally, a
threshold cost is selected so that high cost query jobs are broken down into multiple separately
executable lower cost sub-query tasks. If the threshold cost is too high, not enough high cost
query jobs may be broken down into multiple separately executable lower cost sub-query tasks
by the system thereby causing excessive starvation of concurrently executing low cost query jobs
for shared computing resources. If, on the other hand, the threshold cost is too low, low cost
query jobs may be unnecessarily broken down into multiple separately executable lower cost
sub-query tasks by the system thereby causing excessive latency for the low cost query jobs.
The threshold cost may be configured by an administrator of the system. During
operation, the system may dynamically adjust the threshold cost based on query workload
history. Such history may include query execution metrics for low cost and high cost query jobs.
Such query execution metrics can include latency and throughput of query jobs, among other
metrics.
At step 308, the system determines whether the obtained cost estimate exceeds (or
equals) the obtained threshold cost. If so, system determines (step 310) to divide the query job
into multiple separately executable sub-query tasks. The division may be based on the cost
estimate and the threshold cost. For example, the query job can be divided evenly into N sub-
query tasks where N is the ((cost estimate / threshold cost) + 1). In this case, the first N-1 tasks
would be expected to have equal execution cost. The Nth task would be expected to have at most
the execution cost of one of the first N-1 tasks. If the system determines that the obtained cost
estimate does not exceed (or equals) the obtained threshold cost, then the query job is not divided
and executed as a single query task.
Whether the query job is divided or not, at step 312, a job item representing the query
job is enqueued to the end of a job execution queue. The job execution queue holds up to M
number of job items where M represents the maximum number of query jobs that the system will
allow the database management system to concurrently execute query tasks for. Like the
threshold cost, the size of the job execution queue (e.g., the maximum number M of job items
allowed in the job execution queue at one time) may be predetermined and/or dynamically
adjusted based on query workload history. If the job execution queue has M job items in it when
a new query job is obtained at step 302 (i.e., the job execution queue is full), then the system
may block further processing of the new query job until an existing query job finishes execution
(e.g., until an existing query job is cancelled and the job item for the query job is removed from
the job execution queue or until all sub-query tasks of an existing query job have been executed
and the job item for the query is dequeued from the job execution queue). The system may
maintain another queue for ordering and tracking new query jobs that are obtained when the job
execution queue is full.
At step 314, the job item enqueued at step 312 is dequeued after the job item reaches
the front of the job execution queue. The job item will not reach the front of the job execution
queue until all job items closer to the front of the job execution queue have been dequeued or
removed from the job execution queue. Among other information, a job item representing a
query job enqueued onto the job execution queue may contain query job specification data such
as query parameters for the query job. The job item may also contain fair scheduling
bookkeeping data such as (a) the number of sub-query tasks the query job was divided into, if the
query job was divided at step 310, (b) a numerical result limiter to be used for all sub-query tasks
or per-sub-query tasks numerical result limiters, and (c) a paging value representing the last
result returned from the most recently completed sub-query task which can be used to configure
the next sub-query task.
At step 316, the system causes the next sub-query task to be executed by the database
management system. If the query job was not divided, the next sub-query task will be the only
query task executed for the query job. If the query job was divided, then the next sub-query task
is configured with a result limiter that limits the number of results returned by the database
management system.
At step 318, the system determines if there are more sub-query tasks of the query job
to execute. If so, the method returns to step 312 to re-enqueue the job item for the query job to
the end of the job execution queue. If, at step 318, there are no more sub-query tasks to execute,
then the query job is considered to be finished and the job item for the query job is not re-
enqueued to the end of the job execution queue.
Scheduling query jobs through the job execution may be performed by the system to
ensure a fair scheduling of mixed query loads. Through the system’s use of the job execution
queue, both high cost and low cost query jobs may be fairly and concurrently executed by the
database management system in a round-robin fashion.
CANCELLING A QUERY JOB
It may be the case that execution of a sub-query task for a query job by the database
management system is not progressing. For this or some other reason, a user of the fair
scheduling system may wish to cancel a currently executing query job. Accordingly, in some
embodiments, a request to the fair scheduling system to cancel a currently executing query job is
received. Upon receiving the cancel request, the fair scheduling system removes the job item
corresponding to the query job from the job execution queue. As a result, no further sub-query
tasks of query job will be executed. This cancellation may have no effect on execution of the
currently sub-query tasks
In some embodiments in which the database management system operates on
multiple computing nodes, the system re-submits a cancelled query job as a new query job with
the same query parameters but for execution on a different computing node than the computing
device that the cancelled query job was last executing on when cancelled. This is useful if the
reason the cancelled query job was not progressing was because of a problem particular to the
computing node on which the cancelled query job was last executing.
The cancellation request may be provided by a user through a graphical user interface
presented on the user’s personal computing device. For example, the user interface may present a
list of currently executing query jobs and associated interactive graphical user interface elements
for cancelling selected query jobs.
HARDWARE OVERVIEW
According to one embodiment, the techniques described herein are implemented by
one or more special-purpose computing devices. The special-purpose computing devices may be
hard-wired to perform the techniques, or may include digital electronic devices such as one or
more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs)
that are persistently programmed to perform the techniques, or may include one or more general
purpose hardware processors programmed to perform the techniques pursuant to program
instructions in firmware, memory, other storage, or a combination. Such special-purpose
computing devices may also combine custom hard-wired logic, ASICs, or FPGAs with custom
programming to accomplish the techniques. The special-purpose computing devices may be
desktop computer systems, portable computer systems, handheld devices, networking devices or
any other device that incorporates hard-wired and/or program logic to implement the techniques.
For example, is a block diagram that illustrates a computer system 400 upon
which an embodiment of the invention may be implemented. Computer system 400 includes a
bus 402 or other communication mechanism for communicating information, and a hardware
processor 404 coupled with bus 402 for processing information. Hardware processor 404 may
be, for example, a general purpose microprocessor.
Computer system 400 also includes a main memory 406, such as a random access
memory (RAM) or other dynamic storage device, coupled to bus 402 for storing information and
instructions to be executed by processor 404. Main memory 406 also may be used for storing
temporary variables or other intermediate information during execution of instructions to be
executed by processor 404. Such instructions, when stored in non-transitory storage media
accessible to processor 404, render computer system 400 into a special-purpose machine that is
customized to perform the operations specified in the instructions.
Computer system 400 further includes a read only memory (ROM) 408 or other static
storage device coupled to bus 402 for storing static information and instructions for processor
404. A storage device 410, such as a magnetic disk or optical disk, is provided and coupled to
bus 402 for storing information and instructions.
Computer system 400 may be coupled via bus 402 to a display 412, such as a cathode
ray tube (CRT), for displaying information to a computer user. An input device 414, including
alphanumeric and other keys, is coupled to bus 402 for communicating information and
command selections to processor 404. Another type of user input device is cursor control 416,
such as a mouse, a trackball, or cursor direction keys for communicating direction information
and command selections to processor 404 and for controlling cursor movement on display 412.
This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a
second axis (e.g., y), that allows the device to specify positions in a plane.
Computer system 400 may implement the techniques described herein using
customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic
which in combination with the computer system causes or programs computer system 400 to be a
special-purpose machine. According to one embodiment, the techniques herein are performed by
computer system 400 in response to processor 404 executing one or more sequences of one or
more instructions contained in main memory 406. Such instructions may be read into main
memory 406 from another storage medium, such as storage device 410. Execution of the
sequences of instructions contained in main memory 406 causes processor 404 to perform the
process steps described herein. In alternative embodiments, hard-wired circuitry may be used in
place of or in combination with software instructions.
The term “storage media” as used herein refers to any non-transitory media that store
data and/or instructions that cause a machine to operation in a specific fashion. Such storage
media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for
example, optical or magnetic disks, such as storage device 410. Volatile media includes dynamic
memory, such as main memory 406. Common forms of storage media include, for example, a
floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data
storage medium, a CD-ROM, any other optical data storage medium, any physical medium with
patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other
memory chip or cartridge.
Storage media is distinct from but may be used in conjunction with transmission
media. Transmission media participates in transferring information between storage media. For
example, transmission media includes coaxial cables, copper wire and fiber optics, including the
wires that comprise bus 402. Transmission media can also take the form of acoustic or light
waves, such as those generated during radio-wave and infra-red data communications.
Various forms of media may be involved in carrying one or more sequences of one or
more instructions to processor 404 for execution. For example, the instructions may initially be
carried on a magnetic disk or solid state drive of a remote computer. The remote computer can
load the instructions into its dynamic memory and send the instructions over a telephone line
using a modem. A modem local to computer system 400 can receive the data on the telephone
line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red
detector can receive the data carried in the infra-red signal and appropriate circuitry can place the
data on bus 402. Bus 402 carries the data to main memory 406, from which processor 404
retrieves and executes the instructions. The instructions received by main memory 406 may
optionally be stored on storage device 410 either before or after execution by processor 404.
Computer system 400 also includes a communication interface 418 coupled to bus
402. Communication interface 418 provides a two-way data communication coupling to a
network link 420 that is connected to a local network 422. For example, communication interface
418 may be an integrated services digital network (ISDN) card, cable modem, satellite modem,
or a modem to provide a data communication connection to a corresponding type of telephone
line. As another example, communication interface 418 may be a local area network (LAN) card
to provide a data communication connection to a compatible LAN. Wireless links may also be
implemented. In any such implementation, communication interface 418 sends and receives
electrical, electromagnetic or optical signals that carry digital data streams representing various
types of information.
Network link 420 typically provides data communication through one or more
networks to other data devices. For example, network link 420 may provide a connection through
local network 422 to a host computer 424 or to data equipment operated by an Internet Service
Provider (ISP) 426. ISP 426 in turn provides data communication services through the world
wide packet data communication network now commonly referred to as the “Internet” 428. Local
network 422 and Internet 428 both use electrical, electromagnetic or optical signals that carry
digital data streams. The signals through the various networks and the signals on network link
420 and through communication interface 418, which carry the digital data to and from computer
system 400, are example forms of transmission media.
Computer system 400 can send messages and receive data, including program code,
through the network(s), network link 420 and communication interface 418. In the Internet
example, a server 430 might transmit a requested code for an application program through
Internet 428, ISP 426, local network 422 and communication interface 418.
The received code may be executed by processor 404 as it is received, and/or stored
in storage device 410, or other non-volatile storage for later execution.
In the foregoing specification, embodiments of the invention have been described
with reference to numerous specific details that may vary from implementation to
implementation. The specification and drawings are, accordingly, to be regarded in an illustrative
rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and
what is intended by the applicants to be the scope of the invention, is the literal and equivalent
scope of the set of claims that issue from this application, in the specific form in which such
claims issue, including any subsequent correction.
Throughout this specification, including the claims, where the context permits, the
term “comprise” and variants thereof such as “comprises” or “comprising” are to be interpreted
as including the stated integer or integers without necessarily excluding any other integers.
Claims (13)
1. A computer-implemented method performed by one or more computing devices, the method comprising: obtaining a computer-executable query job and a cost estimate to execute the query job; based on the cost estimate exceeding a threshold cost, determining to divide the query job into a plurality of computer-executable sub-query tasks; causing each of the plurality of sub-query tasks to be separately executed by a database management system; wherein causing each of the plurality of sub-query tasks to be separately executed by the database management system includes: causing the database management system to initiate execution of a first sub-query task of the plurality sub-query tasks, the first sub-query task including a result limiter that limits the number of results returned by the first sub- query task; after the database management system has finished executing the first sub-query task, determining a value of a last result returned by the database management system for the first sub-query task; causing the database management system to initiate execution of a next sub-query task of the plurality of sub-query tasks, the next sub-query task including the determined value of the last result returned by the database management system for the first sub-query task.
2. The method of Claim 1 wherein causing each of the plurality of sub-query tasks to be separately executed by the database management system includes: enqueing a job item representing the query job onto the end of a job execution queue having a front and an end; dequeing the job item after the job item has reached the front of the job execution queue; after dequeing the job item, causing the database management system to initiate execution of a first sub-query task of the plurality sub-query tasks; after dequeing the job item, determining whether there are more sub-query tasks of the plurality of sub-query tasks to execute; in response to determining that there are more sub-query tasks of the plurality of sub- query tasks to execute, re-enqueing the job item onto the end of the job execution queue.
3. The method of Claim 1 wherein the cost estimate is a number of results the query is expected to return.
4. The method of Claim 1 further comprising: in response to receiving a request to cancel the query job, removing a job item representing the query job from a job execution queue.
5. The method of Claim 1 further comprising: at a first time, removing a job item representing a first query job from a job execution queue having a front and an end; wherein, at the first time, a sub-query task of the first query job is executing on a first node of the database management system; at a second time that is after the first time: generating a second query job based on the first query job, enqueing a job item representing the second query job onto the end of the job execution queue, and causing the database management system to initiate execution of a first sub-query task of the second query job on a second node of the database management system that is not the first node.
6. The method of Claim 1 further comprising: detecting a job execution queue, having a front and an end, is full; and enqueing a job item representing the query job onto the end of the job execution queue after the job execution queue is no longer full.
7. One or more computer-readable media storing instructions which, when executed by one or more computing devices, causes performance of a method as recited in any one of Claims 1-6.
8. One or more computing devices comprising: means for obtaining a computer-executable query job and a cost estimate to execute the query job; means for determining to divide the query job into a plurality of computer-executable sub-query tasks based on the cost estimate exceeding a threshold cost; means for causing each of the plurality of sub-query tasks to be separately executed by a database management system; wherein the means for causing each of the plurality of sub-query tasks to be separately executed by the database management system comprises: means for causing the database management system to initiate execution of a first sub-query task of the plurality sub-query tasks, the first sub-query task including a result limiter that limits the number of results returned by the first sub-query task; means for determining a value of a last result returned by the database management system for the first sub-query task after the database management system has finished executing the first sub-query task; means for causing the database management system to initiate execution of a next sub-query task of the plurality of sub-query tasks, the next sub-query task including the determined value of the last result returned by the database management system for the first sub-query task.
9. The one or more computing devices of Claim 8 wherein the means for causing each of the plurality of sub-query tasks to be separately executed by the database management system comprises: means for enqueing a job item representing the query job onto the end of a job execution queue having a front and an end; means for dequeing the job item after the job item has reached the front of the job execution queue; means for causing the database management system to initiate execution of a first sub- query task of the plurality sub-query tasks after dequeing the job item; means for determining whether there are more sub-query tasks of the plurality of sub- query tasks to execute after dequeing the job item; means for re-enqueing the job item onto the end of the job execution queue in response to determining that there are more sub-query tasks of the plurality of sub-query tasks to execute.
10. The one or more computing devices of Claim 8 wherein the cost estimate is a number of results the query is expected to return.
11. The one or more computing devices of Claim 8 further comprising: means for removing a job item representing the query job from a job execution queue in response to receiving a request to cancel the query job.
12. The one or more computing devices of Claim 8 further comprising: means for removing, at a first time, a job item representing a first query job from a job execution queue having a front and an end; wherein, at the first time, a sub-query task of the first query job is executing on a first node of the database management system; means for generating, at a second time that is after the first time, a second query job based on the first query job; means for enqueing, at the second time that is after the first time, a job item representing the second query job onto the end of the job execution queue, and means for causing, at the second time that is after the first time, the database management system to initiate execution of a first sub-query task of the second query job on a second node of the database management system that is not the first node.
13. The one or more computing devices of Claim 8 further comprising: means for detecting a job execution queue, having a front and an end, is full; and means for enqueing a job item representing the query job onto the end of the job execution queue after the job execution queue is no longer full. key1 col1, col2, col3, ... , colm key2 col1, col2, col3, ... , colx key3 col1, col2, col3, ... , coly keyn col1, col2, col3, ... , colz START OBTAIN QUERY JOB OBTAIN COST ESTIMATE OBTAIN THRESHOLD COST COST ESTIMATE THRESHOLD COST? DIVIDE QUERY JOB FROM ENQUEUE JOB ITEM DEQUEUE JOB ITEM INITIATE NEXT TASK MORE TASKS?
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/826,228 | 2013-03-14 | ||
US13/826,228 US9092482B2 (en) | 2013-03-14 | 2013-03-14 | Fair scheduling for mixed-query loads |
Publications (2)
Publication Number | Publication Date |
---|---|
NZ621812A NZ621812A (en) | 2014-07-25 |
NZ621812B true NZ621812B (en) | 2014-10-29 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10817513B2 (en) | Fair scheduling for mixed-query loads | |
US11153371B2 (en) | Systems and techniques for utilizing resource aware queues and/or service sharing in a multi-server environment | |
US7415470B2 (en) | Capturing and re-creating the state of a queue when migrating a session | |
WO2018108001A1 (en) | System and method to handle events using historical data in serverless systems | |
US11586585B2 (en) | Method and system for historical call lookup in distributed file systems | |
US20200310881A1 (en) | Systems and methods for automatically scaling compute resources based on demand | |
US11681829B2 (en) | Approaches for managing restrictions for middleware applications | |
KR101604303B1 (en) | Apparatus and Method for Executing Update and Recording Medium Using the Same, Server and Method for Providing Update | |
CN111858586B (en) | Data processing method and device | |
US11321135B2 (en) | Rate limiting compliance assessments with multi-layer fair share scheduling | |
NZ621812B (en) | Fair Scheduling For Mixed-Query Loads | |
EP3657331B1 (en) | Module assignment management | |
US9172729B2 (en) | Managing message distribution in a networked environment | |
US8805899B2 (en) | Data channel utilization management in multi-user system | |
US10140150B2 (en) | Thread diversion awaiting log call return | |
US20120124078A1 (en) | Ruleset implementation for memory starved systems | |
CN114003382A (en) | Index construction method, device and equipment | |
CN113722313A (en) | Data write request processing method, device, equipment and computer readable medium | |
WO2023211813A1 (en) | Dynamic script generation for distributed query execution and aggregation |