CN114168306B

CN114168306B - Scheduling method and scheduling device

Info

Publication number: CN114168306B
Application number: CN202210126013.8A
Authority: CN
Inventors: 孙坚运; 赵裕众
Original assignee: Beijing Oceanbase Technology Co Ltd
Current assignee: Beijing Oceanbase Technology Co Ltd
Priority date: 2022-02-10
Filing date: 2022-02-10
Publication date: 2022-05-17
Anticipated expiration: 2042-02-10
Also published as: CN114168306A

Abstract

The present disclosure provides a scheduling method and a scheduling apparatus, the method is applied to a database with a plurality of tenants, and the method includes: receiving a plurality of IO requests sent by a plurality of tenants; determining first timestamps of a plurality of IO requests based on a category clock, wherein the category clock is used for limiting disk resources used by different categories of IO requests in one tenant; determining second timestamps of the plurality of IO requests based on a first clock, wherein the first clock is used for limiting disk resources used by the IO requests of different tenants; selecting an IO request to be scheduled from the plurality of IO requests according to the first time stamp and the second time stamp; and scheduling the IO request to be scheduled. According to the method and the device, the class clock is added on the basis of the first clock, so that one IO request only needs to be scheduled once, the isolation of the disk resources among tenants and the disk resources among the class IOs can be realized simultaneously, and the refined control of the disk resources is realized.

Description

Scheduling method and scheduling device

Technical Field

The present disclosure relates to the field of resource management technologies, and in particular, to a scheduling method and a scheduling apparatus.

Background

For the multi-tenant database, some resource isolation algorithms (such as mclock algorithm) need to be used for isolating the disk resources among the tenants. However, there are multiple types of IO requests in a tenant, and in order to control the disk resources more finely, the disk resources used by IO requests of different types need to be limited.

If the mclock algorithm is cascaded, although the disk resource used by an input/output (IO) request may be limited, this approach needs to schedule the IO request twice, which may increase the Central Processing Unit (CPU) overhead of scheduling and the response time of the IO request.

Disclosure of Invention

The present disclosure provides a scheduling method and a scheduling apparatus, which can reduce the CPU overhead and the response time of an IO request.

In a first aspect, a scheduling method is provided, which is applied to a database having a plurality of tenants, and includes: receiving a plurality of IO requests sent by the plurality of tenants; determining first timestamps of the plurality of IO requests based on a category clock, wherein the category clock is used for limiting disk resources used by different categories of IO requests in one tenant; determining second timestamps of the plurality of IO requests based on a first clock, wherein the first clock is used for limiting disk resources used by IO requests of different tenants; selecting an IO request to be scheduled from the plurality of IO requests according to the first time stamp and the second time stamp; and scheduling the IO request to be scheduled.

In a possible implementation manner, the class clock is used to limit the maximum disk resources used by IO requests of different classes, the first clock is an upper limit clock in an mclock algorithm, and the IO request to be scheduled is an IO request whose first timestamp and the second timestamp are both less than the current time.

In one possible implementation manner, the size of the class clock of the IO requests of different classes in one tenant is smaller than or equal to the size of the upper limit clock of the one tenant.

In one possible implementation, the method further includes: determining a third timestamp of the IO request to be scheduled based on a weight clock, wherein the weight clock is used for indicating weights of different classes of IO requests in one tenant; the scheduling the IO request to be scheduled includes: determining a scheduling sequence of the IO requests to be scheduled based on the size of the third timestamp; and scheduling the IO requests to be scheduled in sequence according to the scheduling sequence.

In one possible implementation, the categories of the IO requests include a foreground IO request and a background IO request.

In a second aspect, a scheduling apparatus is provided, which is applied to a database having a plurality of tenants, and includes: the receiving module is used for receiving a plurality of IO requests sent by the plurality of tenants; a first determining module, configured to determine first timestamps of the plurality of IO requests based on a category clock, where the category clock is used to limit disk resources used by IO requests of different categories in one tenant; a second determining module, configured to determine second timestamps of the plurality of IO requests based on a first clock, where the first clock is used to limit disk resources used by IO requests of different tenants; a selecting module, configured to select an IO request to be scheduled from the plurality of IO requests according to the first timestamp and the second timestamp; and the scheduling module is used for scheduling the IO request to be scheduled.

In one possible implementation, the apparatus further includes: a third determining module, configured to determine a third timestamp of the IO request to be scheduled based on a weight clock, where the weight clock is used to indicate weights of IO requests of different classes in one tenant; the scheduling module is to: determining a scheduling sequence of the IO requests to be scheduled based on the size of the third timestamp; and scheduling the IO requests to be scheduled in sequence according to the scheduling sequence.

In a third aspect, a scheduling apparatus is provided, which includes a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor implements the method as described in the first aspect or any possible implementation manner of the first aspect when executing the computer program.

In a fourth aspect, there is provided a computer readable storage medium having stored thereon executable code that, when executed, is capable of implementing a method as described in the first aspect or any one of the possible implementations of the first aspect.

A fifth aspect provides a computer program product comprising executable code that, when executed, is capable of implementing a method as described in the first aspect or any possible implementation manner of the first aspect.

