Automatic derivation of fragmented key values and transparent multi-fragmented transaction and query support

Abstract

The invention relates to automatic deduction of fragmented key values and transparent multi-fragmented transaction and query support. Techniques are provided for processing database commands in a fragmented database. Processing of the database command may include generating or otherwise accessing a shard key expression, and evaluating the shard key expression to identify one or more target shards containing data for executing the database command.

Description

[0001] This application is a divisional application of the invention patent application with application number 202080063037.2, filed on August 24, 2020, and the invention name “Automatic derivation of shard key values and transparent multi-shard transaction and query support”. Technical Field

[0002] The present disclosure relates to database systems and, more particularly, to processing database commands in a sharded database system. Background Art

[0003] Database systems that store increasingly large amounts of data are becoming increasingly common. For example, online transaction processing (OLTP) systems, such as e-commerce, mobile, social, and software-as-a-service (SaaS) systems, often require large database storage. Example applications of OLTP systems include, but are not limited to, large billing systems, ticketing systems, online financial services, media companies, online information services, and social media companies. Given the large amounts of data stored by these database systems, storing all data on a single database instance may not be practical because the amount of data would utilize significant computing resources, such as processors, memory, and storage.

[0004] Horizontal partitioning is a technique for breaking a single, larger table into smaller, more manageable subsets of information, called "partitions." Sharding is a data-tier architecture in which data is horizontally partitioned across independent database instances, each of which is called a "shard." A collection of shards together form a single logical database, called a "sharded database" ("SDB"). Logically, client applications can access a sharded database just like a traditional, non-sharded database. However, tables in a sharded database are horizontally partitioned across the shards.

[0005] In order to access and execute database commands, such as queries and data manipulation commands, on a sharded database system, client applications may need to be specially designed or modified ("shard-aware"). In an example, a client application generates database commands that include or otherwise specify a shard key value that identifies a specific shard for executing the database command.

[0006] In the case where the client application is unaware of the shards, a shard director can be included in the SDB system and configured to process database commands and direct or forward the commands to the target shards. However, continued use of the shard director in this manner can reduce the scalability of the entire sharded database system.

[0007] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The exemplary embodiment(s) of the present disclosure are illustrated by way of example and not limitation in the accompanying drawings in which like reference numerals refer to similar elements and in which:

[0009] Figure 1 Illustrated are examples of a non-sharded database and a sharded database according to one embodiment.

[0010] Figure 2 is a block diagram of a system for sharding a database according to one embodiment.

[0011] Figure 3A is a flow chart for processing database commands according to an embodiment.

[0012] Figure 3B is another flow chart for processing database commands according to an embodiment.

[0013] Figure 4 is a block diagram of a computing device in which the present disclosure may be implemented.

[0014] Figure 5 A block diagram of the basic software system used to control the operation of a computing device. DETAILED DESCRIPTION

[0015] In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the exemplary embodiments (one or more) of the present disclosure. However, it will be appreciated that the exemplary embodiments (one or more) may be practiced without these specific details. In other cases, well-known structures and devices are shown in block diagram form to avoid unnecessarily obscuring the exemplary embodiments (one or more).

[0016] General Overview

[0017] This document describes a technique for processing database commands executed in a sharded database or SDB system in a manner that avoids, for example, problems requiring client applications to be specifically designed to be shard-aware and to provide a shard key along with the requested database command. This SDB command processing technique includes automatic derivation of shard key values for database commands, which can include Structured Query Language (SQL) queries and Data Manipulation Language (DML) commands. In an embodiment, the derivation of the shard key value is transparent to the client application issuing the database command to the sharded database system. Furthermore, the derivation of the shard key value is performed using a shard key expression corresponding to the database command.

[0018] The technology described in this article also supports the derivation of shard key expressions and corresponding shard key values from rich or complex SQL commands, which may include joins, subqueries, and expressions with operators. Therefore, client applications do not need to be specially designed to operate in the SDB system in order to issue database queries and database commands to the sharded database system. For example, a given database command does not need to specify the shard key value or service name of the table family to be routed directly to the target shard, nor does the client application need to explicitly provide the shard key / service name to the SDB system in other ways. Therefore, the SDB command processing technology disclosed in this article helps to eliminate or minimize application changes that hinder the adoption of sharded databases. In addition, by providing automatic and transparent derivation of shard key values for database commands, the client driver supports routing commands directly to the shards.

[0019] The SDB command processing technology also transparently supports multi-shard queries and multi-shard transactions or updates with ACID (atomicity, consistency, isolation, and durability) properties without requiring application code changes. The command processing technology transparently distinguishes between single-shard and multi-shard commands from the application's perspective, so no special programming or configuration is required to distinguish between single-shard and multi-shard commands. In an embodiment, the SDB command processing technology distinguishes single-shard commands from multi-shard commands, which allows the database coordinator to be used only when needed or desired, for example to process only multi-shard commands. In addition, the SDB command processing technology can distinguish between single-shard and multi-shard transactions or updates to promote such commands to protocols that can support coordination of distributed transactions involving multiple data sources. Such multi-shard transaction protocols include XA, Java Transaction API (JTA), and the like.

[0020] Sharded database

[0021] Horizontal partitioning is a technique for breaking a single, large table into smaller, more manageable subsets of information, called "partitions." Sharding is a data-tier architecture in which data is horizontally partitioned across independent database instances, each of which is called a "shard." A collection of shards together form a single logical database, called a "sharded database" or "SDB." Logically, client applications can access a sharded database just like a traditional, non-sharded database. However, tables in a sharded database are partitioned horizontally across the shards.

[0022] Figure 1 Illustrated are examples of a non-sharded database 100 and a sharded database 110. The non-sharded database 100 is a relational database and includes a table 102. All contents of the table 102 are stored in the same non-sharded database 100 and therefore may use the same computing resources, such as processors, memory, and disk space.

[0023] However, sharded database 110 illustrates an alternative configuration using sharding technology. Sharded database 110 includes three shards 112, 114, and 116. Each of shards 112, 114, and 116 is its own distinct database instance and includes its own distinct tables 113, 115, and 117, respectively. However, in sharded database 110, table 102 has been horizontally partitioned into tables 113, 115, and 117 across shards 112, 114, and 116, respectively. Horizontal partitioning in a sharded database involves splitting a database table, such as table 102, across shards so that each shard contains a subset of the rows of table 102. In this example, tables 113, 115, and 117 each contain a subset of the rows of table 102. The different sharding of rows between table 102 and tables 113, 115, and 117 illustrates an example of how data is arranged and split between non-sharded database 100 and sharded database 110. Tables 113, 115, and 117 may be collectively referred to as "sharded tables." The data stored in tables 113, 115, and 117 collectively is equivalent to the data stored in table 102. Sharded database 110 is logically viewed as a single database and can therefore be accessed by client applications like non-sharded database 100.

