Methods and systems for transaction routing in distributed database system

Abstract

The present disclosure describes a method in a distributed database system, the method including: maintaining a graph comprising a plurality of vertices representing a respective plurality of keys, each key in the plurality of keys being a key of a data table stored in the distributed database system; monitoring a plurality of runtime transactions in the distributed database system to identify correlations between two or more keys referenced in the runtime transactions; updating the graph to include any edges between vertices representing keys having identified correlations and to omit any edges between vertices representing uncorrelated keys; and updating a global routing table based on at least one clique in the graph, wherein routing information stored in the global routing table is updated to indicate that two or more data tables routed by keys represented by vertices of the at least one clique are routed together. The above method can reduce data traffic between data nodes, and help to achieve better overall system usage and / or performance in a distributed database system.

Description

METHODS AND SYSTEMS FOR TRANSACTION ROUTING IN DISTRIBUTED DATABASE SYSTEM

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This is the first application for this disclosure.TECHNICAL FIELD

[0003] The present disclosure relates to distributed database systems, and in is particularly related to transaction routing in distributed database systems.BACKGROUND

[0004] A distributed database (also referred to as a distributed data store) is a type of database in which data is stored across multiple data nodes (also referred to as data servers) in a network. A database management system that uses a distributed database may be referred to as a distributed database system. Benefits of a distributed database system, compared to other database systems storing data in a single data node, include more flexible scalability (e.g., can add or remove data nodes depending on current data needs) and higher availability (e.g., multiple data nodes can provide redundancy in case one data node goes offline) .

[0005] Transaction routing in a distributed database system refers to the method by which a transaction (which is a unit of work in a database management system) is sent to a particular data node to be processed. Techniques for transaction routing have been developed with the aim of reducing latency (e.g., transaction processing rates should be high) and workload balancing (e.g., data nodes should preferably handle an approximately equal number of transactions) . In the context of database management systems, transaction routing may be referred to simply as routing, however this should not be confused with packet routing for example.SUMMARY

[0006] In various examples, the present disclosure describes methods and systems for transaction routing in a distributed database system. An example distributed database system may have a shared-everything architecture. In a shared-everything architecture, the multiple data nodes form a shared data storage that is shared across and accessible to multiple clients. However, a challenge with the share-everything architecture is that it can be sensitive to data affinity. Data affinity refers to the relationship or correlation between different sets of data, for example based on how often two sets of data are accessed together in a database transaction. For example, if data is not intelligently distributed across data nodes, data ping-pong may occur (in which data is transferred back and forth between two data node) , which can lead to poor performance of the overall system. Even for a balanced workload with balanced system resource usage, performance can drastically degrade with arbitrary routing occurs.

[0007] In various examples, the present disclosure provides methods and systems for transaction routing that reduces data traffic between data nodes, which may help to achieve better overall system usage and / or performance in a distributed database system (e.g., having a share-everything architecture) . Data tables having correlated data may be collocated on the same data nodes. This may provide a technical advantage in that the efficiency of the database system may be improved (e.g., faster rates of processing a transaction, lower use of communication resources to traffic data between data nodes) .

[0008] Examples of the present disclosure enable automatic detection of data correlation based on runtime transactions. The detected data correlation (e.g., indicated by correlated key pairs) may enable two data tables indexed by a correlated pair of keys to be routed together, which may help to reduce data traffic. The detection of data correlation from runtime transactions may enable the routing information to be dynamically adjusted to reflect actual workloads. This may provide a technical advantage in that the transaction routing can be adjusted in real-time to provide increased efficiency of the database system. Further, manual intervention by a human database administrator may be reduced or avoided.

[0009] Examples of the present disclosure may also enable workload rebalancing to be performed that takes into account data correlation. For example, if a first data table is to be rebalanced between two data nodes, a second data table that is indexed by a  key that is correlated to the key of the first data table may be rebalanced in a similar manner. This helps to ensure that the efficiency realized by collocating correlated data can be maintained after rebalancing.

[0010] Some embodiments of the present disclosure may include one or more of the following features, which can be separately adopted, or work together as a complete solution.

[0011] In an example of a first aspect, the present disclosure describes a method in a distributed database system, the method including: maintaining a graph comprising a plurality of vertices representing a respective plurality of keys, each key in the plurality of keys being a key of a data table stored in the distributed database system; monitoring a plurality of runtime transactions in the distributed database system to identify correlations between two or more keys referenced in the runtime transactions; updating the graph to include any edges between vertices representing keys having identified correlations and to omit any edges between vertices representing uncorrelated keys; and updating a global routing table based on at least one clique in the graph, wherein routing information stored in the global routing table is updated to indicate that two or more data tables routed by keys represented by vertices of the at least one clique are routed together.

[0012] In an example of the preceding example of the first aspect, the method may further include: providing the routing information stored in the global routing table to a client connected to the distributed database system to cause the client to send a transaction to a target data node that is routed in accordance with the routing information.

[0013] In an example of any of the preceding examples of the first aspect, the method may further include: receiving from a client a transaction routed to a target data node that is in conflict with the routing information stored in the global routing table; sending, to the client, the routing information stored in the global routing table; and carrying out the transaction at the target data node.

[0014] In an example of any of the preceding examples of the first aspect, monitoring the plurality of runtime transactions in the distributed database system to identify correlations between two or more keys referenced in the runtime transactions may include: evaluating a pair of keys in a given runtime transaction by: identifying the pair of keys referenced in the given runtime transaction; comparing a parameter value of each key in the pair of keys; identifying a correlation between the pair of keys when each key in the pair of keys has a same parameter value or identifying a noncorrelation between the pair of keys when each key in the pair of keys has a respective different parameter value; and updating the graph to increase a weight of an edge between vertices representing the pair of keys in response to identifying the correlation or updating the graph to decrease the weight of the edge between the vertices representing the pair of keys in response to identifying the noncorrelation; and repeating the evaluating for the plurality of runtime transactions.

[0015] In an example of the preceding example of the first aspect, the plurality of runtime transactions may be evaluated for a defined amount of runtime transactions; and updating the graph to include any edges between vertices representing keys having identified correlations and to omit any edges between vertices representing uncorrelated keys may be performed after the defined amount of runtime transactions and may include maintaining any edges having a non-zero positive weight and removing any edges have a zero or negative weight.

[0016] In an example of any of the preceding examples of the first aspect, the plurality of keys represented in the graph may be keys having shared characteristics.

[0017] In an example of the preceding example of the first aspect, the shared characteristics may include one or more of: a similar minimum value, a similar maximum value, a similar number of distinct values, a same data type, a similar name, a similar value distribution, or primary and foreign key relation.

[0018] In an example of some of the preceding examples of the first aspect, a first group of keys may share a first set of shared characteristics and a second group of keys may share a second set of shared characteristics, correlations may be only identified between keys belonging to a same group, and the at least one clique may be defined to include only vertices representing keys belonging to the same group.

[0019] In an example of any of the preceding examples of the first aspect, updating the global routing table may include: updating the routing information to indicate that two or more data tables routed by keys representing by vertices of a maximum clique in the  graph are routed together; removing from the graph the edges and vertices belonging to the maximum clique; and repeating the updating and removing for remaining edges and vertices in the graph until all edges have been removed from the graph.

[0020] In an example of the preceding example of the first aspect, after all edges have been removed from the graph there may remain at least one singleton data table that is unrouted in the global routing table, and the routing information may be updated to randomly route the singleton data table.

