Automatic Deduction of Sharding Key Values and Transparent Support for Multi-Sharding Transactions and Queries

Abstract

Techniques are provided for processing database commands in a sharded database. Processing of a database command can include generating or otherwise accessing a shard key expression, and evaluating the shard key expression to identify one or more target shards that contain data for performing the database command.

Description

Technical Field

[0001] The present disclosure relates to database systems. More particularly, the present disclosure relates to processing database commands in a sharded database system. Background Art

[0002] 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 typically 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 amount of data stored in these database systems, it may not be practical to store all the data on a single database instance, as the data volume would utilize a large amount of computing resources such as processors, memory, and storage devices.

[0003] Horizontal partitioning is a technique for decomposing a single larger table into smaller, more manageable subsets of information (referred to as "partitions"). Sharding is a data layer architecture in which data is horizontally partitioned among independent database instances, where each independent database instance is referred to as a "shard". The collection of shards together constitutes a single logical database, referred to as a "sharded database" ("SDB"). Logically, a client application can access the sharded database just like a traditional non-sharded database. However, the tables in a sharded database are horizontally partitioned across the shards.

[0004] To access and execute database commands, such as query and data manipulation commands, on a sharded database system, a client application may need to be specially designed or modified ("shard-aware"). In an example, the client application generates a database command that includes or otherwise specifies a shard key value that is used to identify the specific shard for executing the database command.

[0005] In the case where the client application is not aware 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, continuously using the shard director in this way reduces the scalability of the entire sharded database system.

[0006] The methods described in this section are methods that can be adopted, but not necessarily methods that were previously conceived or adopted. Therefore, unless otherwise indicated, any method described in this section should not be assumed to be prior art merely because it is included in this section. Brief Description of the Drawings

[0007] Exemplary embodiment(s) of the present disclosure are shown by way of example and not limitation in the accompanying drawings, in which like reference numerals refer to similar elements and in which:

[0008] Figure 1 An example of a non-sharded database and a sharded database according to one embodiment is illustrated.

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

[0010] Figure 3A is a flowchart for processing database commands according to an embodiment.

[0011] Figure 3B is another flowchart for processing database commands according to an embodiment.

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

[0013] Figure 5 is a block diagram of a basic software system for controlling the operation of a computing device. Detailed Description

[0014] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiment(s) of the present disclosure. It will be recognized, however, that example embodiment(s) may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid unnecessarily obscuring example embodiment(s).

[0015] General Overview

[0016] Techniques are described herein for processing database commands executed in a sharded database or SDB system in a manner that avoids issues such as having to specifically design a client application to be shard-aware and provide a shard key along with the requested database command. Such SDB command processing techniques include automatic derivation of shard key values for database commands, which may 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 a client application issuing a database command to a sharded database system. Additionally, the derivation of the shard key value is performed using a shard key expression corresponding to the database command.

[0017] The techniques described herein also support deriving sharding key expressions and corresponding sharding key values from rich or complex SQL commands, which can include joins, subqueries, and expressions with operators. Thus, client applications do not need to be specifically designed to operate in an SDB system in order to issue database queries and database commands to a sharded database system. For example, a given database command does not need to specify the sharding key value or service name of a table family to directly route to the target shard, and the client application does not need to otherwise explicitly provide the sharding key / service name to the SDB system. Thus, the SDB command processing techniques disclosed herein help eliminate or minimize application changes that impede the adoption of sharded databases. Additionally, by providing automatic and transparent derivation of sharding key values for database commands, the client driver supports routing commands directly to shards.

[0018] The SDB command processing techniques also transparently support multi-shard queries and multi-shard transactions or updates with ACID (atomicity, consistency, isolation, and durability) properties without application code changes. The command processing techniques transparently distinguish single-shard and multi-shard commands from the perspective of the application, so no special programming or configuration is required to distinguish single-shard and multi-shard commands. In an embodiment, the SDB command processing techniques distinguish single-shard commands from multi-shard commands, which allows the database coordinator to be used only when needed or desired, such as to process only multi-shard commands. Additionally, the SDB command processing techniques can distinguish single-shard and multi-shard transactions or updates to elevate such commands to a coordinated protocol that can support distributed transactions involving multiple data sources. Such multi-shard transaction protocols include XA, Java Transaction API (JTA), etc.

