System and method for processing and distributing service request

Abstract

This invention discloses a system and method for processing and distributing service requests. The system receives a service request from a client and identifies the location of the data. It determines the state of a computing storage device associated with the location. Based on the state, it transmits the service request to a storage service associated with the computing storage device. It identifies a response to the service request from the storage service and provides the response to the client.

Description

Technical Field

[0001] One or more aspects of embodiments according to the present disclosure relate to computational storage devices, and more particularly, to processing and distributing service requests to one or more computational storage devices. [Cross - Reference to Related Applications]

[0002] This application claims the priority and benefit of U.S. Provisional Patent Application No. 63 / 339,861, filed on May 9, 2022, with the United States Patent and Trademark Office, the entire disclosure of which is incorporated herein by reference. Background Art

[0003] For various data processing tasks, it may be desirable to use a computational storage device (CSD) (e.g., a solid state drive (SSD) with an embedded processor or a Field Programmable Gate Array (FPGA)), as such storage devices can help provide efficient and economical data processing solutions. For example, a computational storage device can be used to perform database (DB) scan operations that would otherwise be performed by a host central processing unit (CPU) processor. In terms of input / output (I / O), the cost of accessing the storage device for a DB scan operation can be high.

[0004] The above information disclosed in this background art section is only for enhancing the understanding of the background of the present disclosure, and thus the above information may include information that does not constitute prior art. Summary of the Invention

[0005] Embodiments of the present disclosure relate to a method for processing and distributing service requests. A service request is received from a client, and the location of the data is identified. The status of a computational storage device associated with the location is determined. Based on the status, the service request is transmitted to a storage service associated with the computational storage device. A response to the service request from the storage service is identified, and the response is provided to the client.

[0006] According to some embodiments, the service request includes a computational request.

[0007] According to some embodiments, the service request includes storing an input or output request.

[0008] According to some embodiments, the location of the data includes an address associated with a compute storage device.

[0009] According to some embodiments, the state of the compute storage device includes the utilization of the compute resources of the compute storage device.

[0010] According to some embodiments, the method further includes storing the location in a cache in association with an identifier of the data.

[0011] According to some embodiments, the method further includes storing the response in a cache in association with an identifier of the service request.

[0012] According to some embodiments, the service request for the storage service is one of a local request or a remote request.

[0013] According to some embodiments, the storage service is configured to send a command to retrieve data stored in a compute storage device.

[0014] According to some embodiments, the service request is a request to perform a database scan on the data.

[0015] Embodiments of the present disclosure relate to a system for processing and distributing service requests. The system includes a processor and a memory. The memory stores instructions that, when executed by the processor, cause the processor to perform the following operations: receive a service request from a client; identify the location of data; determine the state of a compute storage device associated with the location; transmit the service request to a storage service associated with the compute storage device based on the state; identify a response to the service request from the storage service; and provide the response to the client.

[0016] These and other features, aspects, and advantages of the embodiments of the present disclosure will be more fully understood by considering the following detailed description, the appended claims, and the accompanying drawings. Of course, the actual scope of the invention is defined by the appended claims. Brief Description of the Drawings

[0017] Non-limiting and non-exhaustive embodiments of the present disclosure are described with reference to the following figures, where like reference numerals throughout the views refer to like components unless otherwise specified. FIG. 1 illustrates a block diagram of a system for processing database (DB) queries according to one embodiment. FIG. 2 illustrates a block diagram of the architecture of a host device and a storage device according to one embodiment. FIG. 3 illustrates a flowchart of a process for processing a DB query according to one embodiment. FIG. 4 illustrates a flowchart of a process for offloading a DB scan to a storage device according to one embodiment. FIG. 5 illustrates a block diagram of a system for processing and distributing service requests / queries to one or more compute storage devices according to one embodiment. FIG. 6 illustrates a flowchart of a process for processing and distributing service requests to one or more compute storage devices according to one embodiment. Embodiments

[0018] Hereinafter, exemplary embodiments will be described in more detail with reference to the accompanying drawings, in which like reference numerals always refer to like elements. However, the present disclosure may be implemented in various different forms and should not be construed as limited to the embodiments shown herein. Rather, these embodiments are provided as examples so that the present disclosure will be thorough and complete, and will fully convey the aspects and features of the present disclosure to those skilled in the art. Accordingly, processes, elements, and techniques that are not necessary for those skilled in the art to fully understand the aspects and features of the present disclosure may not be described. Unless otherwise indicated, like reference numerals in the drawings and this written description always denote like elements and thus may not be repeated. Additionally, in the figures, for clarity, the relative sizes of elements, layers, and regions may be exaggerated and / or simplified.

