Apparatus, method and article of manufacture for performing accelerator resource allocation

Abstract

Apparatuses, methods, and articles of manufacture for performing accelerator resource allocation are disclosed. The apparatus may include a storage device that may store a database including tables. The apparatus may also include an accelerator connected to the storage device. The accelerator may include a core. A scan associated with a query may access data from the table in a database stored on a storage device. A scan priority calculator may calculate a priority of the scan. A kernel assignment unit may assign a kernel to the scan based at least in part on a priority of the scan.

Description

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 541,288, filed on September 28, 2023, which is incorporated herein by reference for all purposes. Technical Field

[0002] The disclosure relates generally to accelerators and, more particularly, to improving allocation of resources in an accelerator. Background Art

[0003] A database query may involve scanning of multiple tables. When queries are processed in parallel, the number of scans can be further increased. Although the scans can be performed using software solutions provided by the database management system, the use of hardware resources can be more efficient.

[0004] There is still a need for improvements in the allocation of accelerator resources when processing table scans. Summary of the invention

[0005] The accelerator may determine the priorities of various scans in pending queries of the database. The accelerator may then dispatch accelerator cores to the various scans in proportion to the priorities of the various scans.

[0006] In one general aspect, an apparatus for performing accelerator resource allocation is provided, the apparatus comprising: a storage device storing a database including a table; and an accelerator connected to the storage device, the accelerator including a kernel; a scan priority calculator for calculating a priority of a scan of the table in the database stored on the storage device, the scan being associated with a query; and a kernel dispatch unit for dispatching a kernel to the scan based at least in part on the priority of the scan.

[0007] In one general aspect, a method for performing accelerator resource allocation is provided, the method comprising: identifying a kernel in an accelerator; identifying a scan of a table in a query, the table stored in a database on a storage device connected to the accelerator; determining a priority for the scan; and assigning the kernel to the scan based at least in part on the priority of the scan.

[0008] In one general aspect, an article of manufacture for performing accelerator resource allocation is provided, the article of manufacture comprising a non-transitory storage medium having instructions stored thereon that, when executed by a machine, cause: identifying a kernel in an accelerator; identifying a scan of a table in a query, the table stored in a database on a storage device connected to the accelerator; determining a priority for the scan; and dispatching the kernel to the scan based at least in part on the priority of the scan. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The drawings described below are examples of how the disclosed embodiments may be implemented and are not intended to limit the disclosed embodiments. The various embodiments disclosed may include elements not shown in a particular drawing and / or may omit elements shown in a particular drawing. The drawings are intended to provide illustrations and may not be to scale.

[0010] Figure 1 A machine including an accelerator for dispatching kernels to scans of table queries in a database management system is shown in accordance with the disclosed embodiments.

[0011] Figure 2 Showing the embodiment according to the disclosure Figure 1 Details of the machine.

[0012] Figure 3A The following are examples of the disclosed embodiments. Figure 1 The storage device is associated with Figure 1 A first example arrangement of an accelerator.

[0013] Figure 3B The following are examples of the disclosed embodiments. Figure 1 The storage device is associated with Figure 1 A second example arrangement of an accelerator.

[0014] Figure 3C The following are examples of the disclosed embodiments. Figure 1 The storage device is associated with Figure 1 A third example arrangement of an accelerator.

[0015] Figure 3D The following are examples of the disclosed embodiments. Figure 1 The storage device is associated with Figure 1 A fourth example arrangement of an accelerator.

[0016] Figure 4 Showing the embodiment according to the disclosure Figure 1 Details of the accelerator.

[0017] Figure 5 A query with multiple scans is shown in accordance with the disclosed embodiments.

[0018] Figure 6 The determination according to the disclosed embodiment is shown Figure 5 The scanning priority Figure 4 Scan priority calculator for .

[0019] Figure 7 Showing the embodiment according to the disclosure Figure 4 The kernel is based on Figure 6 The scanning priority is assigned to Figure 5 of the scan.

[0020] Figure 8 Determining when to release according to the disclosed embodiment Figure 4 The kernel Figure 4 The kernel release unit.

[0021] Fig. 9 Showing the embodiment according to the disclosure Figure 1 The accelerator will Figure 4 The kernel is assigned to Figure 5 Flowchart of an example program for scanning.

[0022] Fig.10 Showing the embodiment according to the disclosure Figure 1 The accelerator determines Figure 5 Flowchart of an example program for scanning.

[0023] Fig.11 Showing the embodiment according to the disclosure Figure 1 The accelerator determines Figure 5 Scan Figure 6 Flowchart of an example program for scanning priorities.

[0024] Fig.12 Showing the embodiment according to the disclosure Figure 1 Accelerator usage Figure 4 The kernel is executed Figure 5 Scan and release Figure 4 Flowchart of an example program for the kernel.

[0025] Fig.13 Showing the embodiment according to the disclosure Figure 1 Flowchart of an example procedure for flushing cache data to an accelerator.

[0026] Fig.14 Showing the embodiment according to the disclosure Figure 1 The accelerator determines whether a releasable has been dispatched to Figure 5 of scans but not yet assigned to Figure 5 Scan Figure 4 Flowchart of an example program for the kernel. DETAILED DESCRIPTION

[0027] Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, many specific details are set forth to enable a thorough understanding of the disclosure. However, it should be understood that one of ordinary skill in the art may practice the disclosure without these specific details. In other examples, well-known methods, procedures, components, circuits, and networks are not described in detail to avoid unnecessarily obscuring aspects of the embodiments.

[0028] It will be understood that although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first module may be referred to as a second module, and similarly, a second module may be referred to as a first module without departing from the scope of the disclosure.

[0029] The terms used in the description of the disclosure are only used for the purpose of describing specific embodiments and are not intended to limit the disclosure. As used in the disclosure and the description of the appended claims, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will also be understood that the terms "including" and / or "comprising" when used in this specification indicate the presence of stated features, wholes, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or their groups. The components and features of the accompanying drawings are not necessarily drawn to scale.

[0030] The database management system may receive queries submitted by any number of clients. Each client may submit any number of queries, and each query may involve scanning any number of tables. Because the database management system may not know when any client will submit a query, the database management system may ultimately process any number of queries in parallel.

[0031] The scan of each table may be performed in software, or if hardware resources are available, may be performed in hardware. For example, an accelerator may include one or more cores with implemented scan algorithms that may be used to scan a table.

[0032] The disclosed embodiments provide more efficient allocation of accelerator resources by determining a priority value for each core in the accelerator and then assigning available cores to scans in proportion to their priorities. The priority of each scan may take into account cache statistics and the size of the information to be scanned: the cache statistics may be queried from a database management system. Scans with higher priorities may be assigned a larger number of cores, while relatively low priority scans fall back to software scan implementations.

[0033] The disclosed embodiments may also recognize that just because a core is assigned to a scan does not mean that the database management system can use the core to perform the scan. For example, the database management system may perform a cost function that may determine that a software scan may be faster: for example, based on how data from a table will be used. The disclosed embodiments may recognize that a core is not actually assigned to a scan, and may release the core back to the pool of available cores for use by other scans.

[0034] The disclosed embodiments may also recognize that scans performed by database management system software may include data in caches belonging to the database management system or operating system. To ensure that all current data is available for scans performed by the kernel, the cache may be flushed to disk before the kernel performs the scan.

[0035] Figure 1 A machine including an accelerator for dispatching kernels to scans of table queries in a database management system is shown in accordance with a disclosed embodiment. Figure 1 In the present invention, machine 105 (which may also be referred to as a host or system) may include processor 110, memory 115, and storage 120. Machine 105 may also be considered a database management system, or may be considered to host (ie, execute) database management system software.

[0036] Processor 110 may be any type of processor. (For ease of illustration, processor 110 and other components discussed below are shown as being external to the machine: the disclosed embodiments may include these components within the machine.) Figure 1 A single processor 110 is shown, but machine 105 may include any number of processors, each of which may be a single-core or multi-core processor, each of which may implement a reduced instruction set computer (RISC) architecture or a complex instruction set computer (CISC) architecture (among other possibilities), and which may be mixed in any desired combination.

[0037] The processor 110 may be coupled to a memory 115. The memory 115 may be any kind of memory (such as flash memory, dynamic random access memory (DRAM), static random access memory (SRAM), persistent random access memory, ferroelectric random access memory (FRAM), or non-volatile random access memory (NVRAM) (such as magnetoresistive random access memory (MRAM)), etc.). The memory 115 may also be any desired combination of different memory types and may be managed by a memory controller 125. The memory 115 may be used to store what may be referred to as "short-term" data: that is, data that is not expected to be stored for a long time. Examples of short-term data may include temporary files, data used locally by an application (which may have been copied from other storage locations), etc.

[0038] The processor 110 and the memory 115 may also support an operating system under which various applications may run. These applications may issue requests (which may also be referred to as commands) for reading data from the memory 115 or the storage device 120 or writing data to the memory 115 or the storage device 120. The storage device 120 may be accessed using a device driver 130.

[0039] Storage device 120 may be associated with accelerator 135 (which may also be referred to as a computational storage unit, computational storage device, or computational device). FIG. 3A to FIG. 3D As discussed, the storage device 120 and the accelerator 135 may be designed and manufactured as a single integrated unit, or the accelerator 135 may be separate from the storage device 120. The phrase "associated with..." is intended to cover a single integrated unit that includes both the storage device and the accelerator as well as a storage device that is paired with the accelerator but is not manufactured as a single integrated unit. In other words, when the storage device and the accelerator are physically separate devices but are connected in a manner that enables them to communicate with each other, the storage device and the accelerator may be referred to as being "paired." In addition, in the remainder of this document, any reference to the storage device 120 and / or the accelerator 135 may be understood to refer to physically separate but paired devices (and therefore may include another device) or two devices that are integrated into a single component as a computing storage unit.

[0040] Additionally, the connection between the storage device and the paired accelerator may enable the two devices to communicate, but may not enable one (or both) devices to work with different partners: that is, the storage device may not be able to communicate with the other accelerator, and / or the accelerator may not be able to communicate with the other storage device. For example, the storage device and the paired accelerator may be connected to a network fabric serially (in either order), enabling the accelerator to access information from the storage device in a way that the other accelerator may not be able to achieve.

[0041] Although Figure 1 The generic term "storage" is used, but the disclosed embodiments may include any storage format that may be associated with a computing storage device, examples of which may include hard disk drives and solid-state drives (SSDs). Any reference below to a specific type of storage device (such as, "SSD") should be understood to include such other embodiments disclosed.

