Node equipment in distributed database architecture and resource access method

Abstract

A node device for a distributed database architecture, wherein the node device is configured to access a resource by reading metadata from a shared memory identifying a current owner of the resource. The node device is further configured to access the resource by: requesting the resource from the current owner of the resource; the resource is received from the current owner. The node device enables a multi-instance distributed database system to reduce the number of inter-node messages and context switches, which further improves the overall performance of the system while reducing network latency.

Description

Technical Field

[0001] The present invention generally relates to the field of database management; and more specifically, to a node device for a distributed database architecture, and a computer-implemented method for accessing resources in the distributed database architecture, wherein the distributed database architecture includes the node device. Background Art

[0002] Typically, a distributed database architecture with multiple instances supporting multi-instance writes and reads relies on defining three roles for each database resource used for data and metadata. Typically, database resources include, but are not limited to, memory pages, software locks, and the like. These three roles can be performed jointly by a requester node, an owner node (also called a holder node), and a master node. The requester node requires database resources. The owner node holds the latest version of the database resource. The master node holds resource metadata, manages, and synchronizes access to the resource metadata. A typical distributed database architecture can also be referred to as an RMO (i.e., requester / master / owner) model. In the RMO model, each database resource is managed by a master node responsible for managing resource metadata and distributed access. This means that in a multi-instance distributed database system with many active client sessions on multiple nodes, database read and write operations need to access the resource master node for each operation. In addition, in a multi-instance distributed database system with multiple nodes participating in all resource access operations, intensive metadata and data transmission over the network is required. These accesses require higher CPU usage and cause interruptions to other flows being executed by the nodes involved (e.g., context switching). Therefore, intensive message exchanges and CPU context switches increase latency and network resource occupancy (ie, more CPU resource consumption), which further significantly limits the performance of multi-instance distributed database systems.

[0003] Currently, some methods have been proposed to reduce latency and network resource utilization, such as using different hardware and software-based acceleration. For example, remote direct memory access (RDMA) operations have been implemented to perform direct access to the memory of remote nodes in distributed database systems, such as Oracle real application cluster (RAC) cache fusion performance optimization in Exadata. However, these performance improvements achieved in distributed database systems are based on not modifying the core architecture of the system (i.e., the RMO model) and the number of operations required between nodes. Incremental performance may be observed due to these improvements, but latency, network, and computing resource requirements will not be reduced. In addition, traditional designs and existing methods for similar distributed databases are based on message exchange, and there are three "roles" (up to three instances) participating in the process of sharing database resources, such as memory pages between database nodes. Therefore, existing methods can reduce the latency of message exchange and data transfer by using RDMA operations, but the amount of data exchanged and the number of messages are not reduced. Therefore, since the logic and number of instances involved in the memory page exchange process remain unchanged, the number of CPU context switches will not be reduced. Therefore, the following technical problem exists: in a typical distributed database architecture, excessive CPU context switching leads to increased consumption of expensive CPU resources and increased latency (i.e., delay), resulting in low system resource utilization, which in turn leads to performance degradation of the multi-instance distributed database system.

[0004] Therefore, based on the above discussion, there is a need to overcome the above-mentioned shortcomings associated with traditional methods of reducing latency and CPU consumption in typical distributed database architectures. Summary of the invention

[0005] The present invention provides a node device for a distributed database architecture, and a computer-implemented method for accessing resources in the distributed database architecture, wherein the distributed database architecture includes the node device. The present invention provides a solution to the following existing problems: in a typical distributed database architecture, excessive CPU context switching leads to increased consumption of expensive CPU resources and increased latency (i.e., delay), resulting in low system resource utilization, which in turn leads to decreased performance of a multi-instance distributed database system. The purpose of the present invention is to provide a solution that at least partially overcomes the problems encountered in the prior art, and to provide an improved node device for a distributed database architecture, an improved distributed database architecture including the improved node device, and an improved method for accessing resources in the distributed database architecture.

[0006] The objects of the present disclosure are achieved by what is presented in the attached independent claim. Advantageous implementations of the invention are further defined in the dependent claims.

[0007] In one aspect, the present invention provides a node device for a distributed database architecture, wherein the node device is used to access resources in the following manner: reading metadata identifying the current owner of the resource from a shared memory; requesting the resource from the current owner of the resource; and receiving the resource from the current owner.

