CN109947768A - local identifier for database objects - Google Patents

Abstract

Various examples are directed to systems and methods for utilizing local identifiers in distributed database systems. The database management system server may receive first execution unit data describing the first execution unit of the first database query. The first execution unit data may include first operand metadata describing a set of operands for the first execution unit. The database management system server may determine that the first operand metadata describes at least one operand from the first partition and at least one operand from the second partition. The database management system server may generate a first set of local identifiers describing rows at the first partition and a first set of local identifiers describing rows at the second partition. The database management system server may execute the first execution unit based at least in part on the first set of local identifiers describing the row at the first partition and the first set of local identifiers describing the row at the second partition.

Description

local identifier for database objects

technical field

This document generally relates to methods and systems for use with computer devices, including networked computing devices. More specifically, this document relates to systems and methods for efficiently performing database queries.

Background technique

In a distributed database system, the database is divided into multiple partitions. For example, a single table can be divided into two or more partitions. Partitions can be transportable between different database management system servers. For example, a single database management system server may be responsible for a set of partitions, which may include a portion of the partitions that make up a particular table. Distributed database systems typically utilize a system of globally unique identifiers to refer to database objects such as tables, slices, rows, and the like.

Description of drawings

The present disclosure is illustrated by way of example and not limitation in the following figures.

1 is a diagram illustrating one example of a distributed database system for generating and using local identifiers for database objects.

2 is a flowchart illustrating one example of a process flow that may be executed by a database management system (DBMS) server of a distributed database system to execute an execution unit having a local identifier.

3 is a flowchart illustrating one example of a process flow that may be executed by a DBMS server of a distributed database system to execute an execution unit using an existing set of local identifiers.

4 is a flow diagram illustrating one example of a process flow that may be executed by a DBMS server of a distributed database system to execute an execution unit with an index of local identifiers.

5 is a diagram illustrating an example of an in-memory database management system that may be used to implement a web application in some examples of the network virtualization systems and methods described herein.

FIG. 6 is a diagram illustrating an example of the indexing server of FIG. 5 .

FIG. 7 is a diagram illustrating one example of request processing and execution control of FIG. 6 .

8 is a block diagram illustrating one example of a software architecture of a computing device.

9 is a block diagram of a machine in the example form of a computer system within which instructions are executable to cause the machine to perform any one or more of the methods discussed herein.

Detailed ways

The description that follows includes exemplary systems, methods, techniques, instruction sequences, and computing machine program products embodying the exemplary embodiments. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. However, it will be apparent to those skilled in the art that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known instruction instances, protocols, structures and techniques have not been shown in detail.

Various examples described herein are directed to generating and/or using local identifiers for database objects, eg, in a distributed database system. In many examples, globally unique identifiers (global identifiers) in a distributed database system are not necessarily sequentially assigned to objects within one or more particular partitions. That is, successive slices, rows, etc. may not necessarily have successive global identifiers. For example, in some distributed database systems, global identifiers are assigned by the global sequencer. Global identifiers may be assigned to objects across the distributed database system, eg, in the order in which the objects were created. As a result, knowing the global identifier of a database object in a distributed database system may not provide any information about surrounding objects. Additionally, because the unique global identifier is used for a large number of objects (eg, all objects in a distributed database system), the size of the global identifier can be large.

Global identifiers can be used by distributed database management systems to access specific database objects. For example, global identifiers can be translated into addresses of corresponding objects (eg, primary keys of rows, ranges of primary keys of slices, etc.). Because of the large number of global identifiers that may be used in a distributed database system, a mapping data structure such as a hash map can be used to map global identifiers to corresponding object addresses. For example, to find the address of a database object associated with a particular global identifier, a distributed database management system utilizes a map lookup to obtain the associated physical address from a map structure. However, when the number of global identifiers in a distributed database system is large, map lookup operations can be computationally expensive and inefficient.

Accordingly, various examples described herein utilize local identifiers. The distributed database management system may assign local identifiers to objects in one or more partitions that include operands for a particular execution unit. An execution unit can be any discrete database operation. For example, a database query may include one or more execution units. In some examples, an execution unit may be executed by a single database management system server, eg, on a partition managed by a single database management system server.

In some examples, the distributed database management system (eg, its database management system server) generates a local-to-global mapping that maps global identifiers to appropriate local identifiers. In some examples, for a given partition and execution unit, local identifiers are extracted from a contiguous range of values. In this way, successive objects (eg, successive rows, successive slices, etc.) within a partition may be assigned successive local identifiers. In some examples, the local identifier is maintained at least until execution of the execution unit completes. Because only a small subset of all global identifiers are typically used in any given query or its execution unit, local identifiers can be efficiently mapped to global identifiers and/or physical addresses at runtime, such as direct access lists or Array to implement local to global mapping.

In some examples, it may be desirable to reuse a set of local identifiers from the first execution unit for a second (eg, related) execution unit and/or to rapidly generate a set of local identifiers for the second execution unit. For example, the second execution unit may accept one or more operands as a result of the first execution unit. For example, a database query may include a view operation requesting the names of customers in a first city who placed orders on the first day. The first execution unit may operate on one or more partitions of the order form to identify orders submitted on the first day. The second execution unit may operate on the identified orders to determine which were submitted by customers in the first city. Thus, the second execution unit operates on a subset of the partitions operated on by the first execution unit. In some examples, the distributed database management system generates the second set of local identifiers for the second execution unit by applying one or more partition offsets to the set of local identifiers generated for the first execution unit.

FIG. 1 is a diagram illustrating one example of a distributed database system 100 for generating and using local identifiers for database objects. The distributed database system 100 includes a distributed database management system 102 . Distributed database management system 102 may manage distributed database system 100, eg, including executing its queries and/or execution units using local identifiers as described herein. The distributed database management system 102 may include one or more DBMS servers 104A, 104B, 104N. The DBMS servers 104A, 104B, 104N may manage one or more partitions of one or more tables of the distributed database system 100 . In some examples, different DBMS servers 104A, 104B, 104N manage different partitions or different sets of partitions. Additionally, in some examples, management of one or more partitions may be transferred from one DBMS server 104A, 104B, 104N to another. Each DBMS server 104A, 104B, 104N may include one or more physical computing devices, eg, at a common physical location (eg, a server farm, etc.). The different DBMS servers 104A, 104B, 104N may be located in the same physical location or in different physical locations.

FIG. 1 also shows example tables 106 , 110 of the distributed database system 100 that may be managed by the distributed database management system 102 . Although two tables 106 , 110 are shown in FIG. 1 , in practice a distributed database system such as distributed database system 100 may utilize a scheme using additional tables. Tables 106, 110 include respective partitions. For example, table 106 includes partitions 108A, 108B, 108N, and table 110 includes partitions 112A, 112B, 112N. Although three partitions are shown for each table 106, 110, the table may be divided into any suitable number of partitions. For example, table 106 has a different number of partitions than table 110 in some examples. Responsibility for managing the various partitions 108A, 108B, 108N, 112A, 112B, 112N may be assigned to one or more of the DBMS servers 104A, 104B, 104N. For example, partition 108A may be managed by DBMS server 104A; partition 108B may be managed by DBMS server 104B, and so on. Partitions 108A, 108B, 108N, 112A, 112B, 112N may be of different sizes, eg, with different numbers of rows and/or different data sizes.