[0019] Data stored in a database (DB) may or may not be indexed. If the data is not indexed, a full scan of the database (which is also referred to as a full table / DB scan) may be required to respond to a DB query. For example, since scanning a database requires a large number of input / output (I / O) reads, a full table scan can be slow. A full table scan may also use a large amount of memory and computing resources of the host device because, during the full scan, it may be necessary to check each column in the database to see if one or more rows in the DB query meet the query criterion.

[0020] In the field of data storage and processing, indexing is often used to optimize the performance of a database when processing DB queries. When the content of a DB is not indexed, a full DB scan may be required. For example, when performing a search on a DB containing unindexed data, the host device may need to load the DB onto the memory of the host device and perform a full scan of the DB in the memory using the computing resources of the host device. Therefore, it may be desirable to have a system and method for performing a DB scan operation in a way that minimizes the use of host resources while providing better (e.g., faster) scan performance and scalability.

[0021] Generally, embodiments of the present disclosure relate to systems and methods for offloading a DB scan operation to one or more compute storage devices. Offloading the scan operation can help isolate the scan overhead to the one or more devices performing the scan operation, help reduce the use of host resources, and increase the scan speed.

[0022] Embodiments of the present disclosure provide command sets, communication mechanisms, and data structures to support the data flow across multiple data processing layers of a host device and one or more compute storage devices. In one embodiment, a microservice gateway and / or a scan processing engine helps overcome typical challenges in utilizing compute storage devices in a database management system (DBMS). Such challenges can involve permissions (e.g., a DBMS typically does not run with root privilege), complexity (e.g., for scheduling I / O requests and scan operations), and scalability (e.g., for supporting local and / or remote storage devices).

[0023] In one embodiment, service requests for a storage device can be routed via a microservice gateway. The microservice gateway can act as an interface layer between a client application and a service application of the storage device. Exemplary services requested by the client application can be, for example, a custom DB scan request that enables offloading a scan operation to the storage device. Although scan offloading is used as an example of a service request, embodiments of the present disclosure are not limited thereto and can include other service requests including I / O requests.

[0024] In one embodiment, the microservice gateway includes an application programming interface (API) that a client application can access to send service requests. For example, the DBMS of a host device can use the API to send a customized DB scan request to a storage device. The microservice gateway can select an appropriate storage device to handle the service request. For example, the storage device can be selected based on its status.

[0025] In one embodiment, the service application of the selected storage device receives and processes the service request sent by the microservice gateway. The service application that processes the DB scan request for the selected storage device can be referred to as a scan processing engine (SPE).

[0026] In one embodiment, the SPE receives the customized DB scan request and sends commands during the initialization phase to initialize / configure the selected storage device to process the scan request. The SPE can further schedule I / O and scan execution commands during the execution phase and send the I / O and scan execution commands to the storage device, and deliver the scan output to the microservice gateway. The SPE can further be configured to manage the storage device such that an appropriate number of scan requests can be assigned to the storage device, thereby maximizing the performance of the storage device.

[0027] In one embodiment, the SPE uses the initialization phase to allocate memory for the storage device and prefetch data into the memory of the storage device. For example, performing prefetching may require starting the process of retrieving data from the storage device before the DB scan operation begins. For example, the SPE can perform address translation of logical addresses to physical addresses for DB objects (e.g., DB files) stored in the storage device. The data stored at the physical address can be prefetched into the internal memory of the storage device.

[0028] During the execution phase, the SPE can send one or more commands to perform a scan operation based on the data fetched into the internal memory of the storage device. The SPE can further send one or more commands to read the results of the scan operation and transfer the results to the client that issued the request (e.g., via the microservice gateway).

[0029] FIG. 1 illustrates a block diagram of a system for processing database queries according to an embodiment. The system may include a host device (e.g., a host computer) 100 coupled to one or more compute storage devices 102 via a network fabric 104. The network fabric 104 may include, for example, a Peripheral Component Interconnect (PCI), a Peripheral Component Interconnect Express (PCIe) bus, and / or the like. Communication protocols that may be used for communication via the network fabric 104 may be, for example, a Compute Express Link (CXL), a Non-Volatile Memory Express (NVMe), an NVMe over fabrics (NVMe-oF), and / or the like. The compute storage device 102 may take any suitable form, including but not limited to a solid state drive (SSD), an Ethernet SSD (eSSD), and the like.

[0030] The host device 100 may include a host processor 106 and a host memory 108. The host processor 106 may be a general-purpose processor, such as, for example, a central processing unit (CPU) core of the host device 100. The host memory 108 may include, for example, a random access memory (RAM) (e.g., a dynamic random access memory (DRAM)), a read-only memory (ROM), and the like.