[0008] The node device used for the distributed database architecture enables the multi-instance distributed database system to reduce the number of inter-node messages and CPU context switches by providing distributed access to the resource metadata. By utilizing the shared memory, the node device can directly access the resource metadata. By directly accessing the resource metadata, fewer nodes participate in the resource transmission flow, thereby reducing CPU context switching overhead, network hops and bandwidth. This further improves the performance of the multi-instance distributed database system in terms of efficient use of system resources and reduced latency.

[0009] In one implementation, the node device is used to read the metadata using remote direct memory access (RDMA) reading.

[0010] It is advantageous to use the RDMA read to read the metadata, which can reduce the latency of data transmission and message exchange between various nodes.

[0011] In another implementation manner, the node device is further used to update the resource in the following manner: access the resource; update the resource; update the metadata in the shared memory.

[0012] Since the node device can directly access the resource metadata by using the shared memory, the resource and the resource metadata can be updated efficiently with reduced latency.

[0013] In another implementation, the node device is used to update the metadata using remote direct memory access (RDMA) writing.

[0014] It is advantageous to use the RDMA write to update the metadata, which can reduce the latency of data transmission and message exchange between various nodes.

[0015] In another implementation, the shared memory is managed as an independent module.

[0016] The shared memory is managed as an independent module to provide high availability and persistence for the distributed database architecture including the node devices.

[0017] In another aspect, the present invention provides a distributed database architecture including the node device.

[0018] The distributed database architecture including the node devices reduces the number of messages and context switches between nodes while reducing network latency.

[0019] In another aspect, the present invention provides a computer-implemented method for accessing resources in a distributed database architecture. The computer-implemented method includes: a node device reads metadata identifying a current owner of the resource from a shared memory. The computer-implemented method also includes: the node device requests the resource from the current owner of the resource; the node device receives the resource from the current owner.

[0020] The computer-implemented method achieves all the advantages and effects of the node device after execution.

[0021] It should be understood that all of the above implementations can be used in combination.

[0022] It should be noted that all devices, elements, circuits, units and methods described in this application can be implemented by software or hardware elements or any combination thereof. All steps performed by various entities described in this application and the functions to be performed by various entities described are intended to refer to the corresponding entities for performing the corresponding steps and functions. Although in the description of the following specific embodiments, the specific functions or steps to be performed by the external entity are not reflected in the description of the specific detailed elements of the entity performing the specific steps or functions, it should be clear to the technician that these methods and functions can be implemented by corresponding hardware or software elements or any combination thereof. It should be understood that the features of the present invention are easy to be combined in various combinations without departing from the scope of the present invention defined by the appended claims.

[0023] Additional aspects, advantages, features and objects of the present invention will become apparent from the accompanying drawings and detailed description of illustrative implementations interpreted in conjunction with the following appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The above summary of the invention and the following detailed description of illustrative embodiments may be better understood when read in conjunction with the accompanying drawings. In order to illustrate the present invention, exemplary structures of the present invention are shown in the accompanying drawings. However, the present invention is not limited to the specific methods and tools disclosed herein. In addition, it should be understood by those skilled in the art that the accompanying drawings are not drawn to scale. Where possible, identical elements are represented by identical numerals.

[0025] The embodiments of the present invention are now described by way of example only with reference to the following drawings, in which:

[0026] Figure 1A is a block diagram showing various exemplary components of a node device provided by one embodiment of the present invention;

[0027] Figure 1B is a block diagram illustrating various exemplary components of a distributed database architecture provided by one embodiment of the present invention;

[0028] Figure 1C is a block diagram showing various exemplary components of a distributed database architecture provided by another embodiment of the present invention;

[0029] Figure 2A is a sequence diagram showing a resource transmission flow between nodes of a read-only system provided by one embodiment of the present invention;

[0030] Figure 2B is a sequence diagram showing a resource transmission flow between nodes of a write-only system provided by one embodiment of the present invention;

[0031] Figure 3 It is a flowchart of a method for accessing resources in a distributed database architecture provided by an embodiment of the present invention.

[0032] In the drawings, underlined numbers are used to indicate the item in which the underlined number is located or an item adjacent to the underlined number. Non-underlined numbers are associated with the item identified by the line that associates the non-underlined number with the item. When a number is not underlined and has an associated arrow, the non-underlined number is used to identify the general item that the arrow points to. DETAILED DESCRIPTION

[0033] The following detailed description describes embodiments of the invention and ways in which these embodiments may be implemented. Although some modes of implementing the invention have been disclosed, those skilled in the art will recognize that there may be other embodiments for implementing or practicing the invention.