According to the method and the device, the class clock is added on the basis of the first clock, and the class clock is used for limiting the disk resources used by the multiple class IO requests. The class clock is used for determining the first timestamp, the first clock is used for determining the second timestamp, and the IO request to be scheduled is determined based on the first timestamp and the second timestamp, that is to say, when the disk resource used by the tenant is limited through the first clock, the disk resource used by the class IO is limited, so that one IO request only needs to be scheduled once, the isolation of the disk resource between the tenants and the isolation of the disk resource between the class IOs can be realized simultaneously, and the refined control of the disk resource is realized.

Drawings

Fig. 1 is a schematic structural diagram of an LSM tree provided in an embodiment of the present disclosure.

Fig. 2 is a schematic structural diagram of a scheduling system based on a mclock algorithm according to an embodiment of the present disclosure.

Fig. 3 is a schematic diagram illustrating adjustment of a timestamp of an IO request according to an embodiment of the present disclosure.

Fig. 4 is a schematic flow chart of a scheduling method provided by an embodiment of the present disclosure.

Fig. 5 is a schematic diagram of scheduling a class IO request according to an embodiment of the present disclosure.

Fig. 6 is a schematic structural diagram of a scheduling apparatus according to an embodiment of the present disclosure.

Fig. 7 is a schematic structural diagram of another scheduling apparatus provided in the embodiment of the present disclosure.

Detailed Description

Technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings of the embodiments of the present disclosure, and it is obvious that the described embodiments are only a part of the embodiments of the present disclosure, and not all of the embodiments.

The big data era generates massive and diversified information assets, and higher requirements are put forward on the data storage and data management capacity. The data may be records used in computers to characterize things, such as text, graphics, images, sounds, etc. The data can have various expression forms, and can be stored in a computer after being digitalized. A database may be a collection of data stored on a computer storage device that may hold data that is the object and result of database system operations.

Database systems may include databases, database management systems, application systems, database administrators and users, and the like. A database management system may be the core of an overall database system, which may be data management software that helps users build, use, and manage databases. The database management system can also be used to maintain the database and ensure the security and integrity of the data. The user may be the ultimate use entity of the database, which in some embodiments may be used by the user through a user interface of the application system.

The storage engine of the database may be the underlying software organization of the database, and the database management system uses the data engine to create, query, update, and delete data. Taking a query as an example, a user may send a query request to a database, and the database may query, based on the query request of the user, data corresponding to the query request in the database, and then send the queried data to the user.

Currently, a storage engine of a mainstream database adopts a storage architecture based on a log-structured merge Tree (LSM-Tree). The LSM-Tree is called LSM Tree for short, the LSM Tree can store data in a multi-layer structure, the LSM Tree releases storage space through dumping and combining, and the reading and writing performance of a database system is improved.

An LSM tree may include two or more separate storage structures, each optimized for its respective underlying storage medium, so that data may be efficiently and massively synchronized between the two structures. For ease of understanding, the overall architecture of the LSM tree referred to in the embodiments of the present disclosure is described below in conjunction with fig. 1.

Such as the simplest two storage structures used for ease of illustration in this disclosure. As shown in FIG. 1, a storage structure resides in memory, stores all recently written key-value pairs, and can be updated in place at any time while supporting queries at any time. The other storage structure resides in a non-volatile storage device, which may be, for example, a hard disk or magnetic disk. The LSM tree includes a multi-Level structure for storing data, which may be represented by, for example, a plurality of levels from Level 0 to Level N, where Level N is the last Level in the multi-Level structure. The storage capacity of the LSM tree gradually increases from Level 0 to Level N, and the capacity of each layer is generally 10 times that of the previous layer. Each layer may include one or more ordered Sequence tables (SSTs), an SST being a persistent, ordered, and immutable key-value store structure whose keys and values are arbitrary arrays of bytes. The data inside each SST file is ordered on a key, and the data at each level is globally ordered on a key. That is, keys in different SST files do not overlap each other in the same hierarchy. However, Level 0 layers may overlap. That is, Level 0 only guarantees the internal order of each SST file, and multiple SST files in the same layer may overlap, which is determined by the construction mechanism of the LSM tree, and this disclosure is not set forth in detail herein.

In the storage system based on the LSM tree, as data in the memory is continuously and sequentially additionally written, layers with data ranges overlapped with each other are more and more, and data of the same key is continuously accumulated, thereby causing degradation of reading performance and expansion of space. Therefore, a merge (compact) mechanism is introduced to optimize the read performance and space issues by merging multiple layers by continually merging or deleting data.

The merging of the data may be performed in the memory, and after the merging of the data is completed, the LSM tree may write the merged data to the disk. The merging of data is performed in the background, and therefore, the IO in the data merging process is also referred to as background IO.

A tenant may be a logical concept that owns a set of resources in a database system. The resources may be, for example, resources such as a CPU, a memory, a network bandwidth, a disk space, a disk bandwidth, and an IO per second (IOPS) of a disk, and the resources may be used by a plurality of users. That is, a tenant may be a collection of database functions having several soft and hard resources, and a user may use the database through the tenant. One tenant may have one or more users, and a user may belong to different tenants.

A database can have a plurality of tenants, and the plurality of tenants can be completely isolated. A Database with multiple tenants may also be referred to as a multi-tenant Database, which may be, for example, an Oracle Database (Database), or a VMWare Hypervisor Database, or an OceanBase Database, etc. In the aspect of data security, the data assets of the user can be ensured not to be leaked in a mode of not allowing data access across tenants.