[0031] The host device 100 may include an interface 110 (which is also referred to as a root complex (RC)) for connecting the processor 106 and the host memory 108 to the network fabric 104. The interface 112 may include one or more ports through which the storage device 102 may be connected to the host device 100 via the network fabric 104. In some cases, the one or more ports may be connected to a switch, and the remotely located storage device 102 may be connected to the host device 100 via the switch.

[0032] In one embodiment, the one or more computing storage devices 102 include a storage interface 122, a storage controller 124, and one or more non-volatile memory (NVM) devices 126a to 126c (collectively referred to as 126). The storage interface 122 may facilitate communication between the host device 100 and the storage device 102 (e.g., using connectors and protocols). In some embodiments, the storage interface 122 may facilitate the exchange of storage requests and responses between the host device 100 and the storage device 102. In some embodiments, the storage interface 110 may facilitate the transfer of data between the storage device 102 and the host memory 108 of the host device 100. In one embodiment, the storage interface 122 (e.g., the connector and its protocol) includes a PCIe connection. In one embodiment, the NVMe protocol is used to communicate with the host 100 via the PICe connection. In this regard, the storage interface 122 may further support one or more command sets, including the NVMe command set, a custom scan logic command set, and / or similar command sets.

[0033] In one embodiment, the storage controller 124 includes a storage processor 128 and a storage memory 130. The storage processor 128 may include at least one embedded processing circuit. For example, the embedded processing circuit may include digital circuits (e.g., microcontrollers, microprocessors, digital signal processors, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and / or similar circuits) capable of executing data access instructions to provide access to data stored in the NVM device 126. For example, the data access instructions may include any suitable data storage and retrieval algorithms (e.g., read / write) instructions, encryption / decryption algorithm instructions, compression algorithm instructions, and / or similar instructions.

[0034] In one embodiment, the digital circuits may include static logic blocks and / or dynamic reconfigurable logic blocks (e.g., dynamic logic blocks). For example, the host device 100 may provide logic for configuring one or more of the logic blocks to perform custom scan operations in response to a DB query. For example, the logic may be initialization logic for allocating a region of the storage memory 130 for custom scan operations. The initialization may be a one-time initialization and / or a query-by-query initialization.

[0035] In one embodiment, the logic configured in the logic block includes custom scan logic. The custom scan logic can be used to perform hardware-based scan operations on one or more DB objects stored in the NVM device 126. The hardware-based scan can be implemented as described in U.S. Patent Application No. 17 / 720,272, filed on April 13, 2022, and titled "Hybrid Database Scan Acceleration System", the content of which is incorporated herein by reference.

[0036] In one embodiment, the storage memory 130 is configured to store short-term storage or temporary memory during the operation of the device 102. The storage memory can include DRAM, static random access memory (SRAM), and / or Data Tightly Coupled Memory (DTCM). The storage memory 130 can include one or more buffers, such as an input buffer and an output buffer. The input buffer can be used to hold one or more DB table pages fetched from the NVM device 126. The data in the input buffer can be scanned by the custom scan logic configured in the storage processor 128. The output buffer can be used to hold the results of the custom scan operation.

[0037] The NVM device 126 can include, for example, NAND flash memory. In the case of a database management system, the NVM device 126 can store one or more database files generated by the host device 100. The database files can be stored in the NVM device 126 in any suitable database format (e.g., row format or column-based format, for example).

[0038] FIG. 2 illustrates a block diagram of the architecture of the host device 100 and the storage device 102 according to one embodiment. Although a single storage device is shown in the embodiment of FIG. 2, those skilled in the art should understand that the host device can be coupled to multiple storage devices 102 for offloading scan operations to the multiple storage devices.

[0039] The various architectural components of the host device 100 can include, for example, a DBMS / database 200, a custom scan plug-in 202, a scan processing engine (SPE) 204, and a compute storage device driver 206. The architectural components can be implemented, for example, by computer program instructions stored in the host memory 108 and executed by the host processor 106.

[0040] The DBMS / database 200 can be, for example, a relational database (e.g., PostgreSQL). The database 200 can be configured to receive a DB query from a client application and generate an executable command (also referred to as a query plan) for executing the query.

[0041] In one embodiment, the customized scan plug-in 202 is configured to receive and parse a DB query received by the database 200 and determine whether the DB query is a query that can be processed by the SPE 204. For example, if the DB query is about unindexed data, the customized scan plug-in 202 can determine that the query should be processed by the SPE 204 through a customized DB scan operation. If the DB query is a query that the SPE 204 cannot process or should not process, or if the host processor 106 desires to perform a traditional DB scan, the customized scan plug-in 202 can instruct the database 200 to process the query according to the generated query plan.