FIG. 1 also illustrates local identifiers that may be generated and/or used by DBMS servers 104A, 104B, 104N to execute one or more execution units at distributed database system 100 . In some examples, one or more DBMS servers 104A, 104B, 104N assign partition identifiers 114A, 114B, 114C, 116A, 116B, 116C. Partition identifiers can be assigned to partitions sequentially. For example, the first row at a partition can be assigned a first number, the second row at that partition can be assigned the following integer, the third row at the partition can be assigned the next integer, and so on depending on And so on.

From the partition identifier for a partition, the DBMS server 104A, 104B, 104N can generate a local identifier for a given execution unit. For example, the DBMS servers 104A, 104B, 104N may receive execution unit data describing the execution units to execute. The DBMS server 104A, 104B, 104N may identify a partition that includes operands for the execution unit. In the example of FIG. 1, partitions 108A and 108N from table 106 and partition 112A from table 110 include operands for the example execution units. The DBMS servers 104A, 104B, 104N may utilize the partition identifiers to generate local identifiers for execution units. For example, DBMS servers 104A, 104B, 104N may generate local-to-global mappings 118 . The local identifier for any given row can be determined by adding the partition offset to the partition identifier for that row. The partition offset for a partition may indicate the number of rows added to the partition of the local-to-global map 118 before the partition. In the example of FIG. 1, the partition offset (POS1) of partition 108A is zero; the partition offset (POS3) of partition 108N is equal to the number of rows in partition 108A; and the partition offset (POS3) of partition 112A Equal to the sum of the number of rows in partitions 108A and 108N. The local-to-global mapping 118 may map local identifiers to corresponding global identifiers (indicated by G1-G9 in FIG. 1) and/or to addresses of corresponding rows.

In various examples, DBMS servers 104A, 104B, 104N may utilize local identifiers generated for one execution unit to generate a second set of local identifiers for a second execution unit, eg, using a partition offset. For example, consider one execution unit that utilizes operands from partitions 108A and 112A but not operands from partition 108N. DBMS servers 104A, 104B, 104N may generate new local-to-global mappings similar to 118 starting from neutral identifiers 114A and 116A. For example, the partition offset for the local identifier of partition 112A may indicate the number of rows in partition 108A.

In some examples, the neutral identifier may be omitted, and the DBMS server 104A, 104B, 104N may convert the local-to-global mapping 118 into a new local-to-global mapping 118 for the second execution unit. Returning to the last example, DBMS servers 104A, 104B, 104N may delete entries from local-to-global map 118 corresponding to partitions that do not include operands for the second execution unit (eg, partition 108N in FIG. 1 ) . A new partition offset may be found for the partition that includes the operand for the second execution unit.

In the example of FIG. 1, neutral identifiers and local identifiers are assigned to partitions 108A, 108B, 108N, 112A, 112B, 112N by row. However, in some examples, local identifiers may also be assigned to slices. For example, a slice may include a predetermined number of rows (eg, 128k rows, 64k rows, etc.). The size of the slice may be indicated by the schema or other metadata describing the distributed database system. In other examples, different DBMS servers 104A, 104B, 104N may apply different slice sizes. In some examples, slices may also be assigned neutral identifiers and/or local identifiers. For example, a neutral identifier for a row in a particular slice may be indicated by a slice neutral identifier and an offset indicating the position of the object in the slice.

2 is a flowchart illustrating one example of a process flow 200 executable by a DBMS server of a distributed database system (eg, one of DBMS servers 104A, 104B, 104N) to execute an execution unit having a local identifier. At operation 202, the DBMS server receives execution unit data describing the execution unit. The execution unit may be an execution unit to be executed at the DBMS server. For example, an execution unit may constitute all or a portion of a query to be executed at the distributed database system. Execution unit data may include operand metadata describing operands for the execution unit. Operands include one or more rows from one or more partitions managed by the DBMS server that are to be operated on to execute the execution unit.

At operation 204, the DBMS server may determine whether the operands described by the execution unit data are stored at multiple partitions (eg, multiple partitions managed by the DBMS server). If not (eg, if the operand for the execution unit is at a single partition), the DBMS server may in operation generate a local identifier for that single partition. Generating a local identifier for a single partition may, for example, include sequentially enumerating all or a portion of the rows, slices, etc. at the single partition. For example, when there is a single partition, the local identifier may be similar to the neutral identifier described herein with respect to FIG. 1 .

If the operands for the execution unit are stored at multiple partitions, the DBMS server may generate local identifiers for the set of multiple partitions in operation 208 . The DBMS may generate local identifiers in any suitable manner. For example, the DBMS server may generate neutral identifiers for each partition of the set of partitions. The DBMS server can then concatenate neutral identifiers for these partitions. For example, as described with respect to Figure 1, the DBMS server may add a partition offset to each neutral identifier. The partition offset for each partition may be equal to the sum of the objects (eg, rows, slices, etc.) in the partition with the lower partition offset (eg, the partition that has been assigned a local identifier). In another example, instead of generating neutral identifiers, the DBMS server may assign successive local identifiers to objects at the set of partitions, eg, starting with objects in a first partition, followed by objects in a second partition, etc. and so on.

At operation 210 , the DBMS server may execute the execution unit based at least in part on the local identifier generated at operation 206 and/or at operation 208 . For example, the DBMS server may utilize a local-to-global mapping (eg, mapping 118 of FIG. 1 ) to translate between object names and global identifiers indicated by execution unit data.

3 is a flowchart illustrating one example of a process flow 300 that may be executed by a DBMS server of a distributed database system (eg, one of DBMS servers 104A, 104B, 104N) to execute an execution unit using an existing set of local identifiers . For example, process flow 300 may be executed after process flow 200 of FIG. 2 . At operation 304, the DBMS server may receive next execution unit data describing a next execution unit to be executed by the DBMS server. In some examples, the next execution unit is part of the same database query as the previous execution unit.

At operation 304, the DBMS server may determine whether the next execution unit has operands at a different set of partitions than the set of partitions used by the previous execution unit. If not (eg, if the next execution unit uses operands from the same set of partitions as the previous execution unit), the DBMS server may execute the execution unit at operation 306 using the local identifier previously generated for the previous execution unit.