In order to realize resource isolation between tenants, the related art provides two schemes. One is a schema of Oracle Pluggable Database (PDB), and the other is mclock algorithm proposed by VMWare. These two ways are described below.

Oracle

A plurality of sub-databases in Oracle are arranged in a super database, which is also called a multi-tenant database, and is referred to as a container database (CBD) for short. The sub-database is also called pluggable database, PDB for short. The PDB in Oracle is equivalent to a tenant in the embodiments of the present disclosure.

When there are multiple PDBs in a CBD, if a certain PDB generates a large number of disk IOs, it is likely to affect other PDBs. To avoid the influence between PDBs, Oracle limits the number of IO requests generated by a PDB per second by using a MAX _ IOPS parameter, and limits how many megabytes of IO requests are generated by the PDB per second by setting MAX _ MBPS. Therefore, the limitation of the disk resources available to the tenant can be reached by the MAX _ IOPS and MAX _ MBPS parameters.

mclock algorithm

The mclock algorithm can be used for isolating the disk bandwidths of a plurality of virtual machines and allowing one virtual machine to maximally utilize the disk bandwidths of all host machines when other virtual machines are idle. The virtual machine in the mclock algorithm is equivalent to the tenant in the embodiment of the present disclosure. For convenience of description, the following description is made by taking a tenant as an example.

The mclock algorithm includes pseudo code as follows:

Max_QueueDepth = 32;

(request r, time t, vmvi)

Begin

if vi was idle then

/* Tag Adjustment */

minPtag= minimum of all P tags;

foreach active VM v _j do

/* Tag Assignment */

ScheduleRequest();

End

()

Begin

Active_IOs≥ Max_QueueDepththen

return;

Let Ebe the set of requests with R tag ≤ t

if E not empty then

/* constraint-based scheduling */

select IO request with minimum R tag from

E

else

/* weight-based scheduling */

Let E’ be the set of requests with L tag ≤ t

E’not empty OR Active_IOs == 0 then

select IO request with minimum P tag

from E’

/* Assuming request belong to VM v _k */

Subtract 1/r _kfrom R tags of VM v _k

if IO request selected != NULL then

Active_IOs++;

End

(request r, vmv _i)

Active_IOs-- ;

ScheduleRequest();

the most critical of the mclock algorithm is three clocks, namely a reserved clock (Reservation), an upper limit clock (Limitation) and a weight clock (contribution). The Reservation is used to limit the minimum bandwidth resource used by the tenant, that is, the bandwidth resource allocated to the tenant cannot be lower than the reserved resource. And the Limitation is used for limiting the maximum bandwidth resource used by the tenant, namely the bandwidth resource allocated to the tenant cannot exceed the maximum bandwidth resource. And the Proport is used for indicating the weight of each tenant. When resource allocation is carried out, the mclock algorithm allocates bandwidth resources to the tenants as much as possible according to the weight proportion of the tenants.

The purpose of the mclock algorithm is: and the reserved resource requirements of each tenant are preferentially ensured, then the rest resources are distributed according to the weight proportion, and the resources distributed to each tenant cannot exceed the corresponding maximum resources. The principle of the mclock algorithm is described below in conjunction with fig. 2.

As shown in fig. 2, IO requests sent by multiple tenants 210 to the database need to be scheduled by mclock 220. After mclock220 receives the IO requests, each IO request may be time stamped. The mclock shown in fig. 2 can be understood as a scheduler. The mclock may determine the scheduling order of the IO requests according to the timestamps of the IO requests. Each IO request may include three timestamps (or tags), which are: a timestamp corresponding to Reservation (abbreviated timestamp R), a timestamp corresponding to Limitation (abbreviated timestamp L), and a timestamp corresponding to delivery (abbreviated timestamp P).

The calculation formula of each time stamp is as follows:

wherein,

a timestamp R representing the R-th request of the ith tenant,

a timestamp L representing the r-th request of the ith tenant,

a timestamp P representing the r-th request of the ith tenant.r _iThe Reservation clock (or parameter) representing tenant i,l _ithe limit clock of the tenant i is represented,w _irepresenting the Proport clock of the tenant. t represents the current time. It can be understood that the timestamp R and the timestamp L of the first IO request are both the current time, i.e. the time when the IO request arrives.

r _iThe larger the resources reserved for tenant i;r _ithe smaller the resource reserved for tenant i, the less.l _iThe larger the bandwidth, the larger the maximum bandwidth resource representing tenant i;l _ithe smaller the maximum bandwidth resource representing tenant i.w _iThe larger the weight representing tenant i is;w _ithe smaller the weight representing tenant i.

Taking the timestamp R as an example, for tenant i, the timestamp R of an IO request is the timestamp R of the last IO request plus 1 ≧ greaterr _iAnd the maximum value between the current time t. The current time t here can be understood as the time when the IO request arrives.

This is based on two theories: one is to expect an IO request to be based on 1r _iThe interval of (2) is processed, and second, no compensation is given when the tenant is idle. When a certain tenant becomes idle, namely the request of the certain tenant is greater than 1 ≧r _iThe time stamp R of the incoming IO request is the current time. In this way, when the reserved resource set for a certain tenant is not used, the resource can be allocated to other tenants for use, that is, when other tenants are idle, the tenant can maximally utilize the disk bandwidth resource.