[0024] In one embodiment, sharding is a shared-nothing database architecture because shards 112, 114, and 116 do not need to share physical resources such as processors, memory, and / or disk storage devices. Shards 112, 114, and 116 are loosely coupled in software and do not require clusterware to run. From the perspective of a database administrator, sharded database 110 consists of multiple database instances that are either managed jointly or individually. However, from the perspective of a client application, sharded database 110 logically looks like a single database. Therefore, the number of shards included in sharded database 110 and the distribution of data across those shards are completely transparent to the client application.

[0025] The configuration of the sharded database 110 provides various benefits. For example, in an embodiment, the sharded database 110 improves scalability by eliminating performance bottlenecks and making it possible to increase the performance and capacity of the system by adding additional shards and distributing the load across the shards. The sharded database 110 can be implemented as a shared-nothing architecture, whereby each shard in the sharded database is its own database instance and the shards do not need to share hardware such as processors, memory, and / or disk storage.

[0026] In an embodiment, sharded database 110 provides fault containment because it eliminates single points of failure such as shared disks, shared storage area networks, clusterware, shared hardware, etc. In contrast, sharding provides strong fault isolation because the failure of a single shard does not affect the availability of other shards.

[0027] Sharded database 110 can also help provide enhanced global data distribution. Sharding makes it possible to store specific data in physical proximity to customers. When data must be found in a specific jurisdiction by law, it may be necessary to store the data physically close to the customer to meet regulatory requirements by physically locating the shard for that specific data within that jurisdiction. Storing data physically close to the customer can also provide performance benefits by improving the latency between the customer and the underlying data stored in the shard.

[0028] The sharded database 110 can also help enable rolling upgrades of the system. In a sharded data architecture, changes made to one shard do not affect the contents of other shards in the sharded database, thereby allowing database administrators to first try out changes to a small subset of data stored in a single shard and then roll those changes to the remaining shards in the sharded database.

[0029] Sharded database 110 can also help provide simplicity in cloud deployment. Considering that the size of a shard can be made arbitrarily small, a database administrator can easily deploy a sharded database in a cloud consisting of low-end commodity servers with local storage.

[0030] In general, sharded databases 110 can be most effective in well-partitioned applications that primarily access data within a single shard and do not have strict performance and consistency requirements for cross-shard operations. Therefore, sharding is particularly suitable for OLTP systems such as e-commerce, mobile, social, and SaaS.

[0031] The sharded database 110 can also help provide improvements to the automatic propagation of database schema changes across shards. Instead of requiring a database administrator to manually apply database schema changes to each individual shard, the sharded database 110 can automatically propagate such schema changes to the shards from a single entry point.

[0032] The shard database 110 can also help support traditional structured query language (SQL), so all the complete SQL syntax and keywords that are already available can be utilized. In addition, given that the shard database 110 supports SQL, it can be easily integrated with existing client applications that are configured to access relational databases via SQL.

[0033] The sharded database 110 may also help provide the full range of benefits of a relational database, including schema control, atomicity, consistency, isolation, and durability.

[0034] The shard database 110 can also help provide direct routing of queries to the shards without requiring an intermediary component to route the query. This direct routing improves system latency by reducing the number of network hops required to process the query.

[0035] Overall system architecture

[0036] Figure 2 FIG2 is a block diagram of a database system 200 according to one embodiment. Client application 210 is any type of client application that needs to access data stored in a database. In one embodiment, client application 210 may be a client in an OLTP setting, such as e-commerce, mobile, social, or SaaS. Client application 210 is communicatively coupled to a sharded database 220.

[0037] Sharded database 220 is a logical database in which data is horizontally partitioned across independent database instances. Specifically, data stored in sharded database 220 is horizontally partitioned and stored in shards 230A, 230B, and 230C. A sharded database can include any number of shards, and the number of shards in a sharded database can change over time. According to one embodiment, each of shards 230A, 230B, and 230C is its own database instance and does not need to share physical resources, such as processors, memory, and / or storage devices, with other shards in sharded database 220.

[0038] Shard directory

[0039] The shard database 220 includes a shard directory 240. The shard directory 240 is a special database used to store configuration data for the shard database 220. In one embodiment, the shard directory 240 can be replicated to provide improved availability and scalability. The configuration data stored in the shard directory 240 may include: a routing table that maps which shard 230 stores the data chunk corresponding to a given value, value range, or value set of a shard key; shard topology data that describes the overall configuration of the shard database 220; information about the configuration of shards 230A, 230B, and 230C; information about the configuration of the shard director 250, driver 260, and / or cache 270; information about the client application 210; information about the schema of data horizontally partitioned across shards 230A, 230B, and 230C; a history log of pending and completed schema modification instructions for shards 230A, 230B, and 230C; and all other information relevant to the configuration of the shard database 220.

[0040] A shard key is a list of column values used to horizontally partition a set of tables in a given table family. A shard key can be composite / hierarchical, such as a designated shard key and a super shard key. A shard key can be composed of multiple columns. Each column value of a shard key can be a literal value or a bind variable, and may contain other relevant information, such as operators and operands. In an embodiment, the shard directory 240 provides shard key information to help identify and connect to a specific shard, and such shard key information may include the service name of the table family, the bind parameters (literal values or variables) of the shard key, the bind parameters (literal values or variables) of the super shard key, the type of the shard key, the operator functions and operands involved in deriving the shard key value, and / or the operator functions and operands involved in deriving the super shard key value.

[0041] In one embodiment, the shard directory 240 maintains a routing table that stores mapping data including a plurality of mapping entries. Each of the plurality of mapping entries maps a different set of key values for one or more shard keys to a shard of a plurality of shards in the sharded database. In another embodiment, each of the plurality of mapping entries maps a different set of key values for one or more shard keys to a data block on a shard of a plurality of shards in the sharded database. In another embodiment, each of the plurality of mapping entries maps a different set of key values for one or more shard keys to a shard space including one or more shards in the sharded database. In one embodiment, the key value set may be a range of partition key values. In another embodiment, the key value set may be a list of partition key values. In another embodiment, the key value set may be a set of hash values.

[0042] Therefore, for a database command that needs to access data for a specific shard key value, the routing table can be used to find which shard in the sharded database contains the data block needed to process the query.

[0043] Shard Director