[0021] In an example of any of the preceding examples of the first aspect, the method may further include performing load balancing of a first data table, wherein the first data table is routed by a first key that may be correlated with a second key of a second data table, and wherein the load balancing may be performed by: redistributing the first data table by assigning a first partition of the first data table defined by a first range of the first key to a first data node and assigning a second partition of the first data table defined by a second range of the first key to a second data node; and redistributing the second data table by assigning a first partition of the second data table defined by a first range of the second key to the first data node and assigning a second partition of the second data table defined by a second range of the second key to the second data node, wherein the first range of the second key is equal to the first range of the first key and the second range of the second key is equal to the second range of the first key.

[0022] In another example aspect, the present disclosure describes an apparatus including: a memory; and a processor configured to execute instructions stored in the memory to cause the apparatus to carry out any of the preceding examples of the first aspect.

[0023] In another example aspect, the present disclosure describes a non-transitory computer readable medium having machine-executable instructions stored thereon, wherein the instructions, when executed by an apparatus, cause the apparatus to perform any of the preceding examples of the first aspect.

[0024] In another example aspect, the present disclosure describes a computer program characterized in that, when the computer program is run on a computer, the computer is caused to execute any of the preceding examples of the first aspect.BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:

[0026] FIG. 1 is a block diagram illustrating an example computing system, which may be used to implement examples of the present disclosure;

[0027] FIG. 2A is a block diagram illustrating an example architecture for a database management system, in accordance with examples of the present disclosure;

[0028] FIG. 2B is a block diagram illustrating an example interaction between clients and a database management system, in accordance with examples of the present disclosure;

[0029] FIG. 3A illustrates data tables in an example database management system, in accordance with examples of the present disclosure;

[0030] FIGS. 3B-3D illustrate an example of a graph-based representation of key correlations, in accordance with examples of the present disclosure;

[0031] FIG. 4 is a flowchart illustrating an example method of determining routing information based on data correlation, in accordance with examples of the present disclosure; and

[0032] FIG. 5 is a flowchart illustrating an example method of transaction routing, in accordance with examples of the present disclosure.

[0033] Similar reference numerals may have been used in different figures to denote similar components.DETAILED DESCRIPTION

[0034] Examples of the present disclosure may enable better transaction routing and load balancing in a distributed database system (e.g., having a shared-everything architecture) , by accounting for data affinity. Data affinity refers to the degree of closeness  between data elements, such as how they are accessed, stored and / or processed. In the context of a distributed database system, data affinity may inform how data is stored across data nodes. For example, by taking data affinity into consideration, examples of the present disclosure may enable data that is frequently accessed together (e.g., two data tables that are frequently accessed in the same transaction) to be stored on the same data node, which may help to reduce the need for data transfer between data nodes. Data affinity may include inter-transaction correlations (e.g., where data correlation is found within the same transaction) as well as inter-transaction correlations (e.g., where data correlation is found within the same type of transaction) . When data affinity is taken into account, this means that two sets of data that have correlation with each other should be collocated (e.g., stored on the same data node) .

[0035] A naive way of accounting for data affinity would be to store all data in one data node. However, such an approach does not realize the benefits of using a distributed database. Examples of the present disclosure provide techniques for identifying data correlations and for distributing data intelligently based on the identified data correlations. Examples of the present disclosure may enable realization of a physical data layout (e.g., how data is stored across different physical data nodes) that reduces data traffic (i.e., sending data between data nodes) , and may enable determination of preferred routing based on such a physical data layout. Examples of the present disclosure also provide improved load balancing.

[0036] Although some load balancing techniques have been implemented in existing technologies, the present disclosure provides improved load balancing that detects and accounts for data correlation, as well as enforcing data correlation. As such, examples of the present disclosure may provide improvements on top of existing load balancing technologies.

[0037] Some existing load balancing techniques aim to balance resources at a session or transaction level based on certain configurations at coarse granularity. However, existing approaches do not consider data affinity when performing routing for load balance. A distributed database, such as found in a share-everything architecture, can be very sensitive to data and workload affinity. For example, consider the Transaction Processing Performance Council Benchmark C (TPC-C) from the transaction processing performance council (TPC) . Even with balanced CPU usage, it has been found that a non-direct workload (that is, workload where a transaction is not directed to the data node where the data required for the transaction is located) has only one third of the performance of a directed workload (that is, workload where a transaction is directed to the data node where the data required for the transaction is located) . Thus, it can be seen that in addition to balancing system resources, data affinity is also an important consideration.

[0038] Examples of the present disclosure enable automatic detection of data correlation based on runtime workload and schema information, as well as dynamic adjustment of routing based on workload balance. The disclosed automatic detection of data correlation may be performed on data information at the transaction level. During workload runtime, the workload data is sampled and used to validate routing decisions. In examples disclosed herein, routing decisions are based on a potential key pair graph that is generated by grouping index keys having similar statistics. Load balancing may be performed by adjusting a consistency hash ring at the client side, based on system resources usage statistics maintained at the sever side.

[0039] FIG. 1 illustrates a block diagram of an example simplified computing system 100, which may be used to implement methods and systems described herein. Other processing systems suitable for implementing the methods and systems described in the present disclosure may be used, which may include components different from those discussed below. In some example embodiments, the computing system 100 may be implemented across more than one physical hardware unit, such as in a parallel computing, distributed computing, virtual server, or cloud computing configuration. Although FIG. 1 shows a single instance of each component, there may be multiple instances of each component in the computing system 100.

[0040] The computing system 100 may include one or more processing units 102, each of which may be a hardware processor, such as a central processing unit (CPU) with a hardware accelerator, a graphics processing unit (GPU) , a tensor processing unit (TPU) , a neural processing unit (NPU) , a microprocessor, an application-specific integrated circuit (ASIC) , a field-programmable gate array (FPGA) , a dedicated logic circuitry, a dedicated artificial intelligence processor unit, or combinations thereof.

[0041] The computing system 100 may also include one or more input / output (I / O) interfaces 104, which may enable interfacing with one or more optional input devices 106 and / or optional output devices 108. In the example shown, the optional input device (s) 106 (e.g., a keyboard, a mouse, a microphone, a touchscreen, and / or a keypad) and optional output device (s) 108 (e.g., a display, a  speaker and / or a printer) are shown as external to the computing system 100. In other examples, one or more of the input device (s) 106 and / or the output device (s) 108 may be included as a component of the computing system 100. In other examples, there may not be any input device (s) 106 and output device (s) 108, in which case the I / O interface (s) 104 may not be needed.

[0042] The computing system 100 may include one or more network interfaces 110 for wired or wireless communication with a network. The network interface (s) 110 may include interfaces for wired links (e.g., Ethernet cable) and / or wireless links (e.g., one or more radio frequency links) for intra-network and / or inter-network communications. The network interface (s) 110 may enable wireless communication via one or more transmitters 112 or transmitting antennas, one or more receivers 114 or receiving antennas, and various signal processing hardware and software.

[0043] The computing system 100 may also include one or more storage devices such as storage units 118, which may include a non-transitory storage unit such as a solid state drive, a hard disk drive, a magnetic disk drive and / or an optical disk drive. The storage devices of computing system 100 may include one or more memories 120, which may include a volatile or non-volatile memory (e.g., a flash memory, a random access memory (RAM) , and / or a read-only memory (ROM) ) . The storage devices (e.g., storage units 118 and / or non-transitory memory (ies) 120) may store instructions for execution by the processing units (s) 102, such as to carry out examples of the present disclosure. The memory (ies) 120 may include other software instructions, such as for implementing an operating system or a DBMS disclosed herein and other applications / functions.