Similarly, time stamp P and time stamp L are arranged in a similar manner as time stamp R. However, there is some difference in the time stamp P. For timestamp P, since it is a relative value (no units), we expect timestamp P to always be based on 1 +w _iThe spacing is performed. However, when a tenant becomes active from idle, its timestamp P is no longer linear with time. Especially, when a new tenant arrives, the timestamps of the two are no longer the same reference point, and the alignment process for the timestamp P is required. The mclock algorithm corrects by the smallest timestamp P difference from the current time. Specifically, when a new IO request arrives for a certain idle tenant, the difference between the minimum timestamp P and the current time t is calculated, and then the timestamps P of all IO requests are updated, and the pseudo codes thereof are as follows:

(request r, time t, vmvi)

Begin

if vi was idle then

/* Tag Adjustment */

minPtag= minimum of all P tags;

foreach active VM v _j do

timestamp L is calculated in a similar manner as timestamp P. The timestamp L serves to limit the number of IO requests scheduled in the P-scheduling phase. And when the timestamp L is less than the current time, the number of completed IO requests does not reach the number of IO requests limited by the Limitation. Conversely, when the timestamp L is greater than the current time, it indicates that the number of IO requests limited by Limitation has been reached.

The scheduling process of the IO request is described below. The scheduling process of the IO request is divided into two stages, which are respectively: a Constraint-based phase (otherwise known as an R-scheduled phase) and a Weight-based phase (otherwise known as a P-scheduled phase). An IO request is scheduled either in the R scheduling phase or in the P scheduling phase. First, mclock starts scheduling from the R scheduling phase and then from the P scheduling phase each time. These two stages will be described separately below.

In the R scheduling stage, mclock firstly checks whether the Reservation queue has an IO request, if so, the IO request of the Reservation queue is firstly processed until the time stamp R of each tenant is larger than the current time. The IO request in the Reservation queue is an IO request with a timestamp R less than or equal to the current time. That is, in the R scheduling phase, mclock selects an IO request with a timestamp R smaller than the current time from the plurality of IO requests for scheduling. And if the time stamp R of the IO request of each tenant is larger than the current time, finishing the R scheduling phase. The timestamp R indicates the time the IO request should be scheduled as per the reserved resource requirements. If the timestamp R of the IO request is greater than the current time, it indicates that the IO request has not reached the scheduling time. It should be noted that, in the scheduling phase, the current time refers to the time when the database performs IO scheduling.

And entering a P scheduling stage after the R scheduling stage is finished. In the P-dispatch phase, an IO request with a timestamp L less than or equal to the current time may be selected first by the mclock. Then, mclock may determine a scheduling order of the selected IO requests (i.e., an order of the timestamps P from large to small) according to the size of the timestamp P, and schedule the selected IO requests according to the scheduling order. That is, in the P scheduling phase, the mclock algorithm may schedule according to the size of the timestamp P, and preferentially schedule the IO request with the smallest timestamp P until the timestamp L of each tenant is greater than the current time.

In addition, in the P scheduling phase, after each IO request is scheduled, the timestamps R of all the requests need to be adjusted.

As shown in fig. 3, fig. 3 illustrates a process in which IO requests of tenant 1 are scheduled. In the P scheduling phase, after IO request 2 is scheduled, the timestamp R is vacant, and for the IO request of tenant 1, the timestamps R of two adjacent IO requests (i.e. IO request 1 and IO request 3) jump from 1/R to 3/R directly. If the timestamp R is not adjusted, the tenant's Reservation requirement will not be satisfied. Therefore, the time stamp R needs to be shifted forward, and 1/R is subtracted from the time stamps R of the IO request 3 and the IO request 4, that is, the time stamp R of the IO request 3 becomes 2/R and the time stamp R of the IO request 4 becomes 3/R.

In the P scheduling stage, IO requests of each tenant can be scheduled according to the weight proportion, and when disk resources of some tenants are idle, namely the tenants have no IO requests, other tenants can maximally utilize the idle resources of the disk.

The IO requests may include different classes of IO requests. The IO requests of different classes are also referred to as class IO, and the class IO may refer to IO requests of different service classes sent by the tenant in different service scenarios. The category IOs may include foreground IOs and background IOs. Foreground IO may refer to an IO request triggered by a user. The foreground IO may be, for example, an IO request for reading a data disk triggered by a query request of a user. Background IO may refer to IO requests triggered by a background task. The background IO may be, for example, an IO request to write data to a disk triggered by SSTable merge task as described above.

Although the Oracle PDB and mclock schemes described above can implement resource isolation between tenants, different types of IO requests may exist in one tenant, and currently, no related technology can isolate resources of IO requests of different types.

The scheme of Oracle PDB utilizes MAX _ IOPS and MAX _ MBPS parameters to implement resource isolation for tenant IO requests, but these two parameters do not limit writing of redo log (redo log) (log writer, LGWR) process) and writing of buffer cache (buffer cache) dirty block to disk (database writer, DBWR) process). This is equivalent to that the Oracle PDB only limits the resources of foreground IO of each tenant, and does not limit the resources of background IO. That is, the Oracle approach does not uniformly control the bandwidth of all types of IO requests, and the control is not fine enough. In addition, Oracle only limits the maximum disk bandwidth that cannot be exceeded, without the semantics of reserved resources, which may cause some kind of reasonable IO requests to be starved.