[0044] The shard database 220 includes a shard director 250. The shard director 250 coordinates various functions across the shard database 220 and, accordingly, may also be referred to as a shard coordinator. The shard director 250 coordinates functions including, but not limited to, routing database requests to shards, parsing database commands to generate shard key expressions, propagating database schema changes to shards, monitoring the status of shards, receiving status updates from shards, receiving notifications from client applications, sending notifications to shards, sending notifications to client applications, and / or coordinating various operations that affect the configuration of the shard database 220, such as resharding operations. The shard director 250 is communicatively coupled to the shard directory 240, the client application 210, and the shards 230A, 230B, and 230C.

[0045] In an embodiment, the shard director 250 generates or infers a shard key expression from a database command (such as an SQL query) received from the driver 260. The shard director 250 infers the shard key expression for a particular command by parsing the command using data from the shard catalog 240 (such as table metadata, shard topology data, and synonyms in one or more database command languages). The shard director 250 can also infer a service name and send it to the driver 260 when needed or desired to help distinguish between families of tables that may have the same shard key expression and / or shard key value. In an embodiment, the shard director 250 sends the extracted shard key expression along with the service name to the driver 260 as a byte stream in a suitable format, such as a version of Reverse Polish Notation (RPN) that supports different families of tables, multiple columns in a shard key, multiple levels of shard keys (e.g., shard keys, super shard keys), and SQL expressions with operators, or separately. Another suitable format includes a higher-level representation, such as JavaScript Object Notation (JSON).

[0046] Although depicted as a single shard director 250, in one embodiment, the shard database 220 may include multiple shard directors 250. For example, in one embodiment, the shard database 220 may include three shard directors 250. Having multiple shard directors 250 may allow for coordinated load balancing of tasks performed by the shard directors 250, thereby improving performance. In the case of multiple shard directors 250, in one embodiment, one of the shard directors 250 may be selected as a manager of the shard directors 250 responsible for managing the remaining shard directors 250 (including load balancing).

[0047] Drivers and Caches

[0048] Figure 2The database system 200 includes a driver 260 communicatively coupled to the client application 210 and the sharded database 220. The driver 260 maintains a store or cache 270 to store entries associating a given database command with a sharding key expression. In an embodiment, multiple specific database commands can be associated with a single sharding key expression. The driver 260 and / or the sharding director 250 can convert a specific database command that can include literals, bind variables, and / or operators into a transformed version or prepared statement. In an embodiment, the transformed version or prepared statement is a generalized representation of the database command and can include one or more bind variables to replace one or more literal values from the original database command. The driver 260 can represent many different database commands by using the transformed version or prepared statement and associate many different database commands with a smaller number of sharding key expressions.

[0049] A given shard key expression may also include literals, bind variables, and / or operators. In an embodiment, a shard key expression with bind variables may be used to identify multiple different shards or table families once one or more specific bind values are applied. Generally speaking, a table family is a representation of a hierarchy of related tables, and each table in turn maps which shard stores the data block corresponding to a given shard value. Since many client applications use database commands (e.g., SQL) with bind variables to improve performance, supporting bind variables and operators in shard key expressions and caches may help minimize the number of database commands in the cache and reduce the need to retrieve shard key expressions from the shard director.

[0050] When driver 260 receives a database command from client application 210, driver 260 determines whether any database command entry corresponding to the received database command exists in cache 270. If so, driver 260 retrieves the associated shard key expression from cache 270 and can then evaluate the shard key expression to derive the shard key value based on the actual bind value. In one embodiment, driver 260 evaluates the shard key expression to obtain a fully evaluated shard key value without contacting shard director 250. Driver 260 uses the shard key value to identify a specific shard 230 and can connect to the specific shard to execute the database command. In one embodiment, driver 260 connects directly to the specific shard using a connection from a connection pool, without routing the database command through other components such as shard director 250. In one embodiment, driver 260 stores a shard connection pool in cache 270, which maintains database connections so that connections can be reused when future requests to the database are needed. Since many applications use SQL with bind variables to improve performance, supporting bind variables and operators in shard key expressions and cache 270 greatly reduces the amount of SQL in the cache and reduces the need to retrieve shard key expressions from the shard director.

[0051] The driver 260 is also communicatively coupled to the shard database 220 via the shard director 250. In an embodiment, if the driver 260 determines that a received database command does not correspond to an entry in the cache 270, the driver 260 transmits the database command to the shard director 250 to derive a shard key expression from the database command and return the shard key expression to the driver.

[0052] In another embodiment, the driver 260 is configured to generate a shard key expression by parsing database commands. To do this, the driver 260 is configured to access data in the shard directory 240, which may also be stored locally to the driver, such as in a cache 270. In addition, the driver 260 is configured to perform complex database command parsing in different database command language versions to help support backward compatibility.

[0053] Routing database commands

[0054] Many queries in typical client applications are short and should be processed with millisecond latencies. The additional network hops and resolution required to route a query to the appropriate shard can introduce unacceptable latency for the client application. This disclosure provides techniques for minimizing latency when routing queries sent from client applications.

[0055] The client application 210 generates and sends database commands to request data from the sharded database 220. In some cases, the database commands from the client application 210 will require data from a single shard. Such data requests are referred to as single-shard queries. Single-shard queries will represent the majority of data requests from a typical client application because the shards 230A, 230B, and 230C have been configured so that the blocks in each shard contain corresponding partitions of tables from a table family. Therefore, most database commands that rely on data in a table family will likely be serviced by a single shard because the related data for the table family is collocated on the same shard. Similarly, using duplicate tables for relatively small and / or static reference tables helps increase the likelihood that the query will be processed as a single-shard query.

[0056] In other cases, database commands from client application 210 will require data from multiple shards. Such commands are called cross-shard commands. Processing cross-shard commands is typically slower than processing single-shard commands because it may require joining data from multiple shards. For example, cross-shard commands can be used to generate reports and collect statistics that require data from multiple shards.

[0057] The shard directory 240 maintains a routing table that maps the list of chunks hosted by each shard to a range of hash values associated with each chunk. Thus, the routing table can be used to determine, for a shard key value or set of shard key values, which shard contains the chunk containing the shard key data. In an embodiment, where the database is sharded via composite sharding, the routing table may also include mapping information for a combination of a shard key and a super shard key. Thus, in the case of a composite sharded database, the routing table can be used to determine, for a given set of shard key values, which shard contains the chunk containing the set of shard key values data.

[0058] In an embodiment, the routing table maintained by the shard directory 240 is accessible to the shard director 250, which helps route queries to the appropriate shards. In an embodiment, the functionality of the shard director is implemented in the client application 210, such as via the driver 260. In another embodiment, the functionality of the shard director 250 is implemented on one or more of each individual shard 230. In another embodiment, the functionality of the shard director 250 can be implemented as a software component external to the shard director 250 and the shards 230. The software component can be part of the shard database 220 or can be external to the shard database 220. In an embodiment, the software component can be external to the shard database 220 and the client application 210.