If the next execution unit has operands at a different set of partitions than the set of partitions used by the previous execution unit, the DBMS server may derive the next set of local identifiers from the existing set of local identifiers at operation 308 symbol. This may include, for example, removing from the existing set of local identifiers any local identifiers corresponding to partitions that do not include operands for the next execution unit. The partition offsets for the remaining local identifiers can be modified. Rows from common partitions can also have common offsets. Additionally, if there are any partitions to include that are not considered in the existing set of local identifiers, the local identifiers for these partitions may be added, for example, with the newly generated partition offset. The DBMS server at operation 310 may utilize the next set of local identifiers to execute the next execution unit. In some examples, the DBMS server may add the offset difference value to the local identifier from the previous set of local identifiers to derive the next set of local identifiers. The offset difference for a row can be the difference between the partition offset used for the row in the previous set of local identifiers and the partition offset used for the row in the next set of local identifiers .

4 is a flowchart illustrating one example of a process flow 400 that may be executed by a DBMS server of a distributed database system (eg, one of DBMS servers 104A, 104B, 104N) to execute an execution unit using an index of local identifiers. At operation 402, the DBMS server may generate an index referencing at least two partitions. The index may, for example, map rows or other objects from one or more partitions to rows or objects at one or more other partitions. Indexes can be used, for example, to improve the efficiency with which a DBMS server executes execution units. For example, join indexes may be used by the DBMS server to speed up and/or simplify the execution of join queries and/or execution units. Utilizing local identifiers in an index allows the DBMS server to determine relationships between different rows or other objects without finding global identifiers for those objects.

At operation 404, the DBMS server may receive first execution unit data describing the first execution unit. At operation 406 , the DBMS server may generate a first execution unit index from the index generated at operation 402 . This may include, for example, updating the index to refer (eg, only) to the local identifier at the partition that includes the operand for the first execution unit. For example, the DBMS server may determine which partition or partitions contain operands for the first execution unit. The local identifier may, for example, be removed from and/or added to the index such that the index includes the relationship between the set of partitions associated with the first execution unit. Partitions including operands for the first execution unit may be assigned consecutive local identifiers. For example, a partition offset for the local identifier at the set of partitions of the first execution unit may be generated. These partition offsets can be used to update the partition offset previously used by the local identifier at this index. At operation 408, the DBMS server may utilize the updated index to execute the first execution unit.

At operation 410, the DBMS system may receive second execution unit data describing the second execution unit, including, for example, operands for the second execution unit. At operation 412, the DBMS may generate an updated index for the second execution unit index from an existing index (eg, from the updated index generated at operation 402 and/or from the first execution unit index). Generating the second execution unit index may include, for example, adding and/or removing partitions from a previous index, modifying partition offsets based on the addition or subtraction of partitions, and the like. At operation 414, the DBMS system may execute the second execution unit using the second execution unit index.

To further illustrate the use of local identifiers for database objects, as described herein, consider an example of a DBMS server managing four partitions labeled A-D with example rows indicated by Tables 1-4 below. Tables 1-4 show global identifiers for rows at partitions A-D and example neutral identifiers for those rows. For example, the DBMS server as described herein may assign neutral identifiers to these rows, eg, before and/or after execution unit data is received.

Form 1: Partition A

row global id Row Neutral ID 1000 0 2452 1 3699 2 4721 3

Form 2: Partition B

row global id Row Neutral ID 1111 0 2222 1 3333 2

Form 3: Partition C

row global id Row Neutral ID 4444 0 5555 1 6666 2

Table 4: Partition D

row global id Row Neutral ID 1484 0 1792 1 1801 2

Next, consider the first execution unit that includes operands from all four partitions. The DBMS server may assign local identifiers to rows of partitions A-D, eg, the result is a local-to-global mapping indicated by Table 5 below.

Table 5: Local to global mapping

In this example, the four rows of partition A are assigned local identifiers 0-3. The three rows of partition B are assigned local identifiers 4-6. The partition offset for partition B is 4, indicating the number of rows in partition A (preceding partition B). The partition offset for partition C is 7, indicating the sum of the rows in partitions A and B. Similarly, the partition offset of partition D is 10, indicating the sum of the rows in partitions A, B, and C. Although small numbers are utilized in this example for demonstration purposes, in various example distributed database systems, the size of the global and/or local identifiers may be large enough that considerations regarding storage and processing power become relevant. In one example, the global identifier may be 256 bits, while the local identifiers for execution units may be much smaller (eg, 8 bits, 16 bits, 32 bits, etc.). This may allow for increased efficiency in executing queries and their execution units.

The first execution unit may be or be part of a join query. Therefore, the DBMS server can generate the join index. For example, partitions C and D may be connected as shown in Table 6 below. Form 6

The same connection index expressed using the local identifier as set forth at the local to global mapping of Table 5 is provided by Table 7 below:

Form 7

The same join index expressed in terms of neutral identifiers can be found by subtracting the respective partition offsets from the local identifier (eg, 7 for partition C, 10 for partition D). This produces Form 8:

Form 8:

The DBMS server may utilize, for example, the join index of Table 7 and/or the join index of Table 8 to execute the first execution unit.

Now consider a second execution unit that includes only operands from partitions A, C, and D (eg, no operands for the second execution unit from partition B). The local-to-global mapping for the second execution unit is shown in Table 9 below:

Table 9: Local to global mapping

As shown, since partition B is omitted, the partition offsets for partitions C and D are changed to 4 and 7, respectively. In some examples, the DBMS server may adjust the join index from the first execution unit for use with the set of local identifiers for the second execution unit, such as shown in Table 10 below:

Form 10

FIG. 5 is a diagram illustrating an example of an in-memory database management system 500 . For example, database management system 500 may describe an implementation at a DBMS server such as those described herein. In-memory databases store data primarily at main memory, such as random access memory (RAM). This is different from databases that mainly use disk storage mechanisms. In some examples, database management system 500 may be or may include an example of the HANA system from SAP SE of Walldorf, Germany. Although various features of web applications are described herein in the context of an in-memory database, web application security for service personnel as described herein can generally be implemented for any type of web application.

The in-memory database management system 500 may be coupled to one or more client applications 502A, 502B. Client applications 502A, 502B may utilize data from the database to perform one or more queries, such as presenting a user interface (UI) to one or more users, entering data, accessing data, and the like. Client applications 502A, 502B can communicate with in-memory database management system 500 through a variety of different protocols, including SQL, Multidimensional Expressions (MDX), Hypertext Transfer Protocol (HTTP), Representational StateTransfer , REST), Hypertext Markup Language (HTML).

FIG. 5 also shows a studio 504 that can be used to perform modeling by accessing the in-memory database management system 500 . In some examples, studio 504 may allow complex analysis to be performed on data extracted not only from real-time event data and windows, but also from stored database information. In-memory database management system 500 may include several different components, including index server 506 , XS engine 508 , statistics server 510 , preprocessor server 512 , and name server 514 . These components may operate on a single computing device or may be distributed among multiple computing devices (eg, separate servers). Index server 506 contains the actual data and an engine for processing the data. It also coordinates and uses other servers.