[0019] Sharded database

[0020] Horizontal partitioning is a technique for decomposing a single larger table into smaller, more manageable subsets of information (referred to as "partitions"). Sharding is a data layer architecture in which data is horizontally partitioned among independent database instances, where each independent database instance is referred to as a "shard". The collection of shards together constitutes a single logical database, referred to as 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 horizontally partitioned across shards.

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

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

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

[0024] 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 by adding additional shards and distributing the load across the shards to make it possible to increase the performance and capacity of the system. The sharded database 110 can be implemented as an architecture where nothing is shared, and thus, 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 devices.

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

[0026] The sharded database 110 can also help provide enhanced global data distribution. Sharding makes it possible to store specific data in a location physically close to the customer. When data must be found within a particular jurisdiction by law, it may be necessary to store the data physically close to the customer by physically locating the shard for that specific data within that jurisdiction to meet regulatory requirements. 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.

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

[0028] The sharded database 110 can also help provide simplicity in cloud deployments. Given that the size of the shards can be made arbitrarily small, the database administrator can easily deploy the sharded database in a cloud consisting of low-end commodity servers with local storage devices.

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

[0030] The sharded database 110 can also help provide improved automatic propagation of database schema changes across shards. Instead of requiring the 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.

[0031] The sharded database 110 can also help support traditional Structured Query Language (SQL), and thus can leverage all of the full SQL syntax and keywords that are already available. Additionally, given that the sharded database 110 supports SQL, it can be easily integrated with existing client applications that are configured to access relational databases via SQL.

[0032] The sharded database 110 can also help provide the full-featured benefits of a relational database, including schema control, atomicity, consistency, isolation, and durability.

[0033] The sharded database 110 can also help provide direct routing of queries to the shards without the need for an intermediate component to route the queries. This direct routing improves system latency by reducing the number of network hops required to process the queries.

[0034] Overall system architecture

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

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

[0037] Shard directory

[0038] The sharded database 220 includes a shard directory 240. The shard directory 240 is a special database for storing the configuration data of the sharded 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 can include: a routing table that maps which shard 230 stores data blocks corresponding to a given value, range of values, or set of values of the shard key; shard topology data that describes the overall configuration of the sharded database 220; information about the configuration of the 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 the data horizontally partitioned across the shards 230A, 230B, and 230C; a historical log of outstanding and complete schema modification instructions for the shards 230A, 230B, and 230C; and all other information related to the configuration of the sharded database 220.

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

[0040] In one embodiment, the sharding directory 240 maintains a routing table that stores mapping data including multiple mapping entries. Each mapping entry among the multiple mapping entries maps a different set of key values of one or more sharding keys to a shard among the multiple shards in the sharding database. In another embodiment, each mapping entry among the multiple mapping entries maps a different set of key values of one or more sharding keys to a data block on a shard among the multiple shards in the sharding database. In another embodiment, each mapping entry among the multiple mapping entries maps a different set of key values of one or more sharding keys to a sharding space including one or more shards in the sharding database. In one embodiment, the set of key values can be a range of partition key values. In another embodiment, the set of key values can be a list of partition key values. In another embodiment, the set of key values can be a collection of hash values.

[0041] Thus, for a database command that needs to access data with a specific sharding key value, the routing table can be used to find which shard in the sharding database contains the data block required to process the query.

[0042] Sharding director

[0043] The sharding database 220 includes a sharding director 250. The sharding director 250 coordinates various functions across the sharding database 220, and accordingly can also be referred to as a sharding coordinator. The sharding director 250 coordinates functions including, but not limited to, routing database requests to shards, parsing database commands to generate sharding 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 sharding database 220, such as resharding operations. The sharding director 250 is communicatively coupled to the sharding directory 240, the client application 210, and the shards 230A, 230B, and 230C.

[0044] In an embodiment, the shard director 250 generates or derives a shard key expression from database commands (such as SQL queries) received from the driver 260. The shard director 250 derives 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 for one or more database command languages). When it is desired or needed to help distinguish table families that may have the same shard key expression and / or shard key values, the shard director 250 may also derive a service name and send it to the driver 260. In an embodiment, the shard director 250 sends the extracted shard key expression along with or separately from the service name to the driver 260 in a suitable format, such as a version of Reverse Polish Notation (RPN) that supports different table families, multiple columns in the shard key, a multi-level shard key (e.g., a shard key, a super shard key), and an SQL expression with operators. Another suitable format includes a higher-level representation, such as JavaScript Object Notation (JSON).