[0059] In an embodiment, the shard director functionality may be distributed across multiple software components S1 through SN that exist between the client application 210 and the shard database 220. The software components S1 through SN may have different accessibility to the client application 210 and / or the shard database 220. Such accessibility reflects various communication characteristics, including but not limited to physical proximity, bandwidth, availability of computing resources, workload, and other characteristics that may affect the accessibility of the software components S1 through SN.

[0060] In an embodiment, software component S1 may be a client component of client application 210 and / or driver 260 and may be more accessible to client application 210 than software component S2. Similarly, software component S2 may be more accessible to client application 210 than software component S3, and so on. Thus, in this example, software component S1 is considered closest to client application 210 because it is most accessible to client application 210, and software component SN is considered farthest from client application 210 because it is least accessible to client application 210. In an embodiment, when a database command is created at client application 210, the available software component closest to client application 210 is first used to attempt to process the database request. If the available software component closest to client application 210 cannot process the database command, the next closest software component is tried, and so on, until the database command is successfully processed and directed to shard(s) 230 for execution. For example, a software component may be unable to process a database command if it does not have sufficient mapping data to correctly route the command. By processing database commands using the available software components closest to the client application 210 , the database system 200 can provide improved performance when processing commands because the closest available software components have improved accessibility compared to other software components.

[0061] Accessing and generating shard key expressions

[0062] In an embodiment, the client application 210 generates a database command to be executed on the sharded database 220, but does not include a shard key value. Therefore, the client application 210 cannot directly route the command to one or more identified shards 230 for execution or processing.

[0063] Figure 3A3 is a flowchart for process 300A accessing a shard key expression, which can be evaluated to identify a target shard key value. At block 302, the driver 260 receives a database command from the client application 210. For example, the database command can be a SQL statement or a DML command. At block 304, the driver 260 determines whether the received database command corresponds to any database command entry in a cache 270 coupled to the driver, and if so, identifies the corresponding database command entry. At block 306, if the received database command does correspond to a database command entry in the cache 270, the driver 270 retrieves the shard key expression associated with the identified database command entry from the cache. Following block 306, at block 308, the driver 270 evaluates the shard key expression to determine the shard key value. Generally speaking, the driver 270 evaluates the shard key expression by replacing bind variables with bind values that may be provided in the original database command and / or by evaluating operators in the shard key expression. If the driver 270 cannot determine the shard key value from the shard key expression, the driver may invalidate the corresponding database command entry and provide the database command to the shard director 250 for processing.

[0064] At block 310, the driver 270 uses the shard key value and the routing table to identify the specific target shard 230 that contains the data needed to process the database command. At block 312, the driver 270 connects directly to the specific shard. At block 314, the database command is transmitted to the connected shard for execution, and the results can be returned directly to the driver 260 and the client application 210 as a result of the execution. At block 314, the target shard can also return mapping data identifying all key ranges stored by the specific shard. For example, this mapping data can be stored in the cache 270 by the driver 260 as a connection pool. The mapping data allows the driver 260 to directly route subsequent commands with shard key expressions or values that match the cached mapping data to the target shard without consulting the shard director 250. This helps improve the performance of subsequent database requests to the target shard.

[0065] If the driver 260 determines at block 304 that the received database command does not correspond to any database command entry in the cache 270, then at block 316, the driver 260 requests the shard key expression for the database command. In one embodiment, at block 318, the driver 260 sends the database command to the shard director 250, which parses the database command into a tree structure and traverses the tree structure using data from the shard directory 240 to generate the shard key expression. In this embodiment, the shard director 250 sends the shard key expression to the driver 260, which stores a cache entry associating the shard key expression with the database command at block 320. In another embodiment, at block 318, the driver 260 parses the database command to generate the shard key expression, and at block 320, the driver 260 stores a cache entry associating the shard key expression with the database command. Following block 320 , the driver 260 determines a shard key value from the shard key expression (block 308 ), maps the shard key value to a specific shard (block 310 ), connects to the specific shard (block 312 ), and provides the database command to the shard for execution (block 314 ).

[0066] At block 320, the driver 260 and / or shard director 250 may store the received database command (including the literal) in the cache 270. Alternatively or additionally, at block 320, the driver 260 and / or shard director 250 may transform the received database command into a prepared statement for storage in the cache 270. Generally speaking, a prepared statement is a database command that uses bind variables instead of literals for storage in the cache 270. For example, the original database SQL commands may include: SELECT fname, lname, pcode FROM cust WHERE id=100; SELECT fname, lname, pcode FROM cust WHERE id=200; and SELECT fname, lname, pcode FROM cust WHERE id=300. An example prepared statement representing these three SQL commands may be: SELECT fname, lname, pcode FROM cust WHERE id=:cust_no.

[0067] In an embodiment, if the shard director 250 or the driver 260 cannot generate a shard key expression for a database command, the shard director 250 is configured to parse the database command to generate a shard key value and may return the shard key value to the driver 260 and / or may route the database command to one or more target shards.

[0068] As a result of process 300A, driver cache 270 may accumulate many (if not substantially all) of the most common database commands executed by a given client application over time. Thus, when a database command is received, driver 260 is able to identify the existing database command entry in cache 270, evaluate the corresponding shard key expression to determine the shard key value, and connect directly to the target shard(s) using the determined shard key value. This helps eliminate the "middleman" of shard director 250, thereby facilitating efficient processing of database commands in database system 200.

[0069] As discussed herein, the shard director 220 and / or driver 260 can use table metadata and shard topology, for example, to parse database commands and deduce shard key expressions. There are many suitable ways to represent shard key expressions, such as in Reverse Polish Notation (RPN) format, or in a custom name-value pair structure in JavaScript Object Notation (JSON). In an embodiment, shard key expressions are represented as RPN expressions in the form of shard key lines. Using RPN expressions provides a compact storage format that is also highly extensible for any future additional expression support in the database command language and shard key enhancements (such as multiple hierarchies of shard keys).

[0070] An example representation of a shard key expression in RPN format may follow the following abstract syntax:

[0071]

[0072] In this embodiment, a shard key expression can be specified by a token; a token can be specified by a parameter, a literal, and / or an operator; a parameter can be specified by a column and a number; a literal can be specified by a value in the application and can be a string literal or a numeric literal; a string literal can be specified by a character; a character can be specified by a Unicode representation; a numeric literal can be specified by a certain numeric format; and operators ( <op>).