[0042] In one embodiment, the customized scan plug-in 202 serves as middleware between the database 200 and the SPE 204. In this regard, if the customized scan plug-in 202 determines that a DB query is to be processed by the SPE 204, the customized scan plug-in 202 can send a service request to the SPE 204 to process the DB query through a customized DB scan. The customized scan plug-in 202 can further receive the result of the customized DB scan operation and output the result as a response to the DB query to the client application. The communication between the customized scan plug-in 202 and the SPE 204 can be carried out through inter-process communication (IPC) and / or remote procedure call (RPC).

[0043] The SPE 204 can be configured to receive a customized DB scan request from the customized scan plug-in 202 and determine how to process the query. For example, the SPE 204 can determine how many concurrent scans to issue to the storage device 102, select and / or combine scan ranges, etc. For example, the number of concurrent scans can depend on the availability of the storage device 102 for scan calculations.

[0044] SPE 204 can perform other preprocessing operations for customized DB scan requests. For example, SPE 204 can identify data from the NVM device 126 and prefetch the data from the NVM device 126 into the storage memory 130 (e.g., using a write command). In this regard, a translation library 208 can be invoked to perform an address translation that converts the logical address of the DB file in the file system into the logical block address (LBA) of the storage device 102.

[0045] Then, a data prefetch handler 210 can be invoked to prefetch the DB file from the NVM device 126 into the storage memory 130. For example, the prefetch can start before the scan operation is executed and continue in the background while the scan operation is being performed on the storage device 102.

[0046] SPE 204 can also generate and send commands to configure the storage processor 128 using one or more programs (e.g., a compute logic command set or programmable logic) required for the scan operation. The one or more programs can be an initialization program 218 for receiving and executing an initialization command from SPE 204. The initialization command can be used to allocate an area of the storage memory 130 to store data during the scan. The allocated area can be used, for example, as an input buffer to store the DB file retrieved from the NVM device 126. The initialization command can also be used to determine the memory locations of one or more output buffers to store the output of the scan operation.

[0047] The one or more programs loaded into the storage processor 128 can also be a scan program 220 for performing a scan operation on the data in the input buffer. In this regard, SPE 100 can include a scan command handler 214 that sends commands to the scan program 220 to perform a hardware scan operation (e.g., execute a hardware scan operation or schedule the execution of a hardware scan operation). In one embodiment, the scan commands are asynchronous scan commands that are batched and sent to the storage device 102 for processing.

[0048] In one embodiment, the host device 100 includes a compute storage device driver 206 that enables communication between the host device and the storage device 102. For example, the commands generated by SPE 204 can be passed to the storage device 102 via the device driver 206.

[0049] The storage device 102 may include a storage interface 216 similar to the storage interface 122 shown in FIG. 1. The storage interface 216 is configured to interface with the compute storage device driver 206 of the host 100 to exchange commands, programs, and data to and from the storage device 102. For example, the interface 216 can be used to load a set of compute logic commands (e.g., the initialization program 218 and the scan program 220) into the programmable logic 222 of the storage processor 128.

[0050] FIG. 3 illustrates a flowchart of a process for processing a DB query according to one embodiment. The process begins at operation 300, and in operation 300, the customized scan plug-in 202 identifies the DB query provided by the client application to the database 200.

[0051] In operation 302, the customized scan plug-in 202 determines whether the SPE 204 should be invoked to process the DB query. For example, if the query is about unindexed data, the answer may be "YES", and in operation 304, the customized scan plug-in 202 can send a command to invoke the SPE 204 to process the DB query.

[0052] If the answer is NO, then in operation 306, the customized scan plug-in 202 can request the database 200 to process the DB query according to its query plan.

[0053] FIG. 4 illustrates a flowchart of a process for offloading a DB scan to the storage device 102 according to one embodiment. The process begins at operation 400, and in operation 400, the SPE 204 receives a command (e.g., a scan command) from the customized scan plug-in 202 in response to the DB query.

[0054] In response to the command, the SPE 204 can invoke the storage device 102 to scan the data in the database object (e.g., the DB table) based on the received query. In this regard, in operation 402, the SPE 204 can send one or more commands for configuring the storage device 102 to perform a hardware DB scan. The commands can be a one-time initialization command or a per-query initialization command. The one-time initialization command can be used to allocate an area of the storage memory 226 to read and write data during the scan operation. Another one-time initialization command can be used to load the initialization program 218 and the scan program 220 into the programmable logic 222 of the storage processor 128.