[0045] Although depicted as a single shard director 250, in one embodiment, the sharded database 220 may include multiple shard directors 250. For example, in one embodiment, the sharded database 220 may include three shard directors 250. Having multiple shard directors 250 may allow for load balancing of the 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 the manager of the shard directors 250 responsible for managing the remaining shard directors 250 (including load balancing).

[0046] Driver and Cache

[0047] Figure 2The database system 200 includes a driver 260 communicatively coupled to a client application 210 and a sharded database 220. The driver 260 maintains a store or cache 270 to store entries associating a given database command with a shard key expression. In an embodiment, multiple specific database commands can be associated with a single shard key expression. The driver 260 and / or the shard director 250 can transform a specific database command that can include literals, bind variables, and / or operators into a transformed version or a prepared statement. In an embodiment, the transformed version or the prepared statement is a generalized representation of the database command and can include one or more bind variables in place of 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 the prepared statement and associate many different database commands with a smaller number of shard key expressions.

[0048] A given shard key expression can also include literals, bind variables, and / or operators. In an embodiment, once one or more specific bind values are applied, a shard key expression with bind variables can be used to identify multiple different shards or table families. Generally, a table family is a representation of a hierarchy of related tables, and each table in turn maps which shard stores the data blocks 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 the cache can help minimize the number of database commands in the cache and reduce the need to retrieve shard key expressions from the shard director.

[0049] When the driver 260 receives a database command from the client application 210, the driver 260 determines whether any database command entries corresponding to the received database command exist in the cache 270. If so, then the driver 260 retrieves the associated shard key expression from the cache 270, and the shard key expression can then be evaluated to derive a shard key value based on the actual bind values. In an embodiment, the driver 260 evaluates the shard key expression to obtain a fully evaluated shard key value without contacting the shard director 250. The 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 an embodiment, the driver 260 directly connects to the specific shard using a connection from a connection pool without routing the database command through other components such as the shard director 250. In an embodiment, the driver 260 stores a shard connection pool in the cache 270, which maintains database connections such that when future requests to the database are needed, the connections can be reused. Since many applications use SQL with bind variables to improve performance, support for bind variables and operators in the shard key expression and the cache 270 greatly reduces the amount of SQL in the cache and reduces the need to retrieve shard key expressions from the shard director.

[0050] 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 the received database command does not correspond to an entry in the cache 270, then 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.

[0051] In another embodiment, the driver 260 is configured to generate a shard key expression by parsing the database command. To this end, 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 the cache 270. Additionally, the driver 260 will be configured to perform complex database command parsing in different database command language versions to help support backward compatibility.

[0052] Routing Database Commands

[0053] Many queries in a typical client application are short and should be processed with millisecond latency. Additional network hops and parsing during routing the query to the appropriate shard may introduce latency unacceptable to the client application. This disclosure provides techniques for minimizing latency when routing queries sent from a client application.

[0054] The client application 210 generates and sends database commands for data requests of 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 called single-shard queries. Single-shard queries will represent most of the data requests of a typical client application because the shards 230A, 230B, and 230C have been configured such that the chunks in each shard contain the corresponding partitions of the tables from a table family. Thus, most database commands that rely on data in a table family will likely be serviced by a single shard because the relevant data of the table family is collocated on the same shard. Also, using replicated tables for relatively small and / or static reference tables helps increase the likelihood that a query will be processed as a single-shard query.

[0055] In other cases, the database commands from the client application 210 will require data from multiple shards. Such commands are called cross-shard commands. Processing cross-shard commands is generally 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.

[0056] The shard directory 240 maintains a routing table that maps the list of chunks hosted by each shard to the range of hash values associated with each chunk. Thus, the routing table can be used to determine which shard contains the chunk that holds the shard key data for a shard key value or set of shard key values. In an embodiment, in the case where the database is sharded via composite sharding, the routing table can 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 which shard contains the chunk that holds the data for a given set of shard key values.

