Architecture and data modification concurrency in query processing pushdown

Abstract

Described herein is a distributed database system including compute nodes and page servers that enable compute nodes to push down certain query processing compute tasks to page servers to utilize otherwise idle compute resources at the page servers and to reduce the amount of data moved between the compute nodes and the page servers. The distributed database system includes page servers and compute nodes, where the page servers are configured to maintain multiple versions of stored data objects. The compute nodes are configured to receive queries and generate a transaction context (TC) and a modification table schema (MTS) scoped to the query and to push down the query, the TC, and the MTS to the page servers, which are configured to determine which data objects at the page servers satisfy the query and, for each such object, which version of the object should be returned based on the TC.

Description

BACKGROUND

[0001] A typical distributed database system divides storage and compute workloads among multiple distributed components. Such a system can include, for example, one or more compute nodes / servers, page servers, and storage components. Such a system divides system functionality between compute and storage, whereby compute nodes handle all incoming user queries and query processing activities, while page servers are coupled to storage components to provide a horizontally scaled storage engine, with each page server responsible for a subset of database pages. In such a configuration, page servers are limited to serving pages to compute nodes and updating corresponding pages based on ongoing transactional activity.

[0002] Such an architecture supports scaling to 100+ terabyte sized databases, fast database recovery, near-instantaneous backups, and the ability to scale up and down quickly. The above configuration provides flexibility, scalability, and performance for online transaction processing and / or hybrid analytical processing workloads that require high transactional throughput while also supporting real-time analytics.

[0003] However, such a system can not prove optimal for pure analytical workloads that are intensive on scanning over very large datasets, as all query processing is performed on the compute node(s), which requires moving large amounts of data from the page servers to the compute nodes for processing. SUMMARY

[0004] This summary is provided to introduce selected concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] Described herein is a distributed database system including compute nodes and page servers that enable compute nodes to push down certain query processing compute tasks to page servers to leverage otherwise idle compute resources at the page servers and to reduce the amount of data moved between compute nodes and page servers. In example aspects, the distributed database system includes first and second page servers and a compute node, where each of the page servers is configured to maintain a plurality of versions of a stored data object, and where each version corresponds to a transaction. In another aspect, the first page server is configured to receive a query and a transaction context from the compute node, determine which data objects corresponding to the first page server satisfy the query, and for each such object, determine which version of the object should be returned by the first page server in response to the query. In another aspect, the first page server determines which version should be visible to the query at a particular time by comparing certain transaction identifiers and timestamps, thereby determining which version of the object should be returned.

[0006] In another example aspect, a compute node is configured to modify table metadata to allow concurrent queries for different versions of a table schema. In another aspect, a compute node is configured to modify object identifiers so that query processing at a page server treats corresponding objects as globally unique.

[0007] Other features and advantages will be apparent from the following detailed description, taken in conjunction with the accompanying drawings of various embodiments, A detailed description is discussed with reference to the accompanying drawings of various embodiments. The description is intended to be illustrative, but not to be BRIEF DESCRIPTION OF DRAWINGS

[0008] The accompanying drawings are incorporated in and constitute a part of this specification and, together with the description, explain the principles of the embodiments. In the drawings:

[0009] Figure 1A A block diagram of a system for data and schema modification concurrency in query processing pushdown is shown in accordance with example embodiments.

[0010] Figure 1B A block diagram of a cloud-based system for data and schema modification concurrency in query processing pushdown is shown in accordance with example embodiments.

[0011] Figure 2 A block diagram of a computing system configured for data and schema modification concurrency in query processing pushdown is shown in accordance with example embodiments.

[0012] Figure 3 A block diagram of a distributed database system configured for data and schema modification concurrency in query processing pushdown is shown in accordance with example embodiments.

[0013] Figure 4 A flow diagram of data and schema modification concurrency in query processing pushdown is shown in accordance with example embodiments.

[0014] Figure 5 A flow diagram of version scanning for enabling data and schema modification concurrency in query processing pushdown is shown in accordance with example embodiments.

[0015] Figure 6 A flow diagram of a method for enabling schema modification concurrency in query processing pushdown is shown in accordance with example embodiments.

[0016] Figure 7 is a block diagram of an example computer system in which embodiments can be implemented.

[0017] The features and advantages of the embodiments will become more apparent from the detailed description in conjunction with the accompanying drawings upon review of the following disclosure. Like reference numbers in the drawings are intended to represent the same, similar or analogous elements throughout the several views. A first occurrence of an element in a drawing is indicated by the leftmost number(s) in the corresponding reference number. DETAILED DESCRIPTION

[0018] I. INTRODUCTION

[0019] The specification and drawings are disclosive of one or more embodiments incorporating features of the invention. The scope of the invention is not limited to the disclosed embodiments. The disclosed embodiments are merely illustrative of the invention and modified versions of the disclosed embodiments are also included in the invention. The embodiments of the invention are defined by the claims appended hereto.

[0020] Reference in the specification to "one embodiment", "an embodiment", "example embodiments", etc., means that a described embodiment can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of those skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0021] In this discussion, adjectives such as "substantially" and "approximately" that do not recite a specific tolerance when used in connection with a condition or feature described herein, should not be interpreted as absolute requirements. Rather, such adjectives are used to describe conditions or features that are expected to be accurate within a range of tolerances that are acceptable for operation of the embodiments for an intended application.

[0022] A number of example embodiments are described below. It should be noted that any headings provided herein are not intended to limit or otherwise restrict the scope of the embodiments described. Embodiments are described throughout this document and any type of embodiment can be included under any heading. Moreover, embodiments disclosed in any heading can be combined with any other embodiment described in the same heading and / or a different heading in any manner.

[0023] The following Section II describes example embodiments of concurrent data and schema modification in query processing pushdown. The following Section III describes example computing device embodiments that can be used to implement features of the embodiments described herein. The following Section IV describes more examples and advantages, and Section V provides some concluding remarks.

[0024] II. EXAMPLE EMBODIMENTS

[0025] Embodiments herein are described in the context of query processing and query processing pushdown as non-limiting and illustrative examples, including various types of operations performed in association with query processing and query processing pushdown. However, embodiments herein are not limited thereto, their principles and functionality are applicable to other types of processing tasks, applications, and / or services where offloading operations from a host computing system can be advantageously implemented. A general description of the operational environment and design motivation and description of embodiments follows, followed by detailed descriptions of other embodiments.

[0026] As noted above, there exist distributed database systems where compute resources and storage resources are isolated, such that one or more compute nodes (i.e., servers dedicated to performing "computational" functions) are coupled to, for example, n page servers, each of which manages access to and / or modification of one nth page of data included in a database. In such systems, the compute nodes handle all incoming user queries and query processing activities, while the page servers are coupled to storage components to provide an extended storage engine, with each page server responsible for its subset of database pages. In such a configuration, the page servers are limited to serving pages for the compute nodes and updating respective pages based on transactional activity in progress.

[0027] While such systems can provide very high transactional throughput, such systems can not be optimal for scan-intensive analytic workloads on very large datasets. For example, consider the following analytic query against a table with 1.5B rows and no existing index that can be leveraged for lookup operations:

[0028]

[0029] Query 1

[0030] Query 1The average stock sale is being sought where the transaction commission is greater than $95.00. Assume there are 245,598 rows where the commission is greater than $95.00, which means we have a selective filter to consider given the overall size of the table. But because T_COMM is not a leading column of an existing index, we must scan every row in the table. That is, every row of the 1.5B rows of the table must be scanned to apply the filter, where these rows are stored in multiple pages corresponding to multiple page servers. Thus, to perform such a scan, several remote IOs must be issued from the page(s) server to the compute node to provide it with the required pages, where the compute node must then apply the filter to each row and then aggregate the results of the filter operation. As can be appreciated, such a query can consume a significant amount of system resources in terms of network traffic because all of the pages corresponding to the table must be transferred to the compute node, and the compute cycles on the compute node in turn cause the node to have reduced I / O (i.e., fewer transactions per second).

[0031] Embodiments described herein enable query processing (QP) pushdown, whereby certain query processing operations corresponding to a query can be offloaded ("pushed down") to respective page servers to improve overall system performance. For example, the compute node can be configured to push down the filter shown above to each page server, which can then apply the filter to the rows owned by the page server and return these rows to the compute node. The compute node thereafter must simply aggregate the result sets provided by each page server. In this case, the compute resources of each page server are used to apply the filter, and the only data that passes over the network is the 245,598 rows of the result set, not all 1.5B rows of the table. Query 1 pushed down to each page server, which can then apply the filter to the rows owned by the page server and return these rows to the compute node. The compute node thereafter must simply aggregate the result sets provided by each page server. In this case, the compute resources of each page server are used to apply the filter, and the only data that passes over the network is the 245,598 rows of the result set, not all 1.5B rows of the table.

[0032] However, due to the transactional nature of the system, not all compute nodes and / or page servers will be synchronized at any given moment. Embodiments described herein employ query pushdown while also providing concurrency in the face of both data and metadata (i.e., schema) modifications. The system, devices, and apparatuses can be configured in various ways for maintaining concurrency of data and metadata modifications in query processing pushdown. For example, a system 100A configured for query processing pushdown with schema and data modification concurrency will now be described. Figure 1A and Figure 1B . Figure 1A A block diagram of a system 100A is shown, and Figure 1B A block diagram of a cloud-based system 100B is shown, each configured for schema and data modification concurrency in query processing pushdown.

[0033] As Figure 1AAs shown, system 100A includes user device(s) 102 (also referred to herein as user device 102), service / application host 103, compute node(s) 104, and page server(s) 106. In embodiments, user device 102, service / application host 103, compute node(s) 104, and page server(s) 106 communicate with each other over network 114. Storage 112 is also shown in communication with page server(s) 106. It should be noted that in various embodiments, there are different numbers of user devices, hosts, compute nodes, page servers, and / or storage. Additionally, any combination of the systems and / or components shown in FIG. 1A can be present in system 100A, depending on the embodiment. Figure 1A