[0042] The processor 110, the storage device 120, and the accelerator 135 are shown as being connected to a network fabric 140. The network fabric 140 is intended to represent any network fabric along which information can be passed. The network fabric 140 may include a network fabric that may be internal to the machine 105, and the network fabric may use interfaces such as Peripheral Component Interconnect Express (PCIe), Serial AT Attachment (SATA), Small Computer System Interface (SCSI), etc. The network fabric 140 may also include a network fabric that may be external to the machine 105, and the network fabric may use interfaces such as Ethernet, Infiniband, or Fibre Channel, etc. In addition, the network fabric 140 may support one or more protocols (such as Non-Volatile Memory Express (NVMe), NVMe over a network fabric (NVMe-oF), or Simple Service Discovery Protocol (SSDP), etc.). Therefore, the network fabric 140 may be considered to include both internal and external networking connections, through which commands may be sent directly or indirectly to the storage device 120 (and more specifically, the accelerator 135 associated with the storage device 120). In disclosed embodiments where the network fabric 140 supports external networking connections, the storage device 120 and / or the accelerator 135 may be located external to the machine 105 .

[0043] Because processor 110, storage device 120, and accelerator 135 can communicate via network structure 140, Figure 1 Processor 110, storage 120, and accelerator 135 are shown as connected to network fabric 140. In some disclosed embodiments, storage 120 and / or accelerator 135 may include a connection to network fabric 140, which may include the ability to communicate with a remote machine and / or network: for example, a solid state drive (SSD) with network capabilities. However, in other disclosed embodiments, although machine 105 may include a connection to another machine and / or network (which connection may be considered part of network fabric 140), storage 120 and / or accelerator 135 may not be connected to another machine and / or network. In such disclosed embodiments, storage 120 and / or accelerator 135 may still be reachable from a remote machine, but such commands may be passed through processor 110 and other possibilities to reach storage 120 and / or accelerator 135.

[0044] Figure 2 Showing the embodiment according to the disclosure Figure 1 Details of the machine 105. Figure 2In the embodiment of the present invention, the machine 105 generally includes one or more processors 110, which may include a memory controller 125 and a clock 205 that can be used to coordinate the operation of the components of the machine. The processor 110 may also be coupled to a memory 115, which may include, by way of example, a random access memory (RAM), a read-only memory (ROM), or other state preservation medium. The processor 110 may also be coupled to a storage device 120 and a network connector 210, which may be, for example, an Ethernet connector or a wireless connector. The processor 110 may also be connected to a bus 215, to which a user interface 220 and input / output (I / O) interface ports and other components may be attached, and the I / O interface ports may be managed using an I / O engine 225.

[0045] FIG. 3A to FIG. 3D The following are examples of the disclosed embodiments. Figure 1 The storage device 120 is associated with Figure 1 Various arrangements of the accelerator 135. Figure 3A , a storage device 305 (which may be Figure 1 storage device 120) and computing device 310-1 (which may be Figure 1 accelerator 135, and which may also be referred to as a computational storage unit, computational storage device, or device). Storage device 305 may include a controller (e.g., storage controller) 315 and storage device 320-1. Storage device 305 may be accessible using any desired form of access. For example, in Figure 3A In , the storage device 305 can be accessed across the network fabric 140 using a submission queue and a completion queue, which can form a queue pair. Figure 3A , storage device 305 is shown as including two queue pairs: management queue pair 325 can be used to manage storage device 305, and I / O queue pair 330 can be used to control the I / O of storage device 305. (Without reference to the specific usage of management queue pair 325 and I / O queue pair 330, management queue pair 325 and I / O queue pair 330 may be more generally referred to as queue pairs 325 and 330.) The disclosed embodiments may include any number (one or more) of queue pairs 325 and 330 (or other forms of access), and access may be shared: for example, a single queue pair may be used for both management and I / O control of storage device 305 (i.e., queue pairs 325 and 330 may be combined in one queue pair).