[0057] In an embodiment, the routing table maintained by the shard directory 240 can be accessed by the shard director 250, which helps route queries to the appropriate shard. 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 sharded database 220 or can be external to the sharded database 220. In an embodiment, the software component can be external to the sharded database 220 and the client application 210.

[0058] 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. This accessibility reflects various communication characteristics, including but not limited to physical proximity, bandwidth, availability of computing resources, workload, and other characteristics that will affect the accessibility of the software components S1 through SN.

[0059] In an embodiment, software component S1 may be a client component of the client application 210 and / or the driver 260 and may be more accessible to the client application 210 than software component S2. Similarly, the client application 210 may be more accessible to software component S2 than software component S3, and so on. Thus, in this example, software component S1 is considered to be closest to the client application 210 because it is the most accessible to the client application 210, and software component SN is considered to be farthest from the client application 210 because it is the least accessible to the client application 210. In an embodiment, when a database command is created at the client application 210, the available software component closest to the client application 210 is first used to attempt to process the database request. If the available software component closest to the client application 210 cannot process the database command, then the next closest software component is attempted, and so on, until the database command is successfully processed and routed to the 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 using the available software component closest to the client application 210 to process the database command, the database system 200 can provide improved performance when processing the command because the closest available software component has improved accessibility compared to other software components.

[0060] Accessing and Generating Shard Key Expressions

[0061] In an embodiment, the client application 210 generates a database command to be executed on the shard database 220 but does not include the shard key value. Thus, the client application 210 cannot directly route the command to the identified shard(s) 230 for execution or processing.

[0062] Figure 3AIt is a flowchart for process 300A to access 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 an SQL statement or a DML command. At block 304, the driver 260 determines whether the received database command corresponds to any database command entries in the cache 270 coupled to the driver. If so, the corresponding database command entry is identified. At block 306, if the received database command does correspond to a database command entry in the cache 270, then the driver 270 retrieves the shard key expression associated with the identified database command entry from the cache. After block 306, at block 308, the driver 270 evaluates the shard key expression to determine the shard key value. Generally, the driver 270 evaluates the shard key expression by substituting bound variables with the bound values that can be provided in the original database command and / or by evaluating the operators in the shard key expression. If the driver 270 cannot determine the shard key value from the shard key expression, then the driver can invalidate the corresponding database command entry and provide the database command to the shard director 250 for processing.

[0063] At block 310, the driver 270 uses the shard key value and the routing table to identify a specific target shard 230 that contains the data required to process the database command. At block 312, the driver 270 directly connects to the specific shard. At block 314, the database command is transmitted to the connected shard for execution, and the result can be directly returned to the driver 260 and the client application 210 as the result of the execution. At block 314, the target shard can also return mapping data that identifies all key ranges stored in 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.

[0064] 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 sharding key expression for the database command. In an embodiment, at block 318, the driver 260 sends the database command to the shard director 250, which at block 318 parses the database command into a tree structure and traverses the tree structure using data from the sharding directory 240 to generate the sharding key expression. In this embodiment, the shard director 250 sends the sharding key expression to the driver 260, which at block 320 stores a cache entry associating the sharding key expression with the database command. In another embodiment, at block 318, the driver 260 parses the database command to generate the sharding key expression, and at block 320, the driver 260 stores a cache entry associating the sharding key expression with the database command. After block 320, the driver 260 determines the sharding key value from the sharding key expression (block 308), maps the sharding 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).

[0065] At block 320, the driver 260 and / or the shard director 250 may store the received database command (including literals) in the cache 270. Alternatively or additionally, at block 320, the driver 260 and / or the shard director 250 may transform the received database command into a prepared statement for storage in the cache 270. Generally, a prepared statement is a database command that uses bound 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.

[0066] In an embodiment, if the shard director 250 or the driver 260 cannot generate a shard key expression for a database command, then 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.

[0067] As a result of process 300A, the driver cache 270 may accumulate over time many (if not substantially all) of the most common database commands executed by a given client application. Thus, when a database command is received, the driver 260 is able to identify an existing database command entry in the cache 270, evaluate the corresponding shard key expression to determine a shard key value, and use the determined shard key value to directly connect to the (one or more) target shards. This helps to eliminate the shard director 250 as an "intermediary", thus helping to efficiently process database commands in the database system 200.