[0034] In embodiments, network 114 includes different numbers and / or types of communication links connecting computing devices and hosts / servers, such as but not limited to the Internet, wired or wireless networks and portions thereof, point-to-point connections, local area networks, enterprise networks, cloud networks / platforms, etc. In examples, network 114 can be a cloud-based platform network and / or an enterprise network through which user devices connect to or access services / applications, which in turn can result in compute nodes and page servers performing operations on data permanently saved in data storage.

[0035] Storage 112 can be any type and / or number of data storage devices or systems, and can include internal and / or external storage in various embodiments. While storage 112 is shown in communication with page server(s) 106, in some embodiments, storage 112 can be connected to network 114, or can comprise part of page server(s) 106. Storage 112 can include monolithic storage devices / systems, cloud-based storage systems, distributed storage systems, etc.

[0036] User device(s) 102 in different embodiments are any number, type, or combination of computing devices or computing systems, including terminals, personal computers, laptop computers, tablet devices, smartphones, personal digital assistants, server(s), gaming consoles, etc., including internal / external storage devices, for performing the functions / operations described herein for affinity in page split detection and query processing pushdown, e.g., providing queries to a database (DB) server of service / application host 103, and performing operations of client functionality / client-server scenarios. In various embodiments, user device 102 also includes additional components (not shown for brevity and clarity of illustration), including but not limited to components and subcomponents of other devices and / or systems herein.

[0037] ​The user device(s) 102 can be computing devices associated with a domain, as used herein, a domain generally refers to a physical and / or logical system boundary under the control of an entity, within which applications and / or services are hosted, provided, managed, and / or otherwise implemented, and in embodiments also contains sub-domains, etc. Exemplary, non-limiting domains include, without limitation, web domains, tenancies of a hosted cloud platform, cloud service providers, enterprise systems, and / or any other type of network or system. A tenant is a particular type of domain that represents an organization in a cloud platform. The tenant's domain in the cloud platform is its tenancy, in which the tenant registers and manages applications, stores data / files, accesses services, etc.

[0038] The service / application host 103 includes one or more server computers or computing devices, e.g., local server(s) in addition to or instead of cloud-based servers. The service / application host 103 can host one or more services or applications, as understood by those of skill in the relevant arts benefiting from this disclosure, and can act as a portal or interface through which users / tenants use the user device(s) 102 to gain access to the computing node(s) 104. In some embodiments, the service / application host 103 can host a database server front end that leverages the computing node(s) 104 and page server(s) 106 as back-ends. Further, although the embodiments described herein are expressed in terms of computing nodes and page servers, it should be understood that such terminology is employed for illustrative purposes only. That is, although the respective roles of the computing nodes and page servers are described herein as separate, there are embodiments in which the computing nodes can each act as page servers for some subset of pages, and all of the computing nodes can request pages from and / or push queries to each other.

[0039] The computing node(s) 104 include one or more server computers or computing devices, such as local server(s) in addition to or instead of cloud-based servers. As shown, the computing node(s) 104 include a computing node (CN) pushdown manager 108. The CN pushdown manager 108 is configured to determine and provide modification operations, operation fragments, modification metadata, page indexes associated with data pages of operations, and / or similar operations in the context of QP pushdown to the page server(s) 106. The CN pushdown manager 108 can also be configured to receive data from data pages managed by the page server(s) 106, and in embodiments, some such data can be processed by the page server(s) 106 based on QP pushdown requests provided to the page server(s) 106 from the CN pushdown manager 108. In such embodiments, the CN pushdown manager 108 provides the processed data to a query processor or operation processor of the computing node(s) 104 (described in further detail below) to perform QP operations at the computing node(s) 104.

[0040] The page server(s) 106 include one or more server computers or computing devices, such as local server(s) in addition to or instead of cloud-based servers. As shown, the page server(s) 106 include a page server (PS) pushdown manager 110. The PS pushdown manager 110 is configured to perform certain QP pushdown operations provided by the CN pushdown manager 108 from one or more computing nodes 104. For example, a pushdown query processing command can filter versions of rows that are not visible at a particular time, as discussed in further detail below.

[0041] It should also be noted that embodiments herein contemplate that the computing node(s) 104, the page server(s) 106, the storage 112, and / or the service / application host 103 can include portions of an enterprise network portion of the network(s) 114 that the user device(s) 102 communicate with over the Internet.

[0042] Turning now to Figure 1B , the system 100B is a cloud-based embodiment of the system 100A. Figure 1A As shown, the system 100B includes a cloud platform 118. In embodiments, the cloud platform 118 is a cloud-based platform, such as that is accessible by one or more users of the user device(s) 132 (also referred to herein as user devices 132) over a network (not shown here for clarity and brevity).

[0043] The user devices 132 can be any type and / or number of user devices, such as the user devices 102 directed toFigure 1A those described above with respect to user device 102 in FIG. 1, and can correspond to tenants and / or end users described herein, IT personnel, administrators of systems, in different domains (e.g., different tenancies within cloud platform 118).

[0044] Figure 1B A tenant in the context of cloud platform 118 is a representative of an organization in the cloud platform. A domain of a tenant in the cloud platform is a tenancy in which the tenant registers and manages applications hosted by cloud platform 118, stores data / files, accesses services, etc. Cloud platform 118 is shown to host tenancy 128, which includes one or more tenants. A tenant is able to provide applications / services hosted by cloud platform 118 to users such as end users of tenancy 128. In doing so, the tenant can lease or purchase the right to use system resources within cloud platform 118 to do so, and can utilize the system resources and / or operations to provide their services to the end users.

[0045] For example, in embodiments, cloud platform 118 can host tenants of tenancy 128 (which can include partners and / or service providers of the owner of cloud platform 118), tenants that provide services for database servers of services / applications 120 of cloud platform 118 (also referred to herein as “services / applications” 120). A user of user device(s) 132 with credentials for one of tenancies 118 is allowed to authenticate against this tenancy, and access data, information, services, applications, etc. that are allowed or instantiated for this tenant, e.g., services / applications 120 of cloud platform 118.

[0046] In the context of cloud platform 118, computing node(s) 122 and CN pushdown manager 127 can be respective embodiments of computing node(s) 104 and CN pushdown manager 108 of FIG. 1. Figure 1A In the context of cloud platform 118, page server(s) 124 and PS pushdown manager 126 can be respective embodiments of page server(s) 106 and PS pushdown manager 110 of FIG. 1. Figure 1A In the context of cloud platform 118, page server(s) 124 and PS pushdown manager 126 can be respective embodiments of page server(s) 106 and PS pushdown manager 110 of FIG. 1. Figure 1A In the context of cloud platform 118, storage 130 can be an embodiment of storage 112 of FIG. 1.

[0047] In embodiments, cloud platform 118 comprises one or more distributed or “cloud-based” servers. That is, cloud platform 118 is a network or “cloud” for the implementation of applications and / or services in a network architecture / cloud platform. According to embodiments, the cloud platform comprises a set of networked computing resources, including servers, routers, etc., that are configurable, shareable, provide data security, and are accessible over a network such as the Internet. Cloud applications / services are configured to run on these computing resources, typically on top of an operating system running on the resources, for entities accessing the applications / services locally and / or over the network. A cloud platform such as cloud platform 118 is configured to support multi-tenancy as described above, where cloud-based software serves multiple tenants, each comprising one or more users sharing common access to certain software services and applications of the cloud platform 118, as described herein. Further, the cloud platform is configured to support a hypervisor, implemented as hardware, software, and / or firmware, that runs virtual machines (emulated computer systems, including operating systems) for the tenants. The hypervisor provides a virtual operating platform for the tenants.

[0048] In embodiments, Figure 1A and 1B As part of system 100A and system 100B, respectively, such as computing node(s) 104 and / or 122, page server(s) 106 and / or 124, storage 112 and / or 130, and / or cloud platform 118 also include additional components (not shown for brevity and clarity of illustration) including but not limited to components and subcomponents of other devices and / or systems herein, e.g., operating systems, as shown in FIG. 8 described below.

[0049] Further, as will be appreciated by those of ordinary skill in the relevant arts having the benefit of the present disclosure, system 100A and system 100B illustrate embodiments in which system resources for applications and / or services, such as database server hosting, can be scaled on demand or according to any size, throughput, capacity, etc. needs, and embodiments herein provide pushing operations down to page servers that until now have been exclusively performed by computing nodes, and also provide specific handling of different operations and functions of computing nodes and / or page servers successfully and accurately performing these pushed down operations. A non-exhaustive list of non-limiting examples of such specific handling can include providing schema and data modification concurrency, etc. as described herein. In embodiments, systems, devices, and apparatuses are configured in various ways for schema and data modification concurrency in query processing pushdown.

[0050] Figure 2 A block diagram of a system 200 configured for concurrent data and schema modification in query processing pushdown according to example embodiments is shown. The example illustrated and described system 200 is configured as Figure 1A system 100A and / orFigure 1B Embodiments of system 100B. System 200 is described as follows.

[0051] System 200 includes computing system 202 and storage 236. Computing system 202 can include any type of server or computing system, as mentioned elsewhere herein, or otherwise known, including but not limited to cloud-based systems, local servers, distributed network architectures, etc., and in various examples described herein, can be configured as a computing node and / or a page server. For example, computing system 202 can be configured to operate as one of computing node(s) 104 and / or 122, as shown in Figure 1A and Figure 1B respectively. Likewise, computing system 202 can be configured to operate as one of page server(s) 106 and / or 124, as shown in Figure 1A and Figure 1B respectively.

[0052] As shown in Figure 2 System 200 includes computing system 202 and storage 236. Computing system 202 includes processor 204, memory / storage 206, network interface 228, operation processor 222, page index(es) 226, and query processing (QP) pushdown manager 238. Storage 236 includes data page(s) 222. QP pushdown manager 238 includes CN pushdown manager 232 or PS pushdown manager 234, depending on whether computing system 202 is operating as a computing node or a page server, and will be described in further detail below. CN pushdown manager 232 includes index manager 210, pushdown generator 214, and metadata manager 212. PS pushdown manager 234 includes pushdown engine 220 and version scanner 216. These components of system 200 are described as follows.

[0053] Storage 236 can be configured as or similar to storage 112 and / or 130 in Figure 1A and Figure 1B respectively. Similarly, QP pushdown manager 238 can include embodiments of one or more of CN pushdown manager 108 and / or CN pushdown manager 127 in Figure 1A and Figure 1B respectively, which correspond to CN pushdown manager 232 and PS pushdown manager 234, respectively.