[0073] In an illustrative embodiment, a database command from the client application 210 may be: select * from customers where cust_no = :b1 and date1 = to_date('APR-04-09', 'MON-DD-YY') and cust_region = "California". In this example, "cust_region" is the super shard key, and "cust_no" and "date1" are a composite shard key, or a two-part shard key. The "cust_no" portion of the shard key is specified by the bind variable "b1", which can be evaluated using a specific customer number, such as customer number 100. The "date1" portion of the shard key is specified by the operator "to_date", where the operands "APR-04-09" and "MON-DD-YY" are used to evaluate the operator.

[0074] When parsing a database command, the shard key expression in RPN format is provided in the "Line Expression" column of Table 1 (as shown above). The service name of the table family in the shard key expression is omitted in this example. The driver 260 uses the memory stack to process the shard key expression and derive the shard key value displayed in the "Stack Contents" column. The driver 260 performs various operations in response to different parts of the shard key expression.

[0075] In row 1 of Table 1, the driver 260 receives or otherwise processes a shard key expression command "push_empty_tuple" and, in response, pushes an empty tuple onto the stack, such as an empty array list, indicated as {}. In row 2, the driver 260 receives a shard key expression command "push_empty_key" and, in response, pushes an empty key onto the stack, such as an empty array list, indicated as []. In general, a tuple and a key are provided to facilitate the driver 260 in deducing a shard key value.

[0076] On line 3, the driver 260 receives the command "push_bind_variable 1" and, in response, identifies the bind variable by position and pushes (bind_variable, 1) to the stack. On line 4, the driver 260 receives the command "push_type 2" and, in response, pushes (type, 2) to the stack. In this example, bind type 2 specifies a number. On line 5, the driver 260 receives the command "push_parameter" and, in response, the driver pops two objects from the stack, (type, 2) & (bind_variable, 1). The first bound value is at position 1 of type number, and in this example, the bound value is 100. The driver pushes 100 to the stack. On line 6, the driver 260 receives the command "append_value_to_key" and, in response, pops (100) and [] from the stack and pushes the array list [(100)] to the stack. At this point, [(100)] is the shard key value.

[0077] On line 7, the driver 260 receives the command "push_literal_length 9" and, in response, pushes a (literal_length, 9) object onto the stack. On line 8, the driver 260 receives the command "push_type 1" and pushes a (type, 1) object onto the stack. In this example, type 1 specifies a character. On line 9, the driver 260 receives the command "push_literal APR-04-09" and, in response, pops (type, 1) and (literal_length, 9), reads 9 bytes from the line, and pushes "APR-04-09" as a literal. On line 10, the driver 260 receives the command "push_literal_length9" and, in response, pushes a (literal_length, 9) object onto the stack. On line 11, the driver 260 receives the command "push_type 1" and, in response, pushes a (type, 1) object onto the stack. In this example, type 1 specifies a character. On line 12, the driver 260 receives the command "push_literal 'MON-DD-YY'" and in response pops (type, 1) and (literal_length, 9), reads 9 bytes from the line, and pushes 'MON-DD-YY' as a literal. On line 13, the driver 260 receives the command "push_binary_operator TO_DATE" and in response pops ('MON-DD-YY') and ('APR-04-09'), evaluates TO_DATE using these two operands, and pushes the evaluation result (04 / 04 / 2009 in this example) onto the stack. On line 14, the driver 260 receives the command "append_value_to_key" and in response pops (04 / 04 / 2009) and [(100)] from the stack and pushes the array list [(100)(04 / 04 / 2009)] onto the stack. At this point, [(100)(04 / 04 / 2009)] is the shard key value. At line 15, driver 260 receives the "append_key_to_tuple" command and, in response, pops [(100)(04 / 04 / 2009)] and {} and pushes the top element into {}. The stack contents—[(100)(04 / 04 / 2009)]—are now the complete shard key value.

[0078] On line 16, the driver 260 receives the command "push_empty_key" and in response pushes an empty key to the stack, such as an empty array list indicated as []. This is for a super shard key. On line 17, the driver 260 receives the command "push_literal_length 10" and in response pushes a (literal_length, 10) object to the stack. On line 18, the driver 260 receives the command "push_type1" and in response pushes a (type, 1) object to the stack. In this example, type 1 specifies characters. On line 19, the driver 260 receives the command "push_literalCalifornia" and in response pops (type, 1) and (literal_length, 10), reads 10 bytes from the line, and pushes ('California') as a literal. On line 20, the driver 260 receives the command "append_value_to_key" and, in response, pops ('California') and [] from the stack and pushes the array list [('California')] onto the stack. At this point, [('California')] is the super shard key value. On line 21, the driver 260 receives the command "append_key_to_to_tuple" and, in response, pops [('California')] and {[(100)(04 / 04 / 2009)]} and pushes [('California')] into {[(100)(04 / 04 / 2009)]}. [('California')] is the complete shard key value. On line 22, the driver 260 receives the command "return tuple" and, in response, pops the top element from the stack. The resulting fully evaluated shard key value is provided as {[(100)(04 / 04 / 2009)][('California')]}.

[0079]

[0080]

[0081] Table 1

[0082] Processing multi-shard commands

[0083] In an embodiment, the client application 210 generates database commands that do not include a shard key value and also require data from multiple shards. Generally speaking, the client application 210 requests to execute a mix of single-shard and multi-shard queries. In an embodiment, the driver 260 submits multi-shard queries to the shard director 250 to coordinate the execution of queries across multiple shards. The driver 260 helps identify multi-shard queries that are handled by the shard director 250, and from the perspective of the client application 210, this identification and handling is performed transparently. Therefore, if there is only a possibility of some multi-shard queries, then the client application does not need to always submit queries to the shard director, which may be computationally or resource expensive if most queries are single shards.

[0084] Figure 3B 2 is a flow diagram of a process 300B for managing multi-shard database commands (such as SQL queries). In an embodiment, the driver 260 caches database commands in the cache 270 only when the driver receives a shard key expression from the driver, the shard director 250, or some other component. For subsequently received database commands that match an entry in the cache 270, the driver 260 connects directly to the shard 230 for good performance. In this embodiment, the driver 260 continues to connect to the shard director 250 for subsequent multi-shard commands. As described above, this processing is performed transparently from the perspective of the client application 210, which does not need to distinguish between single-shard and multi-shard commands.

[0085] Flowchart 300B includes block 322, which is after determining at block 304 that the received database command does not correspond to any database command entry in cache 270. At block 322, driver 260 and / or shard director 250 determines whether the received database command is a multi-shard query. If so, then at block 324, shard director 250 receives and handles processing of the multi-shard query. For example, the shard director may parse the query to identify multiple shard key values for multiple target shards, map the shard key values to the target shards, connect to the shards, transmit the query to the shards for execution, and process the results from the shards to generate results that are transmitted back to the driver and client application.