[0068] As discussed herein, the shard director 220 and / or the driver 260 may use table metadata and shard topology, for example, to parse database commands and derive 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, the shard key expression is represented as an RPN expression in shard key line form. Using an RPN expression provides a compact storage format that is also highly scalable for any additional expression support in the future in database command languages and shard key enhancements such as multiple hierarchies of shard keys.

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

[0070] <shard key expression>::= <token>

[0071] <token> ::＝ <parameter> | <literal> | <operator>

[0072] <parameter> ::＝‘:’ <digit> …

[0073] <literal>::= <string literal>|<numeric literal>|...

[0074] <string literal>::= ‘"‘ <char> …‘"′

[0075] <char>::= <unicode representation>

[0076] <numeric literal>::= <number format>

[0077] <op>::= 'to_date' | 'timestamp' | 'add' |'sub' |'mul' | 'div' |'swap' | 'dup' | 'pop' | 'concatenate' |...

[0078] In this embodiment, the sharding key expression can be specified by a token; the token can be specified by a parameter, a literal, and / or an operator; the parameter can be specified by a column and a number; the literal can be specified by a value in the application and can be a string literal or a numeric literal; the string literal can be specified by a character; the character can be specified by a Unicode representation; the numeric literal can be specified by a certain numeric format; and operators that can be evaluated are also provided ( <op>)。

[0079] In an illustrative embodiment, the database command from the client application 210 can 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 composite shard keys or two-part shard keys. The "cust_no" part 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" part 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.

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

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

[0082] On line 3, the driver 260 receives the command "push_bind_variable 1", and in response, binds the variable by location identification and pushes (bind_variable, 1) onto the stack. On line 4, the driver 260 receives the command "push_type 2", and in response pushes (type, 2) onto the stack. In this example, binding 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 binding value is at position 1 of type number, and in this example the binding value is 100. The driver pushes 100 onto 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)] onto the stack. At this point, [(100)] is the shard key value.

[0083] At line 7, the driver 260 receives the command "push_literal_length 9" and, in response, pushes the (literal_length, 9) object onto the stack. At line 8, the driver 260 receives the command "push_type 1" and pushes the (type, 1) object onto the stack. In this example, type 1 specifies a character. At 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. At line 10, the driver 260 receives the command "push_literal_length 9" and, in response, pushes the (literal_length, 9) object onto the stack. At line 11, the driver 260 receives the command "push_type 1" and, in response, pushes the (type, 1) object onto the stack. In this example, type 1 specifies a character. At 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. At 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 (in this example, 04 / 04 / 2009) onto the stack. At 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, the driver 260 receives the command "append_key_to_tuple" and, in response, pops [(100)(04 / 04 / 2009)] and {} and pushes the top element into {}. The stack content - [(100)(04 / 04 / 2009)] - is now the complete shard key value.

[0084] At line 16, the driver 260 receives the command "push_empty_key", and in response pushes an empty key onto the stack, such as the empty array list denoted as []. This is for the super shard key. At line 17, the driver 260 receives the command "push_literal_length 10", and in response pushes the (literal_length, 10) object onto the stack. At line 18, the driver 260 receives the command "push_type 1", and in response pushes the (type, 1) object onto the stack. In this example, type 1 specifies a character. At 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. At 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. At 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. At 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')]}.

[0085]

[0086]

[0087] Table 1

[0088] Processing multi-shard commands

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

[0090] Figure 3B is a flowchart of a process 300B for managing multi-shard database commands, such as SQL queries. In an embodiment, the driver 260 caches a database command 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 subsequent database commands received 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, from the perspective of the client application 210, this processing is performed transparently and it does not need to distinguish between single-shard and multi-shard commands.

[0091] Flowchart 300B includes a block 322, which is after determining at block 304 that the received database command does not correspond to any database command entry in the cache 270. At block 322, the driver 260 and / or the shard director 250 determines whether the received database command is a multi-shard query. If so, then at block 324, the shard director 250 receives and disposes of the processing of the multi-shard query. For example, the shard director can parse the query to identify the 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 the results that are transmitted back to the driver and the client application.