[0054] It is contemplated herein that any component of system 200 can be grouped, combined, separated, etc. with any other component in various embodiments, and Figure 2The illustrated example of system 200 in FIG. is non-limiting in terms of its configuration and / or number of components and its exemplary arrangement. Moreover, it should be appreciated that components such as processor(s) 204, memory / storage device(s) 206, and / or network interface 228 can include multiple instances of such components, whether physical or virtual.

[0055] Processor(s) 204 and memory / storage device(s) 206 can each be any type of processor circuit / system and memory described herein and / or understood by those of skill in the relevant arts having the benefit of the present disclosure. Processor(s) 204 and memory / storage device(s) 206 can each include one or more processors or memories, different types of processors or memories (e.g., one or more types / numbers of caches for query processing, allocations for data storage, etc.), remote processors or memories, and / or distributed processors or memories, respectively. Processor 204 can be a multi-core processor configured to concurrently execute more than one processing thread. Processor(s) 204 can include circuitry configured to execute and / or process computer program instructions, such as but not limited to embodiments of QP pushdown manager 238, including one or more components thereof described herein, which can be implemented as computer program instructions, as described herein. For example, in Figure 4 In execution / operation of flowchart 400, processor(s) 204 can execute the described program instructions, as described in detail below, in embodiments.

[0056] In embodiments, operational processor 222 can be part of a query processor or database server / system configured to perform database operations, such as executing queries against a database. Operational processor 222 can include program instructions executed by processor(s) 204, or in embodiments, can be a hardware-based processing device as described herein.

[0057] In different embodiments, memory / storage device(s) 206 include a volatile storage portion, such as random access memory (RAM), and / or a persistent storage portion, such as a hard drive, non-volatile RAM, etc., to store or be configured to store computer program instructions / code for architecture and data modification concurrency in query processing pushdown as described herein, as well as other information and data described in the present disclosure, including but not limited to embodiments of QP pushdown manager 238, including one or more components thereof as described herein, etc.

[0058] The page index(es) 226 include an index of data pages associated with one or more databases, where the index(es) identify parent data page structures and leaf data page structures as well as page servers that maintain particular data pages. In embodiments, the page index(es) 226 can also include data, such as metadata, and the like, used and / or generated in performing the operations / functions described herein, and the like. In the context of a compute node, e.g., where the QP pushdown manager 238 includes the CN pushdown manager 232, the page index(es) 226 can include information reflecting which of the page server(s) 110 maintains particular data pages of a database. Alternatively, when considered in the context of a page server, where the QP pushdown manager 238 includes the PS pushdown manager 234, the page index(es) 226 can include information about data pages of a database maintained by a page server associated with the PS pushdown manager 110 (i.e., the page server(s) 106). In embodiments, the page index(es) 226 are included in the computing system 202 as shown in FIG. 2. Thus, the page index(es) 226 can be entirely held in memory, e.g., the memory / storage device(s) 206. However, in other embodiments, the page index(es) 226 can be maintained in the storage 236 or a combination of both the computing system 202 and the storage 236. Figure 2 The storage 236 can be internal and / or external storage or any type, such as those disclosed herein. In embodiments, the storage 236 stores one or more data pages that include database objects or database files and are accessible only by or through a page server. When configured to function as a page server, the system 200 stores any number of data pages in the storage 236. Further, more than one page server can be implemented via multiple instances of the system 200, and data pages of a database object or database file can be large in number and / or data size such that data pages of a single database object or database file span multiple instances of the storage 236 of the respective page servers. In embodiments where the system 200 is configured to function as a compute node, the storage 236 can store data pages and / or portions of data pages provided from one or more page servers in response to requests from the compute node.

[0059] The storage 236 can be internal and / or external storage or any type, such as those disclosed herein. In embodiments, the storage 236 stores one or more data pages that include database objects or database files and are accessible only by or through a page server. When configured to function as a page server, the system 200 stores any number of data pages in the storage 236. Further, more than one page server can be implemented via multiple instances of the system 200, and data pages of a database object or database file can be large in number and / or data size such that data pages of a single database object or database file span multiple instances of the storage 236 of the respective page servers. In embodiments where the system 200 is configured to function as a compute node, the storage 236 can store data pages and / or portions of data pages provided from one or more page servers in response to requests from the compute node.

[0060] The network interface 228 can be any type or number of wired and / or wireless network adapters, modems, and the like, configured to enable the system 200 (including the computing system 202) to communicate intra-system with its components, as well as communicate with other devices and / or systems over a network, e.g., through a network / cloud platform such as the network 112 and / or the cloud platform 134, the computing system 202 andFigure 1A system 100A and / or Figure 1B communications between other devices, systems, hosts of system 100B.

[0061] System 200 also includes additional components (not shown for brevity and clarity of illustration) including, but not limited to, components and subcomponents of other devices and / or systems herein, and those described below with respect to FIG. 8, e.g., operating systems, etc., in accordance with embodiments.

[0062] In embodiments, computing system 202 can be configured as a compute node and / or a page server, and QP pushdown manager 238 of computing system 202 can be correspondingly configured in such embodiments. That is, QP pushdown manager 238 can be configured as a CN pushdown manager or a PS pushdown manager, each of which is shown in Figure 2 FIG. 1C as CN pushdown manager 232 and PS pushdown manager 234, respectively. Thus, QP pushdown manager 238 can be implemented in various ways to include a number of components for performing the functions and operations described herein to provide concurrency in query processing pushdown in the face of data and schema modifications in a compute node context and / or in a page server context.

[0063] As noted above, Figure 2 System 200 of FIG. 1C illustrates two non-exclusive options for configuring QP pushdown manager 238: CN pushdown manager 232 and PS pushdown manager 234. CN pushdown manager 232 includes, but is not limited to, index manager 210, metadata manager 212, and pushdown generator 214. PS pushdown manager 234 includes, but is not limited to, pushdown engine 220 and version scanner 216, although additional components as described herein or otherwise can be included and some components can be excluded in various embodiments. For example, as discussed further below, PS pushdown manager 234 can optionally include its own instance of metadata manager 212. Each of these components will now be described in turn.

[0064] The index manager 210 is configured to determine, based on the page index(s) 226, the index of the data page required for the QP pushdown operation. In embodiments, this can include the next data page associated with the data page to be read by the page server. The metadata manager 212 is configured to determine the metadata required and generate versions of the metadata and / or modify the metadata associated with the database to perform the different operations described herein, such as the QP pushdown operations performed by the page servers. Such metadata can include, for example, one or more schemas, each corresponding to a database object (e.g., a table) stored on a data page on one or more page servers, where such schemas are maintained by the computing system 202. In embodiments, the metadata manager 212 is configured to serialize the metadata required to provide to the page servers for the operations. The metadata manager 212 can also modify the metadata to allow for concurrent queries against different versions of the same metadata, and as will be discussed in further detail below.

[0065] The pushdown generator 214 is configured to generate pushdown operations at the computing node to provide to the page servers. In embodiments, the pushdown generator 214 generates query fragments (e.g., including query operators, expressions, etc.) that are assembled with appropriate metadata to form a query plan for the QP pushdown operations to be performed by one or more page servers that would otherwise be unable to perform the required QP pushdown operations.

[0066] The pushdown engine 220 is configured to generate the QP pushdown operations from the information provided by the computing node so that the operation processor 222 can process the operations. For example, the pushdown engine 220 can work in conjunction with the operation processor 222 to determine which rows are in scope for the QP pushdown operations.

[0067] As will be discussed in further detail below, the version scanner 216 is configured to take a transaction context and a query or query fragment and determine, given the transaction context, which versions of the relevant rows are visible and select those rows to include in the query results returned by the PS pushdown manager 234.

[0068] Having provided an introduction to embodiments of computing nodes and page servers along with a general description of the functions performed by the components of such embodiments, the written description now turns to a description of the requirements for concurrent advantages provided by the embodiments. Such a description will be made with reference to Figure 3 FIG. 1, which shows a block diagram of a distributed database system 100 configured for concurrent data and schema modification according to example embodiments.

[0069] As Figure 3The illustrated distributed database system 300 includes user device(s) 102, computing nodes 302, a log server 310, page servers 308, and storage 236. The computing nodes 302 include a primary computing node 304 and a set of secondary computing nodes 306-1 through 306-N. Likewise, the page servers 308 include a set of page servers 308-1 through 308-N. The log server 310 includes a log cache 312.

[0070] The user device(s) 102 are coupled to one or more of the computing nodes and provide workloads to the distributed database system 300 in the form of transactions and other queries. The primary and secondary computing nodes of the computing nodes 302 are coupled to the log server 310 and one or more of the page servers 308.

[0071] Note that while embodiments can sometimes be described in the context of a user device such as the user device(s) 102 providing a query or workload of queries and receiving returned query results, embodiments are not limited to operating with or through a user device such as the user device(s) 102. Indeed, embodiments described herein can execute queries on behalf of or for any source of such queries and provide query results to the same source or entity, or to some other source or entity. For example, queries can be generated by a computing component (not shown) and provided to an embodiment for execution. Thereafter, the embodiment can execute the queries in the manner described herein and provide results back to the query source directly, or to some other location, entity, or component as appropriate. Figure 3

[0072] As noted above, each of the page servers 308 is configured to handle a subset of the pages that make up the database. While the storage 236 and data page(s) 222 stored therein are illustrated as a monolithic storage, embodiments are not so limited. In alternative embodiments (not shown), each of the page servers 308 can be coupled to a dedicated memory that includes only the data pages corresponding to that page server. Likewise, embodiments can be configured anywhere in between, with some pages corresponding to a given page server being stored in one location on one storage unit, while other pages are in other locations.

[0073] ​As noted above, the distributed database system 300 can be configured to perform transactions. Embodiments of the distributed database system 300 are ACID compliant. As known in the art, ACID is an acronym representing a set of properties of database transactions that ensure that, despite errors that can occur due to, for example, hardware failure or power failure, data that is saved to the database is valid. ACID is atomicity, consistency, isolation, and durability. The transactions performed by the distributed database system 300 are ACID compliant because the operations that logically correspond to a transaction collectively satisfy the ACID properties.