[0044] In some examples, one or more data sets and / or module (s) may be provided by an external memory (e.g., an external drive in wired or wireless communication with the computing system 100) or may be provided by a transitory or non-transitory computer-readable medium. Examples of non-transitory computer readable media include a RAM, a ROM, an erasable programmable ROM (EPROM) , an electrically erasable programmable ROM (EEPROM) , a flash memory, a CD-ROM, or other portable memory storage.

[0045] There may be a bus 122 providing communication among components of the computing system 100, including the processing units (s) 102, I / O interface (s) 104, network interface (s) 110, storage unit (s) 118 and memory (ies) 120. The bus 122 may be any suitable bus architecture including, for example, a memory bus, a peripheral bus or a video bus.

[0046] In some embodiments, a database management system (DBMS) in accordance with the present disclosure may be implemented using an example computing system 100 having a plurality of processing units 102. The DBMS is a software-based system that enables a user (e.g., database administrator) to define, create, maintain and control access to the database. The DBMS is the software that interacts with end users (e.g., client users) , applications, and the database itself to capture and analyze the data. The DBMS acronym is sometime extended to indicate the underlying database model, such as RDBMS for relational database model, OODBMS or ORDBMS for object (orientated) database model, and ORDBMS for object-relational database model. Other extensions can indicate some other characteristic, such as DDBMS for a distributed database management system. The core functionality provided by a DBMS is the storage, retrieval and update of data. A fully-fledged general purpose DBMS generally provides core functionalities such as: data storage, retrieval and update, support for transactions, facilities for recovering the database should it become damaged, support for authorization of access and update of data, and enforcing constraints to ensure data in the database abides by certain rules, among other functions.

[0047] A client may interact with the database via an application program interface (API) that interfaces with the DBMS. A database transaction (or simply referred to as transaction) is a unit of work performed within a DBMS. A transaction may include multiple statements, which may be data manipulation language (DML) statements, query statements or other types of statements. A cloud-based database is a type of database service which may be built, deployed and delivered through the cloud. A distributed DBMS may be implemented as a cloud-based database, for example.

[0048] FIG. 2A illustrates a simplified logical block diagram of an architecture of a DBMS 200, which may be used to implement examples of the present disclosure. The distributed DBMS 200 in FIG. 2A includes a compute layer 210, a memory layer 220 and a storage layer 230. It should be understood that the layers 210, 220, 230 refer to logical separation of the functions of the DBMS 200, and are implemented on physical hardware.

[0049] The compute layer 210 may be implemented by a compute cloud (also referred to simply as the “cloud” ) . The compute layer 210 includes one or more data nodes 212 (also referred to as data servers) . Generally, a client (not shown in FIG. 2A) may  make requests to the database by accessing a data node 212 using an API 242 (e.g., using the Java Database Connectivity (JDBC) API or using the Open Database Connectivity (ODBC) API) . Database transactions, each of which can include multiple statements such as insert, update, delete, select (i.e. read request) , are handled by the data nodes 212 in the compute layer 210. It should be noted that the data nodes 212 may not be physical hardware servers, but rather software running on the physical processing resources of the cloud. A data node 212 may be software (also referred to as an instance of the data nodes 212) running on a virtual machine or a container provided by the cloud. Even in examples where a data node 212 is not a physical hardware server, the data node 212 may be considered to have physicality because any software used to instantiate the data node 212 is implemented on a physical machine. For simplicity the present disclosure will refer to a data node 212 as being a physical hardware server.

[0050] The memory layer 220 provides global resources available to all of the data nodes 212. In some examples, the memory layer 220 may be a hybrid layer that is deployed together with the compute layer 210. Some functions may be shared between or implemented in both the compute layer 210 and the memory layer 220, such as a resource monitoring module (not shown) which may be used for monitoring workload and resource usage in the DBMS 200. For example, the memory layer 220 may contain a global buffer 222 and system catalog tables 224. The system catalog tables 224 contain information about the data stored and managed by the DBMS 200, such as a database schema and a global routing table. The global routing table contains information about how data is partitioned across the physical disks in the storage layer 230. Information contained in the global routing table is used by clients to determine which data node 212 to connect to in order to carry out transactions (e.g., based on the data that needs to be accessed for the statements in the transaction) . As will be discussed further below, the global routing table may be updated as data is relocated for workload balancing purposes, for example.

[0051] The storage layer 230 may be implemented using block-based shared storage with a file interface. The storage layer 230 represents the physical on-disk long-term storage of the DBMS 200. Data is stored in the storage layer 230. The storage layer 230 includes one or more page stores 232, which stores pages containing data, and one or more log stores 234, which stores one or more redo logs. The page store (s) 232 serves read requests (that is, requests to read data from one or more pages) received from a data node 212.

[0052] FIG. 2B illustrates an example of how a client may interact with the DBMS 200 via a data node 212 of the DBMS 200. It should be noted that the DBMS 200 in FIG. 2B may have the same or similar architecture to that DBMS 200 shown in FIG. 2A, however some details have been omitted from FIG. 2B for simplicity.

[0053] There may be a plurality of clients 250-1 to 250-k (generally referred to as a client 250) . A client 250 may be any machine (e.g., computing system) that connects to the DBMS 200 in order to carry out a transaction. A client 250 may access the DBMS 200 via an API with any data node 212 (e.g., any one of data node-1 212-1 to data node-n 212-n) .

[0054] As previously mentioned, the global routing table 226 is stored in the system catalog tables 224. Each data node 212 stores a copy of the system catalog tables 224, including the global routing table 226, which are synchronized in real-time. A client 250 can access the global routing table 226 via any data node 212 to which the client 250 is connected. In this example, client-1 250-1 has a connection with data node-1 212-1. Client-1 250-1 can access the global routing table 226 stored on data node-1 212-1 and can cache routing information in a local routing table-1 252-1 stored locally on client-1 250-1. Typically, the local routing table-1 252-1 is smaller than the global routing table 226 because local routing table-1 252-1 only contains routing information that is relevant to the transactions of that client-1 250-1. Generally, each client 250-1 to 250-k stores a respective local routing table 252-1 to 252-k (generally referred to as local routing table 252) locally, which contains routing information that is relevant to the transactions of that respective client. For example, local routing table 252-1 may store routing information for a first data table that is queried by client-1 250-1 whereas local routing table-2 may instead store routing information for a different second data table that is queried by client-2 250-2.

[0055] The DBMS 200 is an example of a distributed database, in which there are multiple physical machines that are located physically apart (e.g., across multiple buildings, regions, etc. ) . Although the data is considered to be logically stored in a single storage layer 230, physically the data is partitioned and stored in physically separate disks. Each physical disk may be accessed by a respective data node 212 (e.g., a physical data server where the physical disk resides) . Therefore, when client-1 250-1 makes a transaction to the DBMS 200, the client-1 250-1 uses routing information in the local routing table-1 252-1 to identify which data node 212 stores the relevant data and a connection is made to that data node 212. For example, the routing information in local  routing table-1 252-1 may cause client-1 250-1 to make a connection with data node-1 212-1 in order to carry out a transaction. For example, if the transaction requires data stored in data table 1, the local routing table-1 252-1 may indicate that data table 1 is routed using a first key. Client-1 may perform hashing on the first key in order to identify data node-1 212-1 and the target data node to send the transaction.