[0034] Figure 1A is a block diagram showing various exemplary components of a node device provided by one embodiment of the present invention. Figure 1A , which shows a block diagram 100A of a node device 102 , which includes a memory 104 , a processor 106 , and a network interface 108 .

[0035] The node device 102 may include appropriate logic, circuits, interfaces or codes for accessing database resources such as memory pages and software locks. The node device 102 may also be referred to as a requester, which requires database resources. In one example, the node device 102 may be used for high performance computing (HPC). Examples of the node device 102 may include, but are not limited to, a network adapter, a server, a computing device in a computer cluster (e.g., a massively parallel computer cluster), a communication device including a portable or non-portable electronic device, a wireless modem, a supercomputer or a device based on remote direct memory access (RDMA).

[0036] The memory 104 may include appropriate logic, circuitry, interfaces, or code for storing data and instructions executable by the processor 106. Examples of implementations of the memory 104 may include, but are not limited to, electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), read only memory (ROM), hard disk drive (HDD), flash memory, solid-state drive (SSD), or CPU cache memory. The memory 104 may store an operating system or other program product (including one or more operating algorithms) to operate the node device 102.

[0037] The processor 106 may include appropriate logic, circuits, interfaces or codes for executing instructions stored in the memory 104. In one example, the processor 106 may be a general-purpose processor. Other examples of the processor 106 may include, but are not limited to, a control unit, a central processing unit (CPU), a digital signal processor (DSP), a microprocessor, a microcontroller, a complex instruction set computing (CISC) processor, an application-specific integrated circuit (ASIC) processor, a reduced instruction set (RISC) processor, a very long instruction word (VLIW) processor, a central processing unit (CPU), a state machine, a data processing unit, a graphics processing unit (GPU), and other processors or control circuits. In addition, the processor 106 may refer to one or more separate processors, processing devices, and processing units as part of a machine, such as a node device 102.

[0038] The network interface 108 may include suitable logic, circuitry, interface or code to communicatively couple the memory 104 and the processor 106. Examples of the network interface 108 include, but are not limited to, a data terminal, a transceiver, a fax machine, a virtual server, and the like.

[0039] Figure 1B is a block diagram showing various exemplary components of a distributed database architecture provided by one embodiment of the present invention. Figure 1A The element pairs in Figure 1B Describe. Figure 1B , which shows a distributed database architecture 100B, the distributed database architecture includes ( Figure 1A ) node device 102, shared memory 110 and current owner 112.

[0040] The distributed database architecture 100B may include appropriate logic, circuitry, interfaces, or code for supporting multi-instance database read and write operations using multiple node devices. The distributed database architecture 100B is particularly used for reading database resources. Alternatively, when a "read" operation requires database resources (e.g., memory pages), the distributed database architecture 100B is used in combination with a specific sequence of resource transfer stream operations, such as in Figure 2A Described in detail in .

[0041] The shared memory 110 may include suitable logic, circuitry, interfaces or code for storing metadata of database resources. The shared memory 110 may also be referred to as global shared memory.

[0042] The current owner 112 may include suitable logic, circuitry, interfaces, or code for storing the latest version of a database resource. When a database resource (e.g., a memory page or a software lock) is transferred between nodes for the purpose of being written or updated by a non-owner node, the writing node becomes the new database resource owner node. Figure 1B In the example of FIG. 1 , the current owner 112 may also be referred to as node 2. In addition, the node device 102 may also be referred to as node 0. Examples of the current owner 112 may include, but are not limited to, a server, a computing device in a computer cluster (e.g., a massively parallel computer cluster), a communication device including a portable or non-portable electronic device, a wireless modem, a supercomputer, or an RDMA-based device. Similar to the node device 102, the current owner 112 may have a memory for storing the latest version of the database resource, a processor for data processing, and a network interface for sending and receiving various requests related to the resource transmission stream.