[0074] The atomicity property of a transaction requires that the transaction either completely succeeds or completely fails. A transaction completely failing means that the database remains unchanged. For example, assume that a transaction includes transferring funds from account A to account B. The entire transaction includes several steps: deducting the funds from account A, transferring the funds anywhere the account B is located, and crediting the funds to account B. In this case, atomicity guarantees that if for any reason the funds are not credited to account B, then no funds are deducted from account A.

[0075] The consistency property ensures that the transaction complies with all applicable rules governing the storage of data, such that the transaction takes the database from one valid state to another valid state.

[0076] The isolation property ensures that different transactions that are executed concurrently leave the database in the same state that would have been obtained if the transactions were executed serially. Isolation is a primary goal of concurrency control, and embodiments discussed further below implement such concurrency control.

[0077] Finally, the durability property guarantees that once a transaction is committed (i.e., completed in a manner that complies with ACID and permanently saved to the database), the transaction will remain committed and any hardware, system, or power failure will not cause the transaction to be lost or put the database in an inconsistent state. Further reference is made to Figure 3 With respect to the distributed database system 300 of

[0078] In embodiments, the primary compute nodes 304 are configured to perform both read and write operations, while the secondary compute nodes 306-1 through 306-N are configured to perform read-only operations. Thus, only the primary compute nodes 304 can execute transactions that change the state of the database. To maintain the ACID properties of transactions, the primary compute nodes 304 can be configured to generate a log record of a transaction upon transaction commit, and store the record locally in a transaction log before any data modifications caused by the transaction are written to disk.

[0079] The log of committed transactions includes all the information needed to re-execute the transaction should a problem (e.g., power failure) occur before the data modified by the transaction can be stored (e.g., in multiple data pages 222 of storage device 236). The log may include information including, but not limited to, transaction identifiers, log sequence numbers, timestamps, information indicating what data object or object was modified and how it was modified.

[0080] Regarding log sequence numbers, the transaction log operates logically as a series of log records, each identified by a Log Sequence Number (LSN). Each new log record is written to the logical end of the transaction log, where the LSN is higher than the LSN of the record that precedes it. Log records are stored sequentially because they are created such that if LSN2 is greater than LSN1, the change described by the log record referenced by LSN2 occurs after the change described by the log record LSN1. Each log record also contains a transaction identifier for the transaction to which it belongs. That is, the transaction identifier is information that uniquely identifies the transaction corresponding to the log record (e.g., a Universally Unique Identifier (UUID) or a Globally Unique Identifier (GUID)).

[0081] In this embodiment, the log record corresponding to the transaction is then forwarded to log server 310, which is configured to provide a log service. The log service on log server 310 accepts log records from the primary compute node 304, permanently stores them in log cache 312, and then forwards the log records to the remaining compute replicas (i.e., secondary compute nodes 306-1 to 306-N) so they can update their local log caches. Log server 310 also forwards log records to the relevant page servers(s), allowing data updates there. In this way, all data changes from the primary compute node 304 are propagated to all secondary compute nodes and page servers via the log service. Finally, the log records are pushed to long-term storage, such as storage device 236. In addition to transaction commits, other types of operations can also be logged at the primary compute node 304 and subsequently forwarded to, but are not limited to, transaction initiation, range and page allocation or deallocation, creation or deletion of tables or indexes, and each data or schema modification.

[0082] As described above, log server 310 enables transaction log records to be replicated to secondary compute nodes and page servers. In the context of QP pushdown, different page servers can be invoked to execute query processing tasks concurrently (i.e., concurrently). However, log records may not be replicated from log server 310 to each page server and / or secondary compute node at the same rate, and / or log record processing may occur at different rates on each page server or compute node. In summary, this means that different page servers / compute nodes may not have the same data view, which could lead to inconsistencies. Therefore, the embodiments described herein prevent the adverse effects of concurrent updates to data and / or metadata by using row-version-based snapshot isolation, while ensuring that the system treats the metadata corresponding to data objects as unique in all circumstances, thus avoiding inconsistencies that can typically arise from mixing snapshot isolation with concurrent metadata updates. Each of these is discussed below in turn.

[0083] Please note that while the embodiments described herein are sometimes expressed in terms of data objects and concepts commonly associated with relational databases (e.g., terms such as “row,” “table,” “schema,” etc.), it should be understood that the embodiments are not limited to relational databases or specific types of objects, such as tables or rows. For example, the concept of row versioning and its use in snapshot isolation also applies to other types of data objects in relational tables that are not rows. For example, versioning can be effectively used to enable concurrent access to blobs or other types of unstructured data. Therefore, the terms “data object” and “row” may sometimes be used in a seemingly equivalent manner herein, and such equivalence should not be inferred.

[0084] Row versioning is a framework that invokes copy-on-write as rows are modified or deleted. This requires that, during transaction execution, older versions of rows must be available to transactions that require an early, consistent state. Therefore, when a row-versioning-based isolation level is enabled, database engines (e.g., such as...) Figure 2 The operation processor 222 of the illustrated computing system 202 stores a version of the row each time it is modified. Each new version of the row can be stored together with the transaction identifier of the transaction that committed the row modification and the commit timestamp, thereby allowing embodiments to determine the point in time when a given version began to exist. Alternatively, the committed transaction and the associated timestamp can be maintained separately from the corresponding version. For example, as will be discussed further below, a commit history table can be maintained, which includes the transaction identifier and commit timestamp of each committed transaction.

[0085] Subsequently, pushdown queries will use row versioning to view data that existed at the start of the transaction or query, instead of protecting all reads with locks. By using row versioning, the likelihood of read operations blocking other transactions is greatly reduced, while providing statement-level or transaction-level read consistency. Now, refer to...Figure 2 The CN pushdown manager 232 and PS pushdown manager 234 of the computing system 202 shown are... Figure 3 The distributed database system 300, and combined with Figure 4 The flowchart 400 is used to describe snapshot isolation in QP pushdown.

[0086] refer to Figure 3 Suppose that (multiple) user devices 102 send a query to secondary compute node 306-1. As described above, secondary compute node 306-1 of compute node 302 is configured to generate and send QP pushdown 314, thereby generating query results and returning the query results to (multiple) user devices 102. Some query processing required is pushed down to at least some page servers 308. Note that although the QP pushdown operation is currently described as being pushed down by secondary compute node 306-1, the embodiments are not limited to this. In embodiments, the QP pushdown operation may be initiated by compute node 302, which includes primary compute node 304. The first step in performing such a QP pushdown is that secondary compute node 306-1 determines which of the page servers 308 should receive the pushed-down QP task. For example, suppose secondary compute node 306-1 is... Figure 2 In an instance of computing system 202, the index manager 210 of the CN pushdown manager 232 can be configured to use the received query and determine the indexes of the data pages required for the QP pushdown operation based on page index(s)226. As described above, the page index(s)226 include indexes of data pages associated with a database, wherein the page index(s) identify the parent data page structure and leaf data page structure, as well as the page server maintaining the specific data page. Thus, the CN pushdown manager 232 can determine which page server 308 should receive the QP pushdown 314. In another embodiment, the appropriate page server 308 can be determined by the pushdown generator 214 in conjunction with the index manager 210.

[0087] After determining where the QP pushdown must be sent, the pushdown generator 214 of the CN pushdown manager 232 then generates the pushdown operation to be provided to the appropriate page server of the page server 308. Specifically, the pushdown generator 214 may generate query fragments including query operators and expressions, which will be received and processed by the PS pushdown manager 234, as will be discussed further below. Alternatively, the pushdown generator 214 may simply provide the original query as part of the QP pushdown 314. In addition to the query and / or query fragments, the pushdown generator 214 must also generate a transaction context to be provided as part of the QP pushdown 314.

[0088] The transaction context includes a snapshot of transaction-related information maintained by the secondary compute node 306-1, reflecting the state of the database at the secondary compute node 306-1 at a specific point in time. While the secondary compute node 306-1 can determine which version of a row it should be able to see at any given time, the page server 308 is not necessarily so, because one or more such servers may not be synchronized with the transactions of the secondary compute node 306-1. For example, the primary compute node 304 may have committed multiple transactions, providing corresponding log records to the log server 310, and the copies of these log records to the page server 308 and the secondary compute node 306-1 may not be synchronized. For example, the page server 308-1 may have received and processed a replicated log record of all updates performed by the primary compute node 304, while the secondary compute node 306-1 may not have. In this case, the page server 308-1 cannot determine which version of the relevant data object in its page should be returned to the secondary compute node 306-1. Therefore, the implementation must provide the transaction context as part of QP pushdown 314, which will enable the relevant page server of page server 308 (in this example, page server 308-1) to determine which row versions to return.

[0089] In this embodiment, the transaction context may include a snapshot of the commit history table, an aborted transaction graph, a snapshot timestamp, and the maximum useful transaction identifier. The commit history table is maintained by each compute node 302 and includes the transaction identifier and commit timestamp for each committed transaction. While theoretically the commit history table may include such information for all committed transactions, in practice it only includes transactions committed within a predetermined time period prior to the current time. Note that the commit history table may differ for each compute node 302 because, as mentioned above, the replication of transaction log records 318 to each may be at different stages of completion, and a given compute node 302 may not yet be aware of some committed transactions.

[0090] The aborted transaction graph is a list of all aborted transactions known to the compute nodes. Similar to the commit history table, the aborted transaction graph includes a transaction identifier for each such aborted transaction. Also similar to the commit history table, the time frame of the aborted transaction graph can be limited to those transactions aborted within a predetermined time period prior to the current time. The snapshot timestamp reflects the real time when the commit history table and the aborted transaction graph were snapshotted. The most useful transaction identifier can include any information corresponding to a specific transaction, such as the transaction ID or the log sequence number associated with a transaction log entry. See also... Figure 2 and Figure 3 Now will describe Figure 4 and Figure 5 Flowcharts 400 and 500.

[0091] refer to Figure 4 Flowchart 400 begins at step 402. In step 402, the query and the corresponding transaction context are received from the compute node at the first page server. For example, and continuing to refer to... Figure 2 and Figure 3 The computing system 200 and the distributed database system 300, such as Figure 3 Page server 308-1 of the shown page server 308 is configured to receive QP pushdown 314 from secondary compute node 306-1, wherein QP pushdown 314 includes transaction context and query or query fragment, as described above. Flowchart 400 continues at step 404.