[0056] A problem can occur if the data partitioning across the data nodes 212 does not account for data correlation within a transaction. For example, consider a transaction having the following statements:

[0057] Select *from table1 where a=1;

[0058] Update table1 set a=3 where a=1;

[0059] When data correlation within the transaction is not taken into account, the first statement (Select) may be directed to data node-1 212-1 and the second statement (Update) may be directed to data node-2 212-2. In such a scenario, the data page containing table1 where a=1 will be transferred between data node-1 212-1 and data node-2 212-2 (which may be referred to as data “ping pong” ) .

[0060] Thus, as a result of failure to account of data correlation, data may need to be moved between data nodes 212 during a transaction. This movement of data (also referred to as data traffic) involves reading and writing to disk, which can be slow. Failure to collocate correlated data can result in performance degradation of the DBMS 200 (e.g., increased latency, overloaded data nodes, etc. ) .

[0061] An example of how data correlation may be automatically detected by the DBMS, in accordance with the present disclosure, is now described. The automatic correlation detection monitors transactions during runtime and gathers query data within each transaction. The data correlation is detected at the schema level by considering the foreign key and primary key relation. The automatic correlation detection involves finding correlation key candidates, graph modeling potential correlation, collecting runtime statistics for graph validation, and in cases maximum clique reduction, as discussed below in further detail. After a pair of keys have been validated to be correlated, they can be used as partition keys for workload balancing purposes.

[0062] The correlation key candidates are first identified. Each correlation key candidate is a key that is potentially correlated with another key. A group of correlation key candidates may be identified based on similarity of key characteristics, such as having similar minimum value, similar maximum value, similar numbers of distinct values, same data type, similar name, similar value distribution, primary and foreign key relation, etc. Various techniques may be used to determine if two keys have a similar key characteristic. For example, two keys may be considered to have a similar key characteristic (e.g., a similar minimum value) if that key characteristic for each of the two keys is within a defined margin of each other (e.g., the two keys have a minimum value within 10%of each other, or within ±10 of each other) . The defined margin may be any suitable margin, which may be defined by percentage (e.g., within 10%, with 5%, with 3%, etc. without limitation) or difference (e.g., within ±50, within ±10, within ±5, etc. without limitation) . In some examples, similarity of a key characteristic may be determined based on a significant overlap in data distribution (e.g., at least 90%overlap, at least 95%overlap, etc. without limitation) . In some examples, similarity of a key characteristic may be determined based other statistical analyses, such as using a clustering algorithm (e.g., k-means clustering, model-based clustering, etc. without limitation) . Other methods of determining similarity between keys may be used. It should be understood that there is a potential trade-off in how similarity is defined. If similarity between two keys is defined to encompass a greater range of differences (e.g., minimum values having a difference of up to 20%may be considered to be similar) then potentially too many correlation key candidates are identified (including many false positives) that will need to be processed, thus requiring more processing resources. On the other hand, if similarity between two keys is defined to encompass a smaller range of differences (e.g., minimum values having a difference of up to 5%may be considered to be similar) then there is a risk that keys that have actual correlation are missed from the correlation key candidates.

[0063] Similarity of key characteristics may be identified from information stored in the schema in the system catalog tables. A group of correlation key candidates may be identified by first identifying all keys (also referred to as indexes) from the system catalog table (e.g., pg_index typically is the system catalog table containing index definitions, from which the index columns may be identified) . Then the minimum value, maximum value, and the number of distinct values within each key are determined. For example, if values of a given key are stored in a B-tree structure, the minimum and maximum values may be determined by querying the leftmost and rightmost values, respectively, of the second level of the B-tree structure, and the number of distinct values may  be determined based on the number of leaves of the B-tree structure. Keys having similar key characteristics are grouped together as a group of correlation key candidates. That is, keys having similar characteristics (such as having similar minimum value, similar maximum value and similar numbers of distinct values) are considered to be potentially correlated with each other.

[0064] It should be noted that there may be multiple groups of correlation key candidates that are grouped by similarity of key characteristics. All correlation key candidates within a group have similar key characteristics to other correlation key candidates within the same group, and there may be multiple such groups that may or may not overlap with each other. For example, a first key may have a minimum value of 10, a maximum value of 100 and 100 distinct values; a second key may have a minimum value of 8, a maximum value of 100 and 95 distinct values; and a third key may have a minimum value of 15, a maximum value of 102 and 100 distinct values. Then the first key and second key may be in a first group of correlation key candidates because they have similar minimum value (e.g., within ±5) , maximum value (e.g., within ±5) and number of distinct values (e.g., within ±10%) ; as well, the first key and third key may be in a second group of correlation key candidates because they have similar minimum value (e.g., within ±5) , maximum value (e.g., within ±5) and number of distinct values (e.g., within ±10%) . However, the second key and the third key would not be grouped with each other because the difference between the minimum values exceed the defined margin of ±5. All groups of correlation key candidates, each having a respective set of similar characteristics, are represented in the same graph. One group of correlation key candidates may be distinguished by another group by assigning group labels to the edges between the vertices representing the correlation key candidates. In the simple example provided above, the edge between the vertices representing the first and second keys may be assigned a first group label (to indicate the first and second keys belong to the first group) and the edge between the vertices representing the first and third keys may be assigned a second group label (to indicate the first and third keys belong to the second group) .

[0065] The above process may be illustrated using the simplified example provided by TPC-C. The TPC-C example is based on a multi-warehouse wholesale operation.

[0066] FIG. 3A illustrates the example data structure 300 of the database in the TPC-C example. In this example, there are nine data tables. Each data table is labeled with the table name, the cardinality and the key (s) for that table. For example, the Warehouse table has a cardinality W (which has a minimum value of 10 in TPC-C benchmark testing) and the key w_id. The relationships between tables are indicated by an arrow, where the number adjacent to each arrow indicates the one-to-many relationship. For example, the arrow from the Warehouse table to the District table indicates that the District table contains 10 entries for each entry in the Warehouse table (and thus the cardinality of the District table is W*10) .

[0067] To identify correlation key candidates, all keys of all the tables are considered. For each key, the minimum value, maximum value and number of distinct values are determined. Then the keys having similar characteristics are grouped together. For example, it may be found that the w_id key of the Warehouse table, the d_id and d_w_id keys of the Districts table and the c_d_id and c_w_id keys of the Customers table have similar characteristics (e.g., similar minimum value, maximum value and number of distinct values) and thus form a group of correlation key candidates. In this example, there is only one group of correlation key candidates, however it should be understood that there can be multiple groups of correlation key candidates each having a respective set of similar characteristics.

[0068] After identifying and grouping keys with similar characteristics, a graph is generated in which the correlation key candidates are vertices of the graph, and correlation key candidates with similar characteristics are connected by edges. FIG. 3B illustrates the example graph 310, in which the correlation key candidates w_id, d_id, d_w_id, c_d_id and c_w_id are represented by respective vertices connected by edges. Two correlation key candidates that are connected by an edge in the graph 310 are potentially correlated to each other.

[0069] The next step is then to validate the graph 310 to remove edges that are not actual correlations. This can be done by collecting data from actual transactions from clients in runtime. If two keys are actually correlated, then the correlation should show up in actual transactions (e.g., real-world transactions requested by real-world clients) . Each time a pair of correlation key candidates from the same group appear in one transaction, the weight of the edge between the pair of correlation key candidates is increased if the transaction reflects actual correlation (e.g., two correlation key candidates have the same parameter value in a single transaction) or decreased if the transaction does not reflect any correlation (e.g., two correlation keys candidates have different parameters value in a single transaction) . Consider the following example transaction:

[0070] select *from warehouse where w_id = 5

[0071] insert into customer where c_w_id = 5 and c_d_id =3

[0072] In the above example transaction, the correlation keys candidates w_id and c_w_id have the same value, thus the weight of the edge 318 between the vertex 312 representing w_id and the vertex 314 representing c_w_id is increased. On the other hand, the correlation keys candidates w_id and c_d_id have different values, thus the weight of the edge 320 between the vertex 312 representing w_id and the vertex 316 representing c_d_id is decreased.

[0073] Each data node 212 may be responsible for collecting information for updating edge weights using transactions processed by each data node 212. The collected information may be used to validate the graph 310 (which is stored in the system catalog tables accessible by all data nodes 212) by updating the edge weights.

[0074] In this way, the parameter values bound to each statement within each transaction are collected as statistical information that is used to validate the graph 310. For example, if the parameter values are the same between a pair of correlation key candidates, the edge weight of the graph is increased between the vertices representing the two correlation key candidates, otherwise the edge weight is decreased.

[0075] In some cases, certain types of statements (e.g., a JOIN query) may indicate a strong correlation between the two keys used for joining two tables, in which case the edge weight between the vertices representing the two key may be increased by a greater amount. In some examples, an edge weight may be increased by a greater amount where there is a hard functional dependency between the two keys. A hard functional dependency is a relationship where one attribute (or a set of attributes) in the database strictly determines another attribute. For example, a data table may contain employee data where each employee has a name and the name determines the employee’s identification; in this case, there is a hard functional dependency between name and identification. An edge weight may be increased by a lesser amount where there is a soft functional dependency between the two keys. A soft functional dependency is more relaxed relationship. It indicates that an attribute is often, but not always dependent on another attribute. For example, if a data table contains data about vehicles, including the vehicle make and model, there is a soft functional dependency between make and model; if one data table is partitioned by make and another data table is partitioned by model, then there is a correlation.

[0076] This statistical information and graph validation may be performed until information from a defined amount of transactions have been collected (e.g., collect information over a defined period of time such as 5 minutes during regular workload, or collect information for a defined number of transactions such as 3000 transactions) .

[0077] FIG. 3C shows an example of the resulting graph with edge weights. An edge having a negative weight or zero weight indicates that there was no correlation found between the correlation key candidates connected by that edge, and an edge having a positive weight indicate that there is correlation between the correlation key candidates connected by that edge. In this example, the edge 318 connecting the vertices 312 and 314, representing w_id and c_w_id respectively, has a positive weight of 278, indicating w_id and c_w_id are correlated keys (also referred to as a key pair) . On the other hand, the edge 320 connecting the vertices 312 and 316, representing w_id and c_d_id respectively, has a negative weight of -1314, indicating no correlation between these two keys.

[0078] The edges having negative or zero weights are removed, leaving only the validated key pairs connected by edges. The resulting graph may be referred to as the validated graph. FIG. 3D shows an example, in which the edges having negative or zero weights in FIG. 3C have been removed, leaving only w_id, c_w_id and d_w_id as correlated keys.

[0079] The global routing table stored in the system catalog tables may then be updated to reflect the key correlations identified in the final graph. In some examples, the global routing table may be updated iteratively based on the maximum clique in the graph. A clique refers to a group of vertices in which every pair of vertices are adjacent to each other (i.e., directly connected by an edge) , and the maximum clique refers to the clique having the largest number of vertices within the graph. In examples where the edges of the graph are labeled according to different groups (where keys belonging to the same group are correlation key candidates) , a clique (and thus the maximum clique) may be defined only where all the edges in the clique are labeled with the same group. That is, a clique may be defined to be a group of vertices in which every pair of vertices are directly connected by an edge that is labeled with the same group. The maximum clique may then be defined to be the clique having the largest number of vertices all directly  connected to each other by edges all having the same group label. The global routing table may be updated based on the maximum clique. In particular, the global routing table may be updated such that the tables indexed by the correlated keys represented by the vertices in the maximum clique are routed together. For example, if a first key of a first data table and a second key of a second data table both belong to the same maximum clique, then the global routing table may be updated to include routing information indicating that the first data table should be routed by the first key and the second data table should be routed by the second key.

[0080] In the example of FIG. 3D, the maximum clique contains the vertices representing w_id, c_w_id and d_w_id. Accordingly, the resulting global routing table may be updated to indicate that w_id, c_w_id and d_w_id are to be used as the key for routing transactions for the corresponding data tables (i.e., for the Warehouse table, Customer table and District table) . Further, because the keys w_id, c_w_id and d_w_id have been found to be correlated, the data tables indexed by these keys should be collocated on the same data node. If the data tables are to be partitioned across multiple data nodes, then the data tables should be partitioned using the same value ranges for the correlated keys. When load balancing is performed, the load balancing also takes into account this correlation, such that if one data table is to be rebalanced based on one key then another data table that is indexed by a correlated key will also be rebalanced in the same way.

[0081] Based on the example in FIG. 3D, the global routing table may be updated to contain the following routing information: Example global routing table

[0082] In the example global routing table above, the Warehouse table, Customer table and District table (indicated by W, C and D, respectively) are routed by the correlated keys w_id, c_w_id and d_w_id. For a transaction including a reference to table W, the transaction is routed based on the key w_id; when the transaction includes a reference to table C, the transaction is routed based on the key c_w_id, and so on. If a transaction references multiple data tables, the transaction may be routed based on the largest table.

[0083] Updating the global routing table includes assigning (or reassigning) the data tables to the data nodes indicated by the global routing table. This may include partitioning a data table across multiple data nodes. In examples of the present disclosure, this partitioning takes into account data correlation. In the example above, the data tables W, C and D are partitioned across data node 1 and data node 2, where the partitioning uses the same value ranges for the correlated keys w_id, c_w_id and d_w_id (e.g., the same ranges of 1-100 and 101-200 are used to partition the data tables across data node 1 and 2, respectively, based on the keys w_id, c_w_id and d_w_id) .

[0084] After the global routing table has been updated based on the maximum clique, the edges and vertices of the maximum clique may be removed from the graph. If the graph includes edges labeled according to different groups, removal of the maximum clique from the graph includes removing all edges contingent on the vertices in the maximum clique including edges labeled with different groups.

[0085] The maximum clique in the remaining graph is then identified and similarly used to update the global routing table and removed from the graph. In this way, the global routing table may be iteratively updated until all correlated keys (represented by vertices connected by edges in the graph) have been added to the global routing table.

[0086] In some examples, after all connected vertices have been added to the global routing table, there may remain one or more data tables that remain absent from the global routing table. Such a data table may be referred to as a singleton data table or an unrouted data table. For example, a particular data table may not have any key belonging to a key pair in the graph (e.g., none of the keys of that particular data table is represented by a vertex connected by an edge to a vertex representing a key in a different data table) . This may be the case where all transactions for that particular data table are performed within the same table using the same key. In some examples, that particular data table may be randomly assigned to a data node. The particular data table may be assigned in a round robin manner, in which each data node may be assigned a singleton data table in turn.

[0087] Information about the correlated keys may be stored by the DBMS. For example, the validated graph (in which only edges representing validated correlations remain) may be stored in the system catalog tables. This stored information may be updated in subsequent validations.