[0043] In operation, the node device 102 used in the distributed database architecture 100B is used to access a resource by reading metadata identifying the current owner 112 of the resource from the shared memory 110. The node device 102 (i.e., the requester) is used to obtain the metadata of the current owner 112 of the resource from the shared memory 110 (in Figure 1B The resource metadata is read by the node device 102 (represented by the number "1" in the figure) to access resources such as memory pages and software locks (i.e., database resources). The resource metadata includes the identifier (ID) of the node device (e.g., the current owner 112) that holds the latest version of the resource. Alternatively, the metadata is used to locate the latest version of the resource. In addition, the metadata is used to maintain fairness in resource access and avoid starvation. Metadata can be used to track copies of one or more memory pages in the distributed database architecture 100B. Metadata can also be used to build one or more consistent read pages in the distributed database architecture 100B. Alternatively, the node device 102 is used to read resource metadata from the shared memory 110 to identify the current owner 112 of the resource.

[0044] The node device 102 is also used to access the resource in the following manner: requesting the resource from the current owner 112 of the resource; receiving the resource from the current owner 112. After identifying the current owner 112 of the resource, the node device 102 (i.e., the requester) is also used to request the resource from the current owner 112. This task is indicated by the arrow marked with the number "2" from the node device 102 to the current owner 112. Thereafter, the node device 102 (i.e., the requester) is used to receive the resource from the current owner 112. This task is indicated by the arrow marked with the number "3" from the current owner 112 toward the node device 102. In this way, in the distributed database architecture 100B, there are a total of two inter-node messages and two thread wake-ups and a single shared memory access, instead of four inter-node messages and four thread wake-ups used in the traditional distributed database architecture (e.g., the RMO model). It is assumed that the traditional distributed database architecture (i.e., the RMO model) has three entities, namely, the requester node, the owner node (or holder), and the master node. In the traditional distributed database architecture (i.e., RMO model), each resource is managed by a single master node responsible for resource metadata and distributed access. This means that in a distributed environment, each database read and write operation running on multiple nodes requires a single master node. In the traditional distributed database architecture (i.e., RMO model), the requester node queries the master node that manages the request source. The master node sends a message to the resource owner node. Thereafter, the resource is transmitted to the requester node by the owner node. After receiving the resource, the requester node sends a confirmation message about the completion of the resource transmission flow to the master node. In this way, in the traditional distributed database architecture (i.e., RMO model), there are four inter-node messages, including three master instances and four thread wakeups. Therefore, in the traditional distributed database architecture (i.e., RMO model), there are intensive message exchanges and central processing unit (CPU) context switches, which further limits system performance. Compared with the traditional distributed database architecture (i.e., RMO model), the distributed database architecture 100B replaces the master node with a shared memory 110, and thus eliminates the master instance of the three instances required in the RMO model. Alternatively, the distributed database architecture 100B eliminates the resource master role as a dedicated instance. In addition, the resource management logic executed by the master control node is moved to the resource owner node (i.e., the current owner 112). Therefore, the distributed database architecture 100B reduces the master instance access penalty, expensive CPU consumption, and the delay caused by the CPU context switch by providing distributed access to resource metadata. By utilizing shared memory 110, the node device 102 (i.e., the requester) can directly access the resource metadata. Direct access replaces the requirement to send requests to dedicated master control nodes and wake them up for indirect metadata access.By directly accessing resource metadata, fewer nodes (ie, node device 102 and current owner 112) participate in resource transfer flows, thereby reducing CPU context switching overhead, network hops, and bandwidth. The distributed database architecture 100B can also be referred to as a modified RMO model without a master node.

[0045] According to one embodiment, the node device 102 is used to read the metadata using remote direct memory access (RDMA) read. In the distributed database architecture 100B, the node device 102 (ie, the requester) is used to read the resource metadata from the shared memory 110 by using an RDMA read operation.

[0046] According to one embodiment, the node device 102 is also used to update the resource in the following manner: access the resource; update the resource; update the metadata in the shared memory 110. In one implementation, the node device 102 (i.e., the requester) can be used to update the resource (e.g., memory page) by reading the resource metadata from the shared memory 110 using an RDMA read operation. Thereafter, the node device 102 (i.e., the requester) can be used to request the resource from the current owner 112. The current owner 112 can be used to send the resource to the node device 102 (i.e., the requester). In this way, the node device 102 (i.e., the requester) can be used to access the resource and update the resource. In addition, the node device 102 (i.e., the requester) can be used to update the resource metadata in the shared memory 110. For example, in Figure 1C Such implementation scenario of the node device 102 is described in detail in .

[0047] According to one embodiment, the node device 102 is used to update the metadata using remote direct memory access (RDMA) writes. In one implementation, the node device 102 (i.e., the requester) is used to update the resource metadata in the shared memory 110 by using an RDMA write operation. For example, Figure 1C An exemplary scenario is described in detail in .

[0048] According to one embodiment, shared memory 110 is managed as an independent module. Shared memory 110 is managed as an independent module to provide high availability and persistence for distributed database architecture 100B. Independent modules can also be referred to as memory structures. Using shared memory 110 enables all database instances to access resource metadata. Shared memory 110 can also be referred to as a memory shared by node device 102 (i.e., requester) and current owner 112 constituting the cluster itself. By using shared memory 110 for resource metadata, resource transmission flow is simplified, and network hop count and CPU utilization are reduced. In one implementation, if the external memory structure and distributed hash module are unavailable or cannot be used, in this implementation, distributed database architecture 100B can still be implemented using other common solutions for managing shared memory 110 and distributed hash structure. In this case, some compromises in terms of high availability, recovery time and memory management efficiency may be inevitable. In many implementation scenarios, shared memory 110 can be a local memory shared by the access node (i.e., node device 102) itself, thus further reducing access latency.

[0049] Therefore, the distributed database architecture 100B uses RDMA read and write operations to achieve efficient remote memory access and data transfer. In the distributed database architecture 100B, the node device 102 (i.e., the requester) can directly access the memory by using the shared memory 110. In addition, the distributed database architecture 100B exhibits reduced network traffic and reduced context switching due to the lack of one instance (i.e., the master instance) as part of the data path with the master node eliminated. In addition, the distributed database architecture 100B enables fair and starvation-free changes in database resource ownership by moving the resource management logic from the master node to the resource owner node (i.e., the current owner 112). Alternatively, the master node logic runs on the owner node (i.e., the current owner 112) instead of on the CPU. The distributed database architecture 100B reduces context switching by using one-sided RDMA instead of transmission control protocol (TCP) messaging. By using the distributed database architecture 100B, control and data message exchanges can be significantly reduced (e.g., 25%). Therefore, CPU and network resource occupancy rates are reduced by the same ratio, thereby improving overall performance and reducing network latency.

[0050] Figure 1C FIG. 1 is a block diagram showing various exemplary components of a distributed database architecture provided by another embodiment of the present invention. Figure 1A and Figure 1B The element pairs in Figure 1C Describe. Figure 1C, where a distributed database architecture 100C is shown.

[0051] The distributed database architecture 100C corresponds to the distributed database architecture 100B, except that the distributed database architecture 100C is used to write database resources, while the distributed database architecture 100B is used to read database resources. Alternatively, the node device 102 (i.e., the requester) of the distributed database architecture 100C is used to access database resources, update database resources, and update resource metadata in the shared memory 110.

[0052] When a "write" operation requires database resources (e.g., memory pages), the following process is performed. In the distributed database architecture 100C, the node device 102 (i.e., the requester) is used to read resource metadata from the shared memory 110 by using an RDMA "read" operation (indicated by an arrow marked with the number "1" from the node device 102 toward the shared memory 110). Thereafter, the node device 102 (i.e., the requester) is used to send a request to access the resource to the current owner 112. The operation is indicated by an arrow marked with the number "2" from the node device 102 to the current owner 112. The current owner 112 is used to send the resource to the node device 102 (i.e., the requester) (indicated by an arrow marked with the number "3" from the current owner 112 to the node device 102). After updating the resource, the node device 102 (i.e., the requester) becomes the new owner of the resource. In addition, the node device 102 (i.e., the requester) is used to update the resource metadata in the shared memory 110 by using an RDMA "write" operation (indicated by the arrow marked with the number "4" from the node device 102 toward the shared memory 110). In this way, in the distributed database architecture 100C, there are a total of two inter-node messages (i.e., from the node device 102 to the current owner 112 and from the current owner 112 to the node device 102), two thread wake-ups, and two shared memory accesses (i.e., for reading resource metadata and updating resource metadata), instead of four inter-node messages and four thread wake-ups used in the typical RMO model. Therefore, the distributed database architecture 100C can also be called a modified RMO model without a master node.

[0053] Table 1 shows the number of CPU context switches and the number of inter-node messages transmitted for reading or writing (or updating) database resources (ie, memory pages) in the distributed database architecture 100B, 100C.

[0054] Table 1

[0055]

[0056] In the distributed database architecture 100B, 100C, the number of inter-node messages and thread wake-ups (i.e., CPU context switches) is two, which is relatively lower than the typical RMO model, in which there are four inter-node messages and four thread wake-ups when a memory page is requested for a read or write operation. In addition, in the distributed database architecture 100B, 100C, the shared memory accesses for read operations and write operations are once and twice, respectively. However, in the typical RMO model, there is no shared memory access. In the typical RMO model, the number of inter-node messages increases, which affects network availability and increases latency and context switching. However, in the distributed database architecture 100B, 100C, the number of inter-node messages decreases, which further reduces the number of context switches, CPU occupancy, and access latency.

[0057] For example, in an actual scenario, the distributed database architecture 100B, 100C can be used in the SQL DB query process. In this product, the typical RMO model is modified to eliminate the master node. The distributed database architecture 100B, 100C eliminates the sending of messages back and forth between the requester node that needs the data page and the master node that holds the metadata of the page and manages the page. In the distributed database architecture 100B, 100C, the resource metadata is stored in a shared memory 110 (i.e., global shared memory) accessible from all cluster nodes. The main data structure can be called a root information hash, which stores basic information about the resource. The resource metadata includes the ID of the owner node (e.g., the current owner 112) of the required resource. When more than one instance requires a specific block, resource transfer management is performed to maintain the integrity of the database data block. After eliminating the master node in the modified RMO model, the resource owner node (i.e., the current owner 112) performs resource management. As part of the cluster database execution flow, database resources are transferred between nodes (e.g., between the current owner 112 and the node device 102) for reading data or writing data. Figure 2A and Figure 2B The two cases of reading data or writing data are described in detail in FIG. 1 and 2. The flow is modified to avoid sending any messages to and from the master node. All control and data transmission only involves the node device 102 (i.e., the requester), the current owner 112 (i.e., the owner node) holding the latest version of the resource, and the shared memory 110 (i.e., the global shared memory).

[0058] Figure 2A FIG. 1 is a sequence diagram showing a resource transmission flow between nodes of a read-only system provided by an embodiment of the present invention. Figure 1A , Figure 1B and Figure 1CThe element pairs in Figure 2A Describe. Figure 2A , which shows a sequence diagram 200A showing a sequence of operations 202 to 210 for a read-only resource transfer flow between a node device 102 and a current owner 112 of a distributed database architecture 100B.

[0059] In one implementation, sequence diagram 200A can be used to "read" only the required memory pages. In addition, the requester and the owner are located on different nodes, such as node device 102 and current owner 112. In order to perform a read-only resource transfer flow between node device 102 and current owner 112, the sequence of operations 202 to 210 is performed in the following manner.

[0060] At operation 202, the node device 102 (ie, the requester) is used to read the root information from the shared memory 110 using an RDMA "read" operation to obtain the ID of the current owner 112 (ie, the resource owner node).

[0061] At operation 204, the node device 102 (i.e., the requester) is used to send a request for access to the resource to the current owner 112 (i.e., the resource owner node) using TCP messaging or an RDMA "send" operation. Alternatively, the node device 102 (i.e., the requester) is used to send a request called "ASK_OWNER" to the current owner 112 (i.e., the resource owner node). In one implementation, the node device 102 (i.e., the requester) can be used to request a memory page for read-only from the current owner 112 (i.e., the resource owner node).

[0062] At operation 206, the current owner 112 (i.e., the resource owner node) is used to send the resource to the node device 102 (i.e., the requester) using TCP messaging or RDMA "send" operation. In the above implementation scenario, the current owner 112 is used to return the read-only memory page to the node device 102 (i.e., the requester). Together with the memory page transfer, the memory page resource information is transmitted from the current owner 112 to the node device 102.

[0063] At operation 208, since the resource is required to be read-only without performing ownership transfer, the current owner 112 (i.e., the resource owner node) is used to add the node device 102 (i.e., the requester) to its page replica holder list managed by the current owner 112 (i.e., the resource owner node).

[0064] At operation 210, since the resource (e.g., memory page or software lock) is required for read-only, there is no need to send a confirmation message (also referred to as a "request to share" message) back to the current owner 112 (i.e., the resource owner node). Therefore, the current owner 112 (i.e., the resource owner node) is used to automatically continue to convert the queue and dequeue it after the resource transfer. The conversion queue can also be referred to as a queue that enables the shared memory 110 to manage resource transfers and sharing between nodes in the database cluster fairly and without starvation.

[0065] Figure 2B FIG. 1 is a sequence diagram showing a resource transmission flow between nodes of a write-only system provided by an embodiment of the present invention. Figure 1A , Figure 1B , Figure 1C and Figure 2A The element pairs in Figure 2B Describe. Figure 2B , which shows a sequence diagram 200B showing a sequence of operations 212 to 222 for a write-only resource transfer flow between a node device 102 and a current owner 112 of a distributed database architecture 100C.

[0066] In one implementation, sequence diagram 200B can be used to "write" only the required memory pages. In addition, the requester and the owner are located on different nodes, such as node device 102 and current owner 112. In order to perform a write-only resource transfer flow between node device 102 and current owner 112, the sequence of operations 212 to 222 is performed in the following manner.

[0067] At operation 212, the node device 102 (ie, the requester) is used to read the root information from the shared memory 110 using an RDMA "read" operation to obtain the ID of the current owner 112 (ie, the resource owner node).

[0068] At operation 214, the node device 102 (i.e., the requester) is used to send a request for access to the resource to the current owner 112 (i.e., the resource owner node) using TCP messaging or an RDMA "send" operation. Alternatively, the node device 102 (i.e., the requester) is used to send a request called "ASK_OWNER" to the current owner 112 (i.e., the resource owner node). In one implementation, the node device 102 (i.e., the requester) can be used to request a memory page for write-only from the current owner 112 (i.e., the resource owner node).

[0069] At operation 216, the current owner 112 (i.e., the resource owner node) is used to send the resource to the node device 102 (i.e., the requester) using TCP messaging or RDMA "send" operation. In the above implementation scenario, the current owner 112 is used to share the memory for write-only or read-only to exclusive (readonly2x) indication and memory page metadata (metadata, MD) with the node device 102 (i.e., the requester). In one case, if the node device 102 (i.e., the requester) already has the latest copy of the memory page, the node device 102 (i.e., the requester) returns the shared memory page.

[0070] At operation 218, the current owner 112 (ie, the resource owner node) is operable to send an invalidate and update the EDP list to all nodes that have read-only copies.

[0071] At operation 220, when the resource needs to be updated, the ownership transition is performed, so the current owner 112 (i.e., the resource owner node) is used to send the resource and resource metadata to the node device 102 (i.e., the requester), and the node device 102 now becomes the new owner. In addition, the node device 102 (i.e., the requester) is used to process the transition queue.

[0072] At operation 222, after acquiring the resource and its metadata, the node device 102 (ie, the requester) is operable to complete the ownership transfer by updating the root information on the shared memory 110. This is accomplished by using an RDMA "write" operation.

[0073] Figure 3 FIG. 1 is a flow chart of a method for accessing resources in a distributed database architecture provided by an embodiment of the present invention. Figure 1A , Figure 1B , Figure 1C , Figure 2A and Figure 2B The element pairs in Figure 3 Describe. Figure 3 , which shows a computer-implemented method 300 for accessing resources in a distributed database architecture. The computer-implemented method 300 includes steps 302 to 306. Figure 1A The node device 102 is used to execute the computer-implemented method 300.

[0074] A computer-implemented method 300 for accessing resources in a distributed database architecture is provided. The computer-implemented method 300 is used to access resources (eg, memory pages or software locks) in a distributed database architecture (eg, distributed database architecture 100B, 100C) for reading or writing (or updating).

[0075] In step 302, the computer-implemented method 300 includes a node device (e.g., node device 102) reading metadata identifying a current owner of a resource (e.g., current owner 112) from a shared memory (e.g., shared memory 110). The node device 102 is configured to read the metadata from the shared memory 110. The metadata includes an identifier (ID) of the current owner 112 of the resource.

[0076] In step 304, the computer-implemented method 300 further includes the node device 102 requesting the resource from the current owner 112 of the resource. In addition, the node device 102 is configured to request the resource from the current owner 112 who holds the latest version of the resource.

[0077] In step 306, the computer-implemented method 300 further includes the node device 102 receiving the resource from the current owner 112. After receiving the request from the node device 102, the current owner 112 is configured to transmit the resource to the node device 102. Alternatively, the node device 102 is configured to receive the resource from the current owner 112 of the resource.

[0078] According to one embodiment, the computer-implemented method 300 further includes reading the metadata using remote direct memory access (RDMA) reading. The node device 102 is configured to read the metadata by, for example, previously Figure 1B The RDMA read operation described in is used to read resource metadata from shared memory 110.

[0079] According to one embodiment, the computer-implemented method 300 further includes updating the resource by: accessing the resource; updating the resource; and updating metadata in the shared memory 110. The node device 102 is used to access the resource, update the resource, and update the resource metadata in the shared memory 110. For example, in Figure 1C An exemplary scenario is described in detail in .

[0080] According to one embodiment, the computer-implemented method 300 further includes updating the metadata using remote direct memory access (RDMA) writes. The node device 102 is configured to update the metadata by, for example, previously writing to the node device 102 in the Figure 1C The resource metadata in shared memory 110 is updated using the RDMA write operation described in detail in .

[0081] According to one embodiment, the shared memory 110 is managed as an independent module. Figure 1B Described in .

[0082] In one aspect, the present invention provides a computer readable medium comprising instructions which, when executed by a processor, cause the processor to perform the method of any one of the above claims. Figure 1A The processor 106 of the node device 102 is used to execute the computer-implemented method 300.

[0083] Therefore, the computer-implemented method 300 implements efficient management of database resources in a distributed database architecture by using the node device 102, the shared memory 110, and the current owner of the resource 112. The computer-implemented method 300 replaces the resource metadata access that is usually performed by the master node with direct access to the shared memory 110. Therefore, in a distributed database architecture (e.g., the distributed database architecture 100B, 100C), the inter-node message transmission count and CPU occupancy rate are reduced, which further improves the overall performance of the multi-instance distributed database system.

[0084] Steps 302 to 306 are merely illustrative. In addition, other alternatives may be provided in which one or more steps are added, one or more steps are deleted, or one or more steps are provided in a different order without departing from the scope of the claims herein.

[0085] Without departing from the scope of the invention as defined by the appended claims, the embodiments of the invention described above may be modified. Expressions such as "including", "comprising", "incorporating", "having", "being / being" etc. used to describe and claim the present invention are intended to be interpreted in a non-exclusive manner, i.e., allowing items, components or elements that are not explicitly described to also exist. References to the singular should also be interpreted as involving the plural. The word "exemplary" used herein means "as an example, instance or illustration". Any embodiment described as "exemplary" is not necessarily interpreted as being more preferred or more advantageous than other embodiments, and / or excluding the combination of features of other embodiments. The word "optionally" used herein means "provided in some embodiments and not provided in other embodiments". It should be understood that certain features of the present invention described in the context of a single embodiment for the sake of brevity may also be provided in a single embodiment by combination. On the contrary, the various features of the present invention described in the context of a single embodiment for the sake of brevity may also be provided in any other described embodiment of the present invention individually or by any suitable combination or appropriately.

Claims

1. A node device (102) for a distributed database architecture (100A, 100B), characterized in that: The node device (102) is used to access resources in the following manner: Reading metadata identifying a current owner (112) of the resource from shared memory (110); Requesting the resource from the current owner (112) of the resource; The resource is received from the current owner (112).

2. The node device (102) according to claim 1, characterized in that: Used to read the metadata using remote direct memory access (RDMA) reading.

3. The node device (102) according to claim 1 or 2, characterized in that: It is also used to update resources by: accessing the resources; updating the resources; and updating the metadata in the shared memory (110).

4. The node device (102) according to claim 3, characterized in that: Used to update the metadata using remote direct memory access (RDMA) writing.

5. The node device (102) according to any one of the above claims, characterized in that: The shared memory (110) is managed as an independent module.

6. A distributed database architecture (100A, 100B), characterized in that: The method comprises a node device (102) according to any one of the preceding claims.

7. A computer-implemented method (300) for accessing resources in a distributed database architecture (100A, 100B), characterized in that: include: The node device (102) reads metadata identifying the current owner (112) of the resource from the shared memory (110); The node device (102) requests the resource from the current owner (112) of the resource; The node device (102) receives the resource from the current owner (112).

8. The computer-implemented method (300) of claim 7, wherein: This includes reading the metadata using remote direct memory access (RDMA) reading.

9. The computer-implemented method (300) according to claim 7 or 8, characterized in that: The method also includes updating the resource by: accessing the resource; updating the resource; and updating the metadata in the shared memory (110).

10. The computer-implemented method (300) of claim 9, wherein: This includes using remote direct memory access (RDMA) writes to update the metadata.

11. The computer-implemented method (300) according to any one of claims 7 to 10, characterized in that: The shared memory (110) is managed as an independent module.

12. A computer-readable medium comprising instructions, characterized in that: The instructions, when executed by a processor (106), cause the processor (106) to perform a method (300) according to any one of the preceding claims.

Images