[0092] At step 404, the data objects that satisfy the query and are stored on the first page server are determined. For example, and then refer to... Figure 2 and Figure 3 The computing system 200 and the distributed database system 300, the page server 308-1 includes an instance of the computing system 202 and an instance of the PS pushdown manager 234. The PS pushdown manager 234 includes a pushdown engine 220 and a version scanner 216. As described above, the pushdown engine 220 can be configured to determine, alone or in conjunction with the operation processor 222, which database objects (e.g., rows) satisfy the query and for each such object. Flowchart 400 continues at step 406.

[0093] At step 406, for each such determined data object, the transaction context is used to determine which version of the corresponding determined data object should be included in the first query sub-result, thereby filtering out versions that should not be included. For example, and continuing to refer to... Figure 2 and Figure 3 The computing system 200 and distributed database system 300, page server 308-1 includes an instance of computing system 202 and an instance of PS pushdown manager 234, which includes pushdown engine 220 and version scanner 216. As described above, version scanner 216 is configured to determine which version of a given object is visible given a transaction context. Version scanning performed by version scanner 216 can be performed in various ways. For example, according to an example embodiment, for version scanning... Figure 5 Flowchart 500 enables concurrent data and schema modifications in query processing pushdown. Flowchart 500 begins at step 502.

[0094] At step 502, the data objects that satisfy the query and are stored on the page server are determined. For example, step 502 is essentially the same as described above. Figure 4 The flowchart 400 is analogous to step 404. More specifically, and continue to refer to each step separately.Figure 2 and Figure 3 The computing system 200 and the distributed database system 300, the page server 308-1 includes an instance of computing system 202 and an instance of PS pushdown manager 234. PS pushdown manager 234 includes pushdown engine 220 and version scanner 216. As described above, pushdown engine 220 can be configured to determine, alone or in conjunction with operation processor 222, which database objects (e.g., rows) satisfy the query and for each such object. Flowchart 500 continues at step 504.

[0095] At step 504, for each version of each such data object, and based on the commit history table, the version commit timestamp corresponding to the version transaction for that version is determined. For example, and continuing to refer to... Figure 2 and Figure 3 In the computing system 200 and the distributed database system 300, the commit history table is included in the transaction context provided to the page server 308-1 as part of the QP pushdown 314, as described above. The commit history table includes the transaction identifier and commit timestamp of the most recently committed transaction, also as described above. Similarly, each version of a data object (e.g., a row) in the database includes a transaction identifier of the transaction responsible for committing that particular version. The version scanner 216 is configured to scan the commit history table for the transaction corresponding to the transaction that committed the corresponding version and determine its commit timestamp, including the version commit timestamp. Flowchart 500 ends at step 506.

[0096] At step 506, for each version of each such data object, the corresponding version should be included in the result set only if it is determined that the version transaction identifier corresponding to the corresponding version is not included in the aborted transaction graph, the version transaction identifier corresponding to the corresponding version is less than the maximum useful transaction identifier, and the snapshot timestamp is greater than the version commit timestamp. For example, and continuing to refer to... Figure 2 and Figure 3 In the computing system 200 and the distributed database system 300, version scanner 216 is configured to select a given object version from the result set if three conditions are met. First, version scanner 216 obtains the transaction identifier for each version of the data object and compares these identifiers with those included in the aborted transaction graph provided to page server 308-1 as part of the transaction context of QP pushdown 314. The result set should not include any versions corresponding to aborted transactions.

[0097] Second, version scanner 216 is configured to filter out any data objects corresponding to versions of transactions that are newer than the maximum useful transaction identifier. More specifically, version scanner 216 should only include versions in the result set whose corresponding transaction identifiers are less than the maximum useful transaction identifier.

[0098] Third and finally, version scanner 216 is configured to compare the snapshot timestamps included in the transaction context provided by secondary compute node 306-1 in QP pushdown 314 with the version commit timestamps determined in step 502 above, and filter out versions that are newer than the snapshot timestamps (i.e., only select versions whose snapshot timestamps are greater than the version commit timestamps).

[0099] Note that, although Figure 5 Flowchart 500 is expressed based on the set of conditions that must be satisfied for the version to be included in the result set, but the implementation does not need to literally implement such logic; instead, logical supplementation can be implemented. For example, Figure 5 Step 504 of flowchart 500 can be interpreted as: if A, B, and C, then version X is included. The logical equivalence test includes: if neither A, nor B, nor C, then version X is excluded. That is, each version of the object can be considered sequentially, where a version is excluded from the result set if any supplementary condition is false. More specifically, a version is excluded if any of the following are true: the transaction corresponding to the version is on the aborted transaction graph; the version transaction identifier is greater than the maximum useful transaction identifier; or the snapshot timestamp is less than the version commit timestamp. Figure 4 The description of flowchart 400 now continues to step 408.

[0100] At step 408, a copy of each determined version is included in the first query sub-result. For example, and continuing to refer to... Figure 2 and Figure 3 After determining multiple versions of data objects that are visible in response to a query, the version scanner 216 can provide identifiers of these versions to the pushdown engine 220 and / or operation processor 222 for selecting such objects to be included in the query results (e.g., rowsets). Flowchart 400 ends at step 410.

[0101] At step 410, the first query sub-result is returned to the compute node. For example, and continue to refer to... Figure 2 and Figure 3 The computing system 200 and the distributed database system 300, the operation processor 222 and / or the pushdown engine 220 are configured to return query results to the secondary computing node 306-1.

[0102] The above respectively forFigure 4 and Figure 5 The descriptions of flowcharts 400 and 500, and the corresponding descriptions of the operation of the compute nodes and page server instances and their components in the computing system 202, are constructed based on the interaction between a single compute node and a single page server. However, it should be understood that the QP pushdown 314 can point to multiple page servers of page server 308, wherein the QP pushdown 314 pointing to each page server is specifically tailored for that page server based on the data objects managed by that page server. Alternatively, the QP pushdown 314 distributed to each page server can be identical. Of course, the query results returned by each page server to the compute node will differ because the underlying data managed by each page server is different, and each returned result of this kind includes only sub-results. Embodiments of compute node 302 are configured to receive results from page servers and aggregate that data into a final result for transmission to the caller (e.g., as...). Figure 3 (The multiple user devices 102 shown). Furthermore, embodiments of compute node 302 can be configured to aggregate such data for return without further filtering the rows before or after aggregation.

[0103] The version control-based snapshot isolation described above enables concurrent data modification. The implementation example is also configured to enable concurrent architecture modification, as will now be discussed in detail below. Figure 2 and Figure 3 As described in the computing system 200 and distributed database system 300, metadata is data about data, and in the context of a database, it is called the schema. The term "schema" refers to the organization of data, serving as a blueprint for how the database is constructed. For example, in the context of a relational database, the schema shows how the database is divided into tables, and similarly defines the type and meaning of each column in the tables.

[0104] Some traditional database systems, whether distributed or not, are typically limited to a single active schema version at any given time. That is, while the schema can be modified using Data Definition Language (DDL) operations, the lack of metadata versioning means that snapshot isolation as described above is impossible. However, the embodiments described herein address this problem by essentially deceiving the relevant schema identifiers, making all schemas included in QP pushdown operations globally unique. This technique is generally described below.

[0105] Consider scenarios such as, Figure 3The primary compute node 304 of the distributed database system 300 receives and executes schema modification (DDL) commands to modify table schemas. The schema modifications are ultimately replicated to other nodes of compute node 302 and the page server 308 via the log record replication process described above. After the log record corresponding to the DDL command is replicated to the page server (e.g., page server 308-1), subsequent QP pushdown commands from the primary compute node 304 to page server 308-1 will be executed against any one or more schemas modified by the DDL command, because both the primary compute node 304 and page server 308-1 are transactionally synchronized with respect to the table data and the metadata describing the table.

[0106] Now consider the same example as above, but the second compute node, such as secondary compute node 306-1, wants to perform a QP pushdown operation limited to the table modified by the DDL command above, but secondary compute node 306-1 has not yet received the replication transaction log record 318 corresponding to the DDL command. In this case, the latest data for the table stored on page server 308-1 corresponds to the new schema (i.e., after the DDL command modification), while the queries / query fragments and metadata included in the QP pushdown 314 propagated from secondary compute node 306-1 to page server 308-1 necessarily correspond to the old schema (i.e., the schema that existed before the DDL command). Even though the latest data for the table stored on page server 308-1 corresponds to the new schema, note that the old version of the table on page server 308-1 continues to correspond to the old schema. Therefore, page server 308-1 can theoretically serve QP pushdown operations limited to either the version of the table corresponding to the previous DDL schema or the version of the table corresponding to the later DDL schema. However, without architecture versioning support in the distributed database system 300, the page server 308-1 cannot perform such operations simultaneously (i.e. concurrently).

[0107] The implementation addresses this issue by performing a schema modification step before pushing the schema down to the page server. Specifically, secondary compute node 306-1 can avoid schema conflicts during the QP pushdown operation by modifying any one or more schemas to be pushed down, making certain identifiers globally unique. Such identifiers include table names, table identifiers, object identifiers, and row set identifiers. By using one or more modified schemas, the pushdown engine 220 will not encounter schema conflicts when building executable query plans for the pushed-down queries / query fragments.

[0108] In this scenario, recall that page server 308-1 is operating on the latest data, and this data corresponds to a DDL-modified schema, while secondary compute node 306-1 is unaware of the schema change and is therefore operating on an older schema. The older schema still applies to the modified table because the data in the table itself has been version-controlled as described above. That is to say, the above statements regarding... Figure 4 and 5 process Figure 4 and 5 The described row filtering operation will filter out any rows corresponding to the new architecture, and the visible and unfiltered rows can be correctly interpreted by referring to the appropriately modified architecture included in the QP pushdown 314 sent from the secondary compute node 306-1. In other words, the embodiment allows QP pushdown operations to use different versions of the architecture by changing its identifier to be globally unique, thereby allowing the system to identify queries as being executed using a unique architecture rather than different versions of the same architecture, and relies on the row filtering mechanism to filter out row versions whose scope is limited to the newer architecture.