[0088] As mentioned previously, rebalancing of the data tables may take into account the data correlation, as disclosed in the present disclosure. Consider again the example shown in FIG. 3A. Assume that the Warehouse table is partitioned between data node 1 and data node 2, such that data indexed by w_id 1 to 100 is stored in data node 1 and data indexed by w_id 101 to 200 is stored in data node 2. If w_id is correlated with c_w_id (e.g., as represented by the validated graph shown in FIG. 3D) , this means that the Customer table should be also partitioned between data node 1 and data node 2 such that data indexed by c_w_id 1 to 100 is stored in data node 1 and data indexed by c_w_id 101 to 200 is stored in data node 2. Consider the example in which the Warehouse table is rebalanced by moving data in the Warehouse table indexed by w_id 50 to 100 to data node 2. Because c_w_id is correlated with w_id (as indicated by the stored graph) , this means that data in the Customer table indexed by c_w_id 50 to 100 also should be moved to data node 2.

[0089] The processed described above for automatic detection of data correlation, graph validation (or revalidation in the case where the graph was previously validated) and updating the global routing table may be performed repeatedly, for example on a regular or periodic basis (e.g., every 5 minutes) . This may help to ensure that the routing information contained in the global routing table is reflective of actual workloads.

[0090] The information stored in the global routing table is used by clients to maintain respective local routing tables. An example of how a client uses and updates the routing information is now described with reference to FIG. 2B.

[0091] As previously described, each client 250 maintains a respective local routing table 252 in a local cache. When a client 250 wishes to perform a transaction with the DBMS 200, the client 250 uses the local routing table 252 to determine the routing key value. To determine which data node 212 should be the connection target, the client 250 uses a consistency hash ring to hash the routing key value to the target data node 212. Typically, the value range corresponding to each data node 212 on the consistency hash ring should be adjusted according to the current system resource usage on each data node 212 to prevent some data nodes from being overloaded. The client 250 may additionally use a round robin to identify the target data node 212. Round robin and consistent hashing are commonly used techniques that add resiliency in case of added or dropped data nodes 212.

[0092] The client 250 sends a transaction to the target data node 212 (e.g., client 1 250-1 sends a transaction to data node-1 212-1 in the example of FIG. 2B) . While sending the first statement in the transaction, the client 250 compares the version number associated with the local routing table 252 with the version number associated with the global routing table 226 (acopy of which is available at each data node 212) . If the version number does not match, the client 250 requests updated routing information from the target data node 212. In response, the target data node 212 generates a list of preferred nodes according to the alias of the transaction. The target data node 212 also determines whether any routing policies exist. If there are routing policies, the target data node 212 selects the routing policy with the highest priority. If there are not any routing policies, the target data node 212 uses the random routing method. The target data node 212 sends the updated routing information (e.g., including updated target nodes, routing key, and routing method) to the client 250. The client 250 caches the routing information in its local routing table 252 for future transactions. It should be noted that the current transaction (which the client 250 has already sent to the target data node 212) may continue even if the current target data node 212 does not match the updated routing information.

[0093] FIG. 4 is a flowchart illustrating an example method 400 for determining routing information based on data correlation, as disclosed herein. The method 400 may be carried out in a server of the DBMS, such as at a data node (e.g., embodied in the computing system 100) . The method 400 may be performed in a distributed DBMS, particularly where data storage is distributed among a plurality of data nodes. The method 400 may be performed by a functional unit, such as a processor or any other suitable unit.

[0094] At 402, a graph is maintained at the DBMS. The graph contains a plurality of vertices representing a respective plurality of keys. Each key represented by a vertex in the graph is a key of a data table stored in the DBMS. Vertices that represent a group of keys having shared characteristics are connected to each other by edges. Similar characteristic may include, for example, a similar minimum value, a similar maximum value, a similar number of distinct values, a same data type, a similar name, a similar  value distribution and / or primary and foreign key relation. When there are two or more different groups of keys with respective two or more different sets of shared characteristics, the edges may be labeled with group labels indicating the different groups. All vertices connected by edges labeled with the same group label belong to the same group and share the same set of similar characteristics.

[0095] In some examples, prior to maintaining the graph at step 402, the graph may be first generated. The graph may be generated by identifying correlation key candidates from the database schema (e.g., schema information stored in the system catalog tables) . As described above, this may involve identifying keys having shared characteristics as correlation key candidates and grouping them together to generate the graph by representing each correlation key candidate as a respective vertex and connecting the correlation key candidates with edges (which may be labeled with group labels as appropriate) .

[0096] At 404, a plurality of runtime transactions in the DBMS is monitored (e.g., in real-time or near real-time) to identify correlations between two or more keys referenced in the runtime transactions. This step may be performed by each server (e.g., each data node) of the DBMS in order to collect information about possible data correlations and to validate the graph. The step 404 may be performed for a defined amount of runtime transactions, such as runtime transactions over a defined period of time (e.g., over 5 minutes) or over a defined number of runtime transactions (e.g., over 1000 transactions) . Performing step 404 may involve steps 406-412 for each runtime transaction and for each pair of keys in the runtime transaction. That is, steps 406-412 may be performed repeatedly in order to carry out step 404.

[0097] At 406, a pair of keys referenced in the given runtime transaction is identified. For example, a statement of the transaction may be parsed to identify a pair of keys that have been identified as correlation key candidates. If there are different groups of correlation key candidates having different sets of similar characteristics, only correlation key candidates belonging to the same group are considered to be a pair of keys at step 406.

[0098] At 408, the parameter value of each key in the pair of keys are compared with each other. The parameter value of each key identified at step 406 may be extracted and compared with each other.

[0099] At 410, a correlation between the pair of keys is identified when each key in the pair of keys has the same parameter value. Otherwise, a noncorrelation between the pair of keys is identified when each key in the pair of keys has a respective different parameter value.

[0100] At 412, the graph is updated based on the identified correlation or noncorrelation. In particular, the weight of the edge in the graph between the vertices representing the pair of keys is updated based on the identified correlation or noncorrelation. The weight may be increased when a correlation is identified and may be decreased when a noncorrelation is identified. In some examples, the amount by which the edge weight is increased or decreased may be fixed (e.g., increased or decreased by 1) . In some examples, the amount by which the edge weight is increased or decreased may be dependent on the strength of the identified correlation or noncorrelation. For example, a correlation that is identified in a JOIN statement may be considered to be a stronger correlation and the edge weight may be increased by a greater amount (e.g., increased by 2 instead of 1) .

[0101] As mentioned above, steps 406-412 are repeated to evaluate each pair of keys in each of the plurality of runtime transactions. It should be noted that each key may be evaluated in multiple key pairs. For example, if three keys A, B, C belonging to the same group are referenced in a transaction, then there may be three key pairs evaluated: (A, B) , (B, C) and (C, A) .

[0102] At 414, the graph is updated to include any edges between vertices representing keys having identified correlations and to omit any edges between vertices representing uncorrelated keys. For example, after step 404 has been performed to monitor the plurality of runtime transactions and identify correlations for a defined amount of runtime transactions, the validated graph should have edge weights that represent correlation or noncorrelation between the keys represented by the vertices. Thus, the graph may be updated to include only edges having a non-zero positive weight (which indicate correlation) and to remove any edges have a zero or negative weight (which indicate noncorrelation) .

[0103] After step 414, the graph may be considered to be validated with information collected from the plurality of runtime transactions. This validated graph may be stored in the system catalog tables for future use (e.g., for revalidation) .