[0055] The initialization command for each query can be used to execute the initialization program 218 to prepare for performing a customized DB scan. For example, the initialization program 218 can prepare an input buffer for storing DB page data and determine the addresses of one or more output buffers for storing the output of the scan operation. In one embodiment, a separate output buffer can be allocated for each row of the DB table.

[0056] The initialization of each query can further include analyzing the DB query to determine the number of parallel scans that can be issued, determining the scan range, and so on.

[0057] The initialization of each query can further include prefetching the DB table data into the input buffer of the storage memory 226. In this regard, the SPE 204 can convert the logical address of the DB table stored in the file system into the LBA of the storage device 102. The SPE 204 can send a write command based on the converted address. The write command can enable the prefetching of data in the NVM device 126 into the input buffer of the storage memory 226.

[0058] In operation 404, the SPE 204 can send one or more commands to perform a customized DB scan on the data in the database object. The SPE 204 can run one or more (e.g., eight) customized scan operations in parallel. The output of the customized DB scan can be stored in the output buffer of the storage memory 226.

[0059] In operation 406, the SPE 204 can read the results from the output buffer. In this regard, the SPE 204 can call a monitoring thread to monitor a signal from the storage device 102 indicating that there is data in the output buffer to be retrieved by the SPE 204. In response to the signal, the SPE 204 can send a read command for reading data from the output buffer to the host memory 108.

[0060] In operation 408, the output can be provided as a response to the DB query to the query client. In one embodiment, the host memory 108 for storing the scan results is shared with the customized scan plug-in 202. In such a case, the customized scan plug-in 202 can access the host memory 108 to retrieve and deliver the results to the query client. [Microservice Gateway] []

[0061] In one embodiment, offloading operations to storage device 102 can be managed by a microservices gateway. An exemplary operation that can be offloaded to the storage device is the customized DB scan request described with reference to FIGS. 1 to 4, however the embodiments are not limited thereto. For example, other types of service requests can include other compute requests, authentication requests, input / output (I / O) requests, and / or the like.

[0062] In one embodiment, the microservices gateway serves as an interface layer between the application that sends the service request and the service application of the storage device that processes the request. For example, the microservices gateway can be the interface layer between the customized scan plug-in 202 and the SPE 204.

[0063] Offloading a service request to storage device 102 may require more than just forwarding the received request. For example, it may be necessary to evaluate and process the request and / or the status of the storage device to select an appropriate storage device to which to forward the service request. In addition to routing, other types of processing can include authentication of the client application and / or logging of the service request. At least some of the processing can be implemented as a background process that is transparent to the client application that issued the request. In this way, the microservices gateway can provide a simple and easy-to-use interface for applications to send service requests to the storage device.

[0064] FIG. 5 illustrates a block diagram of a system for processing and distributing service requests / queries to one or more compute storage devices according to one embodiment. The system includes a client application 500 that generates service requests for one or more compute storage devices (CSDs) 502a to 502d (collectively referred to as 502). The storage devices 502 can be similar to the storage device 102 shown in FIGS. 1 to 2.

[0065] The client application 500 can include, for example, a database 100 having the customized scan plug-in 202 shown in FIG. 2, and / or other applications that may need to send requests to the storage device. The service request can be a compute request (e.g., a customized DB scan request), an I / O request (e.g., a read / write request), and / or the like.

[0066] The system includes a microservices gateway 504 that can be implemented, for example, using an application programming interface (API). In this regard, the gateway 504 can serve as an interface between the client application 500 and one or more storage services 506a - 506c (collectively referred to as 506) that handle service requests for the one or more storage devices 502. In some embodiments, the gateway 504 is a stand-alone interface component running on a host device. In some embodiments, the gateway 504 is integrated into one or more of the storage services 506 (e.g., local storage services 506a, 506b).

[0067] The storage services 506 can receive local service requests or remote service requests from the gateway 504. Local requests can include, for example, function calls, IPC, local transmission control protocol / Internet protocol (TCP / IP) requests, and / or similar requests. Remote requests can include, for example, RPC, remote TICP / IP requests, hypertext transfer protocol (HTTP) requests, and / or other requests transmitted over a data communication network.

[0068] In one embodiment, at least one storage service 506 is configured to manage service requests for at least one storage device 502. For example, the storage service 506 can participate in address translation (e.g., between a file system and a storage device) to find the physical address of data to be loaded into the memory of the storage device. The storage service 506 can further send a computation request to the storage device 502 and read the computation output from the storage device to pass the computation output to the gateway 504. An exemplary storage service 506 is the SPE 204 described with reference to FIGS. 1 - 4.