[0046] The computing device 310-1 may be paired or associated with the storage device 305. The computing device 310-1 may include any number (one or more) of processors 335, which may also be referred to as computing storage processors, computing engines, or engines, and the processors 335 may provide one or more services 340-1 and 340-2, which may be collectively referred to as services 340, and the services 340-1 and 340-2 may also be referred to as computing storage services (CSS). For greater clarity, (although the disclosed embodiments may include exactly as Figure 3A Each processor 335 may provide any number (one or more) of services 340. Services 340 may be functions built into processor 335, Figure 1 The processor 110 downloads the function (ie, Figure 1 335 ) or both. Similar to queue pairs 325 and 330 of storage device 305 , computing device 310 - 1 may be reachable across management queue pair 345 and / or I / O queue pair 350 , which may be used to manage computing device 310 - 1 and / or control I / O of computing device 310 - 1 , respectively. (Without reference to the specific uses of management queue pair 345 and I / O queue pair 350 , management queue pair 345 and I / O queue pair 350 may be more generally referred to as queue pairs 345 and 350 ). Similar to queue pairs 325 and 330 , other forms of access besides queue pairs 345 and 350 may be used, and a single queue pair may be used for both management and I / O control of computing device 310 - 1 (i.e., queue pairs 345 and 350 may be combined in one queue pair ).

[0047] Processor 335 can be considered as near-storage processing: that is, Figure 1 The processor 110 is closer to the storage device 305. Because the processor 335 is closer to the storage device 305, the processor 335 may be able to Figure 1 The processor 110 executes commands on data stored in the storage device 305 more quickly. Figure 3A 305 , but the processor 335 may have associated memory that may be used for local execution of commands on data stored in the storage device 305 .

[0048] Although Figure 3AStorage device 305 and computing device 310-1 are shown as being individually reachable across network fabric 140, but disclosed embodiments may also include storage device 305 and computing device 310-1 connected in series. That is, commands directed to storage device 305 and computing device 310-1 may both be received at the same physical connection to network fabric 140 and may be passed through one device to reach the other. For example, if computing device 310-1 is located between storage device 305 and network fabric 140, computing device 310-1 may receive commands directed to both computing device 310-1 and storage device 305: computing device 310-1 may process commands directed to computing device 310-1, and may pass commands directed to storage device 305 to storage device 305.

[0049] Service 340 may provide a number of different functions that may be performed on data stored in storage device 305. For example, service 340 may provide predefined functions (such as encryption, decryption, compression and / or decompression of data, erasure coding, and / or application of regular expressions). Alternatively, service 340 may provide more general functions (such as data search and / or SQL functions). Service 340 may also support running application-specific code. That is, an application using service 340 may provide custom code to be executed using data on storage device 305. In some disclosed embodiments, service 340 may be stored in a "program slot": that is, a specific address range within processor 335. Service 340 may also be any combination of such functions. Table 1 lists some examples of services that may be provided by processor 335.

[0050] Table 1: Service Types

[0051] The processor 335 (in fact, the computing device 310-1) can be implemented in any desired manner. Example implementations may include local processors (such as central processing units (CPUs), graphics processing units (GPUs), general-purpose GPUs (GPGPUs), data processing units (DPUs), and tensor processing units (TPUs), as well as other possibilities). The processor 335 may also be implemented using a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or a system on a chip, as well as other possibilities. If the computing device 310-1 includes more than one processor 335, each processor 335 may be implemented as described above. For example, the computing device 310-1 may have one each of a CPU, a TPU, and an FPGA, or the computing device 310-1 may have two FPGAs, or the computing device 310-1 may have two CPUs and one ASIC, and so on.

[0052] Depending on the desired interpretation, computing device 310 - 1 or one or more processors 335 may be considered a computational storage unit.

[0053] Although Figure 3A Storage device 305 and computing device 310-1 are shown as separate devices, but Figure 3B Thus, computing device 310-2 may include controller 315, storage device 320-1, and one or more processors 335 that provide services 340-1 and 340-2. Figure 3A The storage device 305 of the computing device 310-1 can receive management and I / O commands via queue pairs 345 and / or 350. Even though the computing device 310-2 is shown as including both the storage device 320-1 and one or more processors 335, Figure 3B Still, it may be considered to include storage associated with the computational storage unit.

[0054] exist Figure 3C In yet another variation shown in FIG. 3 , a computing device 310-3 is shown. The computing device 310-3 may include a controller 315 and a storage device 320-1, as well as one or more processors 335 that provide services 340-1 and 340-2. However, even though the computing device 310-3 may be considered a single component including the controller 315, the storage device 320-1, and the one or more processors 335 (and also considered a storage device associated with a computing storage unit), the computing device 310-3 may be considered a single component including the controller 315, the storage device 320-1, and the one or more processors 335. Figure 3B , the controller 315 and the one or more processors 335 may each include their own queue pairs 325 and / or 330 and 345 and / or 350 (again, which may be used for management and / or I / O). By including the queue pairs 325 and / or 330, the controller 315 may provide transparent access to the storage device 320-1 (rather than requiring all communications to go through the one or more processors 335), while the queue pairs 345 and / or 350 may be used to access the one or more processors 335.

[0055] Additionally, one or more processors may have proxied storage device access 355 for accessing storage device 320-1. Instead of routing access requests through controller 315, one or more processors 335 may be able to use proxied storage device access 355 to access data directly from storage device 320-1.

[0056] exist Figure 3C , the controller 315 and the proxy's storage device access 355 are shown with dashed lines to indicate that they are optional elements and may be omitted depending on the implementation.

[0057] at last, Figure 3D Another implementation is shown. Figure 3D , a computing device 310 - 4 is shown, which may include an array, which may include one or more storage devices (or computing storage devices (CSDs)) 320 - 1 to 320 - 4. Figure 3D Four storage elements are shown, but the disclosed embodiments may include any number (one or more) of storage elements. In addition, each storage element may be other storage devices (such as, FIG. 3A to FIG. 3D storage device shown in ).

[0058] Because the computing device 310-4 may include more than one storage device 320-1 to 320-4, the computing device 310-4 may include an array controller 360. The array controller 360 may manage how data is stored on the storage devices 320-1 to 320-4 and how data is obtained from the storage devices 320-1 to 320-4. For example, if the storage devices 320-1 to 320-4 are implemented as a particular level of redundant array of independent disks (RAID), the array controller 360 may be a RAID controller. If the device elements 320-1 to 320-4 are implemented using a particular form of erasure coding, the array controller 360 may be an erasure coding controller.

[0059] Figure 4 Showing the embodiment according to the disclosure Figure 1 Details of the accelerator 135. Figure 4 In the example, accelerator 135 may communicate with storage device 120 (eg, across network fabric 140) to access database 405, which may include tables (such as table 410). Figure 4 The storage device 120 is shown as storing one database 405, which is shown as including one table 410, but the disclosed embodiments may support any number (one or more) of databases 405 stored on the storage device 120, and each database 405 or any number (one or more) of databases 405 may include any number (one or more) of tables 410. The database 405 may receive queries from various users to access information from the table 410. Although Figure 4 In the figure, the receiver 420, the query acquisition unit 425, the cache query unit 435, the scan priority calculator 440, the kernel dispatch unit 445, the kernel allocation unit 450, the cache flush unit 460, and the kernel release unit 455 are shown to be included in the accelerator 135, but the embodiment is not limited thereto, and the above elements may be located outside the accelerator 135.

[0060] The accelerator 135 may include various cores, such as core 415-1 (core 1) and 415-2 (core 2), which may be collectively referred to as cores 415. The cores 415 may be dispatched to perform various scans of the table 410 in the database 405. Each core 415 may be implemented in any desired manner. For example, each core 415 may include a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on a chip, a central processing unit (CPU), a graphics processing unit (GPU), a general purpose GPU (GPGPU), a data processing unit (DPU), or a tensor processing unit (TPU), as well as other possibilities. Each core 415 may also be implemented differently from the other cores 415. For example, core 415-1 may be implemented as an FPGA, while core 415-2 may be implemented as a CPU.

[0061] Each core 415 can be designed to implement a specific scan function. The scan function can use any desired algorithm to access data from the table 410. For example, one scan function can access data by reading a row of data at a time, while another scan function can access data by reading a column of data at a time. Different cores 415 can implement the same or different scan functions as needed.

[0062] Although Figure 4 Only two cores 415 are shown, but the disclosed embodiments may include any number (one or more) of cores 415. Figure 4 The kernel 415 is shown as being part of the accelerator 135, but in some disclosed embodiments, the accelerator 135 may provide for dispatching of the kernel 415 external to the accelerator 135. For example, the storage device 120 may be coupled to two accelerators 135, one accelerator 135 may include the kernel 415, and the other accelerator 135 may be used to dispatch the kernel 415 to perform a scan of the table 410 in the database 405.

[0063] In order to assign a kernel 415 to a scan, the accelerator 135 may need to know which queries are currently pending. In some disclosed embodiments, the receiver 420 may receive a query from a user. The query may be sent to the accelerator 135 instead of or in addition to the query being sent to the database 405.

[0064] In other disclosed embodiments, the accelerator 135 may request any pending queries from the database 405. The accelerator 135 may include a query obtaining unit 425, which may inquire the database 405 about any currently pending queries. In some disclosed embodiments, the query obtaining unit 425 may obtain any pending queries directly from a specific location in the database 405; in other disclosed embodiments, the query obtaining unit 425 may send a query to the database 405 to learn which queries are currently pending, and the database 405 may respond with any currently pending queries, and the responded currently pending queries may be received by the accelerator 135 using the receiver 420. For example, the query obtaining unit 425 may access a cumulative statistics system of the database 405, and the cumulative statistics system of the database 405 may include information about which queries are currently pending.

[0065] Note that the above discussion focuses on "currently pending queries". Once the database 405 (or kernel 415) has begun processing a query, the query is no longer "pending", but is "in process". Once processing of a query has begun, processing can be expected to continue using the selected method. However, in some disclosed embodiments, queries that are "in process" can be assigned or reassigned to different resources. For example, a query that is processed in software can be reassigned to a hardware core that becomes available after completing processing of a previous query.

[0066] Regardless of how the accelerator 135 learns of any pending query, the accelerator 135 may then identify any scans applicable to the query (e.g., to be performed as part of processing the query). In general, a "scan" may be understood to involve reading or otherwise processing data from one or more tables. The accelerator 135 may include a parser ( Figure 4 405). Note that the query may be constructed according to a specific syntax to enable such parsing. However, since the database 405 may include such a parser (for parsing the query for processing by the database 405), the accelerator 135 may also require the database 405 to parse the query to identify the scan applicable to the query.

[0067] Figure 5 A query with multiple scans according to a disclosed embodiment is shown. Figure 5 , query 505 is shown. Query 505 requests to obtain the values ​​from one table based on two columns in another table having the same values. Figure 4410. Thus, query 505 may involve two scans: one scan of each table. These scans are shown as scans 510-1 and 510-2 (which may be collectively referred to as scans 510). The disclosed embodiments may include any number (zero or more) of scans 510 in query 505, and any number (zero or more) of queries 505 may be processed by the database management system at any time. And although Figure 5 Scans 510 are shown as being associated with a single table (eg, scan 510 - 1 is associated only with table tab1 , scan 510 - 2 is associated only with table tab2 ), but as mentioned above, disclosed embodiments may include scans that may involve multiple tables.

[0068] Return to Figure 4 Once identified Figure 5 Query 505 Figure 5 of the scan 510—and once the access to satisfy Figure 5 Such a table scan 510 - the accelerator 135 can begin to determine Figure 5 The priority of each scan 510 is determined by Figure 5 The various criteria for the priority of scanning 510. For example, if Figure 5 Scan 510 has been targeted by kernel 415-1 Figure 5 Some queries 505 are processed, then core 415-1 can be dispatched to process Figure 5 Another query 505 Figure 5 Note that if the kernel 415 has already performed a scan for Figure 5 Some queries 505 Figure 5 The scan 510 does not need to be calculated for Figure 5 Another query 505 Figure 5 The same scan priority of 510: the same core can be used for the Figure 5 of the scan 510 without using another kernel 415 that could otherwise be used.

[0069] Can be used to determine Figure 5 Another criterion for the priority of the scan 510 may be how much information from the table may have been cached. As mentioned above, the database 405 may include a Figure 5 The software implementation of scanning 510. In order to support Figure 5 510, database 405 may include a cache (such as cache 430 (which may be stored in, for example, Figure 1 In addition, because the database management system can be Figure 1 105, so Figure 1An operating system running on processor 110 may include its own data cache. Because such caches may be stored in a memory system that can be accessed faster than storage device 120, these caches may be used to speed up access to data that is (or is expected to be) frequently accessed. In the remainder of this document, any reference to cache 430 may be understood to refer to cache 430 and the data caches stored by the processor 110. Figure 1 Either or both of the caches managed by the operating system running on processor 110.

[0070] However, the accelerator 135 may not have access to the cache 430. For example, the benefit of the accelerator 135 is that it is "close" to the storage device 120 and therefore can be compared to the cache 430. Figure 1 The processor 110 can access data from the storage device 120 faster (the accelerator 135 can provide a faster access speed than the processor 110). Figure 1 The processor 110 is connected to the storage device 120 by a bus with a high bandwidth. However, for the cache Figure 1 Memory 115 or Figure 1 10, this higher speed bus may not be beneficial: accessing data from such a cache may require using Figure 1 The processor 110 can be used to access the same bus of the storage device 120. If enough data is currently cached in the cache 430, the advantage of recent data processing by the core 415 can be lost and the database 405 can be processed in software. Figure 5 The scanning 510 can be more efficient, and Figure 5 The priority of scan 510 may be set to zero (or other low priority value).

[0071] In order to determine whether there is enough data currently cached in cache 430, accelerator 135 may want to know how much data exists in table 410, and how much data in table 410 is currently cached in cache 430. Database 405 may have such information. For example, database 405 may know how big table 410 is, and how much data is currently cached in cache 430. Therefore, cache query unit 435 may query database 405 for such information.

[0072] Once accelerator 135 receives information about the size of table 410 and the amount of data from table 410 currently cached in cache 430, accelerator 135 can determine whether kernel 415 is executing Figure 5 Are the benefits of scanning 510 sufficient to justify using kernel 415 to perform the Figure 540 . For example, as discussed above, the accelerator 135 may not be able to access the cache 430 (or may not be able to access the cache 430 quickly enough). Therefore, if any data of the table 410 is currently cached in the cache 430, it may be necessary to flush the data from the cache 430 back to the storage device 120 so that the kernel 415 can access the latest information from the table 410 (and prevent the user from updating the data of the table 410 in the cache 430, which may not be written to the storage device 120 in time for the kernel 415 to perform the update on the updated data in the table 410). Figure 5 If more than 50% (or other threshold) of table 410 is already in cache 430, have database 405 perform a scan of table 410. Figure 5 The scan 510 instead of letting the kernel 415 execute Figure 5 The scanning 510 can be more efficient, and Figure 5 The priority of scan 510 may be set to zero (or other low priority value).

[0073] In addition, the database 405 may have information about how much of the data from the table 410 in the cache 430 is dirty: that is, how much of the data from the table 410 in the cache 430 has been updated by the client but has not yet been written back to the storage device 120. If the amount of dirty data from the table 410 in the cache 430 is greater than a certain threshold amount of data, the database 405 is again allowed to perform the table 410 update. Figure 5 The scan 510 instead of letting the kernel 415 execute Figure 5 The scanning 510 can be more efficient, and Figure 5 The priority of scan 510 may be set to zero (or other low priority value).

[0074] The parameters indicated above—the threshold amount of data from table 410 that resides in cache 430, or the amount of dirty data from table 410 in cache 430—are adjustable parameters. The disclosed embodiments may support the use of any values ​​for such parameters without limitation. In addition, the form these parameters take may be adjusted as desired. For example, although the threshold amount of data from table 410 cached in cache 430 is described as a percentage, a fixed amount of data (which may be expressed in bytes or specific multiples thereof, or in other units such as blocks stored on storage device 120) may be used instead. Similarly, although the threshold amount of dirty data from table 410 in cache 430 is described as a specific amount of data (which may be expressed in bytes or specific multiples thereof, or in other units such as blocks stored on storage device 120), a percentage of the size of table 410 may be used instead.

[0075] Assuming there is no reason to Figure 5 The priority of the scan 510 is set to zero, then the scan priority calculator 440 can be used to calculate Figure 5 The priority of scanning 510 can be calculated using any desired algorithm. Figure 5 410 and the amount of data from table 410 currently cached in cache 430. As a specific example, the priority may be calculated as the size of table 410 minus the amount of data from table 410 currently cached in cache 430. As an equation, Figure 5 The priority of the scan 510 may be set equal to the total table blocks - (cached dirty data blocks + cached valid data blocks). (Note that the above equation uses blocks instead of bytes, but the disclosed embodiments may support the use of bytes or other data units as an alternative).

[0076] In the above description, the scanning of the relatively large table 410 may be prioritized over the scanning of the relatively small table 410. In addition, Figure 5 The priority of the scan 510 may be decreased based on the amount of data from the table 410 currently cached in the cache 430. These factors mean that a higher value indicates a higher priority for the scan, and a lower value indicates a lower priority for the scan. However, the disclosed embodiments may also include a scan priority calculator 440 that calculates a priority, where a low value indicates a relatively high priority, and a high value indicates a relatively low priority.

[0077] Figure 6 The determination according to the embodiment of the present disclosure is shown Figure 5 Scan 510 priority Figure 4 The scanning priority calculator 440. Figure 6 In a given scan 510 (which involves Figure 4 Table 410), Figure 4 The cache query unit 435 may be used to determine Figure 4 The data size 605 of the table 410 and / or Figure 4 The cache data size 610 of the table 410 (which may be related to Figure 4 Table 410 Figure 4 The amount of dirty data in the cache 430 and Figure 4 Table 410 Figure 4 The scan priority calculator 440 may then use the data size 605 and the cache data size 610 to determine a priority (eg, a scan priority) 615 to assign to the scan 510 .

[0078] Return again Figure 4 ,once Figure 6Priority 615 has been assigned to the pending query Figure 5 All scans 510, the kernel dispatch unit 445 can be based on Figure 5 Scan 510 Figure 6 The priority level 615 will dispatch core 415 to Figure 5 Any method can be used to assign the kernel 415 to the scan. For example, Figure 6 The priority 615 order will be dispatched to the core 415 Figure 5 That is, one or more cores 415 may be assigned to have Figure 6 The highest priority is 615 Figure 5 The scan 510 may then dispatch one or more cores 415 to a Figure 6 The next highest priority is 615 Figure 5 Scan 510, and so on. Alternatively, Figure 5 Scan 510 Figure 6 Priority 615 but also through Figure 5 Each scan of 510 Figure 6 The weighted priority 615 of core 415 is assigned to Figure 5 That is, the total number of available cores may be determined, and then the number of available cores may be multiplied by the “ Figure 5 Each scan 510 Figure 6 The priority of 615 is relative to Figure 6 The method gives Figure 5 The higher priority scan 510 more cores 415, but can be avoided Figure 5 The scan 510 has Figure 6 The relatively low priority 615 of the core 415 is "starved". In other words, using Figure 6 The weighted priority 615 helps ensure that even Figure 5 The scan 510 does not have Figure 6 The relatively high priority 615, Figure 5 Each scan 510 of can also be dispatched to a kernel 415. As an equation, if k Indicates the number of available cores, s express Figure 5 The number of scans 510, and p i Indicates i Scanned Figure 6 The priority level is 615, then it is assigned to Figure 5 The number of kernels for each scan 510 can be expressed as If this equation does not result in an integer number of cores being dispatched to Figure 5For a particular scan 510 of , the calculated result may be rounded (up or down) to the nearest integer, or the fractional portion may simply be discarded. Figure 7 An example of application of this weighted priority method is shown.

[0079] The above method can treat all cores 415 as equal. That is, in determining Figure 6 The kernel dispatch unit 445 may assume that any kernel 415 can execute Figure 5 510. This assumption may not hold true if different cores 415 implement different scanning functions. To address such assumptions, the core dispatch unit 445 may group the available cores 415 based on what scanning functions the available cores 415 actually implement, and may process each group of available cores 415 separately. Similarly, the core dispatch unit 445 may group the available cores 415 based on which cores 415 are capable of performing Figure 5 Each scan 510 to Figure 5 The scan 510 is grouped. In this case, in addition to the number of available cores 415 k and Figure 5 The number of scans 510 s can be reduced to the size of each applicable group (i.e., the expected number of Figure 5 The same equations as above can be used to determine the number of scans 510 that can be performed and the number of cores 415 that can execute such an algorithm). Of course, in disclosed embodiments where a core 415 can be modified to perform different scan functions (e.g., disclosed embodiments where a core 415 is implemented using a processor or FPGA), any core 415 may be able to perform any scan function simply by modifying the core 415 appropriately for the next scan function, in which case Figure 5 Such subdivision of kernel 415 and scan 510 may be avoided.

[0080] In some cases, Figure 5 A scan 510 (eg, scan 510-1) may be relative to Figure 5 Other scans 510 (eg, scan 510 - 2 ) have Figure 6 A sufficiently low priority 615, so that the kernel dispatch unit 445 may not ultimately dispatch any kernel 415 to Figure 5 In this case, a software implementation of the scanning algorithm may be used to perform Figure 5 of the scan 510, wherein the kernel 415 is not considered for Figure 5 Scan 510.

[0081] Note that accelerator 135 may be used at any time to determine Figure 5 Scan 510 Figure 6priority 615. In some cases, when kernel 415 has executed Figure 5 During the other scans 510, the accelerator 135 may be expected to determine Figure 5 Scan 510 Figure 6 priority 615. For example, Figure 5 After the query 505 of other clients has been processed, it is received from the client Figure 5 In this case, the accelerator 135 can be allocated only among the cores 415 that are currently available: that is, the cores that are not currently assigned to execute Figure 5 Thus, if the accelerator 135 includes, for example, 10 cores 415, but six cores 415 are already executing Figure 5 The scan 510 is assigned to Figure 5 Scan 510 but has not started execution Figure 5 510, then for Figure 5 For a newly received query 505, there may be only four cores 415 available for dispatching to Figure 5 510, and the core dispatch unit 445 may function to dispatch only from those four cores 415 instead of from all 10 cores 415. In other disclosed embodiments, the accelerator 135 may be configured to dispatch even for the currently executing Figure 5 The scan 510 of the kernel 415 also determined Figure 5 Scan 510 Figure 6 Priority 615: Then based on Figure 6 The new scan priority 615 will already be executing Figure 5 The scan 510 core 415 is reassigned to Figure 5 The new scan 510.

[0082] In some disclosed embodiments, the core dispatch unit 445 may choose to dispatch all available cores 415 to Figure 5 This approach can minimize the downtime of the core 415: keeping the core 415 as functional as possible can be a goal. However, in other disclosed embodiments, the core dispatch unit 445 may choose not to dispatch the core 415 to the Figure 5 For example, the core dispatch unit 445 may keep a certain number or percentage of cores 415 undispatched so that they are available for future scans that may be received. Figure 5 The method may aim to optimize the scanning efficiency rather than maximize the kernel. Alternatively, the kernel dispatch unit 445 may wait for the Figure 5 Query 505 Figure 5 The scan 510 is dispatched until enough cores 415 are available Figure 5 Query 505 Figure 5 The method may aim to: Figure 5 Query 505 may be delayed waiting for core 415 to become available, but also ensures that the query is executed in core 415 (if possible) (recognizing that even considering the delay of waiting for core 415 to become available, the query ... the query 505 may be delayed waiting for core 415 to become available, but the query 505 may be delayed waiting for core 415 to become available, Figure 5 The query 505 can also be faster than using software).

[0083] Note that just because the kernel dispatch unit 445 may have Figure 5 The fact that a particular scan 510 is dispatched to a particular kernel 415 does not mean that the kernel 415 will ultimately execute Figure 5 510. As discussed further below, it is ultimately the database management system cost function that determines what scan function to apply. Figure 5 If the kernel 415 of the scan 510 does not support the scan function selected by the database management system cost function, then even if the kernel 415 is dispatched to the kernel dispatch unit 445 Figure 5 Scan 510, Figure 5 The scan 510 may also be performed in software. Thus, the database management system cost function may ultimately be responsible for determining Figure 5 The scan 510 is performed by the kernel 415 or in software (e.g., Figure 1 The processor 110 executes the

[0084] Why can't the core dispatch unit 445 dispatch all available cores 415 to Figure 5 Another example of scanning 510, the kernel dispatch unit 445 may recognize that there may be Figure 5 The upper limit of the number of kernels 415 for accelerating a particular scan 510 is set, and the additional kernels are applied to Figure 5 A single scan 510 of may not be worthwhile. For example, consider Figure 5 A single query of 505 is pending and Figure 5 The query 505 only Figure 5 Furthermore, assume that table 410 is relatively small: for example, only one block of data (which can be processed by kernel 415 in a single iteration of the scanning algorithm executed). Figure 5 The scan 510 Figure 6 The priority 615 may be relatively low.

[0085] because Figure 5 The scan 510 is Figure 5 The only scan considered is 510, so Figure 6 Whether the priority 615 is low or high can be considered irrelevant: Figure 5 The scan 510 of can still be assigned to all available cores 415. However, since the table 410 is relatively small, multiple cores 415 are assigned to Figure 5 The scan 510 of may have little or no benefit: a single core 415 may be sufficient. In this case, the core dispatch unit 445 may dispatch only some (or one) of the available cores 415 instead of all the available cores 415 to the Figure 5 Scan 510.

[0086] As mentioned above, although the core dispatch unit 445 can dispatch the core 415 to Figure 5 Scan 510, but core 415 is dispatched to Figure 5 The fact that scan 510 does not guarantee that kernel 415 is actually used to execute Figure 5 The kernel 415 may implement a particular scanning function. However, the database management system may have a variety of different scanning algorithms that can be used, and a cost function may be used to determine which scanning algorithm is considered to be effective. Figure 5 The best choice for each scan 510. The scanning algorithm implemented by the kernel 415 may represent only one such function and may not be selected as the lowest cost function to be used.

[0087] If the database management system cost function does not select kernel 415 to execute Figure 5 If the scanning function of the specific scan 510 is not implemented, the core 415 is not actually used. Therefore, the core 415 can be allocated to execute only if the database management system cost function selects the scanning algorithm implemented by the core 415. Figure 5 The allocation is handled by the kernel allocation unit 450. Once the database management system cost function has selected a scan to be executed by the kernel 415 Figure 5 The kernel allocation unit 450 can instruct the kernel 415 to actually start executing Figure 5 In some disclosed embodiments, the kernel allocation unit 450 may also notify the kernel release unit 455, discussed further below, of the allocation to the kernel. Figure 5 The specific core 415 of scan 510 was not assigned to Figure 5 of the scan 510 and may be released.

[0088] Note that there is a difference between core dispatching and core allocation: core dispatching can involve reserving cores for use Figure 5 510, while kernel allocation may involve actually using a kernel to perform Figure 5510 of the scan. This distinction can be thought of as analogous to the difference between making a reservation for dinner at a restaurant and showing up at the restaurant when the reservation is made: the former ensures that the table is waiting for the diner, but the diner does not actually use the table until the diner shows up at the restaurant. Similarly, the kernel dispatch unit 445 dispatches the kernel 415 to Figure 5 The scan 510 does not ensure that the kernel 415 is used to execute Figure 5 Scan 510: The kernel 415 may be allocated only at the kernel allocation unit 450 to execute Figure 5 After scanning 510, it is used to perform Figure 5 The scan 510 may be performed by the scanning algorithm implemented by the kernel 415 depending on the database management system cost function. Figure 5 Scan 510.

[0089] The complexity lies in the fact that in some disclosed embodiments, the database management system cost function may not be aware of the kernel 415 that is available to perform Figure 5 Scan 510. After all, if there is no available Figure 5 The database management system cost function considers the kernel 415 to perform the scan 510. Figure 5 However, even if core 415 is available, this fact does not necessarily mean that core 415 can be used to execute Figure 5 As discussed above, Figure 5 Prioritizing which scans 510 may be performed by the kernel 415 means that the kernel 415 may or may not be available to perform Figure 5 Any single scan 510. In addition, depending on the scanning function implemented by the kernel 415, even if the kernel 415 is available, the kernel 415 may not be Figure 5 The best choice for a particular scan 510. Therefore, the database management system cost function may not assume Figure 5 Any particular scan 510 should be performed by the kernel 415. In other words, in some disclosed embodiments, the kernel 415 is Figure 5 The dispatch of the scan 510 may precede the execution of the database management system cost function so that the database management system cost function only considers the data that is actually available for execution. Figure 5 The scanning function of 510 is that when it comes to execution Figure 5 The kernel allocation unit 450 may be executed during the scan 510 .

[0090] As discussed above, some data from table 410 may be in cache 430. Assuming that accelerator 135 cannot access cache 430 (or accessing data from cache 430 may be slower than accessing data from storage device 120 due to distance or access protocol), ensuring that any data in cache 430 is available before kernel 415 executes Figure 5 It may be important that the cache flush unit 460 triggers the flushing of any data from the cache 430 (again, as discussed above, this may involve flushing data from a database management system or Figure 1 415 ) to ensure that the accelerator 135 (and more specifically, the kernel 415 ) can access the latest data from the table 410 . However, since the kernel 415 can only perform Figure 5 The scan 510 needs to access the data, so there may be a link between the kernel allocation unit 450 and the cache flush unit 460: if the kernel 415 is not allocated to the cache by the kernel allocation unit 450, Figure 5 In other words, calling the cache flushing unit 460 may be the first step for the kernel 415 to start executing the table 410. Figure 5 The last operation (or one of the last operations) before scanning 510.

[0091] Flushing data from cache 430 back to storage 120 may involve writing any dirty data back to storage 120 and removing any clean data (i.e., data that is valid but has not been updated) from cache 430. By writing dirty data back to storage 120, it is ensured that kernel 415 has access to the latest data (including any updates that the client may have made). By removing any clean data from cache 430, cache flushing unit 460 may ensure that any client may have the latest data from database 405, again ensuring that all clients are working from the same data (and preventing clients from updating cache data that kernel 415 may not have access to).

[0092] There is another potential result of the accelerator 135 being unable to access the cache 430. This other result is that the cache flush unit 460 may not be able to selectively flush specific blocks (or other bits of data) from the cache 430. Therefore, in some disclosed embodiments, the cache flush unit 460 may trigger all data in the cache 430 to be flushed to the storage device 120. However, in other disclosed embodiments, the cache flush unit 460 may be able to specify what data is flushed from the cache 430 back to the storage device 120: for example, the cache flush unit 460 may be able to specify that only the data of the table 410 is flushed back to the storage device 120, wherein any data from other tables remains in the cache 430. In such disclosed embodiments, the dirty data of the table 410 in the cache 430 may be flushed to the storage device 120, and the clean data of the table 410 may be deleted from the cache 430, but the data of other tables may remain in place. Such a more selective approach may allow the client to continue to update data in cache 430, wherein such updates may not affect the execution of the kernel 415. Figure 5 Scan 510.

[0093] In other disclosed embodiments, the cache flush unit 460 may write only the dirty data of the table 410 back to the storage device 120, but leave the clean data of the table 410 in the cache 430. Leaving the clean data of the table 410 in the cache 430 may allow other scans or clients to access such data more quickly. However, in such disclosed embodiments, it may be important to mark the clean data of the table 410 in the cache 430 so that if any client attempts to update the data of the table 410 in the cache 430, such updates are instead directed to the storage device 120 (to ensure that the kernel 415 continues to have access to the latest data of the table 410). Such disclosed embodiments may involve setting a bit in the cache 430 to indicate that a particular block (or other unit of data) is not writable (at least when executed by the kernel 415). Figure 5 During the scan 510: When the kernel 415 completes Figure 5 510, such a bit may be reset) to ensure that updated data is written to storage device 120 instead. In addition, if the flag is set, cache 430 may know that blocks (or other data bits) in cache 430 may need to be flushed after the update operation is completed.

[0094] Finally, the kernel release unit 455 can release the unused Figure 5 The kernel 415 of the scan 510. One way in which the kernel 415 may be released is if the kernel 415 completes execution Figure 5 Once the kernel 415 has completed execution: Figure 5 The scan 510, kernel 415 can be used to Figure 5 Another scan 510 of and may be released. However, recall that the database management system cost function may not select the scanning algorithm implemented by the kernel 415 to perform Figure 5 Scan 510: The database management system cost function can select different scanning algorithms (in addition to the kernel 415) to perform Figure 5 In this case, the kernel 415 may also be released so that the kernel 415 can be used for dispatching to Figure 5 Other scans 510.

[0095] When core 415 has been allocated Figure 5 When scanning 510, it is determined when the kernel 415 has completed execution Figure 5 The scan 510 of may be as simple as determining that the kernel 415 is no longer actively executing instructions. (Alternatively, the kernel 415 may perform the scan 510 after completing its scan.) Figure 5 When the scan 510 is executed, a signal is sent to the kernel release unit 455 to let the kernel release unit 455 know that the kernel 415 is available again), but it is determined that the kernel 415 is assigned to Figure 5 Scan 510 but not assigned to Figure 5 Scan 510 (e.g., because the database management system cost function selects a different scan function than kernel 415) is a different problem: it is not currently executed Figure 5 The core 415 of the scan 510 may just be waiting to start, rather than being unallocated.

[0096] There are various possible solutions for solving this situation. In some disclosed embodiments, when assigned to Figure 5 The core 415 of Scan 510 is not actually assigned to Figure 5 When scanning 510, the kernel allocation unit 450 can notify the kernel release unit 455. In other disclosed embodiments, the kernel dispatch unit 445 can associate the timestamp with the kernel 415 to Figure 5 Then, when the kernel release unit 455 executes, it can associate the kernel 415 with the dispatch of the scan 510. Figure 5 The timestamp associated with the dispatch of the scan 510 is compared with the current timestamp. If the difference between the timestamps is greater than the threshold difference, the core release unit 455 can conclude that the core 415 is not allocated by the core allocation unit 450 and can be released to be used for Figure 5 Other scans 510.

[0097] The core release unit 455 can be used to maintain which cores 415 are currently assigned to Figure 5 of the scan 510 and which cores 415 are currently available to be dispatched to Figure 5510 table to operate. Note that in such an embodiment disclosed, each kernel 415 may only require one bit, thereby minimizing the amount of storage required. When the kernel dispatch unit 445 dispatches a kernel 415 to Figure 5 510, the table may be updated to set the flag, and when the kernel 415 has completed execution Figure 5 When scanning 510 of , the table can be reset by the kernel release unit 455. Note that the kernel release unit 455 can also maintain other information in the table (such as when the kernel dispatch unit 445 dispatches the kernel 415 to Figure 5 timestamp of the scan 510). As discussed above and with further reference to the following Figure 8 , which can be used to determine the amount of time that is allocated to the Figure 5 The core 415 of Scan 510 was not assigned to Figure 5 Such a scan 510.

[0098] Figure 7 Showing the embodiment according to the disclosure Figure 4 The kernel 415 is based on Figure 6 A scan priority of 615 is assigned to Figure 5 Scan 510. Figure 7 , four scans 510 - 1 through 510 - 4 are shown, each with a corresponding priority 615 - 1 through 615 - 4 (which may be collectively referred to as priority 615 ). Figure 7 Also shown are five cores 415-1 through 415-5. Figure 7 Four scans 510 and five kernels 415 are shown, but the disclosed embodiments may include any number of scans 510 and any number of kernels 415: Figure 7 The four scans 510 and five kernels 415 shown in FIG. 4 are examples only.

[0099] Summing the priorities 615 yields a total of 36 (12+12+8+4). This means that among the five cores 415, scans 510-1 and 510-2 can each be assigned two of the cores 415 ( , which is rounded up to two). Scan 510-3 may be dispatched to one of the kernels 415 ( , which is rounded down to 1). Scan 510-4 may not be dispatched to kernel 415 ( , which is rounded up to one, but all cores 415 have been dispatched), and the database software scanning function can be used to fall back.

[0100] It is noteworthy that scans 510-1 and 510-2 each have more than one core 415 assigned to them. This may raise the following question: How can two cores 415 be used for a single scan? The answer is that each of cores 415-1 to 415-4 can process a portion of the data in scans 510-1 and 510-2, which can speed up the overall execution of scans 510-1 and 510-2.

[0101] Figure 8 Determining when to release according to the disclosed embodiment Figure 4 Kernel 415 Figure 4 The kernel releases unit 455. Figure 8 , the kernel release unit 455 is shown as receiving timestamps 805-1 and 805-2 (which may be collectively referred to as timestamp 805) and threshold 810. Timestamp 805-1 may represent when Figure 4 The kernel dispatch unit 445 will Figure 4 The kernel 415 is assigned to Figure 5 510, and it can be stored, for example, in a table managed by the kernel release unit 455. Timestamp 805-2 can represent a current timestamp: for example, a timestamp when the kernel release unit 455 is called. Based on timestamps 805-1 and 805-2, the kernel release unit 455 can determine a difference, and can compare the difference to a threshold value 810. If the difference between timestamps 805-1 and 805-2 meets threshold value 810 (for example, if the difference between timestamps 805-1 and 805-2 is greater than threshold value 810), the kernel release unit 455 can conclude that Figure 4 The kernel 415 has waited long enough and can be released to be used for execution Figure 5 Another scan 510 of . Note that the difference may “satisfy” the threshold 810 in any desired manner: for example, the difference may be less than, less than or equal to, greater than, or greater than or equal to the threshold 810 to “satisfy” the threshold 810 .

[0102] Fig. 9 Showing the embodiment according to the disclosure Figure 1 The accelerator 135 will Figure 4 The kernel 415 is assigned to Figure 5 A flowchart of an example procedure for scanning 510 is provided. Fig. 9 In block 905, Figure 1 The accelerator 135 can be recognized Figure 4 kernel 415. In this context, “identification” Figure 4 The kernel 415 may be understood to mean recognizing Figure 4 The specific core 415 can be used to process Figure 5 Query 505 in Figure 5 Scan 510 can be used with Figure 4 The specific identifier associated with the kernel 415 (which can be Figure 4 The kernel 415 and Figure 4 any other kernel 415). For example, if Figure 4 Different kernels 415 may implement different scanning algorithms, and only some of those scanning algorithms may be applicable to Figure 5 Scan 510, then at box 905, only Figure 4 The kernel(s) implementing the applicable scanning algorithm 415. Note also that Figure 1 The accelerator 135 may be identified at block 905 Figure 4 More than one core 415, which can be Figure 4 More than one core 415 may be assigned to Figure 5 A scan of 510 occurs.

[0103] At block 910, Figure 4 The query obtaining unit 425 can identify Figure 5 Query 505 in Figure 5 Scan 510. Figure 5 A scan of 510 can be obtained from Figure 4 Table 410 access data, Figure 4 The data of table 410 is stored in Figure 1 The storage device 120 Figure 4 In the database 405, Figure 1 The accelerator 135 can be connected to Figure 1 The storage device 120. Note that Figure 5 The query 505 may include Figure 5 More than one scan 510, which means Figure 4 The query obtaining unit 425 may identify at block 910 Figure 5 More than one scan 510. At block 915, Figure 4 The scan priority calculator 440 may determine Figure 5 Scan 510 Figure 6 Priority 615 (or if Figure 4 The query obtaining unit 425 identifies in block 910 Figure 5 More than one scan 510, then determine Figure 5 Each scan of 510 Figure 6 Finally, at block 920, Figure 4 The kernel dispatch unit 445 can be based on Figure 6 The priority 615 will Figure 4 The kernel 415 is assigned to Figure 5 510 (or more generally, Figure 4 One or more cores 415 are assigned to Figure 5 One or more scans 510).

[0104] Fig.10 Showing the embodiment according to the disclosure Figure 1 Accelerator 135 recognition Figure 5 A flowchart of an example procedure for scanning 510 is provided. Fig.10 In block 1005, Figure 4 The query obtaining unit 425 can be obtained from Figure 4 Database 405 obtained Figure 5 At block 1010, the query obtaining unit may use its own parser to parse the query 505 and identify Figure 5 Optionally, at block 1015, Figure 4 The query obtaining unit 425 may request Figure 4 The database 405 Figure 5 The query 505 is parsed to identify Figure 5 Scan 510.

[0105] Fig.11 Showing the embodiment according to the disclosure Figure 1 The accelerator 135 determines Figure 5 Scan 510 Figure 6 A flowchart of an example procedure for scanning priority 615 is shown. Fig.11 In block 1105, Figure 4 The cache query unit 435 may determine the Figure 5 Scan 510 access Figure 4 Table 410 Figure 6 Size 605. Figure 4 The cache query unit 435 can also determine from Figure 4 The current cache of table 410 is in Figure 4 The amount of data in the cache 430 Figure 6 The size is 610. Note that from Figure 4 The current cache of table 410 is in Figure 4 The amount of data in the cache 430 Figure 6 The size 610 may include Figure 4 Table 410 Figure 4 The amount of dirty data in the cache 430 and the Figure 4 Table 410 Figure 4 The amount of valid (clean) data in cache 430 . Figure 4 The cache query unit 435 can also determine the caches from Figure 4 Table 410 Figure 4The amount of dirty data and clean data in the cache 430. Optionally, at block 1110, Figure 4 The cache query unit 435 can query Figure 4 Finally, at block 1115, Figure 4 The scan priority calculator 440 may be based on the table 410 Figure 6 The size of 605 and the current cache is Figure 4 The amount of data in the cache 430 Figure 6 The size of 610 is calculated Figure 5 Scan 510 Figure 6 The priority is 615.

[0106] Fig.12 Showing the embodiment according to the disclosure Figure 1 The accelerator 135 uses Figure 4 The kernel 415 executes Figure 5 Scan 510 and release Figure 4 A flowchart of an example program of the kernel 415 is shown. Fig.12 In block 1205, Figure 1 The accelerator 135 may determine whether the database management system cost function has been selected Figure 4 The kernel 415 executes Figure 5 If yes, then at block 1210, Figure 4 The cache flushing unit 460 can flush Figure 4 cache 430, at block 1215, Figure 4 The kernel allocation unit 450 can Figure 4 The kernel 415 is assigned to the scan 510, and at block 1220, Figure 4 Kernel 415 executable Figure 5 Finally, at block 1225, Figure 4 The kernel release unit 455 can Figure 4 The core 415 is released back to the pool of available cores.

[0107] If the DBMS cost function does not select Figure 4 The kernel 415 executes Figure 5 510, then processing may proceed directly to block 1225 to enable Figure 4 The kernel release unit 455 will Figure 4 The core 415 is released back to the pool of available cores.

[0108] Fig.13 Showing the embodiment according to the disclosure Figure 1 Flow chart of an example procedure for flushing cache data of the accelerator 135. Fig.13In block 1305, Figure 4 The cache flush unit 460 may request to Figure 4 The cache 430 Figure 4 Any dirty data in table 410 is written back Figure 1 Then, at block 1310, Figure 4 The cache flush unit 460 may request from Figure 4 Cache 430 deleted Figure 4 Any valid (clean) data in Table 410. Note that if Figure 4 The cache flush unit 460 can access Figure 4 The cache 430 itself, then Figure 4 The cache flush unit 460 may perform these operations directly without requiring other elements (such as a database management system or an operating system) to perform such operations.

[0109] Fig.14 Showing the embodiment according to the disclosure Figure 1 The accelerator 135 determines whether a releasable has been assigned to Figure 5 of scan 510 but has not yet been assigned to Figure 5 Scan 510 Figure 4 A flowchart of an example program of the kernel 415 is shown. Fig.14 In block 1405, Figure 4 The kernel dispatch unit 445 can access Figure 4 Kernel 415 to Figure 5 The scan 510 is associated with the dispatch Figure 8 timestamp 805-1. At block 1410, Figure 4 The kernel release unit 455 may determine Figure 8 Timestamp 805-2, Figure 8 The timestamp 805-2 may represent Figure 1 The current time of the machine 105. At block 1415, Figure 4 The kernel release unit 455 may determine Figure 8 The timestamp 805-1 is Figure 8 The difference between the timestamp 805-2 and the timestamp 805-3 can be determined whether the difference satisfies Figure 8 If yes, then at block 1420, Figure 4 The kernel release unit 455 can Figure 4 The kernel 415 is released back to the available kernel pool; otherwise, at box 1425, Figure 4 The kernel release unit 455 can Figure 4 The kernel 415 is assigned to Figure 5 Scan 510.

[0110] existFigures 9 to 14 In the flowchart, some embodiments of the disclosure are shown. However, those skilled in the art will recognize that other embodiments of the disclosure are possible by changing the order of the blocks, by omitting blocks, or by including connections not shown in the drawings. All such variations of the flowchart are considered disclosed embodiments, whether explicitly described or not.

[0111] The disclosed embodiments may support determining the priority of scans for queries issued by a client to a database. By determining the priority of the scans, cores in an accelerator may be assigned to the scans in proportion to the priority of the scans. By assigning cores to scans in proportion to the priority of the scans, some cores may be assigned to different scans, thereby providing improved processing of multiple scans using the cores. This method provides technical advantages over simply assigning all cores in an accelerator to the first scan encountered in a query.

[0112] The disclosed embodiments include mechanisms for managing tail latency across multiple queries and supporting fair distribution of scan kernels among parallel scans. The disclosed embodiments avoid dispatching all scan kernels to one scan, resulting in one scan acquiring all resources and other possible parallel scans falling back to the native scan algorithm of the database management system (DBMS), regardless of their need for resources. The disclosed embodiments may also support scans that are aware of DBMS / operating system (OS) cache updates: the disclosed embodiments may thus avoid reading data from disk that has not yet been updated to disk. The disclosed embodiments may also enable different database clients to access updated kernel information, their availability, and real-time dispatching. The disclosed embodiments may also take into account relations that will be scanned in cache. Falling back to the DBMS scan algorithm when most relations are available in cache may have a significant impact on performance.

[0113] To find the query being executed at the current time, the DBMS cumulative statistics system can be queried. Given the original query in the access system, the DBMS internal parser can be used to extract the relations that need to be scanned. Among these scan candidates, the cache statistics of each relation can be obtained. Then, the priority value of each scan can be calculated based on the relation size and the cache statistics of each relation: Priority=relation.blocks-relation.cache.valid-relation.cache.dirty These parameters and how they are used to generate priority scores can be tested and adjusted based on different scenarios, use cases, and the state of the system. In some disclosed embodiments, the priority function can assign a score of zero to relationships whose majority of blocks are valid or dirty or whose number of dirty pages is greater than a certain threshold: If relation.cache.dirty + relation.cache.valid>relation.blocks / 2 || relation.cache.dirty>MAX_DIRTY then priority = 0; Afterwards, available cores can be distributed to scans in proportion to their priorities: The number of cores assigned to a relation = (the number of available cores × the relation priority) / the sum of the priorities of all processed relations The kernel dispatch function may be called by each scan in the planner phase. This function analyzes all relations in all queries currently running in the system that have not been analyzed before. Therefore, it is possible that a kernel dispatch call of a single scan may dispatch kernels to other scans. However, if kernel dispatch has already been completed for the scan that called the function during a function call of a previous scan, no more dispatches are made. Furthermore, if there are no kernels available in the system, no dispatches may be made. This function may be protected by a mutex lock, so when there are multiple simultaneous queries, the first one to acquire the lock runs the function and has it decide all current scans in the system.

[0114] In general, the kernel dispatch function does the following: Acquire Lock Release stalled cores (these are cores that have been previously dispatched to a scan and have not been claimed after a certain amount of time, perhaps due to a cost function bidding loss) Computes and dispatches kernels to all available scans in the system that have not previously been assigned a kernel.

[0115] Cache Scan Cache information for a particular relation may not be directly available. To determine the number of valid, dirty, or invalid blocks for a relation, the DBMS cache system may be queried for each block of the relation. Given cache information for a particular block of a particular relation, the disclosed embodiments may loop through all blocks and collect information about all blocks. In a cache scan, the number of dirty pages for a relation and the number of valid pages for a relation may be identified. Since flushing specific pages of a relation may not be feasible, the disclosed embodiments may only track the number of dirty and valid pages for a relation in the cache, without tracking specific dirty pages and specific valid pages of a relation in the cache. However, in some disclosed embodiments, specific dirty pages and specific valid pages of a relation in the cache may be tracked.

[0116] After scanning the cache for a relationship, the statistical information may be stored in shared memory. There are several reasons for doing this. First, other relationships may release kernel computation mechanisms for accessing this information. Second, the information may be reused for subsequent scans of the relationship. In systems where scans are more frequent than writes, reusing a relationship that has been previously scanned may reduce the resources used. The disclosed embodiments may use a counter to indicate how many times the cache statistics for a relationship have been used without rescanning the cache for the relationship. Basically, the disclosed embodiments may maintain a local cache of cache statistics for each relationship.

[0117] Flush dirty pages Before starting a scan (execution initialization phase), the dirty pages of a relation can be flushed so that the latest version of the relation is scanned. In this phase, the cache statistics of the relation can be checked: if the relation is already available and not expired, it can be used to find out if there are any dirty pages and whether a cache flush is needed. If the relation is not available or expired, the cache can be scanned for the relation: the statistics collected can then be used to decide whether to flush the cache. Cache flushing can be done with two different calls: one for flushing the DBMS cache and one for flushing the OS cache.

[0118] Handling backoff caused by cost functions The cost function of the scan is called in the planning phase. In this phase, the cost bids made by the scan API and other scan algorithms can be determined, and the algorithm with the lower / lowest cost can be used to perform the scan. However, because other scans may also be trying to use resources, the disclosed embodiments may cause some scans to not be assigned the requested resources. Basically, in the planning phase, the disclosed embodiments can decide how many cores to allocate to the scan, and those cores can be reserved. The disclosed embodiments can expect to allocate these cores later in the execution initialization phase. However, if the scan API loses the cost bid to another scan algorithm, the execution initialization phase may not be called, and the disclosed embodiments may not know that those cores should not be reserved for other scans. Therefore, the disclosed embodiments can track the time cores reserved for the scan. Whenever a core allocation is performed, the disclosed embodiments can check for scans that have reserved cores but have not yet claimed them. If a threshold amount of time has passed, those cores may not be reserved.

[0119] The following discussion is intended to provide a brief, general description of one or more suitable machines that can implement specific aspects of the disclosure. One or more machines may be controlled at least in part by input from conventional input devices (such as keyboards, mice, etc.) and by instructions received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signals. As used herein, the term "machine" is intended to broadly cover a single machine, a virtual machine or a system of machines that are communicatively combined, multiple virtual machines, or devices that operate together. Exemplary machines include computing devices (such as personal computers, workstations, servers, portable computers, handheld devices, phones, tablets, etc.) and transportation devices (such as private or public transportation (e.g., cars, trains, taxis, etc.)).

[0120] One or more machines may include embedded controllers (such as programmable or non-programmable logic devices or arrays, application specific integrated circuits (ASICs), embedded computers, smart cards, etc.). One or more machines may utilize one or more connections to one or more remote machines (such as through a network interface, modem, or other communication combination). The machines may be interconnected by way of physical networks and / or logical networks (such as intranets, the Internet, local area networks, wide area networks, etc.). Those skilled in the art will appreciate that network communications may utilize a variety of wired and / or wireless short-range or long-range carriers and protocols (including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth, etc.). ® light, infrared, cable, laser, etc.).

[0121] Embodiments of the present disclosure may be described by reference to or in conjunction with associated data including functions, programs, data structures, applications, etc., which, when accessed by a machine, cause the machine to perform a task or define an abstract data type or low-level hardware context. The associated data may be stored, for example, in volatile and / or non-volatile memory (e.g., RAM, ROM, etc.), or in other storage devices and their associated storage media (including hard drives, floppy disks, optical storage devices, tapes, flash memory, memory sticks, digital video disks, biometric storage devices, etc.). The associated data may be transmitted in a transmission environment (including physical and / or logical networks) in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format. The associated data may be used in a distributed environment and stored locally and / or remotely for machine access.

[0122] The disclosed embodiments may include a tangible, non-transitory machine-readable medium including instructions executable by one or more processors, including instructions for performing elements of the disclosure as described herein.

[0123] The various operations of the above methods may be performed by any suitable means capable of performing the operations (such as various hardware and / or software components, circuits and / or modules). Software may include an ordered list of executable instructions for implementing logical functions, and may be embodied in any "processor-readable medium" for use by or in conjunction with an instruction execution system, device or apparatus (such as a single-core or multi-core processor or a system containing a processor).

[0124] The blocks or steps of the methods or algorithms and functions described in conjunction with the embodiments disclosed herein may be directly embodied in hardware, software modules executed by a processor, or a combination of the two. If implemented in software, the functions may be stored on or transmitted via a tangible, non-transitory computer-readable medium. The software module may reside in a random access memory (RAM), flash memory, read-only memory (ROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, a hard disk, a removable disk, a CD ROM, or any other form of storage medium known in the art.

[0125] Having described and illustrated the principles of the disclosure with reference to the illustrated embodiments, it will be appreciated that the illustrated embodiments may be modified in arrangement and detail without departing from these principles, and may be combined in any desired manner. Also, although the foregoing discussion has focused on specific embodiments, other configurations are contemplated. Specifically, even though expressions such as "according to the disclosed embodiments" are used herein, these phrases are generally intended to refer to embodiment possibilities, and are not intended to limit the disclosure to specific embodiment configurations. As used herein, these terms may refer to the same or different embodiments that may be combined into other embodiments.

[0126] The foregoing illustrative embodiments should not be construed as limiting the disclosure thereof. Although some embodiments have been described, it will be readily appreciated by those skilled in the art that many modifications may be made to these embodiments without materially departing from the novel teachings and advantages of the present disclosure. Therefore, all such modifications are intended to be included within the scope of the present disclosure as defined in the claims.

[0127] The disclosed embodiments extend to the following statements without limitation: Statement 1. The disclosed embodiments include a device, the device comprising: a storage device storing a database including a table; and an accelerator connected to the storage device, the accelerator including a core; a scan priority calculator for calculating a priority of a scan of the table in a database stored on a storage device, the scan being associated with the query; and A kernel dispatching unit is configured to dispatch the kernel to the scan based at least in part on the priority of the scan.

[0128] Statement 2. A disclosed embodiment includes the apparatus of statement 1, wherein the apparatus is part of a database management system.

[0129] Statement 3. The disclosed embodiment includes the apparatus according to statement 1, further comprising: a receiver for receiving the query from a user end.

[0130] Statement 4. A disclosed embodiment includes the apparatus of statement 1 wherein the accelerator is separate from the storage device.

[0131] Statement 5. A disclosed embodiment includes the apparatus of statement 1, wherein the apparatus integrates a storage device and an accelerator.

[0132] Statement 6. A disclosed embodiment includes the apparatus of statement 1, wherein the accelerator comprises: a scan priority calculator and a core dispatch unit.

[0133] Statement 7. A disclosed embodiment includes the apparatus of statement 1, wherein the accelerator further comprises: a second core.

[0134] Statement 8. A disclosed embodiment includes an apparatus as described in statement 1, wherein the scan priority calculator is configured to: calculate the priority of the scan based at least in part on a first size of the table or a second size of an amount of data from the table in cache.

[0135] Statement 9. A disclosed embodiment includes the apparatus of statement 8, wherein the cache comprises: a first cache of a database management system or a second cache of an operating system.

[0136] Statement 10. A disclosed embodiment includes the apparatus of statement 8, further comprising: a cache query unit for determining a second size of the amount of data from the table in the cache.

[0137] Statement 11. A disclosed embodiment includes the apparatus of statement 10, wherein the cache query unit is configured to query a database management system to determine a first size of the table or a second size of an amount of data from the table in the cache.

[0138] Statement 12. A disclosed embodiment includes the apparatus of statement 1, wherein the scan priority calculator comprises: a query obtaining unit for obtaining the query from a database management system.

[0139] Statement 13. A disclosed embodiment includes the apparatus of statement 1, wherein the kernel dispatch unit is configured to dispatch the kernel to the scan of the second scan based at least in part on the priority of the scan and the second priority of the second scan.

[0140] Statement 14. A disclosed embodiment includes the apparatus of statement 13 wherein a second scan is associated with said query.

[0141] Statement 15. A disclosed embodiment includes the apparatus of statement 13 wherein the second scan is associated with a second query.

[0142] Statement 16. A disclosed embodiment includes the apparatus of statement 1 wherein the scan priority calculator comprises: a parser for parsing the query to identify the scan.

[0143] Statement 17. A disclosed embodiment includes the apparatus of statement 1, wherein: The database management system includes: a parser for parsing the query to identify the scan; and The scan priority calculator is configured to use a parser of the database management system.

[0144] Statement 18. The disclosed embodiment includes the apparatus according to statement 1, further comprising: a cache flushing unit for flushing the first cache of the database management system or the second cache of the operating system to the storage device.

[0145] Statement 19. A disclosed embodiment includes the apparatus of statement 18, wherein the cache flush unit is configured to write dirty data from the first cache of the database management system or the second cache of the operating system to the storage device.

[0146] Statement 20. A disclosed embodiment includes the apparatus of statement 18, wherein the cache flush unit is configured to delete valid data from the first cache of the database management system or the second cache of the operating system.

[0147] Statement 21. A disclosed embodiment includes the apparatus of statement 18, wherein the cache flush unit is configured to: perform the scan based at least in part on a database management system selecting the kernel to perform the scan.

[0148] Statement 22. A disclosed embodiment includes the apparatus of statement 1, further comprising: a kernel release unit for releasing the kernel based at least in part on the completion of the scan.

[0149] Statement 23. The disclosed embodiment includes the apparatus of statement 1, further comprising: a kernel allocation unit for allocating the kernel to the scan.

[0150] Statement 24. A disclosed embodiment includes the apparatus of statement 23, wherein the core allocation unit is configured to: allocate the core to the scan based at least in part on a database management system selecting the core to perform the scan.

[0151] Statement 25. A disclosed embodiment includes the apparatus of statement 1, further comprising: a kernel release unit configured to release the kernel based at least in part on database management system selection software performing the scan.

[0152] Statement 26. A disclosed embodiment includes the apparatus of statement 25, wherein: The kernel dispatch unit is configured to associate a first timestamp with the kernel and the scan; and The kernel release unit is configured to release the kernel based at least in part on a threshold difference between the first timestamp and the second timestamp.

[0153] Statement 27. The disclosed embodiments include a method comprising: Identify the cores in the accelerator; identifying a scan of a table in the query, the table being stored in a database on a storage device connected to the accelerator; prioritizing the scan; and The core is assigned to the scan based at least in part on a priority of the scan.

[0154] Statement 28. A disclosed embodiment includes the method of statement 27 wherein the accelerator is part of a database management system.

[0155] Statement 29. A disclosed embodiment includes the method of statement 27 wherein the accelerator is separate from the storage device.

[0156] Statement 30. A disclosed embodiment includes the method of statement 27 wherein the accelerator and the storage device are integrated into a single device.

[0157] Statement 31. A disclosed embodiment includes the method of statement 27 wherein the step of identifying the scan of the table in the query includes receiving a query from a user.

[0158] Statement 32. A disclosed embodiment includes the method of statement 31 wherein the step of receiving a query from a user comprises obtaining the query from a database management system.

[0159] Statement 33. A disclosed embodiment includes the method of statement 32 wherein the database management system receives the query from a user.

[0160] Statement 34. A disclosed embodiment includes the method of statement 27 wherein identifying the scan of the table in the query comprises parsing the query to identify the scan of the table.

[0161] Statement 35. A disclosed embodiment includes the method of statement 27 wherein the step of identifying the scan of the table in the query comprises: identifying the scan of the table in the query using a database management system.

[0162] Statement 36. The disclosed embodiment includes a method according to statement 27, wherein the step of determining the priority of the scan includes: calculating the priority of the scan based at least in part on a first size of the table or a second size of the amount of data from the table in the cache.

[0163] Statement 37. A disclosed embodiment includes the method of statement 36 wherein the cache comprises a first cache or a second cache of a database management system or an operating system.

[0164] Statement 38. A disclosed embodiment includes the method of statement 36 wherein the step of determining the priority of the scan further comprises determining a first size of the table or a second size of the amount of data from the table in cache.

[0165] Statement 39. The disclosed embodiment includes a method according to statement 38, wherein the step of determining a first size of the table and a second size of the amount of data from the table in the cache includes: querying a database management system for the first size of the table or the second size of the amount of data from the table in the cache.

[0166] Statement 40. A disclosed embodiment includes the method of statement 27, wherein: The step of identifying the kernel in the accelerator includes: identifying the kernel and a second kernel in the accelerator; Assigning the kernel to the scan based at least in part on a priority of the scan includes assigning the kernel and a second kernel to the scan based at least in part on a priority of the scan.

[0167] Statement 41. A disclosed embodiment includes the method of statement 27, wherein: The step of identifying the scan of the table in the query includes: identifying the scan of the table in the query and a second scan of a second table; The step of determining the priority of the scan includes: determining the priority of the scan and a second priority of a second scan; and The kernel is assigned to the scan or the second scan based at least in part on the priority of the scan and a second priority of the second scan.

[0168] Statement 42. A disclosed embodiment includes the method of statement 27, further comprising: performing said scanning using said kernel.

[0169] Statement 43. The disclosed embodiments include the method of statement 42, wherein causing the kernel to perform the scan comprises flushing a first cache of a database management system or a second cache of an operating system.

[0170] Statement 44. The disclosed embodiments include the method according to statement 43, wherein the step of flushing the first cache of the database management system or the second cache of the operating system includes: writing dirty data from the first cache of the database management system or the second cache of the operating system to a storage device.

[0171] Statement 45. The disclosed embodiments include the method according to statement 43, wherein the step of flushing the first cache of the database management system or the second cache of the operating system includes: deleting valid data from the first cache of the database management system or the second cache of the operating system.

[0172] Statement 46. The disclosed embodiment includes a method according to statement 43, wherein the step of flushing the first cache of the database management system or the second cache of the operating system includes: at least partially based on the database management system selecting the kernel to perform the scan to flush the first cache of the database management system or the second cache of the operating system.

[0173] Statement 47. A disclosed embodiment includes the method of statement 42 wherein the step of using the kernel to perform the scan includes determining that a database management system selects the kernel to perform the scan.

[0174] Statement 48. A disclosed embodiment includes the method of statement 47 wherein the step of performing the scan using the kernel further comprises: assigning the kernel to the scan.

[0175] Statement 49. A disclosed embodiment includes the method of statement 27, further comprising: performing said scanning based at least in part on a database management system selection software to release said kernel.

[0176] Statement 50. A disclosed embodiment includes the method of statement 49, wherein: The step of assigning the kernel to the scan based at least in part on the priority of the scan includes: storing a first timestamp; The step of performing the scan to release the kernel based at least in part on database management system selection software includes: determining a second timestamp; and It is determined that a difference between the first time stamp and the second time stamp exceeds a threshold difference.

[0177] Statement 51. The disclosed embodiments include an article of manufacture comprising a non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause: Identify the cores in the accelerator; identifying a scan of a table in the query, the table being stored in a database on a storage device connected to the accelerator; prioritizing the scan; and The core is assigned to the scan based at least in part on a priority of the scan.

[0178] Statement 52. A disclosed embodiment includes the article of manufacture of statement 51 wherein the accelerator is part of a database management system.

[0179] Statement 53. A disclosed embodiment includes the article of manufacture of statement 51 wherein the accelerator is separate from the storage device.

[0180] Statement 54. A disclosed embodiment includes the article of manufacture of statement 51 wherein the accelerator and the storage are integrated into a single device.

[0181] Statement 55. A disclosed embodiment includes the article of manufacture of statement 51 wherein the step of identifying the scan of the table in the query includes receiving a query from a user.

[0182] Statement 56. A disclosed embodiment includes the article of manufacture of statement 55, wherein the step of receiving the query from the client comprises obtaining the query from a database management system.

[0183] Statement 57. A disclosed embodiment includes the article of manufacture of statement 56 wherein the database management system receives the query from a user.

[0184] Statement 58. A disclosed embodiment includes the article of manufacture of statement 51 wherein identifying the scan of the table in the query comprises parsing the query to identify the scan of the table.

[0185] Statement 59. A disclosed embodiment includes the article of manufacture of statement 51 wherein the step of identifying the scan of the table in the query comprises: identifying the scan of the table in the query using a database management system.

[0186] Statement 60. The disclosed embodiment includes an article according to statement 51, wherein the step of determining the priority of the scan includes: calculating the priority of the scan based at least in part on a first size of the table or a second size of the amount of data from the table in the cache.

[0187] Statement 61. A disclosed embodiment comprises the article of manufacture of statement 60 wherein the cache comprises a first cache of a database management system or a second cache of an operating system.

[0188] Statement 62. A disclosed embodiment includes the article of manufacture of statement 60 wherein the step of determining the priority of the scan further comprises determining a first size of the table or a second size of an amount of data from the table in cache.

[0189] Statement 63. The disclosed embodiment includes an article according to statement 62, wherein the step of determining a first size of the table and a second size of the amount of data from the table in the cache includes: querying a database management system for the first size of the table or the second size of the amount of data from the table in the cache.

[0190] Statement 64. A disclosed embodiment includes the article of manufacture of statement 51, wherein: The step of identifying the kernel in the accelerator includes: identifying the kernel and a second kernel in the accelerator; Assigning the kernel to the scan based at least in part on a priority of the scan includes assigning the kernel and a second kernel to the scan based at least in part on a priority of the scan.

[0191] Statement 65. A disclosed embodiment includes the article of manufacture of statement 51, wherein: The step of identifying the scan of the table in the query includes: identifying the scan of the table in the query and a second scan of a second table; The step of determining the priority of the scan includes: determining the priority of the scan and a second priority of a second scan; and The kernel is assigned to the scan or the second scan based at least in part on the priority of the scan and a second priority of the second scan.

[0192] Statement 66. A disclosed embodiment comprises the article of manufacture of statement 51, a non-transitory storage medium having further instructions stored thereon, said further instructions, when executed by a machine, causing said scanning to be performed using said kernel.

[0193] Statement 67. A disclosed embodiment includes an article of manufacture as described in statement 66, wherein the step of performing the scan using the kernel includes: flushing a first cache of a database management system or a second cache of an operating system.

[0194] Statement 68. The disclosed embodiments include an article of manufacture according to statement 67, wherein the step of flushing the first cache of the database management system or the second cache of the operating system includes: writing dirty data from the first cache of the database management system or the second cache of the operating system to a storage device.

[0195] Statement 69. The disclosed embodiments include an article of manufacture according to statement 67, wherein the step of flushing the first cache of the database management system or the second cache of the operating system includes: deleting valid data from the first cache of the database management system or the second cache of the operating system.

[0196] Statement 70. The disclosed embodiment includes an article according to statement 67, wherein the step of flushing the first cache of the database management system or the second cache of the operating system includes: at least partially based on the database management system selecting the kernel to perform the scan to flush the first cache of the database management system or the second cache of the operating system.

[0197] Statement 71. A disclosed embodiment includes an article of manufacture as described in statement 66 wherein the step of using the kernel to perform the scan includes determining that a database management system selects the kernel to perform the scan.

[0198] Statement 72. A disclosed embodiment includes an article of manufacture as described in statement 71, wherein the step of performing the scan using the kernel further includes: assigning the kernel to the scan.

[0199] Statement 73. A disclosed embodiment includes an article of manufacture as described in statement 51, a non-transitory storage medium having additional instructions stored thereon, which, when executed by a machine, cause software to perform the scan to release the core based at least in part on database management system selection.

[0200] Statement 74. A disclosed embodiment includes an article of manufacture according to statement 73, wherein: The step of assigning the kernel to the scan based at least in part on the priority of the scan includes: storing a first timestamp; The step of performing the scan to release the kernel based at least in part on database management system selection software includes: determining a second timestamp; and It is determined that a difference between the first time stamp and the second time stamp exceeds a threshold difference.

[0201] Therefore, in view of the wide variety of permutations to the embodiments described herein, this detailed description and accompanying material are intended to be illustrative only and should not be taken as limiting the scope of the disclosure. Therefore, the disclosure claims all such modifications that may fall within the scope and spirit of the appended claims and their equivalents.

Claims

1. A device for performing accelerator resource allocation, the device comprising: A storage device storing a database including a table; as well as an accelerator connected to the storage device, the accelerator including a core; a scan priority calculator for calculating a first priority for a first scan of a first table in a database stored on a storage device, the first scan being associated with the query; as well as A kernel dispatching unit is configured to dispatch a kernel to the first scan based at least in part on a first priority level of the first scan.

2. The device according to claim 1, further comprising: Receiver, used to receive queries from the user end.

3. The device according to claim 1, wherein: The scan priority calculator is configured to calculate a first priority of the first scan based at least in part on a first size of the first table or a second size of an amount of data from the first table in the cache.

4. The device according to claim 3, further comprising: The cache query unit is configured to determine a second size of the amount of data from the first table in the cache.

5. The device according to claim 1, wherein: The kernel dispatch unit is configured to dispatch the kernel to the first scan or the second scan based at least in part on a first priority of the first scan and a second priority of the second scan.

6. The device according to claim 1, further comprising: The cache flushing unit is used to flush the first cache of the database management system or the second cache of the operating system to the storage device.

7. The device according to claim 6, wherein: The cache flush unit is configured to execute a first scan based at least in part on a database management system selecting a kernel to execute.

8. The apparatus according to claim 1, further comprising: The kernel release unit is configured to release the kernel based at least in part on the database management system selection software performing a first scan.

9. The apparatus according to claim 8, wherein: The kernel dispatch unit is configured to: associate a first timestamp with the kernel and the first scan; and The kernel release unit is configured to release the kernel based at least in part on a threshold difference between the first timestamp and the second timestamp.

10. A method for performing accelerator resource allocation, the method comprising: Identify the cores in the accelerator; identifying a first scan of a first table in a query, the table stored in a database on a storage device coupled to the accelerator; determining a first priority for a first scan; as well as The kernel is assigned to the first scan based at least in part on a first priority level of the first scan.

11. The method according to claim 10, wherein: Determining a first priority for the first scan includes calculating the first priority for the first scan based at least in part on a first size of the first table or a second size of an amount of data from the first table in the cache.

12. The method according to claim 11, wherein: The step of determining a first priority for the first scan also includes determining a first size of the first table or a second size of an amount of data from the first table in the cache.

13. The method of claim 10, wherein: The step of identifying a first scan of a first table in the query includes: identifying a first scan of the first table and a second scan of a second table in the query; The step of determining a first priority for the first scan includes: determining a first priority for the first scan and a second priority for the second scan; and Assigning the kernel to the first scan includes assigning the kernel to the first scan or the second scan based at least in part on a first priority of the first scan and a second priority of the second scan.

14. The method according to claim 10, further comprising: A first scan is performed using the kernel.

15. The method according to claim 14, wherein: The step of using the kernel to perform the first scan includes: flushing a first cache of a database management system or a second cache of an operating system.

16. The method according to claim 10, further comprising: Based at least in part on the database management system selection software performing a first scan to free the cores.

17. The method of claim 16, wherein: The step of assigning the kernel to the first scan based at least in part on the first priority of the first scan includes: storing a first timestamp; The step of performing a first scan to free up kernels based at least in part on the database management system selection software includes: determining a second timestamp; and It is determined that a difference between the first time stamp and the second time stamp exceeds a threshold difference.

18. An article of manufacture comprising a non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause: Identify the cores in the accelerator; identifying a first scan of a first table in the query, the first table stored in a database on a storage device coupled to the accelerator; determining a first priority for a first scan; as well as The kernel is assigned to the first scan based at least in part on a first priority level of the first scan.

19. The article of claim 18, wherein: Determining a first priority for the first scan includes calculating the first priority for the first scan based at least in part on a first size of the first table or a second size of an amount of data from the first table in the cache.

20. The article of manufacture of claim 18, a non-transitory storage medium having stored thereon additional instructions that, when executed by a machine, cause: based at least in part on database management system selection software performing a first scan to release the core.

Images