The XS engine 508 allows clients to connect to the in-memory database management system 500 using a web protocol (eg, HTTP). Although XS engine 508 is illustrated as a component of in-memory database management system 500 , in some examples, XS engine 508 may be implemented as one or more applications located between client applications 502A, 502B and in-memory database management system 500 Interface (Application Program Interface, API) and/or service. For example, XS engine 508 may be configured to process client requests received in languages other than SQL, such as MDX, HTTP, REST, HTML, and the like.

Statistics server 510 collects information about status, performance and resource consumption from all other server components. Statistics server 510 may be accessed from studio 504 to obtain the status of various alarm monitors.

The preprocessor server 512 is used to analyze the textual data and extract information on which the textual search capabilities are based.

The name server 514 maintains information about the database topology. This is used in distributed systems with instances of the database on different hosts. The name server 514 knows where components run and what data resides on which server. In an example embodiment, a single enqueue server may operate in the manner described above for the enqueue server, in particular with respect to creating and managing lightweight enqueue sessions.

FIG. 6 is a diagram illustrating an example of the index server 506 . Specifically, the index server 506 of FIG. 5 is depicted in greater detail. Index server 506 includes connection and session management component 600, which is responsible for creating and managing sessions and connections for database clients (eg, client applications 502A, 502B). Once the session is established, the client can communicate with the database management system 500 using SQL statements. For each session, a set of session parameters 602 may be maintained, such as autocommit, current transaction isolation level, and the like. Users (eg, system administrators, developers) can be authenticated by database management system 500 itself (eg, by logging in with login information such as username and password using authentication component 604), or authentication can be delegated to an external authentication provider, For example, a Lightweight Directory Access Protocol (LDAP) directory.

Client queries may be analyzed and executed by a set of components summarized as request processing and execution control 606 . SQL processor 608 examines the syntax and semantics of client SQL statements and generates a logical execution plan. In some examples, generating the logical execution plan includes generating and/or utilizing local identifiers for partition objects as described herein. For example, generating a logical execution plan may include executing some or all of the process flows 200, 300, 400 described herein. MDX is a language for querying and manipulating multidimensional data stored in online analytical processing (OLAP) cubes. As such, an MDX engine 610 may be provided to allow parsing and execution of MDX commands. The planning engine 612 allows applications to perform basic planning operations in the database layer. One such operation is to create a new version of the dataset as a copy of the existing dataset, while applying filters and transformations.

The calculation engine 614 implements various SQL scripts and planning operations. The computation engine 614 creates logical execution plans for computation models derived from SQL scripts, MDX, plans, and domain-specific models. This logical execution plan may include, for example, decomposing the model into operations that can be processed in parallel. Data is stored in relational store 616, which implements a relational database in main memory. Each SQL statement can be processed in the context of a transaction. New sessions are implicitly assigned to new transactions. Transaction manager 618 coordinates database transactions, controls transactional isolation, and keeps track of running and closed transactions. When a transaction is committed or rolled back, the transaction manager 618 notifies the involved engines about this event so that they can perform the required action. Transaction manager 618 also cooperates with persistence layer 620 to implement atomic and durable transactions.

The authorization manager 622 is called by other database system components to check whether the user has the specified authority to perform the requested operation. Database management system 500 allows permissions to be granted to users or roles. A permission grants the right to perform the specified action on the specified object.

Persistence layer 620 ensures that the database is restored to the most recently committed state after a restart and that transactions are either fully executed or fully undone. To achieve this goal in an efficient manner, the persistence layer 620 uses a combination of write-ahead journaling, shadow paging, and savepoints. Persistence layer 620 also provides a page management interface 624 for writing and reading data to and from separate disk storage 626, and also contains a logger 628 that manages transaction logs. Log entries may be written by persistence layer 620 either implicitly by persistence layer 620 when data is written via the persistence interface, or explicitly by utilizing the log interface.

FIG. 7 is a diagram illustrating one example of request processing and execution control 606 . This figure depicts the request processing and execution control 606 of FIG. 6 in greater detail. SQL processor 608 includes SQL parser 700 that parses SQL statements and generates a logical execution plan 702 which SQL parser 700 passes to SQL optimizer 704 . SQL optimizer 704 optimizes logical execution plan 702 and converts it into physical execution plan 706 , which is then passed to SQL executor 708 . Compute engine 614 implements various SQL scripts and planning operations, and includes a compute engine optimizer 710 that optimizes operations and a compute engine executor 712 that executes operations, as well as native compute engine operators 714, L operators 716, and R operators 718.

L infrastructure 720 includes several components to assist in the running of L programs, including L runtime (system mode) 722 , L compiler 724 , and L runtime (user mode) 726 .

Example :

Example 1 is a database management system server of a distributed database system, the database management system server including a processor and a memory in communication with the processor, wherein the database management system server is programmed to perform operations comprising: receiving a description of a first First execution unit data of the first execution unit of the database query, the first execution unit data includes first operation metadata describing a set of operands for the first execution unit; the first operation metadata is determined by the database management system server describing at least one operand from a first partition of the distributed database system and at least one operand from a second partition of the distributed database system; a first set of local identifiers describing rows at the first partition are generated by the database management system server identifier; generating, by the database management system server, a first set of local identifiers describing the row at the second partition; and based at least in part on the first set of local identifiers describing the row at the first partition and the identifier describing the row at the second partition the first set of local identifiers to execute the first execution unit at the distributed database system.

In Example 2, the subject matter of Example 1 optionally includes wherein the database management system server is further programmed to perform operations comprising: receiving second execution unit data describing a second execution unit, the second execution unit data comprising describing second operand metadata for a set of operands of the second execution unit; determining that the second operand data describes at least one operand from the first partition; adding a first offset to a local identifier selected from the identifiers to generate a second set of local identifiers describing the row at the first partition; and generating a second set of local identifiers describing the row at the first partition based at least in part on the second set of local identifiers describing the row at the first partition A second execution unit is executed at the distributed database system.

In Example 3, the subject matter of Example 2 optionally includes wherein the second operand metadata also describes at least one operand from a third partition of the distributed database system, wherein the first partition and the third partition are part of a common table .

In Example 4, the subject matter of any one or more of Examples 1-3 optionally includes wherein the database management system server is further programmed to perform execution comprising generating at least a portion of the row associated with the first partition and the row at the second partition An operation of indexing at least a portion of the index, wherein the indexing is based at least in part on the first set of local identifiers.

In Example 5, the subject matter of Example 4 optionally includes wherein the database management system server is further programmed to perform operations comprising: receiving a first operation metadata including second operation metadata describing a set of operands for the second execution unit two execution units; determining that second operand metadata describes at least one operand from the first partition; generating an updated index at least in part by adding a first offset difference to a first local identifier of the index, wherein the first The offset difference is a difference between the partition offset of the first partition from the first set of local identifiers and the partition offset of the first partition of the second set of local identifiers; and based at least in part on the The updated index is used to execute the second execution unit at the distributed database system.

In Example 6, the subject matter of any one or more of Examples 1-5 optionally includes wherein the first local identifier describing the first set of local identifiers for the row at the first partition includes indicating the row at the first partition. The slice identifier of the slice and a row offset indicating the offset of the first row at the first partition.