[0104] At 416, the global routing table (which may be stored in the system catalog tables and accessible to all the data nodes of the DBMS) is updated based on a clique in the graph. In examples where edges are labeled with group labels, only vertices  connected by edges having the same group label may belong to the same clique. Vertices belonging to a clique are all directly connected to each other by edges, meaning the vertices belonging to the same clique representing keys that are all correlated to each other. This means that data tables indexed by those keys should be routed together (e.g., collocated on the same data node) , to account for correlation of their data. Thus, the routing information stored in the global routing table is updated to indicate that two or more data tables routed by keys represented by vertices of the clique are routed together.

[0105] In some examples, step 416 may be performed by carrying out steps 418-422 iteratively. In each iteration, at 418, the global routing table is updated with routing information based on the maximum clique in the graph. Then, at 420, the edges and vertices belonging to the maximum clique are removed from the graph (it should be noted that this removal of the maximum clique does not affect the validated graph that is stored in the system catalog tables; that is, this removal may be considered only a temporary removal) . Removal of the maximum clique also includes removal of all edges that connect to the vertices belonging to the maximum clique, including edges labeled with a group label that is different from the group label of the maximum clique. At 422, steps 418 and 420 are repeated for the remaining edges and vertices in the graph (e.g., the next maximum clique is identified in the remaining graph and used to update the global routing table) . This is performed iteratively until all edges have been removed from the graph (i.e., until there are no more cliques in the remaining graph) .

[0106] After completion of step 416, the global routing table has been updated with routing information reflecting the data correlations identified through collection of information from actual runtime transactions. Thus, the global routing table includes routing information that enables routing to be carried out that takes into account data correlation, which may help to reduce data traffic and improve overall performance of the DBMS.

[0107] Optionally, at 424, after all edges have been removed from the graph there may remain a singleton data table (meaning a data table that remains unrouted in the global routing table, for example because that data table does not have any key (s) correlated with the key (s) of another data table) . For such a singleton data table, the routing information is updated to randomly route the singleton data table. If there are multiple singleton data tables, a round robin approach may be used to assign the single data tables to different data nodes in turn.

[0108] Any time after the global routing table has been updated with the routing information, steps 426 and / or 428 may be performed.

[0109] At 426, the routing information stored in the global routing table may be provided to a client. The client may store only routing information relevant to its transactions in a local routing table. This routing information causes the client to route a transaction to a target data node in accordance with the routing information.

[0110] In some examples, a client may route a transaction to a target node that is in conflict with the routing information in the global routing table (e.g., the client may be using out of date routing information) . A data node that receives the transaction may send to the client the up-to-date routing information stored in the global routing table. However, the transaction may continue to be carried out by that data node. The data node may perform operations to determine the up-to-date routing policy to be sent to the client. This may include, for example, the data node generating a list of preferred nodes according to the alias of the transaction. The data node may check whether any routing policies exist or not. If there are routing policies, the data node may select the routing policy with highest priority. If there are not any routing policies, the data node may use the random routing method. Then, the data node may send the up-to-date routing information (e.g., target nodes, routing key, and routing method) to the client, and the client may store this in the local cache (e.g., in the local routing table) .

[0111] At 428, load balancing may be performed. In particular, the load balancing is performed in a way that aims to redistribute correlated data together. For example, consider the case where load balancing is to be performed for a first data table (e.g., the first data table is redistributed by assigning a first partition of the first data table defined by a first range of a first key to a first data node and assigning a second partition of the first data table defined by a second range of the first key to a second data node) . If the first key of the first data table is correlated with a second key of a second data table, then that second data table should also be redistributed in the same manner (e.g., the second data table is redistributed by assigning a first partition of the second data table defined by the same first range of the second key to the first data node and assigning a second partition of the second data table defined by the same second range of the second key to the second data node) . This helps to ensure that data correlation is maintained  whenever load rebalancing takes place. Such load rebalancing may occur more often than updating the global routing table (e.g., resource checking may take place every few seconds, and each instance of resource checking may lead to load rebalancing) .

[0112] FIG. 5 is a flowchart illustrating an example method 500 for transaction routing, as disclosed herein. The method 500 may be carried out by a client (e.g., embodied in the computing system 100) . The method 500 may be performed in a distributed DBMS, particularly where data storage is distributed among a plurality of data nodes. The method 500 may be performed by a functional unit, such as a processor or any other suitable unit.

[0113] At 502, the client maintains routing information in a local routing table (e.g., stored in a local cache of the client) . The routing information may have been previously retrieved from a global routing table (e.g., at a previous transaction with the DBMS) . The routing information is used to identify a target data node of the DBMS to which the client should send a transaction to be processed. The client may use various techniques to identify the target data node, such as using a consistency hash ring to have the routing key value to the target data node and / or performing a round robin to identify the target data node.

[0114] At 504, a transaction is sent to a target data node. The transaction includes one or more statements. Each statement may reference at least one primary key that is used to route the transaction to the target data node (in accordance with the routing information in the local routing table) .

[0115] At 506, the client compares the version number of the routing information cached in the local routing table with the version number of the routing information stored in the global routing table at the target data node. This may be done when the client sends the first statement in the transaction to the target data node. If the version number matches, this means the routing information is up to date and the transaction is routed to the target data node in accordance with the up-to-date routing information. The method 500 proceeds to step 512 in which the transaction continues to be processed at the target data node.

[0116] If a version mismatch is found, then the method 500 proceeds to step 508.

[0117] At 508, the client obtains up-to-date routing information from the target data node. This may involve operations at the target data node to determine the appropriate routing policy for the client. Operations at the target data node may include, for example, the target data node generating a list of preferred nodes according to the alias of the transaction. The target data node may check whether any routing policies exist or not. If there are routing policies, the target data node may select the routing policy with highest priority. If there are not any routing policies, the target data node may use the random routing method. Then, the target data node may send the up-to-date routing information (e.g., target nodes, routing key, and routing method) to the client.

[0118] At 510, the client stores the up-to-date routing information in the local cache (e.g., in the local routing table) . This up-to-date routing information may be used for a future transaction. At 512, the current transaction continues to be processed at the target data node even if the target data node is not in accordance with the up-to-date routing information.

[0119] In various examples, the present disclosure describes methods, systems and computer readable media that may help to improve efficiency of a distributed database system by enabling data correlation to be automatically detected and taken into account in transaction routing and workload rebalancing.

[0120] Examples disclosed herein enable automatic detection of data correlation based on information collected from runtime transactions, without requiring manual intervention by a human database administrator. Data correlation may be automatically detected with little or no added overhead.

[0121] Examples of the present disclosure may provide technical advantages in improved performance of the overall distributed database system, for example by reducing data traffic. At the same time, resource management and workload rebalancing may be performed while taking into account data correlations.

[0122] Examples of the present disclosure may be implemented in any database management system having data stored across multiple data nodes, such as in a share-everything architecture.

[0123] The present disclosure encompasses various embodiments, including not only method embodiments, but also other embodiments such as apparatus embodiments and embodiments related to non-transitory computer readable storage media. Embodiments may incorporate, individually or in combinations, the features disclosed herein.

[0124] Although this disclosure refers to illustrative embodiments, this is not intended to be construed in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the disclosure, will be apparent to persons skilled in the art upon reference to the description.

[0125] Features disclosed herein in the context of any particular embodiments may also or instead be implemented in other embodiments. Method embodiments, for example, may also or instead be implemented in apparatus, system, and / or computer program product embodiments. In addition, although embodiments are described primarily in the context of methods and apparatus, other implementations are also contemplated, as instructions stored on one or more non-transitory computer-readable media, for example. Such media could store programming or instructions to perform any of various methods consistent with the present disclosure.