[0069] In one embodiment, the gateway 504 includes one or more components including an identity provider 508, a request distributor 510, and a content directory server 512. These components can be implemented by software, firmware, and / or hardware. In some embodiments, the gateway 504 is part of the host device 100, and these components can be implemented by the host processor 106 based on instructions stored in the host memory 108.

[0070] The identity provider 508 can be configured to authenticate the client application 500 as needed. One or more different types of connections and authentication mechanisms can be used for authentication. Different types of connections can include, for example, TCP / IP, IPC, RPC, and / or local function calls. Different types of authentication mechanisms can include, for example, authentication based on public key infrastructure (e.g., secure sockets layer (SSL) certificates), passwords, hard / soft tokens, device identifiers, and / or similar authentication mechanisms. For example, if an SSL client certificate is used for authentication, the client application 500 performs an SSL handshake with the identity provider 508, during which the application provides the SSL certificate to the identity provider for verification.

[0071] In one embodiment, the request distributor 510 is configured to process and distribute service requests to the storage service 506. The request distributor 510 can be configured to select the location of the data required to service requests from the client application 500. The data can be stored in one or more of the storage devices 502. The service request can be forwarded to the storage service 506 associated with the selected location. In one embodiment, the location information and / or the response to the service request can be saved in a location cache and / or a response cache, respectively. In this way, the location and / or response required to respond to the service request can be quickly retrieved from the appropriate cache to process the request more quickly.

[0072] In one embodiment, the location for servicing the service request and / or the resource availability at the location can be provided by the content directory server 512. In this regard, the content directory server 512 can maintain and / or access the location of the data required to service the service request. The location information can include the server address and / or device path of the storage device 502 where the data is stored. When new data is written or existing data is updated in the storage device 502, the content directory server 512 can update the location data.

[0073] In one embodiment, the content directory server maintains status information for the one or more locations (e.g., the status of the one or more storage devices in the one or more locations). The status information can include, for example, the availability of the computing resources of the one or more storage devices 502. When a location is selected or invoked to process the data stored at that location, the directory server 512 can update the availability information for that location (e.g., from available to unavailable).

[0074] The content directory server 512 can manage location and status data using, for example, a file system or a database system. For example, records can be generated in a database system, and the records can identify the location of the storage device and the associated status (e.g., as a key-value pair). For example, the records can store information such as {key, server name, device name, current usage}, where the "key" identifies the data, the "server name" is the name of the server that hosts the storage device 502, the "device name" identifies the storage device, and the "current usage" identifies the device as available / unused or unavailable / used.

[0075] In some embodiments, the location and / or status data is provided by a local storage system, a distributed storage system, a key-value store, etc. For example, a key-value store can store key-value location information as: {"LOC_" + key, server name, device name}, and store key-value status information as {"USAGE_" + key, current usage}.

[0076] FIG. 6 illustrates a flowchart of a process for processing and distributing service requests to one or more compute storage devices according to one embodiment. The process begins at operation 600, and in operation 600, the gateway 504 receives a service request from the client application 500. The service request can be a compute request for offloading computing to the storage device 502, e.g., (by way of example), a custom DB scan request provided by the custom scan plug-in 202. The service request can also be an I / O request, e.g., (by way of example), a read request for reading data from the storage device, or a write request for storing data to the storage device 502.

[0077] In one embodiment, the service request includes one or more of a key, an operation type, client information, or metadata. The key can include an identifier of the data to be processed according to the service request. The operation type can identify the type of the requested operation, e.g., (by way of example), compute, store, read, delete, and / or similar operations. The client information can identify the client application 500, including, e.g., (by way of example), the client name, the client Internet Protocol (IP) address, etc. The metadata information can include metadata related to the data, e.g., (by way of example), length, offset, and / or similar data.

[0078] In some embodiments, the client application 500 may be authenticated (e.g., by the identity provider 508) to verify the identity of the requesting application. In this regard, the identity provider 508 may determine whether the SSL certificate, password, token, and / or other authentication information received from the client application is valid.

[0079] Assuming that the client application 500 can be authenticated, in operation 602, the request distributor 510 determines whether a response to the service request is available in the response cache. If the answer is yes, then in operation 604, the response is retrieved from the cache and provided to the client application 500 that issued the request.

[0080] If the response cache does not contain a response, then in operation 606, the request distributor 510 identifies one or more locations of the data identified in the service request. For example, the request distributor 510 may send a portion of the service request (e.g., the key and operation type) to the content directory server 512 to locate the data. The content directory server 512 may respond with the server address and device path of the location / storage device 502 where the identified data is stored. The content delivery server 512 may further provide the status / availability of the identified location / storage device to service the request.