In Example 7, the subject matter of any one or more of Examples 1-6 optionally includes wherein the first local identifier that describes the first set of local identifiers for the row at the first partition includes indicating a partition neutral identifier and a second portion indicating the partition offset of the first execution unit of the first partition.

In Example 8, the subject matter of any one or more of Examples 1-7 optionally includes wherein the database management system server is further programmed to perform operations comprising: receiving second execution unit data describing the second execution unit, the second execution unit data includes second operand metadata describing a set of operands for the second execution unit; determining that the second operand data describes at least one operand from the first partition; based at least in part on the second execution unit partition offsets to generate a second set of local identifiers describing the row at the first partition; and executing a second execution unit at the distributed database system based at least in part on the second set of local identifiers describing the row at the first partition .

Example 9 is a method of executing a database query in a distributed database management system, the method comprising: receiving, by a database management system server, first execution unit data describing a first execution unit of a first database query, the first execution unit data including first operation metadata describing a set of operands for the first execution unit; the first operation metadata is determined by the database management system server to describe at least one operand from the first partition of the distributed database system and from the distributed database system. at least one operand of a second partition of the database system; a first set of local identifiers describing rows at the first partition is generated by the database management system server; a first set of local identifiers describing rows at the second partition is generated by the database management system server a local identifier; and executed by the database management system server at the distributed database system based at least in part on a first set of local identifiers describing rows at the first partition and a first set of local identifiers describing rows at the second partition first execution unit.

In Example 10, the subject matter of Example 9 optionally includes receiving, by a database management system server, second execution unit data describing a second execution unit, the second execution unit data including a set of operands describing a set of operands for the second execution unit second operational metadata; it is determined by the database management system server that the second operational metadata describes at least one operand from the first partition; by the database management system server at least in part by passing to the first set of partials from the row describing the row at the first partition adding a first offset to a local identifier selected from the identifiers to generate a second set of local identifiers describing the row at the first partition; and by the database management system server based at least in part on the second set of local identifiers describing the row at the first partition the group local identifier to execute the second execution unit at the distributed database system.

In Example 11, the subject matter of Example 10 optionally includes wherein the second operand metadata also describes at least one operand from a third partition of the distributed database system, wherein the first partition and the third partition are part of a common table .

In Example 12, the subject matter of any one or more of Examples 9-11 optionally includes generating, by the database management system server, an index that associates at least a portion of the row at the first partition with at least a portion of the row at the second partition, wherein the index is based at least in part on the first set of local identifiers.

In Example 13, the subject matter of Example 12 optionally includes receiving, by a database management system server, a second execution unit including second operational metadata describing a set of operands for the second execution unit; determining by the database management system server second operand metadata describes at least one operand from the first partition; the updated index is generated by the database management system server at least in part by adding a first offset difference to a first local identifier of the index, wherein the first the offset difference is the difference between the partition offset of the first partition from the first set of local identifiers and the partition offset of the first partition of the second set of local identifiers; and by the database management system The server executes the second execution unit at the distributed database system based at least in part on the updated index.

In Example 14, the subject matter of any one or more of Examples 9-13 optionally includes wherein the first local identifier that describes the first set of local identifiers for the row at the first partition includes indicating that the row at the first partition The slice identifier of the slice and a row offset indicating the offset of the first row at the first partition.

In Example 15, the subject matter of any one or more of Examples 9-14 optionally includes wherein the first local identifier that describes the first set of local identifiers for the row at the first partition includes indicating a partition neutral identifier and a second portion indicating the partition offset of the first execution unit of the first partition.

In Example 16, the subject matter of any one or more of Examples 9-15 optionally includes receiving, by the database management system server, second execution unit data describing the second execution unit, the second execution unit data including the description for the first execution unit second operation metadata for a set of operands of two execution units; the second operation metadata is determined by the database management system server to describe at least one operand from the first partition; the second operation unit partition is determined by the database management system server at least in part based on the second execution unit an offset to generate a second set of local identifiers describing the row at the first partition; and generating a second set of local identifiers at the distributed database system by the database management system server based at least in part on the second set of local identifiers describing the row at the first partition Execute the second execution unit.

Example 17 is a machine-readable medium including instructions stored thereon that, when executed by at least one processor, cause at least one processor to perform operations comprising: receiving a description of a first at a distributed database system First execution unit data of the first execution unit of the database query, the first execution unit data includes first operation metadata describing a set of operands for the first execution unit; determining that the first operation metadata description is from a distributed database at least one operand of a first partition of the system and at least one operand from a second partition of the distributed database system; generating a first set of local identifiers describing rows at the first partition; generating rows describing rows at the second partition and executing the first execution unit based at least in part on the first set of local identifiers describing the row at the first partition and the first set of local identifiers describing the row at the second partition.

In Example 18, the subject matter of Example 17 optionally includes wherein the machine-readable medium further includes instructions stored thereon that, when executed by the at least one processor, cause the at least one processor to execute an The operation of: receiving second execution unit data describing the second execution unit, the second execution unit data including second operation metadata describing a set of operands for the second execution unit; determining that the second operation metadata description is from the at least one operand of a partition; generating a th two sets of local identifiers; and executing the second execution unit at the distributed database system based at least in part on the second set of local identifiers describing the row at the first partition.

In Example 19, the subject matter of Example 18 optionally includes wherein the second operand metadata also describes at least one operand from a third partition of the distributed database system, wherein the first partition and the third partition are part of a common table .

In Example 20, the subject matter of any one or more of Examples 17-19 optionally includes wherein the machine-readable medium further includes instructions stored thereon that, when executed by the at least one processor, cause the at least one The processor performs operations including generating an index that associates at least a portion of the row at the first partition with at least a portion of the row at the second partition, wherein the index is based at least in part on the first set of local identifiers.

8 is a block diagram 800 illustrating one example of a software architecture 802 of a computing device. Architecture 802 may be used in conjunction with various hardware architectures such as those described herein. Figure 8 is only a non-limiting example of a software architecture, and many other architectures may be implemented to facilitate the functionality described herein. A representative hardware layer 804 is illustrated and may represent, for example, any of the computing devices mentioned above. In some examples, hardware layer 804 may be implemented according to the architecture of computer system 900 of FIG. 9 .

The representative hardware layer 804 includes one or more processing units 806 with associated executable instructions 808 . Executable instructions 808 represent executable instructions for software architecture 802, including implementations of the methods, modules, subsystems, and components, etc. described herein, and may also include memory and/or storage module 810, memory and/or storage module 810 There are also executable instructions 808 . Hardware layer 804 may also include other hardware as indicated by other hardware 812 , which may represent any other hardware of hardware layer 804 , such as the other hardware illustrated as part of computer system 900 .