[0086] Flowchart 300B can also be used to support transparent multi-shard transactions, such as DML transactions that can modify data in multiple different shards. Driver 260 helps handle multi-shard transactions in an atomic manner by supporting the coordination of global distributed transactions involving multiple data sources, such as by facilitating multi-shard transactions to be processed through, for example, the XA protocol or the Java Transaction API (JTA). In general, XA is a two-phase commit protocol that is natively supported by many databases and transaction monitors. XA ensures data integrity by coordinating a single transaction that accesses multiple relational databases and guarantees that transaction updates are committed in all participating databases or completely rolled back from all databases, thereby recovering to the state before the transaction began.

[0087] In other systems, client applications may need to: 1) always use XA if there may be some multi-shard transactions (which can be expensive if most transactions are actually single-shard); or 2a) selectively use XA or 2b) go through the shard director 250 and shard directory 240 when there are multi-shard updates. The latter approach (2a, 2b) can be challenging because the application does not always know when it is accessing data across multiple shards. The present disclosure helps by transparently promoting transactions to XA only when needed.

[0088] In an embodiment, at block 322, when the driver detects an existing local transaction to a shard 230 or shard director 250 and detects a request or initiation of a second local transaction to a different shard or shard director, the driver 260 promotes the database transaction to XA (or other suitable protocol). In this example, the connection from the client application to the driver is a logical connection, and the connection from the driver to each database (shard or shard director) is a physical connection. For each logical connection, the driver can maintain one or more physical connections to the shard database. When multiple local transactions exist with different physical connections, the driver promotes the local transaction to XA. For each database command, the database notifies the driver if the command has started a transaction or is already in a transaction. When the client application issues a commit or rollback, the driver executes the XA protocol to commit or rollback. By default, the database can use tightly coupled transaction branches for the same database. This helps make all pre-commit updates made in one transaction branch of a tightly coupled transaction visible to other tightly coupled branches in different database instances. In an embodiment, to facilitate seamless promotion of transactions to XA, if a command would start a transaction in the shard database 220, the shard(s) 230 and the shard director 250 may notify the driver 260 via a piggyback message.

[0089] In an embodiment, at block 324, the driver 260 sends the multi-shard transaction to the shard director 250, which helps manage the inherent performance overhead in coordinating multiple transaction branches in a distributed transaction, significant recoverability issues, and cascading failures due to in-doubt transactions.

[0090] grammar

[0091] Although the present disclosure provides various examples of how to create, manage, and manipulate the syntax of sharded databases, these examples are merely illustrative. The present system can be implemented using existing relational database coding languages or query languages, such as structured query language (SQL). This means that legacy systems can be easily upgraded, migrated, or connected to a system that includes the sharded database teachings described herein because no major changes to SQL are required. The use of data manipulation language (DML) does not require any changes to take advantage of the benefits of the present system. Furthermore, the use of DDL requires only minor changes to support the keywords necessary to implement the sharded organization of the sharded database. Additionally, the features disclosed herein can be applied to a variety of different sharding options, such as Oracle Real Application Clusters (RAC) sharding, shared disk sharding, unified database or container database sharding, shared-nothing databases, and the like.

[0092] Database Overview

[0093] Embodiments of the present disclosure are used in the context of a database management system (DBMS). Accordingly, a description of an example DBMS is provided.

[0094] Generally speaking, a server, such as a database server, is a combination of integrated software components and an allocation of computing resources (such as memory, nodes, and processing on the nodes for executing the integrated software components), where the combination of software and computing resources is dedicated to providing a specific type of functionality on behalf of the server's clients. A database server manages and facilitates access to a specific database, processing client requests to access the database.

[0095] A database comprises data and metadata stored on a persistent storage mechanism (such as a collection of hard disks). For example, these data and metadata may be logically stored in a database according to a relational and / or object-relational database structure.

[0096] A user interacts with a DBMS's database server by submitting commands to the database server. These commands cause the database server to perform operations on the data stored in the database. A user can be one or more applications running on a client computer that interacts with the database server. Multiple users may also be collectively referred to as users herein.

[0097] Database commands can be in the form of database statements. In order for a database server to process a database statement, the database statement must conform to a database language supported by the database server. A non-limiting example of a database language supported by a database server is SQL, including proprietary forms of SQL supported by database servers such as Oracle (e.g., Oracle Database 11g). SQL Data Definition Language ("DDL") instructions are issued to a database server to create or configure database objects, such as tables, views, or complex types. DML instructions are issued to a DBMS to manage data stored within a database structure. For example, SELECT, INSERT, UPDATE, and DELETE are common examples of DML instructions found in some SQL implementations. SQL / XML is a common extension of SQL used when manipulating XML data in object-relational databases.

[0098] Generally speaking, data is stored in a database in one or more data containers, each container contains records, and the data within each record is organized into one or more fields. In a relational database system, data containers are typically referred to as tables, records are referred to as rows, and fields are referred to as columns. In an object-oriented database, data containers are typically referred to as object classes, records are referred to as objects, and fields are referred to as attributes. Other database architectures may use other terms. Systems implementing various aspects of the present disclosure are not limited to any particular type of data container or database architecture. However, for the purposes of explanation, the examples and terminology used herein will be those typically associated with relational or object-relational databases. Therefore, the terms "table," "row," and "column" will be used herein to refer to data containers, records, and fields, respectively.

[0099] A multi-node database management system consists of interconnected nodes that share access to the same database. Typically, the nodes are interconnected via a network and share, to varying degrees, access to shared storage, such as a collection of disk drives and the data blocks stored thereon. The nodes in a multi-node database system can be in the form of a group of computers (e.g., workstations, personal computers) interconnected via a network. Alternatively, the nodes can be nodes of a grid, which consists of nodes in the form of server blades interconnected with other server blades on a rack.

[0100] Each node in a multi-node database system hosts a database server. A server, such as a database server, is a combination of integrated software components and an allocation of computing resources (such as memory, nodes, and processing on the nodes for executing the integrated software components), where the combination of software and computing resources is dedicated to performing specific functions on behalf of one or more clients.

[0101] Resources from multiple nodes in a multi-node database system can be allocated to run the software for a particular database server. Each combination of software and resource allocation from a node is referred to herein as a "server instance" or "instance" of the server. A database server can include multiple database instances, some or all of which run on separate computers, including separate server blades.

[0102] Hardware Overview

[0103] Now refer to Figure 4 , Figure 4 4 is a block diagram illustrating a basic computing device 400 in which example embodiment(s) of the present disclosure may be embodied. The computing device 400 and its components, including their connections, relationships, and functionality, are meant to be illustrative and are not intended to limit implementation of the example embodiment(s). Other computing devices suitable for implementing the example embodiment(s) may have different components, including components with different connections, relationships, and functionality.