The mclock algorithm can isolate the disk bandwidths of multiple tenants, and allows one tenant to maximally utilize the disk bandwidths of all hosts when other tenants are idle. However, the mclock algorithm no longer distinguishes the disk bandwidth for different classes of IO requests in tenants. If the mclock algorithm is applied again in the tenant, the bandwidth isolation of IO requests of different categories can also be realized, however, this nested scheduling manner results in that one IO request performs scheduling twice, which wastes CPU resources and increases Response Time (RT).

Based on this, the embodiments of the present disclosure provide a scheduling method, which increases a category clock, so that, while tenant resource limitation is performed, category IO resources are also limited. For example, the embodiments of the present disclosure may add the category clock on the basis of the mclock algorithm, i.e., on the basis of three clocks of redundancy, Limitation, and reporting. The class clock may be used to limit disk resources used by IO requests of different classes. For example, the class clock may be used to limit the minimum disk resources used by IO requests of different classes. In this case, the class clock may be used to guarantee the minimum resource requirements for a certain class of IO requests. As another example, the class clock may be used to limit the maximum disk resources used by IO requests of different classes. In this case, the class clock is used to limit the maximum disk resources that can be used by a certain class of IO requests. As another example, the class clock may be used to indicate the weight of IO requests of different classes. In this case, the class clock may be used to enable the database to allocate disk resources for each class of IO requests according to the weight of the class IO.

From the above, the class clock can control the resources of the IO requests of different classes, so that fine control over the disk resources can be realized.

The disk resource in the embodiment of the present disclosure may be a disk bandwidth resource, and may also be an IOPS of a disk. The IOPS may be used to represent the number of IO requests that a disk can handle per second. When the size of the IO request is fixed, the larger the IOPS of the disk, the larger the bandwidth of the disk. Thus, in some cases, the disk bandwidth resources and disk IOPS may be interchanged.

The embodiment of the disclosure can be applied to any scene where resources of tenants are limited by clocks, that is, for any scene where resources of tenants are limited by clocks, a category clock can be added to realize fine control of disk resources.

The scheme of the embodiment of the present disclosure is described below with reference to fig. 4. The method described in figure 4 can be applied to a database with multiple tenants. The database may store data based on the LSM tree mentioned earlier. By way of example, the database is an OceanBase database. The respective steps in fig. 4 will be described in detail below.

In step S410, a plurality of IO requests sent by a plurality of tenants are received. The plurality of IO requests may include IO requests of different categories, such as foreground IO and background IO as described above. The multiple tenants may be all tenants of the database or may be partial tenants. For example, the multiple tenants are tenants with IO requests in the database.

In step S420, first timestamps of the plurality of IO requests are determined based on the category clock. The first timestamp is a timestamp corresponding to the category clock.

Multiple types of IO requests can be provided in one tenant, and the sizes of the type clocks of the IO requests of different types can be the same or different.

The categories of IO requests included within a tenant may or may not be the same. The sizes of the class clocks of IO requests of the same class in different tenants may be the same or different.

In order to enable IO requests of a certain class to be idle when IO requests of other classes are idle, idle resources in a tenant can be maximally utilized. The formula for calculating the first timestamp may refer to the formula for calculating the timestamp in the mclock algorithm. For example, the calculation formula of the first timestamp may be as follows:

wherein,

a category timestamp (i.e. first timestamp) of the r-th request representing the j-th category of the i-th tenant,cl _ija category clock representing the jth category of the ith tenant.cl _ijThe larger the size, the more disk resources are allocated for the category i of the tenant i;cl _ijthe smaller the disk resources allocated for category i, denoted tenant i.

If it is desired to limit the traffic of a certain class of IO requests (e.g., background IO requests), the class of IO requests may be restrictedcl _iThe setting is smaller; if it is desired to increase the traffic of a certain class of IO requests (e.g., foreground IO requests), the class of IO requests may be usedcl _iThe setting is larger.

In step S430, second timestamps of the plurality of IO requests are determined based on the first clock. The second time stamp is a time stamp corresponding to the first clock.

The first clock may be used to limit disk resources used by IO requests of different tenants. The type of the first clock is not specifically limited in the embodiments of the present disclosure, and the first clock may be any clock for limiting the disk resource used by the tenant. For example, the first clock may be a clock in an mclock algorithm, i.e., the first clock may be one or more of a reserve clock, a progress clock, and a Limitation clock.

If the first clock is a clock in the mclock algorithm, the formula for calculating the second timestamp may refer to formula (1) described above.

In step S440, an IO request to be scheduled is selected from the plurality of IO requests according to the first timestamp and the second timestamp.

The embodiment of the present disclosure does not specifically limit the manner of selecting the IO request to be scheduled. For example, an IO request whose first timestamp and second timestamp are both smaller than the current time may be taken as an IO request to be scheduled. For another example, the IO request with the first timestamp or the second timestamp smaller than the current time may be used as the IO request to be scheduled.