In the example architecture of FIG. 8, software architecture 802 may be conceptualized as a stack of layers, where each layer provides specific functionality. For example, software architecture 802 may include layers such as operating system 814 , libraries 816 , frameworks/middleware 818 , applications 820 , and presentation layer 844 . Operationally, application 820 and/or other components within the layer may invoke API call 824 through the software stack and in response to API call 824 access responses shown as messages 826, returned values, and the like. The illustrated layers are representative, and not all software architectures have all layers. For example, some mobile or specialized operating systems may not provide framework/middleware 818, while others may provide such a layer. Other software architectures may include additional or different layers.

Operating system 814 can manage hardware resources and provide common services. Operating system 814 may include, for example, kernel 828 , services 830 , and drivers 832 . Kernel 828 may act as an abstraction layer between hardware and other software layers. For example, the kernel 828 may be responsible for memory management, processor management (eg, scheduling), component management, networking, security settings, and the like. Services 830 may provide other common services for other software layers. In some examples, servicing 830 includes interrupt servicing. The interrupt service may detect receipt of an interrupt and, in response, cause the architecture 802 to suspend its current processing and execute an interrupt service routine (ISR) when the interrupt is accessed.

Driver 832 may be responsible for controlling or interfacing with the underlying hardware. For example, depending on the hardware configuration, drivers 832 may include display drivers, camera drivers, drives, flash drives, serial communication drives (eg, Universal Serial Bus (USB) drives), Drivers, NFC Drivers, Audio Drivers, Power Management Drivers, etc.

Libraries 816 may provide common infrastructure that may be utilized by applications 820 and/or other components and/or layers. Libraries 816 typically provide functionality that allows other software modules to perform tasks in a manner that is easier than interfacing directly with underlying operating system 814 functionality (eg, kernel 828, services 830, and/or drivers 832). Libraries 816 may include system libraries 834 (eg, C standard libraries) that may provide functions such as memory allocation functions, string manipulation functions, math functions, and the like. Additionally, the library 816 may provide an API library 836, such as a media library (eg, a library that supports rendering and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), a graphics library (eg, OpenGL frameworks that can be used to render 2D and 8D in graphics content on a display), database libraries (eg, SQLite, which can provide various relational database functions), web libraries (eg, WebKit, which can provide web browsing capabilities) ,and many more. Libraries 816 may also include various other libraries 838 to provide many other APIs to applications 820 and other software components/modules. In some examples, library 816 may provide one or more APIs that are served by message-oriented middleware.

Framework 818 (also sometimes referred to as middleware) may provide higher-level common infrastructure that may be utilized by applications 820 and/or other software components/modules. For example, framework 818 may provide various graphical user interface (GUI) functions, high-level resource management, high-level location services, and the like. Framework 818 may provide a wide range of other APIs that may be utilized by applications 820 and/or other software components/modules, some of which may be specific to a particular operating system or platform.

Applications 820 include built-in applications 840 and/or third-party applications 842 . Examples of representative built-in applications 840 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and/or a gaming application. The third-party applications 842 may include any of the built-in applications 840 as well as a wide variety of other applications. In a particular example, a third-party application 842 (eg, an application developed using Android ^™ or an iOS ^™ software development kit (SDK) by an entity that is not a vendor of a particular platform) may be a software development kit such as iOS ^™ , Android ^™ , Mobile software running on a mobile operating system such as a Phone or other mobile computing device operating system. In this example, third-party applications 842 may invoke API calls 824 provided by a mobile operating system, such as operating system 814, to facilitate the functionality described herein.

Applications 820 may utilize built-in operating system functions (eg, kernel 828, drivers 832, and/or drivers 832), libraries (eg, system 834, API 836, and other libraries 838), frameworks/middleware 818 to create user interfaces to interact with User interaction of the system. Alternatively or additionally, in some systems, interaction with the user may occur through a presentation layer (eg, presentation layer 844). In these systems, the application/module "logic" may be separated from those aspects of the application/module that interact with the user.

Some software architectures utilize virtual machines. In the example of FIG. 8, this is illustrated by virtual machine 848. A virtual machine creates a software environment in which applications/modules can execute as if they were executing on a hardware computing device. The virtual machine 848 is hosted by the host operating system (operating system 814) and typically, though not always, has a virtual machine monitor 846 that manages the operation of the virtual machine 848 and its interaction with the host operating system (ie, interface to the operating system 814). Software architecture executes within virtual machine 848 , such as operating system 850 , libraries 852 , frameworks/middleware 854 , applications 856 and/or presentation layer 858 . These layers of the software architecture executing within virtual machine 848 may be the same as the corresponding layers previously described or may be different.

Modules, Components and Logic

Certain embodiments are described herein as including logic or several components, modules or mechanisms. A module may constitute a software module (eg, (1) code embodied on a non-transitory machine-readable medium or (2) in a transmission signal) or a hardware implemented module. A hardware-implemented module is a tangible unit capable of performing certain operations and may be configured or arranged in a particular manner. In example embodiments, one or more computer systems (eg, stand-alone, client, or server computer systems) or one or more processors may be configured by software (eg, applications or application portions) to operate to perform operations as described herein Hardware implementation modules for some of the operations described.