[0081] In operation 608, the request distributor 510 determines the status of the locations identified by the content directory server 512 and selects an appropriate location based on the status information. For example, if the data is stored in multiple locations, the request distributor 510 may select a location based on whether the associated computing resources are busy or idle. A location with idle computing resources may be selected over a location with busy computing resources. If more than one location has idle computing resources, the request distributor 510 may select a local location over a remote location.

[0082] In one embodiment, the content directory server 512 is informed of the location selection. The content directory server 512 may update the status of the selected location to unavailable.

[0083] In operation 610, the request distributor 510 may log the service request to a log file as needed. The log of the service request can be used to maintain a record of the service request for debugging purposes, performance monitoring, security, and / or similar purposes.

[0084] In operation 612, the request distributor 510 transmits a service request to the storage service 506 that manages the selected storage device 502. For example, if the service request is a customized DB scan request, the storage service 506 for receiving the request may be one of the SPEs 204. The storage service 506 may, for example, locate the data to be processed in the selected storage device 502 and prefetch the data into the internal memory of the storage device. The storage service 506 may also, for example, use an external storage management system such as a file system or a distributed storage system to insert, delete, and update data in the storage device. The storage service 506 may further send a calculation request to the selected storage device and read the calculation output from the storage device to pass the calculation output to the gateway 504.

[0085] In operation 614, the request distributor 510 may identify the response output by the storage service 506 and update the response cache (if a response cache is used) with the identified response. For example, the response may be stored in the response cache in association with the identifier of the service request.

[0086] In operation 616, if the request changes the location or availability of the data, the request distributor 510 may signal the content directory server 512 to update the location of the data. The content directory server 512 may continue to update the availability of the storage device 502 based on the updated location.

[0087] In operation 618, the request distributor 510 provides the response to the client application 500.

[0088] It should be understood that, as would be recognized by those skilled in the art, the order of the steps of the processes in the flowcharts of FIGS. 3, 4, and 6 is not fixed and may be modified, the order may be changed, the processes may be implemented in different ways, sequentially, in parallel, or simultaneously, or changed to any desired order.

[0089] In some embodiments, a processor may refer to one or more processors and / or one or more processing cores. The one or more processors may be hosted in a single device or distributed across multiple devices (e.g., on a cloud system). Processors may include, for example, application specific integrated circuits (ASICs), general or special purpose central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), and programmable logic devices such as field programmable gate arrays (FPGAs). In a processor as used herein, each function is performed by hardware configured (i.e., hardwired) to perform the function, or by more general hardware (e.g., a CPU) configured to execute instructions stored in a non-transitory storage medium (e.g., memory). A processor may be fabricated on a single printed circuit board (PCB) or distributed across several interconnected PCBs. A processor may include other processing circuitry; for example, the processing circuitry may include two processing circuits interconnected on a PCB, namely an FPGA and a CPU.

[0090] It should be understood that although the terms "first", "second", "third", etc. may be used herein to describe various elements, components, regions, layers, and / or sections, these elements, components, regions, layers, and / or sections should not be limited by these terms. These terms are only used to distinguish between individual elements, components, regions, layers, or sections. Thus, a first element, first component, first region, first layer, or first section discussed herein may also be referred to as a second element, second component, second region, second layer, or second section without departing from the spirit and scope of the inventive concept.

[0091] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the inventive concept. Additionally, unless explicitly stated, the embodiments described herein are not mutually exclusive. Aspects of the embodiments described herein may be combined in some implementations.

[0092] Unless the context clearly indicates otherwise, the singular forms "a", "an" as used herein are also intended to include the plural forms. It should be further understood that when the term "comprises and / or comprising" is used in this specification, it specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items. For example, expressions such as "at least one of..." when appearing before a series of elements modify the entire series of elements rather than the individual elements of the series. In addition, when the embodiment of the inventive concept is described using "may", it means "one or more embodiments of the present disclosure". In addition, the term "exemplary" is intended to mean an example or illustration. The terms "use", "using", and "used" as used herein may be regarded as synonymous with the terms "utilize", "utilizing", and "utilized", respectively.

[0093] It should be understood that when an element or layer is referred to as being "on", "connected to", "coupled to", or "adjacent to" another element or layer, the element or layer may be directly on, directly connected to, directly coupled to, or directly adjacent to the other element or layer, or there may be one or more intermediate elements or layers. In contrast, when an element or layer is referred to as being "directly" on, "directly connected to", "directly coupled to", or "immediately adjacent to" another element or layer, there are no intermediate elements or layers.

[0094] Although exemplary embodiments of systems and methods for processing database queries and systems and methods for processing and distributing service requests have been specifically described and illustrated herein, many modifications and variations will be apparent to those skilled in the art. Therefore, it should be understood that the systems and methods for processing database queries and the systems and methods for processing and distributing service requests constructed in accordance with the principles of the present disclosure may be implemented in a manner different from that specifically described herein. The present disclosure is also defined in the following claims and their equivalents.