[0104] Computing device 400 may include a bus 402 or other communication mechanism for addressing main memory 406 and for transferring data between and among the various components of device 400 .

[0105] Computing device 400 may also include one or more hardware processors 404 coupled to bus 402 for processing information. Hardware processor 404 may be a general-purpose microprocessor, a system on a chip (SoC), or other processor.

[0106] A main memory 406, such as a random access memory (RAM) or other dynamic storage device, may also be coupled to bus 402 for storing information and software instructions to be executed by processor(s) 404. Main memory 406 may also be used for storing temporary variables or other intermediate information during execution of software instructions to be executed by processor(s) 404.

[0107] The software instructions, when stored in a storage medium accessible to the processor(s) 404, render the computing device 400 as a special-purpose computing device customized to perform the operations specified in the software instructions. The terms "software," "software instructions," "computer program," "computer-executable instructions," and "processor-executable instructions" should be broadly interpreted to cover any machine-readable information, whether human-readable or not, for instructing a computing device to perform specific operations, and include, but are not limited to, application software, desktop applications, scripts, binaries, operating systems, device drivers, boot loaders, shells, utilities, system software, JavaScript, web pages, web applications, plug-ins, embedded software, microcode, compilers, debuggers, interpreters, virtual machines, linkers, and text editors.

[0108] Computing device 400 may also include a read only memory (ROM) 408 or other static storage device coupled to bus 402 for storing static information and software instructions for processor(s) 404 .

[0109] One or more mass storage devices 410 can be coupled to bus 402 for persistently storing information and software instructions on fixed or removable media such as magnetic, optical, solid-state, magneto-optical, flash memory, or any other available mass storage technology. The mass storage device can be shared over a network or can be dedicated mass storage. Typically, at least one of the mass storage devices 410 (e.g., the device's primary hard drive) stores the bulk of the programs and data used to direct the operation of the computing device, including an operating system, user applications, drivers, and other supporting files, as well as various other data files.

[0110] The computing device 400 may be coupled to a display 412, such as a liquid crystal display (LCD) or other electronic visual display, via the bus 402 for displaying information to a computer user. In some configurations, a touch-sensitive surface incorporating touch detection technology (e.g., resistive, capacitive, etc.) may be overlaid on the display 412 to form a touch-sensitive display for communicating touch gesture (e.g., finger or stylus) input to the processor(s) 404.

[0111] An input device 414, including alphanumeric and other keys, may be coupled to bus 402 for communicating information and command selections to processor 404. In addition to or in lieu of the alphanumeric and other keys, input device 414 may also include one or more physical buttons or switches, such as, for example, a power (on / off) button, a "home" button, volume control buttons, etc.

[0112] Another type of user input device may be a cursor control 416, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 404 and for controlling cursor movement on the display 412. Such input devices typically have two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), to allow the device to specify a position within a plane.