In various embodiments, hardware-implemented modules may be implemented mechanically or electronically. For example, hardware-implemented modules may include special-purpose circuits or logic (eg, special-purpose processors such as field programmable gate arrays (FPGAs) or application-specific integrated circuits (application-specific integrated circuits) that are permanently configured to perform certain operations , ASIC)). A hardware-implemented module may also include programmable logic or circuitry (eg, contained within a general-purpose processor or another programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision as to whether to implement a hardware-implemented module mechanically, with dedicated and permanently configured circuitry, or with temporarily configured circuitry (eg, configured by software) may be driven by cost and time considerations.

Accordingly, the term "hardware-implemented module" should be understood to encompass a tangible entity, whether physically constructed, permanently configured (eg, hardwired), or temporarily or temporarily configured (eg, programmed) to An entity that operates in a certain way and/or performs some of the operations described herein. Considering embodiments in which hardware-implemented modules are temporarily configured (eg, programmed), each hardware-implemented module need not be configured or instantiated at any one time. For example, where the hardware-implemented modules include a general-purpose processor configured using software, the general-purpose processor may be configured as various hardware-implemented modules at different times. Software may accordingly configure the processor to constitute a particular hardware-implemented module at one time and a different hardware-implemented module at a different time, for example.

Hardware-implemented modules may provide information to and may receive information from other hardware-implemented modules. Accordingly, the described hardware-implemented modules may be considered to be communicatively coupled. Where multiple such hardware-implemented modules exist concurrently, communication may be accomplished through signal transmission (eg, by connecting appropriate circuits and buses of the hardware-implemented modules). In embodiments where multiple hardware-implemented modules are configured or instantiated at different times, communication between such hardware-implemented modules may be accomplished, for example, by storing and retrieving information in memory structures accessible to the multiple hardware-implemented modules . For example, a hardware-implemented module may perform an operation and store the output of the operation in a memory device to which it is communicatively coupled. Another hardware-implemented module may then access the memory device at some later time to retrieve and process the stored output. Hardware-implemented modules may also initiate communications with input or output devices, and may operate on resources (eg, collections of information).

The various operations of the example methods described herein may be performed, at least in part, by one or more processors that are temporarily configured (eg, by software) or permanently configured to perform the associated operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.

Similarly, the methods described herein may be implemented, at least in part, by a processor. For example, at least some of the operations of the methods may be performed by one or more processors or processor-implemented modules. The execution of certain operations may be distributed among one or more processors, not only residing within a single machine, but deployed across multiple machines. In some example embodiments, one or more processors may be located in a single location (eg, within a home environment, office environment, or server farm), while in other embodiments processors may be distributed across multiple locations.

One or more processors are also operable to support the execution of related operations in a "cloud computing" environment or as a "software as a service" (SaaS). For example, at least some of these operations may be performed by a set of computers (as an example of a machine including a processor) via a network (eg, the Internet) and via one or more suitable interfaces (eg, an API) Accessible.

Electronic Devices and Systems

Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, or software, or in combinations of them. Example embodiments may be implemented using a computer program product, eg, a computer program tangibly embodied in an information carrier (eg, in a machine-readable medium), for execution by or to control the operation of a data processing apparatus, wherein the data processing apparatus For example, a programmable processor, a computer or multiple computers.

Computer programs may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, including as stand-alone programs or as modules, subroutines, or suitable Other units used in the computing environment. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

In example embodiments, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and the apparatus of, example embodiments can be implemented as, special purpose logic circuitry (eg, an FPGA or ASIC).

A computing system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and by virtue of a client-server relationship to each other. In embodiments deploying programmable computing systems, it will be appreciated that both hardware and software architectures merit consideration. In particular, it will be appreciated whether a certain implementation is in permanently configured hardware (eg, an ASIC), in temporarily configured hardware (eg, a combination of software and a programmable processor), or in a combination of permanently and temporarily configured hardware. A functional choice can be a design choice. The hardware (eg, machine) and software architectures that may be deployed in various example embodiments are set forth below.

Example Machine Architecture and Machine-Readable Media

9 is a block diagram of a machine in the example form of a computer system 900 within which instructions 924 are executable to cause the machine to perform any one or more of the methods discussed herein. In alternate embodiments, a machine may operate as a stand-alone device or may be connected (eg, networked) to other machines. In a networked deployment, a machine may operate as a server or client machine in a server-client network environment, or as a peer-to-peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, web appliance, network router, switch or bridge, Or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by the machine. Additionally, although only a single machine is illustrated, the term "machine" should also be understood to include a set (or sets) of instructions executing, individually or jointly, any one or more of the methods discussed herein. any collection of machines.

The example computer system 900 includes a processor 902 (eg, a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 904 and a static memory 906 , which are connected to the computer via a bus 908 . communicate with each other. Computer system 900 may also include a video display unit 910 (eg, a liquid crystal display (graphics processing unit, LCD) or cathode ray tube (CRT)). Computer system 900 also includes alphanumeric input device 912 (eg, a keyboard or touch-sensitive display screen), UI navigation (or cursor control) device 914 (eg, mouse), disk drive or storage device 916, signal generation device 918 (eg, speakers) and network interface device 920.

machine readable medium

The disk drive device 916 includes a machine-readable medium 922 on which is stored a device that implements or is utilized by any one or more of the methods or functions described herein. Set or sets of data structures and instructions 924 (eg, software). Instructions 924 may reside entirely or at least partially within main memory 904 and/or within processor 902 during their execution by computer system 900 , where main memory 904 and processor 902 also constitute machine-readable medium 922 .

Although machine-readable medium 922 is shown in example embodiments as a single medium, the term "machine-readable medium" may include a single medium or multiple media (eg, centralized or distributed databases, and/or associated caches and servers). The term "machine-readable medium" should be understood to include any tangible medium capable of storing, encoding, or carrying instructions 924 for execution by a machine and causing the machine to perform any one or more of the methods of the present disclosure, or capable of Stores, encodes, or carries data structures utilized by or associated with such instructions 924 . The term "machine-readable medium" should thus be understood to include, but not be limited to, solid-state memory as well as optical and magnetic media. Specific examples of machine-readable media 922 include non-volatile memory, including, for example, semiconductor memory devices such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory, EEPROM) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

Transmission medium

Instructions 924 may also be sent or received over a communications network 926 utilizing a transmission medium. Instructions 924 may be transmitted using network interface device 920 and any of a variety of well-known transport protocols (eg, HTTP). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, mobile phone networks, plain old telephone (POTS) networks, and wireless data networks (eg, WiFi and WiMax) network). The term "transmission medium" should be understood to include any intangible medium capable of storing, encoding, or carrying instructions 924 for execution by a machine, and includes digital or analog communication signals or other intangible media to facilitate communication of such software.

Although embodiments have been described with reference to specific example embodiments, it will be understood that various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the present disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings, which form a part hereof, show, by way of illustration and not limitation, specific embodiments in which the subject matter may be implemented. The illustrated embodiments are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, and structural and logical substitutions and changes may be made without departing from the scope of the present disclosure. This "Detailed Description" section is therefore not to be taken in a limiting sense, and the scope of the various embodiments is defined only by the appended claims, along with the full scope of equivalents to which such claims are entitled.

Such embodiments of the inventive subject matter may be referred to herein individually and/or collectively by the term "invention" for convenience only and not intended to actively limit the scope of this application to any single invention or inventive concept, If in fact more than one is disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be understood that any arrangement, which is calculated to achieve the same purpose, may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above-described embodiments, as well as other embodiments not specifically described herein, will be apparent to those skilled in the art upon reading the above description.

Claims (20)

1. a kind of database management system server of distributed data base system, the database management system server include Processor and memory with the processor communication, wherein the database management system server is programmed to execute behaviour Make, the operation includes:

Receive the first execution unit data of the first execution unit of description first database inquiry, the first execution unit number According to the first operation metadata including description for one group of operand of first execution unit；

Determine the first operation metadata description from the distributed data base by the database management system server At least one of at least one operand of first subregion of system and the second subregion from the distributed data base system Operand；

First group of local identifier for describing the row of first subregion is generated by the database management system server；

First group of local identifier for describing the row of second subregion is generated by the database management system server；With And

It is at least partially based on first group of local identifier for describing the row at first subregion and describes at second subregion First group of local identifier of row to execute first execution unit at the distributed data base system.

2. database management system server as described in claim 1, wherein the database management system server also by It is programmed to carry out including operation below:

The second execution unit data of the second execution unit of description are received, the second execution unit data include that description is used for institute State the second operation metadata of one group of operand of the second execution unit；

Determine described at least one operand of second operation metadata description from first subregion；

At least partially by the local identities selected into first group of local identifier of the row from describing first subregion Symbol adds the first offset to generate second group of local identifier for describing the row at first subregion；And