The category clock and the first clock may be the same type of clock. As one example, the class clock and the first clock are both clocks that limit the minimum disk resources used. If the first clock is used to limit the minimum disk resource used by IO requests of different tenants, for example, the first clock is a reserve clock in an mclock algorithm, the class clock may be used to limit the minimum disk resource used by IO requests of different classes, for example, the class clock may be used to represent the minimum IOPS of an IO request of a certain class. In this case, the IO request to be scheduled may be an IO request that simultaneously satisfies the minimum resource requirement of the tenant and the minimum resource requirement of the class IO.

As another example, the class clock and the first clock are both clocks that limit the maximum disk resources used. If the first clock is used to limit the maximum disk resources used by IO requests of different tenants, for example, the first clock is a Limitation clock in an mclock algorithm, the class clock may be used to limit the maximum disk resources used by IO requests of different classes, for example, the class clock may represent the maximum IOPS of an IO request of a certain class. In this case, the IO request to be scheduled may be an IO request that does not exceed the maximum resource limit of the tenant, nor the maximum resource limit of the class IO.

In step S450, the IO request to be scheduled is scheduled. According to the embodiment of the disclosure, the IO request to be scheduled in the plurality of IO requests can be scheduled preferentially, and other IO requests in the plurality of IO requests can be scheduled later.

The method and the device for limiting the disk resources based on the first clock increase the class clock, and limit the disk resources used by the multiple class IO requests by using the class clock. The class clock is used for determining the first timestamp, the first clock is used for determining the second timestamp, and the IO request to be scheduled is determined based on the first timestamp and the second timestamp, that is to say, when the disk resource used by the tenant is limited through the first clock, the disk resource used by the class IO is limited, so that one IO request only needs to be scheduled once, the isolation of the disk resource between the tenants and the isolation of the disk resource between the class IOs can be realized simultaneously, and the refined control of the disk resource is realized.

The scheme of the embodiment of the present disclosure is described below by taking the first clock as the Limitation clock in the mclock algorithm as an example.

In the P scheduling stage of the mclock algorithm, a certain tenant can maximally utilize all disk resources when other tenants are idle. Based on this, if it is expected that an IO request of a certain category can maximally utilize the idle resources of the tenant when IO requests of other categories are idle, the category clock may be applied in the P scheduling phase, that is, the selection of the IO request may be performed based on the category clock in the P scheduling phase. In this case, the class clock may be used to limit the maximum disk resources for different classes of IO requests within a tenant, e.g., the class clock may be used to represent the maximum IOPS for a certain class of IO requests.

In the related art, in a P scheduling stage of a mclock algorithm, an IO request with a second timestamp less than or equal to a current time needs to be selected, but in the embodiment of the present disclosure, an IO request with a second timestamp less than the current time and a first timestamp less than the current time may be selected, that is, an IO request to be scheduled is an IO request with a first timestamp and a second timestamp both less than the current time.

That is, the pseudo-code in the mclock algorithm may modify the pseudo-:

Let E’ be the set of requests with L tag≤t and CL tag≤t

where CL is the first timestamp and L is the second timestamp.

Through the scheduling, the Limitation of the tenant is not exceeded, the Limitation of the class IO is not exceeded, and meanwhile the class IO in the tenant can utilize the idle IO resources of the tenant to the maximum extent.

It can be understood that the size of the class clock of the IO requests of different classes in one tenant is smaller than or equal to the size of the Limitation clock of one tenant, i.e. the size of the Limitation clock of one tenantcl _iIs less than or equal tol _iThe size of (2). For example, to limit a class of IO requests, the class clock of the class of IO requests may be set to be less than the tenant's limit clock. If the IO requests of a certain class do not need to be limited, the class clock of the IO requests of the class can be set to be equal to the Limitation clock of the tenant. Of course, the sum of the class clocks of multiple class IO requests within a tenant may be greater than the size of the limit clock of the tenant.

The following describes a scheduling process of IO requests in the embodiment of the present disclosure with reference to fig. 5. Fig. 5 illustrates the case of IO requests in tenant 1, where tenant 1 includes an IO request of a category a and an IO request of a category B.

At time 0, tenant 1 generates 5 IO requests of class A, and at time 5 μ s, tenant 1 generates 10 IO requests of class B based on 1 ^ 4l ₁The time interval of =10 μ s stamps L for the above 15 IO requests. Since IO requests of class A come first, mclock is first based on 1 ≦l ₁The step size of (2) is that 5 IO requests of class A are sequentially stamped with time stamps L. Then, 10 IO requests of the B category are sequentially stamped with a time stamp L. The results are shown in FIG. 5.

Assuming the database wants to stream limit IO requests of class A, a 1 ≦ for IO requests of class Acl _1AGreater than 1l ₁. Assume 1-cl _1A=50 μ s, mclock may timestamp the class a IO requests with a time stamp CL at a time interval of 50 μ s. If the IO request in class B is not to be throttled, then a 1 ≦ for the IO request in class Bcl _1BCan be equal to 1l ₁. Since the IO requests of class B arrive at time 5 μ s, mclock may time stamp the IO requests of class B with CL in sequence from time 5 μ s. The results are shown in FIG. 5.