[0113] Although in some configurations (such as Figure 4 In the configuration shown, one or more of the display 412, input device 414, and cursor control 416 are external components (i.e., peripherals) of the computing device 400, but some or all of the display 412, input device 414, and cursor control 416 are integrated as part of the form factor of the computing device 400 in other configurations.

[0114] The functions of the disclosed systems, methods, and modules may be performed by the computing device 400 in response to the processor(s) 404 executing one or more programs of software instructions contained in the main memory 406. Such software instructions may be read into the main memory 406 from another storage medium, such as the storage device(s) 410. Execution of the software instructions contained in the main memory 406 causes the processor(s) 404 to perform the functions of the example embodiment(s).

[0115] Although the functions and operations of (one or more) example embodiments may be implemented entirely with software instructions, hardwired or programmable circuitry (e.g., ASIC, FPGA, etc.) of the computing device 400 may, in other embodiments, be used in place of or in combination with software instructions to perform the functions as required by the particular implementation at hand.

[0116] As used herein, the term "storage medium" refers to any non-transient medium that stores data and / or software instructions that cause a computing device to operate in a particular manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media include, for example, non-volatile random access memory (NVRAM), flash memory, optical disks, magnetic disks, or solid-state drives, such as storage device 410. Volatile media include dynamic memory, such as main memory 406. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape, or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a hole pattern, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, flash memory, any other memory chip, or a cassette tape.

[0117] Storage media are distinct from transmission media but can be used in conjunction with them. Transmission media are involved in transferring information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wiring that comprises bus 402. Transmission media can also take the form of acoustic or light waves, such as those generated in radio wave and infrared data communications.

[0118] Various forms of media may be involved in carrying one or more sequences of one or more software instructions to processor(s) 404 for execution. For example, the software instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the software instructions into its dynamic memory and send the software instructions over a telephone line using a modem. A modem local to computing device 400 may receive the data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal and appropriate circuitry may place the data on bus 402. Bus 402 carries the data to main memory 406, from which processor(s) 404 retrieve and execute the software instructions. The software instructions received by main memory 406 may optionally be stored on storage device 410 before or after execution by processor 404.

[0119] The computing device 400 may also include one or more communication interfaces 418 coupled to the bus 402. The communication interface 418 provides a two-way data communication connection to a wired or wireless network link 420 that is connected to a local network 422 (e.g., Ethernet, wireless local area network, cellular telephone network, Bluetooth wireless network, etc.). The communication interface 418 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. For example, the communication interface 418 may be a wired network interface card, a wireless network interface card with an integrated radio antenna, or a modem (e.g., ISDN, DSL, or cable modem).

[0120] Network link(s) 420 typically provide data communication to other data devices through one or more networks. For example, network link 420 can provide a connection to a host computer 424 or to data equipment operated by an Internet Service Provider (ISP) 426 through a local network 422. ISP 426, in turn, provides data communication services through the global packet data communication network now commonly referred to as the "Internet" 428. Local network(s) 422 and Internet 428 use electrical, electromagnetic, or optical signals to carry digital data streams. The signals through the various networks and the signals on network link(s) 420 and through communication interface(s) 418 that carry digital data to and from computing device 400 are example forms of transmission media.

[0121] Computing device 400 can send messages and receive data, including program code, through network(s), network link(s) 420, and communication interface(s) 418. In the Internet example, server 430 can send the requested code corresponding to the program through Internet 428, ISP 426, local network(s) 422, and communication interface(s) 418.

[0122] The received code may be executed by processor 404 as it is received, and / or stored in storage device 40 or other non-volatile storage for later execution.

[0123] Software Overview

[0124] Figure 5 4 is a block diagram of a basic software system 500 that can be used to control the operation of a computing device 400. The software system 500 and its components, including their connections, relationships, and functionality, are meant to be illustrative only and are not meant to limit the implementation of the example embodiment(s). Other computing devices suitable for implementing the example embodiment(s) may have different components, including components with different connections, relationships, and functionality.

[0125] Software system 500 is provided to direct the operation of computing device 400. Software system 500 includes a kernel or operating system (OS) 510, which may be stored in system memory (RAM) 406 and on fixed storage (eg, hard disk or flash memory) 410.

[0126] The OS 510 manages low-level aspects of computer operation, including managing the execution of processes, memory allocation, file input and output (I / O), and device I / O. One or more applications, represented as 502A, 502B, 502C ... 502N, can be "loaded" (e.g., transferred from fixed storage 410 into memory 406) for execution by the system 500. Applications or other software intended for use on the device 400 can also be stored as downloadable computer-executable instruction sets, such as for downloading and installation from an Internet location (e.g., a web server, an application store, or other online service).

[0127] Software system 500 includes a graphical user interface (GUI) 515 for receiving user commands and data in a graphical manner (e.g., "point and click" or "touch gestures"). These inputs can, in turn, be acted upon by system 500 according to instructions from operating system 510 and / or application(s) 502. GUI 515 is also used to display results 502 of operations from OS 510 and application(s) so that the user can provide additional input or terminate the session (e.g., log off).

[0128] OS 510 may execute directly on bare hardware 520 (e.g., processor(s) 404) of device 400. Alternatively, a hypervisor or virtual machine monitor (VMM) 530 may be interposed between bare hardware 520 and OS 510. In this configuration, VMM 530 acts as a software "buffer" or virtualization layer between OS 510 and bare hardware 520 of device 400.

[0129] VMM 530 instantiates and runs one or more virtual machine instances ("guest machines"). Each guest machine includes a "guest" operating system (such as OS 510) and one or more applications (such as application 502) designed to execute on the guest operating system. VMM 530 presents a virtual operating platform to the guest operating system and manages the execution of the guest operating system.

[0130] In some cases, VMM 530 can allow a guest operating system to run as if it were running directly on bare hardware 520 of device 400. In these cases, the same version of the guest operating system that is configured to execute directly on bare hardware 520 can also execute on VMM 530 without modification or reconfiguration. In other words, in some cases, VMM 530 can provide complete hardware and CPU virtualization to the guest operating system.

[0131] In other cases, the guest operating system may be specifically designed or configured to execute on the VMM 530 to improve efficiency. In these cases, the guest operating system "knows" that it is executing on a virtual machine monitor. In other words, in some cases, the VMM 530 can provide paravirtualization to the guest operating system.

[0132] The above basic computer hardware and software are provided to illustrate the basic underlying computer components that can be used to implement the example embodiment(s). However, the example embodiment(s) are not necessarily limited to any particular computing environment or computing device configuration. Rather, the example embodiment(s) can be implemented in any type of system architecture or processing environment that one skilled in the art would understand in light of this disclosure to be capable of supporting the features and functions of the example embodiment(s) presented herein.

[0133] Extensions and replacements

[0134] Although some of the drawings described in the foregoing specification include flowcharts with steps shown in a certain order, these steps can be performed in any order and are not limited to the order shown in those flowcharts. In addition, some steps can be optional, can be performed multiple times, and / or can be performed by different components. All steps, operations and functions of the flowcharts described herein are intended to indicate the operations performed using programming in a special-purpose computer or a general-purpose computer in various embodiments. In other words, each flowchart in this disclosure, in conjunction with the relevant text of this document, is a guide, plan or specification for all or part of an algorithm for programming a computer to perform the described functions. The technical level in the field associated with this disclosure is known to be high, and therefore the flowcharts and related text in this disclosure have been prepared to convey information about programs, algorithms and their implementation methods with the sufficiency and detail level that a technician would typically expect in this field.

[0135] In the foregoing description, the exemplary embodiments of the present disclosure have been described with reference to many specific details. However, the details may vary from one implementation to another, depending on the requirements of the particular implementation at hand. Thus, the exemplary embodiments should be considered illustrative rather than restrictive.< / op>

Claims

1. A computer-implemented method comprising: receiving, from a client application, a first database command to be executed as part of a particular transaction; A local transaction is initiated for a first database command, the local transaction accessing a first shard of a sharded database, wherein the sharded database includes: a first shard managed by a first database server, and a second shard not accessed by the first database command, wherein the second shard is managed by a second database server; receiving, from the client application, a second database command to be executed as part of the particular transaction; After initiating a local transaction for a first database command, detecting that a second database command should access a second shard; In response to detecting that the second database command should access the second shard, the local transaction is promoted to a distributed transaction that: includes a first shard and a second shard, and Use a commit protocol that local transactions do not use; and After promoting the local transaction, the second database command is executed in the distributed transaction.

2. The method of claim 1 , wherein the database driver in the client application performs at least one item selected from the group consisting of: Detect that the second database command should access the second shard, and Promote a local transaction to a distributed transaction.

3. The method according to claim 1, wherein: The first computer hosts the client application; The second computer hosts the shard director; Detecting that the second database command should access the second shard includes: Sending a second database command to the shard director, and A shard key value corresponding to the second shard is received from the shard director.

4. The method of claim 1 , wherein promoting the local transaction comprises promoting the local transaction to one selected from the group consisting of an eXtended Architecture (XA) transaction and a Java Transaction API (Application Programming Interface) (JTA) transaction.

5. The method according to claim 1, further comprising: Execute the first database command; Detection of failure in executing the second database command; In response to detecting a failure in executing the second database command, changes made during execution of the first database command are rolled back.

6. The method according to claim 1, wherein: The sharded database includes a third shard managed by a third database server; and The method also includes detecting that the second database command should access the third shard.

7. The method of claim 1 , wherein detecting that the second database command should access the second shard comprises: Get the shard key expression corresponding to the second database command, and Evaluate the shard key expression to obtain the shard key value corresponding to the second shard.

8. The method according to claim 7, wherein: The first computer hosts the client application; Obtaining the shard key expression involves the database driver executing in the client application: sending a second database command to the second computer, and A shard key expression is received from the second computer.

9. The method of claim 8, wherein receiving a shard key expression comprises receiving a series of stack operators arranged in a specific order in the shard key expression.

10. The method of claim 9, wherein evaluating a shard key expression comprises applying, by a database driver in a client application, the series of stack operators to a stack in the particular order to generate the shard key value.

11. A non-transitory computer-readable medium storing instructions, which, when executed by one or more processors, cause the method of any one of claims 1 to 10 to be performed.

12. A system comprising one or more computing devices, the computing devices including components implemented at least in part by computing hardware, the computing hardware configured to implement the method of any one of claims 1-10.

Images