[0092] Flowchart 300B can also be used to support transparent multi-shard transactions, such as DML transactions that can modify data in multiple different shards. The driver 260 helps to dispose of multi-shard transactions atomically by supporting the coordination of global distributed transactions involving multiple data sources, such as by facilitating multi-shard transactions to be processed via, for example, the XA protocol or the Java Transaction API (JTA). Generally speaking, XA is a two-phase commit protocol natively supported by many databases and transaction monitors. XA ensures data integrity by coordinating a single transaction accessing multiple relational databases and guarantees that transaction updates are committed in all participating databases or fully rolled back from all databases, thus restoring to the state before the transaction started.

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

[0094] In an embodiment, at block 322, when the driver detects an existing local transaction to shard 230 or shard director 250 and detects that a second local transaction to a different shard or shard director has been requested or initiated, 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 connections from the driver to each database (shard or shard director) are physical connections. For each logical connection, the driver can maintain one or more physical connections to the shard databases. When there are multiple local transactions with different physical connections, the driver promotes the local transactions to XA. For each database command, if the command has started a transaction or is in a transaction, the database notifies the driver. 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 to make all pre-commit updates made in one transaction branch of a tightly coupled transaction visible to other tightly coupled branches in different instances of the database. In an embodiment, to facilitate the seamless promotion of the transaction to XA, if the command will start a transaction in the shard database 220, then the (one or more) shards 230 and the shard director 250 can notify the driver 260 via a piggyback message.

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

[0096] Syntax

[0097] Although the present disclosure provides various examples of syntax for how to create, manage, and manipulate a sharded database, these examples are merely illustrative. The 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 significant 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 system. Additionally, the use of DDL requires only minor changes to support the keywords necessary to implement the sharded organization of the sharded database. Further, 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, etc.

[0098] Database Overview

[0099] 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.

[0100] Generally, a server, such as a database server, is an allocated combination of integrated software components and 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 function on behalf of clients of the server. The database server manages and facilitates access to a particular database, thereby processing requests from clients to access the database.

[0101] A database includes data and metadata stored on a permanent memory mechanism (such as a collection of hard disks). For example, these data and metadata can be logically stored in the database according to a relational and / or object - relational database structure.

[0102] Users interact with the database server of the DBMS by submitting commands to the database server, which 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 can also be collectively referred to as users herein.

[0103] 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 the 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 the database server to create or configure database objects such as tables, views, or complex types. DML instructions are issued to the DBMS to manage the data stored within the 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.

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

[0105] 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 access to a shared storage device to varying degrees, e.g., sharing access to a set 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.

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

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

[0108] Hardware Overview

[0109] Now refer to Figure 4 , Figure 4 which is a block diagram of 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 functions, are meant to be illustrative and are not meant to limit the implementation of example embodiment(s). Other computing devices suitable for implementing example embodiment(s) may have different components, including components with different connections, relationships, and functions.

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

[0111] The computing device 400 may also include one or more hardware processors 404 coupled to the bus 402 for processing information. The hardware processors 404 may be general-purpose microprocessors, system-on-chips (SoCs), or other processors.

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

[0113] When software instructions are stored in a storage medium accessible to the processor(s) 404, the computing device 400 is presented as a special-purpose computing device customized to execute the operations specified in the software instructions. The terms "software", "software instructions", "computer program", "computer-executable instructions", and "processor-executable instructions" should be interpreted broadly 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, binary files, operating systems, device drivers, boot loaders, shells, utilities, system software, JAVASCRIPT, web pages, web applications, plugins, embedded software, microcode, compilers, debuggers, interpreters, virtual machines, linkers, and text editors.

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

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

[0116] The computing device 400 may be coupled via the bus 402 to a display 412, such as a liquid crystal display (LCD) or other electronic visual display, 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 transmitting touch gesture (e.g., finger or stylus) inputs to the processor(s) 404.

[0117] An input device 414 including alphanumeric keys and other keys may be coupled to the bus 402 for transmitting information and command selections to the processor 404. In addition to or instead of alphanumeric keys and other keys, the 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.

[0118] Another type of user input device can be a cursor control 416 (such as a mouse, trackball, or cursor direction keys) for transmitting direction information and command selections to the processor 404 and for controlling the movement of a cursor on the display 412. Such an input device typically has 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.