Assuming that the current time is 140 μ s, if there is no class clock in the embodiment of the present disclosure, in the P scheduling phase, the IO requests to be scheduled may include 5 IO requests of class a and 10 IO requests of class B. If the IO request to be scheduled is selected based on the timestamp L and the timestamp CL at the same time, if the IO request to be scheduled is an IO request of which both the L value and the CL value are smaller than the current time, the IO request to be scheduled can only include 3 IO requests of the a category and 10 IO requests of the B category, so that resources used by the IO requests of the a category are limited.

In some embodiments, after the IO requests are classified, different weights may be set for the IO requests of different categories, and the IO requests may be scheduled according to the weights of the IO categories, so that the IO requests may be scheduled more flexibly.

After classifying the weight clock, the calculation formula of the timestamp P may be as follows:

wherein,

timestamp P, P representing the r-th request of the j-th category of the i-th tenant_ijA weight clock representing the jth category of the ith tenant, and t represents the current time.

As an example, embodiments of the present disclosure may determine a third timestamp of the IO request to be scheduled based on the weight clock. The weight clock is used to indicate the weight of IO requests of different classes within a tenant. Further, in the P scheduling stage, based on the size of the third timestamp, a scheduling order of the IO requests to be scheduled may be determined. And the IO requests to be scheduled may be scheduled in sequence according to the scheduling order.

For example, assume that the database has 3 tenants, tenant 1, tenant 2, and tenant 3, which have weights of 1/2, 1/3, and 1/6, respectively. For tenant 1, tenant 1 includes an IO request of a type a and an IO request of a type B, and the embodiments of the present disclosure may set respective weights for the IO request of the type a and the IO request of the type B. However, the sum of the weight of the IO request of the a-class and the weight of the IO request of the B-class cannot exceed the weight of tenant 1. If it is desired to preferentially schedule IO requests of a certain class, the weight of the IO requests of the class may be set to be larger. The following description will take an example in which the weight of the IO request of the type a is 1/6 and the weight of the IO request of the type B is 1/3. It can be understood that the class IO in tenant 2 and tenant 3 may also have their own weight, and for brevity, the description is omitted here.

If the respective weights are not set for the IO requests of different classes, the IO requests in each tenant are scheduled in a first-in first-out order. Still taking fig. 5 as an example, if the IO requests are not classified, the 15 IO requests are sequentially scheduled in the order of L value from large to small. The IO request of the A category is dispatched firstly when the IO request of the A category is reached firstly; if the IO request of the B category arrives later, the IO request of the B category is scheduled after 5 IO requests of the A category are scheduled.

For the database, if the IO request of the class B is important, for example, the IO request of the class B is a foreground IO request, priority processing is desirably performed on the foreground IO in order to improve response time. However, IO requests of class B cannot be handled preferentially according to the scheduling policy described above.

After setting the respective weights for the class IOs, still taking tenant 1 as above, if the weight of the class a IO request is 1/6 and the weight of the class B IO request is 1/3, the class B IO request can be processed preferentially according to the scheduling principle of the P scheduling stage because the class B IO request has a higher weight than the class a IO request.

For example, the weight of the class a IO request is 1/6, and the timestamps P of 5 class a IO requests are 6,12,18,24, and 30, respectively. The weighting of the IO requests of B-class is 1/3, and the timestamps P of 10 IO requests of B-class are 3,6,9,12,15,18,21,24,27,30, respectively. In the P scheduling stage, the IO requests are sequentially scheduled according to the sequence of the timestamps P from large to small, so that the IO requests of the type B can be processed in time.

In some embodiments, the embodiments of the present disclosure may also set respective Reservation clocks for IO requests of different categories, so as to perform fine control on reserved resources of IO requests of a category. The sum of reserved resources of IO requests of multiple classes in a tenant cannot exceed the reserved resources of the tenant. Reserved resources of IO requests of different types in one tenant may be equal or different, and this is not specifically limited in the embodiment of the present disclosure.

After the Reservation clock is classified, the calculation formula of the timestamp R may be as follows:

wherein,

a timestamp R representing the R request of the jth category of the ith tenant,r _ija Reservation clock representing the jth category of the ith tenant, and t represents the current time.

Method embodiments of the present disclosure are described in detail above in conjunction with fig. 1-5, and apparatus embodiments of the present disclosure are described in detail below in conjunction with fig. 6 and 7. It is to be understood that the description of the apparatus embodiments corresponds to the description of the method embodiments, and therefore reference may be made to the preceding method embodiments for parts which are not described in detail.

Fig. 6 is a schematic structural diagram of a scheduling apparatus according to an embodiment of the present disclosure. The apparatus 600 is applicable to a database with multiple tenants. The database may store data based on the LSM tree mentioned earlier. By way of example, the database is an OceanBase database. The apparatus 600 includes a receiving module 610, a first determining module 620, a second determining module 630, a selecting module 640, and a scheduling module 650. The functions of these modules are described separately below.

A receiving module 610, configured to receive a plurality of input/output IO requests sent by the plurality of tenants.

A first determining module 620, configured to determine first timestamps of the plurality of IO requests based on a class clock, where the class clock is used to limit disk resources used by IO requests of different classes in one tenant.

A second determining module 630, configured to determine a second timestamp of the plurality of IO requests based on a first clock, where the first clock is used to limit disk resources used by IO requests of different tenants.