[0109] Furthermore, the implementation can generate globally unique names and IDs not only for different architectures but also for the indexes used by pushdown queries. For example, suppose a table has a clustered B-tree index (identified as "Id_1") and two non-clustered B-tree indexes (identified as 'ID_2' and 'ID_3'). In the case where three different QP pushdown operations each range from a different index among these indexes, the implementation can modify the identifier of each index to be globally unique.

[0110] This operation can be performed in several ways. For example, suppose... Figure 2 The computing system 202 is configured as a compute node, such as secondary compute node 306-1, and is performing QP pushdown. As described above, the pushdown generator 214 of the CN pushdown manager 232 generates pushdown operations to be provided to the appropriate page servers of page server 308. In addition to queries and / or query fragments and transaction contexts, the pushdown generator 214 can also be configured to generate one or more modified schemas for objects within the scope of the pushed-down query operations, and provide one or more such modified schemas in QP pushdown 314, as provided to one or more page servers 308.

[0111] In other embodiments, the metadata manager 212 of the CN pushdown manager 232 may alternatively be configured to generate modified schemas or schemas for objects within the scope of the pushed-down query operations. In other embodiments, an instance of the metadata manager 212 may be included in the PS pushdown manager 234 and configured to modify schema(s) in the same manner. That is, instead of performing schema modifications on, for example, secondary compute node 306-1, the pushdown generator 214 of the CN pushdown manager 232 may push down unmodified schemas to one or more page servers in the page servers 308, while simultaneously signaling to the page servers (via their own metadata manager instance 212) that they should modify their schemas as needed.

[0112] Figure 6 Flowchart 600 illustrates one way of performing these operations, which shows a method for enabling concurrency of schema modification in query processing pushdown in one embodiment. Figure 1A System 100A in Figure 1B System 100B in Figure 2 System 200 and / or Figure 3 The distributed database system 300 is configured to operate according to flowchart 600. Based on the following description, other structural and operational examples will be clear to those skilled in the art(s).

[0113] Flowchart 600 begins at step 602. In step 602, a set of table schemas is maintained, which corresponds to the relational tables stored in pages of a distributed database. For example, and referring to respectively... Figure 2 and Figure 3 The computing system 200 and the distributed database system 300, wherein the main computing node 304 of the distributed database system 300 includes an instance of the computing system 202, and, as described above, maintains the schema corresponding to the tables stored in the pages maintained by the page server 308. Flowchart 600 continues at step 604.

[0114] At step 604, a query is received. For example, and continuing to refer to Figure 1 and... Figure 2 The computing system 200 and the distributed database system 300 allow queries to be performed from, for example... Figure 3 The distributed database system 300 shows that the data is sent by (multiple) user devices 102 and received by the main computing node 304. Flowchart 600 continues at step 606.

[0115] In step 606, the table set corresponding to the relation table being queried is identified. For example, and continuing to refer to Figure 1 and... Figure 2 The computing system 200 and the distributed database system 300, Figure 2The metadata manager 212 of the illustrated computing system 202 is configured to determine the metadata required for the QP pushdown operation to be performed by the page server, as described above. Flowchart 600 continues at step 608.

[0116] At step 608, a modified table schema set is generated as follows: for each table in the identified table set, a modified table schema is generated, which includes at least a partial copy of the table schema corresponding to the respective table and includes a globally unique identifier. For example, and continuing to refer to Figure 1 and... Figure 2 The computing system 200 and the distributed database system 300, Figure 2 The metadata manager 212 of the illustrated computing system 202 is configured to determine the required metadata and generate versions of the metadata and / or modify the metadata associated with the database to perform the QP pushdown operation to be performed by the page server as described above. More specifically, the metadata manager 212 is configured to create a copy of each table schema identified at step 606 above and modify the copy such that at least one of its identifiers is modified to be globally unique. For example, one or more of the table name, table identifier, object identifier, and row set identifier may be modified to be globally unique. Flowchart 600 continues at step 610.

[0117] At step 610, a request is transmitted to the first page server, which includes a pushdown query and modification of the table schema set. For example, and continuing to refer to Figure 1 and... Figure 2 The computing system 200 and the distributed database system 300, with the primary compute node 304 configured to push down QP 314 to at least one page server in the page servers 308, such as page server 308-1, in the manner described above. In addition to the transaction context and query or query fragment described above, the primary compute node 304 also includes modifying the table schema in the QP pushdown 315. Flowchart 600 continues at step 612.

[0118] At step 612, on the first page server, a query result is generated and returned using the modified table schema set, wherein the query result includes data that satisfies the query and is stored on the first page server. For example, and continuing to refer to Figure 1 and... Figure 2 The computing system 200 and the distributed database system 300, and the page server 308-1 include, for example, Figure 2An instance of computing system 202 is shown, and includes a PS pushdown manager 234. The pushdown engine 220 of the PS pushdown manager 234 is configured to generate an executable query plan for a QP operation using any one or more schemas and query / query fragments received in QP pushdown 314. This plan can then be executed by the operation processor 222 to generate query results. Because one or more table schemas included in the QP pushdown 314 are globally unique, schema conflicts do not occur where such a schema corresponds to an earlier version of the schema. As part of such a QP operation, the version scanner 216 is configured, as described above, to filter out invisible query results based on the transaction context included in QP pushdown 314, and in doing so, the elimination scope is limited to rows with schema versions newer than the schema version pushed down in QP pushdown 314. Any remaining rows(s) after filtering are then returned as query results to the main compute node 304. Flowchart 600 ends at step 614.

[0119] At step 614, the query results are received from the first page server. For example, and continuing to refer to Figure 1 and... Figure 2 The computing system 200 and the distributed database system 300, with the main computing node 304 configured to receive query results from, for example, a page server 308-1.

[0120] III. Example Computer System Implementation