[0119] While in some configurations (such as Figure 4 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, 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.

[0120] The functions of the disclosed systems, methods, and modules can be performed by the computing device 400 in response to one or more programs executed by the (one or more) processors 404 that include software instructions contained in the main memory 406. Such software instructions can be read into the main memory 406 from another storage medium (such as the (one or more) storage devices 410). Execution of the software instructions contained in the main memory 406 causes the (one or more) processors 404 to perform the functions of the (one or more) example embodiments.

[0121] While the functions and operations of the (one or more) example embodiments can be implemented entirely with software instructions, hardwired or programmable circuitry of the computing device 400 (e.g., ASIC, FPGA, etc.) can be used in other embodiments to perform functions in lieu of or in combination with software instructions according to the requirements of the current particular implementation.

[0122] As used herein, the term "storage medium" refers to any non-transitory 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 includes, for example, non-volatile random access memory (NVRAM), flash memory, optical discs, magnetic disks, or solid state drives, such as the storage device 410. Volatile media includes dynamic memory, such as the 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-ROM, 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 cartridge.

[0123] A storage medium is distinct from but can be used in conjunction with a transmission medium. The transmission medium participates in carrying information between storage media. For example, the transmission medium includes coaxial cables, copper wire, and fiber optics, including the wiring that includes bus 402. The transmission medium can also take the form of acoustic or light waves, such as those generated in radio wave and infrared data communications.

[0124] Various forms of media can participate in carrying one or more sequences of one or more software instructions to (one or more) processors 404 for execution. For example, the software instructions can initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can 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 can receive the data on the telephone line and use an infrared transmitter to convert the data into an infrared signal. An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on bus 402. Bus 402 carries the data to main memory 406, from which (one or more) processors 404 retrieve and execute the software instructions. The software instructions received by main memory 406 can optionally be stored on storage device 410 before or after being executed by processor 404.

[0125] Computing device 400 can also include one or more communication interfaces 418 coupled to bus 402. Communication interface 418 provides two-way data communication coupled 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.). Communication interface 418 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. For example, communication interface 418 can 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).

[0126] (One or more) network links 420 generally provide data communication to other data devices via 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 via a local network 422. The ISP 426 in turn provides data communication services via the global packet data communication network now commonly referred to as the "Internet" 428. The (one or more) local networks 422 and the Internet 428 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals that carry digital data to and from the computing device 400 via various networks and (one or more) signals on the network link 420 and through the (one or more) communication interfaces 418 are example forms of transmission media.

[0127] The computing device 400 can send messages and receive data, including program code, via the (one or more) networks, the (one or more) network links 420, and the (one or more) communication interfaces 418. In the Internet example, a server 430 can send the requested code corresponding to a program via the Internet 428, the ISP 426, the (one or more) local networks 422, and the (one or more) communication interfaces 418.

[0128] The received code can be executed by the processor 404 when it is received, and / or stored in the storage device 40 or other non-volatile memory for subsequent execution.

[0129] Software Overview

[0130] Figure 5 is a block diagram of a basic software system 500 that can be used to control the operation of the computing device 400. The software system 500 and its components, including its connections, relationships, and functions, are meant to be illustrative only and do not imply limitations on the implementation of the (one or more) example embodiments. Other computing devices suitable for implementing the (one or more) example embodiments can have different components, including components with different connections, relationships, and functions.

[0131] The software system 500 is provided to direct the operation of the computing device 400. The software system 500, which can be stored in the system memory (RAM) 406 and the fixed memory (e.g., hard disk or flash memory) 410, includes a kernel or operating system (OS) 510.

[0132] The OS 510 manages the 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 the fixed storage device 410 to the memory 406) for execution by the system 500. Applications or other software intended for use on the device 400 can also be stored as a downloadable set of computer-executable instructions, e.g., for downloading and installation from an Internet location (e.g., a web server, an app store, or other online service).

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

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

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

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

[0137] In other cases, the guest operating system can be specifically designed or configured to execute on the VMM 530 for increased efficiency. In these cases, the guest operating system "knows" that it is executing on the virtual machine monitor. In other words, in some cases, the VMM 530 can provide para-virtualization to the guest operating system.