A selecting module 640, configured to select an IO request to be scheduled from the plurality of IO requests according to the first timestamp and the second timestamp.

And the scheduling module 650 is configured to schedule the IO request to be scheduled.

Optionally, the class clock is used to limit a maximum disk resource used by IO requests of different classes, the first clock is an upper limit clock in an mclock algorithm, and the IO request to be scheduled is an IO request whose first timestamp and the second timestamp are both less than a current time.

Optionally, the size of the class clock of the IO requests of different classes in one tenant is smaller than or equal to the size of the upper limit clock of the one tenant.

Optionally, the apparatus 600 further comprises: a third determining module, configured to determine a third timestamp of the IO request to be scheduled based on a weight clock, where the weight clock is used to indicate weights of IO requests of different classes in one tenant; the scheduling module 640 is configured to: determining a scheduling sequence of the IO requests to be scheduled based on the size of the third timestamp; and scheduling the IO requests to be scheduled in sequence according to the scheduling sequence.

Optionally, the categories of the IO requests include foreground IO requests and background IO requests.

Fig. 7 is a schematic structural diagram of another apparatus for managing a database according to an embodiment of the present disclosure. The management database apparatus 700 depicted in fig. 7 may include a memory 710 and a processor 720, and the memory 710 may be used to store executable code. The processor 720 may be configured to execute the executable code stored in the memory 710 to implement the steps of the various methods described previously. In some embodiments, the apparatus 700 may further include a network interface 730, and data exchange between the processor 720 and an external device may be implemented through the network interface 730.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. The procedures or functions described in accordance with the embodiments of the disclosure are, in whole or in part, generated when the computer program instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website, computer, server, or data center to another website, computer, server, or data center via wire (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be read by a computer or a data storage device including one or more available media integrated servers, data centers, and the like. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a Digital Versatile Disk (DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), among others.

The above description is only for the specific embodiments of the present disclosure, but the scope of the present disclosure is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present disclosure, and all the changes or substitutions should be covered within the scope of the present disclosure. Therefore, the protection scope of the present disclosure shall be subject to the protection scope of the claims.

Claims

1. A scheduling method, the method being applied to a database having a plurality of tenants, the method comprising:

receiving a plurality of IO requests sent by the plurality of tenants;

determining a first timestamp of each IO request in the plurality of IO requests based on a category clock, wherein the category clock is used for limiting disk resources used by different categories of IO requests in one tenant, and the categories of the plurality of IO requests comprise a foreground IO request and a background IO request;

determining a second timestamp of each IO request in the plurality of IO requests based on a first clock, the first clock being used to limit disk resources used by IO requests of different tenants;

selecting an IO request to be scheduled from the plurality of IO requests according to the first time stamp of each IO request and the second time stamp of each IO request;

and performing primary scheduling on the IO request to be scheduled.

2. The method of claim 1, wherein the class clock is used to limit a maximum disk resource used by IO requests of different classes, the first clock is an upper limit clock in a mclock algorithm, and the IO request to be scheduled is an IO request whose first timestamp and the second timestamp are both smaller than a current time.

3. The method of claim 2, wherein the size of the class clock of different class IO requests within a tenant is less than or equal to the size of the upper bound clock of the tenant.

4. The method of claim 2, further comprising:

determining a third timestamp of the IO request to be scheduled based on a weight clock, wherein the weight clock is used for indicating weights of different types of IO requests in one tenant;

the scheduling the IO request to be scheduled includes:

determining a scheduling sequence of the IO requests to be scheduled based on the size of the third timestamp;

and scheduling the IO requests to be scheduled in sequence according to the scheduling sequence.

5. A scheduling apparatus, the apparatus being applied to a database having a plurality of tenants, the apparatus comprising:

the receiving module is used for receiving a plurality of IO requests sent by the plurality of tenants;

a first determining module, configured to determine a first timestamp of each IO request in the multiple IO requests based on a category clock, where the category clock is used to limit disk resources used by IO requests of different categories in one tenant, and the categories of the multiple IO requests include a foreground IO request and a background IO request;

a second determining module, configured to determine a second timestamp of each IO request in the plurality of IO requests based on a first clock, where the first clock is used to limit disk resources used by IO requests of different tenants;

a selecting module, configured to select an IO request to be scheduled from the multiple IO requests according to the first timestamp of each IO request and the second timestamp of each IO request;

and the scheduling module is used for scheduling the IO request to be scheduled for one time.

6. The apparatus of claim 5, the class clock is configured to limit a maximum disk resource used by IO requests of different classes, the first clock is an upper limit clock in a mclock algorithm, and the IO request to be scheduled is an IO request whose first timestamp and the second timestamp are both smaller than a current time.

7. The apparatus of claim 6, wherein a size of a class clock of different class IO requests within a tenant is less than or equal to a size of an upper bound clock of the tenant.

8. The apparatus of claim 6, the apparatus further comprising:

a third determining module, configured to determine a third timestamp of the IO request to be scheduled based on a weight clock, where the weight clock is used to indicate weights of IO requests of different classes in one tenant;

the scheduling module is to:

9. A scheduling apparatus comprising a memory having executable code stored therein and a processor configured to execute the executable code to implement the method of any one of claims 1-4.