[0121] As described herein, the embodiments include, but are not limited to, those described herein. Figure 1A System 100A, Figure 1B System 100B and / or Figure 3 System 300, and any of its components and / or subcomponents, as well as any operations and portions of the flowcharts / flowsheets described herein and / or other examples described herein, may be implemented in hardware or in hardware combined with software and / or firmware, including as computer program code / instructions configured to execute in one or more processors and stored in a computer-readable storage medium, or as hardware logic / circuit, such as in a system-on-a-chip (SoC), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), trusted platform module (TPM), etc. An SoC may include an integrated circuit chip that includes a processor (e.g., a microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and / or additional circuitry and / or embedded firmware to perform its functions.

[0122] The embodiments described herein can be implemented in one or more computing devices similar to mobile systems and / or computing devices in fixed or mobile computer embodiments, including one or more features of the mobile systems and / or computing devices described herein, as well as alternative features. The description of the computing devices provided herein is for illustrative purposes and is not intended to be limiting. Embodiments can be implemented in other types of computer systems, as known to those skilled in the art(s).

[0123] The embodiments described herein can be implemented in one or more computing devices similar to mobile systems and / or computing devices in fixed or mobile computer embodiments, including one or more features of the mobile systems and / or computing devices described herein, as well as alternative features. The description of the computing devices provided herein is for illustrative purposes and is not intended to be limiting. Embodiments can be implemented in other types of computer systems, as known to those skilled in the art(s).

[0124] Figure 7 Exemplary implementations of a computing device 700 in which embodiments may be implemented are shown. For example, the embodiments described herein may be implemented in one or more computing devices similar to the computing device 700 in fixed or mobile computer embodiments, including one or more features and / or alternative features of the computing device 700. The description of the computing device 700 provided herein is for illustrative purposes and is not intended to be limiting. Embodiments may be implemented in other types of computer systems as known to those skilled in the art(s).

[0125] like Figure 7 As shown, computing device 700 includes one or more processors, referred to as processor circuitry 702, system memory 704, and a bus 706 coupling various system components, including system memory 704, to processor circuitry 702. Processor circuitry 702 is electronic and / or optical circuitry implemented in one or more physical hardware circuitry devices and / or integrated circuit devices (semiconductor chip or die) as a central processing unit (CPU), microcontroller, microprocessor, and / or other physical hardware processor circuitry. Processor circuitry 702 can execute program code stored in a computer-readable medium, such as program code for operating system 730, application 732, other programs 734, etc. Bus 706 represents any one or more of various types of bus architectures, including memory bus or memory controller, peripheral bus, accelerated graphics port, and processor or local bus using any of these bus architectures. System memory 704 includes read-only memory (ROM) 708 and random access memory (RAM) 710. Basic input / output system 712 (BIOS) is stored in ROM 708.

[0126] The computing device 700 also includes one or more of the following drives: a hard disk drive 714 for reading from and writing to a hard disk, a disk drive 716 for reading from or writing to a removable disk 718, and an optical disc drive 720 for reading from or writing to a removable optical disc 722, such as a CD-ROM, DVD-ROM, or other optical media. The hard disk drive 714, disk drive 716, and optical disc drive 720 are connected to the bus 706 via a hard disk drive interface 724, a disk drive interface 726, and an optical disc drive interface 728, respectively. The drives and their associated computer-readable media provide the computer with non-volatile storage of computer-readable instructions, data structures, program modules, and other data. While hard disks, removable disks, and removable optical discs have been described, other types of hardware-based computer-readable storage media can be used to store data, such as flash memory cards, digital video disks, RAM, ROM, and other hardware storage media.

[0127] Multiple program modules may be stored in a hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include an operating system 730, one or more applications 732, other programs 734, and program data 736. Applications 732 or other programs 734 may include, for example, computer program logic (e.g., computer program code or instructions) for implementing the embodiments described herein, such as, but not limited to, [other components]. Figure 1A System 100A, Figure 1B System 100B and / or Figure 3 The system 300, and any of its components and / or subcomponents, as well as the flowcharts / flow tables described herein, including portions thereof, and / or other examples described herein.

[0128] Users can input commands and information into the computing device 700 through input devices such as a keyboard 738 and a pointing device 740. Other input devices (not shown) may include a microphone joystick, game controller, satellite antenna, scanner, touchscreen and / or touchpad, voice recognition system for receiving voice input, gesture recognition system for receiving gesture input, etc. These and other input devices are typically connected to the processor circuitry 702 via a serial port interface 742 coupled to bus 706, but may also be connected via other interfaces such as a parallel port, game port, or Universal Serial Bus (USB).

[0129] Display screen 744 is also connected to bus 706 via an interface such as video adapter 746. Display screen 744 can be external to or incorporated into computing device 700. Display screen 744 can display information or serve as a user interface for receiving user commands and / or other information (e.g., via touch, finger gestures, virtual keyboard, etc.). In addition to display screen 744, computing device 700 may also include other peripheral output devices (not shown), such as speakers and printers.

[0130] Computing device 700 is connected to network 748 (e.g., the Internet) via an adapter or network interface 750, modem 752, or other means for establishing communication on the network. Modem 752 can be internal or external and can be connected to bus 706 via serial port interface 742, such as... Figure 7 As shown, another port type can be used to connect to bus 706, including the parallel interface.

[0131] As used herein, the terms “computer program medium,” “computer-readable medium,” and “computer-readable storage medium” are used to refer to physical hardware media, such as a hard disk associated with hard disk drive 714, removable disk 718, removable optical disk 722, other physical hardware media (e.g., RAM, ROM), flash memory cards, digital video disks, zip disks, MEM, nanotechnology-based storage devices, and other types of physical / tangible hardware storage media. Such computer-readable storage media are distinct from and do not overlap with communication media and propagation signals (excluding communication media or propagation signals). Communication media implement computer-readable instructions, data structures, program modules, or other data in modulated data signals (e.g., carrier waves). The term “modulated data signal” refers to a signal having one or more characteristics that are set or changed in a manner that encodes information in a signal. By way of example and not limitation, communication media include wireless media, such as acoustic, RF, infrared, and other wireless media, as well as wired media. Embodiments also relate to such communication media that are separate from and do not overlap with embodiments relating to computer-readable storage media.

[0132] As described above, computer programs and modules (including application 732 and other programs 734) can be stored on a hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage media. Such computer programs can also be received via network interface 750, serial port interface 742, or any other interface type. When executed or loaded by an application, such computer programs enable computing device 700 to implement the features of the embodiments described herein. Therefore, such computer programs represent a controller of computing device 700.

[0133] The embodiments also relate to computer program products that include computer code or instructions stored on any computer-readable medium. Such computer program products include hard disk drives, optical disk drives, memory device packages, memory sticks, memory cards, and other types of physical storage hardware.

[0134] IV. Additional Example Implementations

[0135] As described, systems and devices implementing the techniques described herein can be configured and enabled in various ways to perform their respective functions to enable concurrent schema and data modifications in query processing pushdown. In embodiments, one or more steps or operations of any flowcharts and / or process tables described herein may not be performed. Furthermore, steps or operations appended to or replacing those in any flowcharts and / or process tables described herein may be performed. Additionally, in examples, one or more operations of any flowcharts and / or process tables described herein may be performed out of order, in an alternative order, or partially (or completely) concurrently with each other or with other operations.

[0136] As described herein, systems, devices, components, etc., configured to perform functions and / or operations in embodiments are also contemplated to perform such functions and / or operations.

[0137] The embodiments described herein also include distinguishing aspects of distributed query processing systems. For example, in distributed query processing, metadata may be stored on remote or linked servers and retrieved or read by the primary compute node when a query needs to be compiled. In this case, remote queries can be delegated without transmitting metadata to the remote server, as the metadata already exists and is maintained there. In contrast, the embodiments described herein consider metadata that is on or maintained by compute nodes, where a subset of the database's data pages may be stored on or managed by each page server, but no single page server has the complete metadata dataset of the database. According to the described embodiments, the metadata required by the page server to perform a pushdown query operation is serialized at the compute node and then provided to the page server to enable the compilation and execution of said operation thereon.

[0138] Based on the described embodiment of enabling concurrent architecture and data modification in query processing pushdown, a solution with unique components and configurations is provided to improve processing load and efficiency in compute node and page server systems, reduce memory pressure at compute nodes, and significantly reduce network bandwidth usage and I / O operations between compute nodes and page servers, while also providing faster completion times for operations, such as those via pushdown operations, which were previously unavailable for software-based services, let alone the specific embodiment of compute nodes and associated page servers described herein. Therefore, the described embodiment achieves improved query performance for analytical queries on large datasets.

[0139] The additional examples and embodiments described in this section may be applied to the examples disclosed in any other chapter or section of this disclosure.

[0140] This invention provides a method in a first page server of a distributed database system. The distributed database system also includes compute nodes. The first page server is configured to store data pages comprising data objects, maintain multiple versions of these data objects, and wherein each version corresponds to a version transaction associated with a version transaction identifier and a version commit timestamp. The method includes: receiving a query and a transaction context corresponding to the query from the compute nodes; determining which data objects stored on the first page server satisfy the query; for each such determined data object, determining which version of the determined data object should be included in a first query sub-result, thereby filtering out versions that should not be included, the determination being based on the transaction context; including a copy of each determined version in the first query sub-result; and returning the first query sub-result to the compute nodes.

[0141] In another embodiment of the above method, the transaction context is generated by the compute node in response to receiving a query. The transaction context includes: a commit history table and a snapshot of each of the aborted transaction graphs, wherein the commit history table includes: a transaction identifier and a transaction commit timestamp for each of one or more transactions previously committed to the database, and wherein the aborted transaction graph includes the transaction identifier for each of one or more transactions previously aborted and not committed to the database; a snapshot timestamp corresponding to the snapshot taking time; and the maximum useful transaction identifier.

[0142] In another embodiment of the above system, determining which version of the corresponding determined data object should be included in the first query sub-result based on the transaction context includes: for each version of the corresponding determined data object: determining the version commit timestamp of the version transaction corresponding to the corresponding version based on the commit history table; determining that the corresponding version of the corresponding determined data object should be included in the result set only if: the version transaction identifier corresponding to the corresponding version is not included in the aborted transaction graph; the version transaction identifier corresponding to the corresponding version is less than the maximum useful transaction identifier; and the snapshot timestamp is greater than the version commit timestamp.

[0143] Embodiments of the above method further include: receiving a first query sub-result at a computing node; and providing query results based on the first query sub-result without further filtering the first query sub-result.

[0144] In embodiments of the above method, the distributed database system further includes a second page server, and the method further includes: receiving a query and a transaction context on the second page server, the second page server being configured to execute the query to generate a second query sub-result; receiving the second query sub-result on the compute node; and the compute node then providing a query result based on a combination of the first and second query sub-results.

[0145] This paper presents a distributed database system. The distributed database system includes a distributed database that stores pages comprising relational tables, at least one relational table capable of maintaining multiple versions of at least one row in the corresponding table, each version corresponding to a version transaction associated with a version transaction identifier and a version commit timestamp. The distributed database system includes: a first page server configured to store a subset of the pages of the distributed database; a primary compute node maintaining a set of table schemas, subsets of which correspond to the relational tables of the page subsets; the primary compute node being configured to: receive a first query; collect a first query table schema for each table referenced by the first query; for each collected first query table schema, modify the identifier of the corresponding schema to be globally unique, thereby generating a first modified query table schema; generate a transaction context corresponding to the first query; push down the first modified query table schema, transaction context, and first query to the first page server; the first page server is further configured to: receive the first modified query table schema, transaction context, and first query from the primary compute node; execute the received first query using the first modified query table schema to generate a first query result; and return the first query result to the primary compute node.

[0146] In the above embodiments of the distributed database system, the identifiers of the corresponding architecture include one or more of the following: table name; table identifier; object identifier; and row set identifier.

[0147] In the above-described distributed database system embodiment, the transaction context includes: a commit history table and a snapshot of each of the aborted transaction graphs, wherein the commit history table includes a transaction identifier and a transaction commit timestamp for each of one or more previously committed transactions to the database, and wherein the aborted transaction includes a transaction identifier for each of one or more previously aborted transactions that were not committed to the database; a snapshot timestamp corresponding to the snapshot taking time; and a maximum useful transaction identifier.

[0148] In the above-described distributed database system embodiment, the first page server is further configured to execute the received first query by: identifying rows that satisfy the first query, and for each such row for which multiple versions are maintained, filtering out versions of the corresponding rows that should not be returned in the first query result, the filtering transaction context; including a copy of each unfiltered row in the first query result; and returning the first query result to the main computing node.

[0149] In the above-described distributed database system embodiment, filtering out versions of the corresponding rows that should not be returned in the first query result includes, for each corresponding version: determining the version commit timestamp of the version transaction corresponding to the corresponding version of the corresponding row based on the commit history table; determining that the corresponding version of the corresponding row should be filtered out and not returned in the first query result in the following cases: finding a version transaction identifier corresponding to the corresponding version of the corresponding row in the aborted transaction graph; the version transaction identifier corresponding to the corresponding version of the corresponding row is greater than the maximum available transaction identifier; or the snapshot timestamp is less than the version commit timestamp.

[0150] The above-described embodiments of the distributed database system further include: receiving the first query result at the primary computing node; and the primary computing node providing query results based on the first query result without further filtering the first query result.

[0151] In the above-described distributed database system embodiment, the main computing node is further configured to: receive a schema modification command; and execute the schema modification command to perform a transaction that modifies at least one schema in the schema of the first query table, wherein the transaction generates a transaction log record.

[0152] The above-described distributed database system embodiment further includes: a secondary computing node; a log server configured to receive transaction log records from the primary computing node, permanently store the transaction log records in a cache, and then copy the transaction log records to the primary page server and the secondary computing node.

[0153] The above-described distributed database system embodiment also includes a second page server configured to: receive a first query and a first transaction context from the primary computing node after the transaction log records have been copied to the first page server; execute the first query to generate a second query result, wherein the primary computing node is further configured to: receive the second query result from the second page server; and provide a final query result based on a combination of the first and second query results.

[0154] In the above-described distributed database system embodiment, the secondary computing node is configured to: receive a second query before the replication of the transaction log to the secondary computing node is complete; collect a second query table schema for each table referenced by the second query, at least one second query table schema corresponding to a schema modified by a schema modification command; for each collected second query table schema, modify the identifier corresponding to the corresponding schema to be globally unique, thereby generating a second modified query table schema; push down the second modified query table schema and the second query to the first page server; the first page server is further configured to concurrently execute the first query and the second query by: receiving the second modified query table schema and the second query from the secondary computing node; using the second modified query table schema to execute the received second query to generate a third query result; and returning the third query result to the secondary computing node.

[0155] This document provides a system for a distributed database including pages for storing data. The system includes: a primary compute node; a first page server configured to store a subset of pages in the distributed database and execute pushdown queries provided by the primary compute node, the scope of which is limited to the stored subset of pages; the primary compute node being configured to: maintain a set of table schemas corresponding to relational tables stored in the distributed database pages; receive queries; identify a set of table schemas corresponding to the queries; generate a set of modified table schemas by generating modified table schemas based on the table schemas in the table schema set corresponding to each table in the identified table set; send a request to the first page server including the pushdown query and the set of modified table schemas, wherein the first page server is further configured to use the set of modified table schemas to generate and return query results, wherein the query results include data stored on the first page server that satisfies the query; and receive the query results from the first page server.

[0156] In embodiments of the above system, generating a modified table schema includes generating at least a partial copy of the table schema, the partial copy including an identifier of the copied table schema that is modified to be globally unique.

[0157] In one embodiment of the above system, the identifier of the replicated table schema includes one or more of the following: table name; table identifier; object identifier; and row set identifier.

[0158] In an embodiment of the above system, the primary computing node is further configured to: receive a schema modification command; and execute the schema modification command to perform a transaction that modifies at least one schema in the schema set, the transaction generating a transaction log record.

[0159] The embodiments of the above system also include: a log server configured to receive transaction log records from the primary compute node, permanently store the transaction log records in a cache, and then copy the transaction log records to the first page server and the secondary compute node.

[0160] V. Conclusion

[0161] While various embodiments of the disclosed subject matter have been described above, it should be understood that they are presented by way of example only and not as limitations. Those skilled in the art will understand that various changes in form and detail may be made therein without departing from the spirit and scope of the embodiments as defined by the appended claims. Therefore, the breadth and scope of the disclosed subject matter should not be limited to any of the exemplary embodiments described above, but should be defined solely by the appended claims and their equivalents.

Claims

1. A method in a first page server of a distributed database system, the distributed database system further comprising a compute node, the first page server configured to store data pages of a database, the pages comprising data objects, for which data objects a plurality of versions of the objects are maintained, and wherein each version corresponds to a version transaction associated with a version transaction identifier and a version commit timestamp, the method comprising: receiving, from the compute node, a query and a transaction context corresponding to the query, the transaction context comprising: a snapshot of each of a commit history table and an aborted transactions graph, wherein the commit history table comprises a transaction identifier and a transaction commit timestamp for each of one or more transactions that were previously committed to the database, and wherein the aborted transactions graph comprises a transaction identifier for each of one or more transactions that were previously aborted and not committed to the database; a snapshot timestamp corresponding to the time at which the snapshot was taken; and a maximum useful transaction identifier; determining which data objects stored on the first page server satisfy the query; determining, for each such determined data object, which version of the respective determined data object should be included in a first query sub-result based on the transaction context; including a copy of each determined version in the first query sub-result; and returning the first query sub-result to the compute node.

2. The method of claim 1, wherein determining which version of the respective determined data object should be included in the first query sub-result comprises, for each version of the respective determined data object: determining, based on the commit history table, the version commit timestamp of the version transaction corresponding to the respective version; and determining that the respective version of the respective determined data object should be included in a result set only if: the version transaction identifier corresponding to the respective version is not included in the aborted transactions graph; the version transaction identifier corresponding to the respective version is less than the maximum useful transaction identifier; and the snapshot timestamp is greater than the version commit timestamp.

3. The method of claim 1, further comprising: receiving the first query sub-result at the compute node; and the compute node providing a query result based on the first query sub-result without filtering the first query sub-result.

4. The method of claim 1, wherein the distributed database system further comprises a second page server, the method further comprising: receiving the query and transaction context at the second page server, the second page server configured to execute the query to generate a second query sub-result; receiving the second query sub-result at the compute node; and the compute node then providing a query result based on a combination of the first query sub-result and the second query sub-result.

5. The method of claim 1, wherein determining, for each version of the respective determined data object, which version of the respective determined data object should be included in the first query sub-result comprises: ​ ​ ​ based on the commit history table, determining a version commit timestamp of the version transaction corresponding to the respective version of the respective row; and determining that the respective version of the respective row should be filtered out and not returned in the first query result in the following cases: the version transaction identifier corresponding to the respective version of the respective row is found on the aborted transactions graph; the version transaction identifier corresponding to the respective version of the respective row is greater than the maximum useful transaction identifier; or the snapshot timestamp is less than the version commit timestamp.

6. A distributed database system comprising a distributed database storing pages, the pages comprising relational tables, at least one relational table being capable of maintaining multiple versions of at least one row of the respective table, each version corresponding to a version transaction associated with a version transaction transaction identifier and a version commit timestamp, the distributed database system comprising: a first page server configured to store a subset of the pages of the distributed database; and a primary compute node maintaining a set of table schemas, a subset of the set of table schemas corresponding to the relational tables of the subset of the pages, the primary compute node being configured to: receive a first query; collect a first query table schema for each table referenced by the first query; for each first query table schema collected, modify an identifier of the respective schema to be globally unique, thereby generating a first modified query table schema; generate a transaction context corresponding to the first query; and push the first modified query table schema, the transaction context, and the first query down to the first page server; the first page server being further configured to: receive the first modified query table schema, the transaction context, and the first query from the primary compute node; execute the received first query using the first modified query table schema to generate a first query result; and return the first query result to the primary compute node.

7. The distributed database system of claim 6, wherein the identifier of the respective schema comprises one or more of: a table name; a table identifier; an object identifier; and a row set identifier.

8. The distributed database system of claim 6, wherein the transaction context comprises: a snapshot of each of a commit history table and an aborted transactions graph, wherein the commit history table comprises a transaction identifier and a transaction commit timestamp for each of one or more transactions previously committed to the database, and wherein the aborted transactions comprises a transaction identifier for each of one or more transactions previously aborted and not committed to the database; a snapshot timestamp corresponding to the time at which the snapshot was taken; and a maximum useful transaction identifier.

9. The distributed database system of claim 6, wherein the first page server is further configured to execute the received first query by: ​ ​ ​ identifying rows that satisfy the first query and, for each such row for which multiple versions are maintained, filtering out the version of the respective row that should not be returned in the first query result, the filtering being based on the transaction context; including in the first query result a copy of each row that is not filtered out; and returning the first query result to the primary compute node.

10. The distributed database system of claim 8, wherein filtering out the version of the respective row that should not be returned in the first query result comprises, for each version of the respective row: based on the commit history table, determining a version commit timestamp of the version transaction corresponding to the respective version of the respective row; and determining that the respective version of the respective row should be filtered out and not returned in the first query result in the following cases: the version transaction identifier corresponding to the respective version of the respective row is found on the abort transaction graph; the version transaction identifier corresponding to the respective version of the respective row is greater than the maximum useful transaction identifier; or the snapshot timestamp is less than the version commit timestamp.

11. The distributed database system of claim 6, wherein: the primary compute node is further configured to: receive the first query result; and provide a query result based on the first query result without further filtering of the first query result.

12. The distributed database system of claim 6, wherein the primary compute node is further configured to: receive a schema modification command; and execute the schema modification command to perform a transaction that modifies at least one schema in the first query table schema, the transaction generating a transaction log record.

13. The distributed database system of claim 12, further comprising: a secondary compute node; and a log server configured to accept the transaction log record from the primary compute node, permanently save the transaction log record to a cache, and then replicate the transaction log record to the first page server and the secondary compute node.

14. The distributed database system of claim 13, further comprising a second page server configured to: after the replication of the transaction log record to the first page server is complete, receive the first query and first transaction context from the primary compute node; and performing the first query to generate second query results; wherein the primary compute node is further configured to: receive the second query result from the second page server; and provide a final query result based on a combination of the first query result and the second query result.

15. The distributed database system of claim 14, wherein the secondary compute node is configured to: before the replication of the transaction log record to the secondary compute node is complete, receive a second query; gather a second query table schema for each table referenced by the second query, at least one second query table schema corresponding to a schema modified by the schema modification command; and wherein the secondary compute node is further configured to: provide a second query result based on the second query and the second query table schema. For each second query table schema collected, an identifier corresponding to the respective schema is modified to be globally unique, thereby generating a second modified query table schema; and The second modified query table schema and the second query are pushed down to the first page server; The first page server is capable of concurrently executing the first query and the second query by being further configured to: receive the second modified query table schema and the second query from the secondary compute node; execute the received second query using the second modified query table schema to generate a third query result; and return the third query result to the secondary compute node.

16. A system comprising a distributed database of pages storing data, the system comprising: a primary compute node; and a first page server configured to store a subset of pages of the distributed database and execute a pushed down query provided by the primary compute node, the query scoped to the stored subset of pages, the primary compute node being configured to: maintain a set of table schemas corresponding to relational tables stored in the distributed database pages; receive a query; identify a set of the relational tables corresponding to the query; generate a set of modified table schemas by generating, for each table in the identified set of tables, a modified table schema based on a table schema in the set of table schemas corresponding to the respective table; send a request to the first page server, the request including a pushed down query and the set of modified table schemas, wherein the first page server is further configured to generate and return a query result using the set of modified table schemas, wherein the query result includes data stored on the first page server that satisfies the query; and receive the query result from the first page server.

17. The system of claim 16, wherein generating a modified table schema comprises generating at least a partial copy of the table schema, the partial copy including an identifier of the copied table schema that is modified to be globally unique. The identifier of the copied table schema includes one or more of:

18. The system of claim 17, wherein, a table name; a table identifier; an object identifier; and a row set identifier.

19. The system of claim 16, wherein the primary compute node is further configured to: receive a schema modification command; and execute the schema modification command to perform a transaction that modifies at least one schema in the set of table schemas, the transaction generating a transaction log record.

20. The system of claim 19, further comprising: a log server configured to accept the transaction log record from the primary compute node, persist the transaction log record to a cache, and then replicate the transaction log record to the first page server and a secondary compute node. ​

Images