[0126] The terms "system" and "network" may be used interchangeably in embodiments of this application. "At least one" means one or more, and "aplurality of" means two or more. The term "and / or" describes an association relationship of associated objects, and indicates that three relationships may exist. For example, A and / or B may indicate the following three cases: Only A exists, both A and B exist, and only B exists, where A and B may be singular or plural. The character " / " usually indicates an "or" relationship between associated objects. "At least one of the following items (pieces) " or a similar expression thereof indicates any combination of these items, including a single item (piece) or any combination of a plurality of items (pieces) . For example, "at least one of A, B, or C" includes A, B, C, A and B, A and C, B and C, or A, B, and C, and "at least one of A, B, and C" may also be understood as including A, B, C, A and B, A and C, B and C, or A, B, and C. In addition, unless otherwise specified, ordinal numbers such as "first" and "second" in embodiments of this application are used to distinguish between a plurality of objects, and are not used to limit a sequence, a time sequence, priorities, or importance of the plurality of objects.

[0127] It should be understood that examples of the present disclosure may be embodied as a method, an apparatus, a non-transitory computer readable medium, a processing module, a chipset, a system chip or a computer program, among others. An apparatus may include a transmitting module configured to carry out transmitting steps described above and a receiving module configured to carry out receiving steps described above. An apparatus may include a processing module, processor or processing unit configured to control or cause the apparatus to carry out examples disclosed herein.

[0128] Although the present disclosure describes methods and processes with steps in a certain order, one or more steps of the methods and processes may be omitted or altered as appropriate. One or more steps may take place in an order other than that in which they are described, as appropriate.

[0129] Although the present disclosure is described, at least in part, in terms of methods, a person of ordinary skill in the art will understand that the present disclosure is also directed to the various components for performing at least some of the aspects and features of the described methods, be it by way of hardware components, software or any combination of the two. Accordingly, the technical solution of the present disclosure may be embodied in the form of a software product. A suitable software product may be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer readable medium, including DVDs, CD-ROMs, USB flash disk, a removable hard disk, or other storage media, for example. The software product includes instructions tangibly stored thereon that enable a processing device (e.g., a personal computer, a server, or a network device) to execute examples of the methods disclosed herein. The machine-executable instructions may be in the form of code sequences, configuration information, or other data, which, when executed, cause a machine (e.g., a processor or other processing device) to perform steps in a method according to examples of the present disclosure.

[0130] The present disclosure may be embodied in other specific forms without departing from the subject matter of the claims. The described example embodiments are to be considered in all respects as being only illustrative and not restrictive. Selected features from one or more of the above-described embodiments may be combined to create alternative embodiments not explicitly described, features suitable for such combinations being understood within the scope of this disclosure.

[0131] All values and sub-ranges within disclosed ranges are also disclosed. Also, although the systems, devices and processes disclosed and shown herein may comprise a specific number of elements / components, the systems, devices and assemblies could be modified to include additional or fewer of such elements / components. For example, although any of the elements / components  disclosed may be referenced as being singular, the embodiments disclosed herein could be modified to include a plurality of such elements / components.The subject matter described herein intends to cover and embrace all suitable changes in technology.

Claims

1.A method in a distributed database system, the method comprising:maintaining a graph comprising a plurality of vertices representing a respective plurality of keys, each key in the plurality of keys being a key of a data table stored in the distributed database system;monitoring a plurality of runtime transactions in the distributed database system to identify correlations between two or more keys referenced in the runtime transactions;updating the graph to include any edges between vertices representing keys having identified correlations and to omit any edges between vertices representing uncorrelated keys; andupdating a global routing table based on at least one clique in the graph, wherein routing information stored in the global routing table is updated to indicate that two or more data tables routed by keys represented by vertices of the at least one clique are routed together.2.The method of claim 1, further comprising:providing the routing information stored in the global routing table to a client connected to the distributed database system to cause the client to send a transaction to a target data node that is routed in accordance with the routing information.3.The method of claim 1, further comprising:receiving from a client a transaction routed to a target data node that is in conflict with the routing information stored in the global routing table;sending, to the client, the routing information stored in the global routing table; andcarrying out the transaction at the target data node.4.The method of any one of claims 1 to 3, wherein monitoring the plurality of runtime transactions in the distributed database system to identify correlations between two or more keys referenced in the runtime transactions comprises:evaluating a pair of keys in a given runtime transaction by:identifying the pair of keys referenced in the given runtime transaction;comparing a parameter value of each key in the pair of keys;identifying a correlation between the pair of keys when each key in the pair of keys has a same parameter value or identifying a noncorrelation between the pair of keys when each key in the pair of keys has a respective different parameter value; andupdating the graph to increase a weight of an edge between vertices representing the pair of keys in response to identifying the correlation or updating the graph to decrease the weight of the edge between the vertices representing the pair of keys in response to identifying the noncorrelation; andrepeating the evaluating for the plurality of runtime transactions.5.The method of claim 4, wherein:the plurality of runtime transactions is evaluated for a defined amount of runtime transactions; andupdating the graph to include any edges between vertices representing keys having identified correlations and to omit any edges between vertices representing uncorrelated keys is performed after the defined amount of runtime transactions and comprises maintaining any edges having a non-zero positive weight and removing any edges have a zero or negative weight.6.The method of any one of claims 1 to 5, wherein the plurality of keys represented in the graph are keys having shared characteristics.7.The method of claim 6, wherein the shared characteristics include one or more of: a similar minimum value, a similar maximum value, a similar number of distinct values, a same data type, a similar name, a similar value distribution or a primary and foreign key relation.8.The method of claim 6 or 7, wherein a first group of keys share a first set of shared characteristics and a second group of keys share a second set of shared characteristics, wherein correlations are only identified between keys belonging to a same group, and wherein the at least one clique is defined to include only vertices representing keys belonging to the same group.9.The method of any one of claims 1 to 8, wherein updating the global routing table comprises:updating the routing information to indicate that two or more data tables routed by keys representing by vertices of a maximum clique in the graph are routed together;removing from the graph the edges and vertices belonging to the maximum clique; andrepeating the updating and removing for remaining edges and vertices in the graph until all edges have been removed from the graph.10.The method of claim 9, wherein after all edges have been removed from the graph there remains at least one singleton data table that is unrouted in the global routing table, the routing information is updated to randomly route the singleton data table.11.The method of any one of claims 1 to 10, further comprising performing load balancing of a first data table, wherein the first data table is routed by a first key that is correlated with a second key of a second data table, wherein the load balancing is performed by:redistributing the first data table by assigning a first partition of the first data table defined by a first range of the first key to a first data node and assigning a second partition of the first data table defined by a second range of the first key to a second data node; andredistributing the second data table by assigning a first partition of the second data table defined by a first range of the second key to the first data node and assigning a second partition of the second data table defined by a second range of the second key to the second data node, wherein the first range of the second key is equal to the first range of the first key and the second range of the second key is equal to the second range of the first key.12.An apparatus comprising:a memory; anda processor configured to execute instructions stored in the memory to cause the apparatus to carry out the method of any one of claims 1 to 11.13.A non-transitory computer readable medium having machine-executable instructions stored thereon, wherein the instructions, when executed by an apparatus, cause the apparatus to perform the method of any one of claims 1 to 11.14.A computer program characterized in that, when the computer program is run on a computer, the computer is caused to execute the method of any one of claims 1 to 11.

Images