[0095] 100: Host device / Host 102: Computing storage device / Storage device 104: Network configuration 106: Host Processor / Processor 108: Host Memory 110, 216: Storage Interface / Interface 122: Storage Interface 124: Storage Controller 126a, 126b, 126c: Non-Volatile Memory (NVM) Device 128: Storage Processor 130, 226: Storage Memory 200: Database / DBMS 202: Custom Scan Plug-in 204: Scan Processing Engine (SPE) 206: Compute Storage Device Driver / Device Driver 208: Address Translation Library 210: Data Prefetch Handler 214: Scan Command Handler 218: Initialization Program 220: Scan Program 222: Programmable Logic 400, 402, 404, 406, 408, 600, 602, 604, 606, 608, 610, 612, 614, 616, 618: Action 500: Client Application 502a, 502b, 502c, 502d: Compute Storage Device (CSD) 504: Microservice Gateway 506a, 506b: Local Storage Service / Storage Service 506c: Storage Service 508: Identity Provider 510: Request Distributor 512: Content Directory Server / Directory Server

Claims

1. A method for processing and distributing service requests, the method comprising: A gateway is provided between the client and the service application, wherein the service application is communicatively coupled to a first computing storage device and a second computing storage device different from the first computing storage device. The gateway receives a first service request from the client, wherein the first service request identifies data for performing a first service; based on receiving the first service request: the gateway identifies the location of the data; the gateway identifies a first computing storage device based on the location; the gateway determines the state of the first computing storage device associated with the location; the gateway transmits the first service request to the service application based on the state, wherein the service application is configured to transmit commands for using a program to configure the first computing storage device to perform operations associated with the first service request, transmit a first signal to the first computing storage device to process the first service request based on the program, receive a response from the first computing storage device, and forward the response to the gateway; and the gateway provides the response to the client.

2. The method as described in request item 1, wherein the first service request includes a computation request.

3. The method as described in request item 1, wherein the first service request includes a storage input or output request.

4. The method as described in claim 1, wherein the location of the data includes an address associated with the first computing storage device.

5. The method of claim 1, wherein the state of the first computing storage device includes the utilization rate of the computing resources of the first computing storage device.

6. The method as described in claim 1, further comprising: The location is stored in a cache in association with the identifier of the data.

7. The method as described in claim 1, further comprising: The response is stored in a cache in association with the identifier of the first service request.

8. The method as described in request item 1, wherein the first service request applied to the service is either a local request or a remote request.

9. The method as described in claim 1, wherein the service application is configured to transmit a second command to retrieve the data stored in the first computing storage device.

10. The method as described in request item 1, wherein the first service request is a request to perform a database scan on the data.

11. A system for processing and distributing service requests, the system comprising: Memory devices; processor; and memory, wherein the memory stores instructions, which, when executed by the processor, cause the processor to perform the following operations: providing a gateway between a client and a service application, wherein the service application is communicatively coupled to a first compute storage device and a second compute storage device other than the first compute storage device; receiving a first service request from the client at the gateway, wherein the first service request identifies data for performing a first service; identifying the location of the data by the gateway; identifying the first compute storage device by the gateway based on the location; determining the state of the first compute storage device associated with the location by the gateway; transmitting the first service request to the service application by the gateway based on the state, wherein the service application is configured to transmit commands for using a program to configure the first compute storage device to perform operations associated with the first service request, transmit a first signal to the first compute storage device to process the first service request based on the program, receive a response from the first compute storage device, and forward the response to the gateway; and providing the response to the client by the gateway.

12. The system as described in claim 11, wherein the first service request includes a computation request.

13. The system as described in claim 11, wherein the first service request includes a storage input or output request.

14. The system of claim 11, wherein the location of the data includes an address associated with the first computing storage device.

15. The system of claim 11, wherein the state of the first computing storage device includes the utilization rate of the computing resources of the first computing storage device.

16. The system of claim 11, wherein the instructions further cause the processor to perform the following operations: store the location in a cache in association with an identifier of the data.

17. The system of claim 11, wherein the memory device includes a cache, wherein the instructions further cause the processor to perform the following operations: store the response in the cache in association with an identifier of the first service request.

18. The system as described in claim 11, wherein the first service request applied to the service is either a local request or a remote request.

19. The system of claim 11, wherein the service application is configured to transmit a second command to retrieve the data stored in the first computing storage device.

20. The system as described in claim 11, wherein the first service request is a request to perform a database scan on the data.

Images