Second group of local identifier for being at least partially based on the row at description first subregion comes in the distributed data base Second execution unit is executed at system.

3. database management system server as claimed in claim 2, wherein the second operation metadata also describes to come from At least one operand of the third subregion of the distributed data base system, wherein first subregion and the third subregion It is a part of common table.

4. database management system server as described in claim 1, wherein the database management system server also by It is programmed to carry out the row including at least part and second subregion for generating the row being associated at first subregion at least The operation of the index of a part, wherein described be indexed to is at least partly based on first group of local identifier.

5. database management system server as claimed in claim 4, wherein the database management system server also by It is programmed to carry out including operation below:

Receive the second operation metadata for including description for one group of operand of second execution unit second executes list Member；

Determine described at least one operand of second operation metadata description from first subregion；

Updated rope is generated at least partially by the first offset difference is added to the first partial identifier of the index Draw, wherein the first offset difference is the subregion offset of first subregion from first group of local identifier Difference between the subregion offset of first subregion in second group of local identifier；And

It is at least partially based on the updated index and to execute at the distributed data base system and described second execute list Member.

6. database management system server as described in claim 1, wherein first of the row at description first subregion The first partial identifier of group local identifier includes slice identifier and the instruction institute of the slice at instruction first subregion State the line displacement amount of the offset of the first row at the first subregion.

7. database management system server as described in claim 1, wherein first of the row at description first subregion The first partial identifier of group local identifier includes indicating the first part of subregion neutrality identifier described first point with instruction The second part of the first execution unit subregion offset in area.

8. database management system server as described in claim 1, wherein the database management system server also by It is programmed to carry out including operation below:

The second execution unit data of the second execution unit of description are received, the second execution unit data include that description is used for institute State the second operation metadata of one group of operand of the second execution unit；

Determine described at least one operand of second operation metadata description from first subregion；

The second execution unit subregion offset is at least partially based on to generate second group of office for describing the row at first subregion Portion's identifier；And

Second group of local identifier for being at least partially based on the row at description first subregion comes in the distributed data base Second execution unit is executed at system.

9. a kind of method that data base querying is executed in distributed data base management system (DDBMS), this method comprises:

The first execution unit of the first execution unit of description first database inquiry is received by database management system server Data, the first execution unit data include first operand of the description for one group of operand of first execution unit Data；

Determine the first operation metadata description from the distributed data base by the database management system server At least one of at least one operand of first subregion of system and the second subregion from the distributed data base system Operand；

First group of local identifier for describing the row of first subregion is generated by the database management system server；

First group of local identifier for describing the row of second subregion is generated by the database management system server；With And

First group of part of the row for describing first subregion is at least partially based on by the database management system server Identifier is held at the distributed data base system with first group of local identifier for describing the row at second subregion Row first execution unit.

10. method as claimed in claim 9, further includes:

By the database management system server receive description the second execution unit the second execution unit data, described second Execution unit data include second operation metadata of the description for one group of operand of second execution unit；

Determine the second operation metadata description from first subregion extremely by the database management system server A few operand；

From the database management system server at least partially by first group of the row to from from description first subregion The local identifier selected in local identifier adds the first offset and describes second of the row at first subregion to generate Group local identifier；And

Second group of part of the row for describing first subregion is at least partially based on by the database management system server Identifier to execute second execution unit at the distributed data base system.

11. method as claimed in claim 10, wherein the second operation metadata is also described from the distributed data At least one operand of the third subregion of library system, wherein first subregion and the third subregion are common tables A part.

12. method as claimed in claim 9 further includes generating association described first by the database management system server At least part of index of the row of at least part of row at subregion and second subregion, wherein described be indexed to few portion Divide and is based on first group of local identifier.

13. method as claimed in claim 12, further includes:

One group of operand for including description for second execution unit is received by the database management system server Second execution unit of the second operation metadata；

Determine the second operation metadata description from first subregion extremely by the database management system server A few operand；

First is added at least partially by the first partial identifier of the index from the database management system server Offset difference generates updated index, wherein the first offset difference is from first group of local identifier First subregion subregion offset and second group of local identifier in first subregion subregion offset between Difference；And

The updated index is at least partially based on come in the distributed data by the database management system server Second execution unit is executed at the system of library.

14. method as claimed in claim 9, wherein first group of local identifier of the row at description first subregion First partial identifier includes the slice identifier of the slice at instruction first subregion and indicates at first subregion The line displacement amount of the offset of the first row.

15. method as claimed in claim 9, wherein first group of local identifier of the row at description first subregion First partial identifier includes indicating the first part of subregion neutrality identifier and indicating that the first of first subregion executes list The second part of Meta Partition offset.

16. method as claimed in claim 9, further includes:

By the database management system server receive description the second execution unit the second execution unit data, described second Execution unit data include second operation metadata of the description for one group of operand of second execution unit；

Determine the second operation metadata description from first subregion extremely by the database management system server A few operand；

Second execution unit subregion offset is at least partially based on by the database management system server to generate description institute State second group of local identifier of the row at the first subregion；And

Second group of part of the row for describing first subregion is at least partially based on by the database management system server Identifier to execute second execution unit at the distributed data base system.

17. a kind of including the machine readable media for the instruction being stored thereon, described instruction is worked as to be executed by least one processor When make at least one described processor execute operation, the operation includes:

Receive the first execution unit number of the first execution unit of the first database inquiry at description distributed data base system According to the first execution unit data include first operand number of the description for one group of operand of first execution unit According to；

Determine at least one fortune of first subregion of the first operation metadata description from the distributed data base system Calculate at least one operand of member and the second subregion from the distributed data base system；

Generate first group of local identifier for describing the row at first subregion；

Generate first group of local identifier for describing the row at second subregion；And

It is at least partially based on first group of local identifier for describing the row at first subregion and describes at second subregion First group of local identifier of row execute first execution unit.

18. machine readable media as claimed in claim 17, wherein the machine readable media further includes being stored thereon Instruction, it includes below that described instruction, which executes at least one described processor, Operation:

The second execution unit data of the second execution unit of description are received, the second execution unit data include that description is used for institute State the second operation metadata of one group of operand of the second execution unit；

Determine described at least one operand of second operation metadata description from first subregion；

At least partially by the local identities selected into first group of local identifier of the row from describing first subregion Symbol adds the first offset to generate second group of local identifier for describing the row at first subregion；And

Second group of local identifier for being at least partially based on the row at description first subregion comes in the distributed data base Second execution unit is executed at system.

19. machine readable media as claimed in claim 18, wherein the second operation metadata is also described from described point At least one operand of the third subregion of cloth Database Systems, wherein first subregion and the third subregion are common Table a part.

20. machine readable media as claimed in claim 17, wherein the machine readable media further includes being stored thereon Instruction, it includes generating to close that described instruction, which executes at least one described processor, Join the operation of at least part of index of the row at least part and second subregion of the row at first subregion, Wherein described be indexed to is at least partly based on first group of local identifier.