[0138] The basic computer hardware and software described above are given 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. Instead, the example embodiment(s) can be implemented in any type of system architecture or processing environment that those skilled in the art will understand, based on the present disclosure, to be capable of supporting the features and functions presented in the example embodiment(s) herein.

[0139] Extensions and Alternatives

[0140] Although some of the flowcharts included in the foregoing specification include 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. Additionally, some steps can be optional, can be performed multiple times, and / or can be performed by different components. All of the steps, operations, and functions in the flowcharts described herein are intended to indicate operations performed by programming in a special-purpose computer or a general-purpose computer. In other words, each flowchart in the present disclosure, in combination with the relevant text herein, is a guide, plan, or specification for programming a computer to perform the described functions, either in whole or in part. The level of skill in the art associated with the present disclosure is known to be high, and thus the flowcharts and relevant text in the present disclosure have been prepared to convey information about the programs, algorithms, and their implementations with the level of adequacy and detail that those skilled in the art would typically expect in the field.

[0141] In the foregoing specification, the example embodiment(s) of the present disclosure have been described with reference to numerous specific details. However, the details can vary depending on the requirements of the current particular implementation. Thus, the example embodiment(s) should be considered illustrative rather than restrictive.< / op> < / op> < / char> < / char> < / literal> < / digit> < / parameter> < / operator> < / literal> < / parameter> < / token> < / token>

Claims

1. A method for processing database commands, comprising: receiving, at a driver component, a database command from a client application, wherein the driver component has access to a cache including database command entries; wherein the database command has a corresponding shard key expression; determining whether the database command matches any of the database command entries in the cache; in response to the database command matching an existing database command entry in the cache, the driver component retrieving the corresponding shard key expression from the existing database command entry; in response to the database command not matching any of the database command entries in the cache: requesting the corresponding shard key expression for the database command; in response to requesting the corresponding shard key expression, receiving the corresponding shard key expression of the database command; storing, in the cache, a new database command entry for the database command, wherein the stored new database command entry associates the database command with the corresponding shard key expression; evaluating the corresponding shard key expression to determine a shard key value, wherein the corresponding shard key expression includes at least one of a bind variable or an operator; identifying a specific shard of a sharded database system based on the shard key value; and connecting to the specific shard to execute the database command.

2. The method according to claim 1, further comprising: in response to the database command not matching any of the database command entries in the cache: parsing, by the driver component, the database command to create a parsed representation of the database command; and generating, by the driver component, the corresponding shard key expression of the database command based on the parsed representation of the database command.

3. The method according to claim 1, further comprising: in response to the database command not matching any of the database command entries in the cache: providing, by the driver component, the database command to a shard director, wherein the shard director remotely executes on the client application; parsing, by the shard director, the database command to create a parsed representation of the database command; generating, by the shard director, the corresponding shard key expression of the database command based on the parsed representation of the database command; and providing, by the shard director, the corresponding shard key expression to the driver component for storing a new database command entry associating the database command with the corresponding shard key expression.

4. The method according to claim 1, wherein: the existing database command entry corresponds to a transformed version of the database command including one or more bind variables replacing one or more literal values; the one or more bind variables include the bind variables of the corresponding shard key expression.

5. The method according to claim 1, wherein storing the new database command entry for the database command in the cache further comprises: generating a transformed version of the database command including one or more bind variables replacing one or more literal values; and wherein the new database command entry in the cache corresponds to the transformed version of the database command, and the one or more bind variables include the bind variables of the corresponding shard key expression.

6. The method according to claim 1, Wherein: The corresponding shard key expression used to determine the shard key value includes at least one of the following: Replacing the bound variable with a literal value, or Evaluating the operator.

7. The method according to claim 1, wherein the database command is a Structured Query Language (SQL) command.

8. The method according to claim 1, wherein connecting to the specific shard to execute the database command includes the driver component directly connecting to the specific shard without routing the database command through the shard director.

9. The method according to claim 1, further including: Receiving, at the driver component, a second database command from a client application; Determining that the second database command is a multi-shard database command; and In response to determining that the second database command is a multi-shard database command, processing the second database command using the shard director.

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

11. A system including one or more computing devices, the computing devices including components at least partially implemented by computing hardware configured to implement the method according to any one of claims 1-9.

Images