Optimized hybrid transaction and analytic processing architecture for real-time analytic queries

Abstract

Methods for copying transactional tables of a transactional database to an analytic database and maintaining updates to those transactional table representations are disclosed. Snapshots of the transactional table are provided to the analytic database via a transport mechanism, such as a data storage service or a data flow service, and stored in the analytic database. Then, checkpoints including portions of a change data capture log that have recorded transactional changes to the transactional table of the transactional database are provided to the analytic database via the same or different transmission mechanisms and used to submit those transactional changes to snapshot representations. The snapshot representation may be used in response to an incoming analytic query to provide real-time query results.

Description

Background Art

[0001] As organizations' technological capabilities to create, track, and retain information have continued to improve, a variety of different technologies have been developed to manage and store the growing wave of information. For example, database systems provide clients with many different dedicated or customized hardware and software configurations to manage the stored information. However, the amount of data that organizations must store and manage continues to increase, which often leads to a corresponding increase in the size and complexity of data storage and management technologies (such as database systems), which in turn increases the cost of maintaining the information.

[0002] New technologies increasingly seek to reduce the complexity and storage requirements of maintaining data while increasing the efficiency of data processing and querying. Challenges frequently arise in obtaining the correct configuration of data storage, processing, and querying so that these database systems can be efficiently configured to perform various functions for different workloads. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 A service provider network is shown that includes at least a transactional database service and an analytical database service so that clients of the service provider network can both maintain transactional data and run analytical queries against the transactional data in accordance with some embodiments.

[0004] Figure 2 Various components of a transactional database system including a database engine and a separate distributed database storage service are shown according to some embodiments.

[0005] Figure 3 A distributed storage system of a transactional database system according to some embodiments is shown.

[0006] Figure 4A Various components of an analytical database system configured to store data blocks for clients of an analytical database service using warm and cold storage tiers, wherein the warm storage tier includes one or more node clusters associated with the clients, are shown in accordance with some embodiments.

[0007] Figure 4B An example of a cluster of nodes of an analytical database system performing queries on transactional database data is shown in accordance with some embodiments.

[0008] Figure 5 is a flow diagram illustrating a process of maintaining a representation of a portion of a transactional data table from a transactional database system within an analytical database system, according to some embodiments.

[0009] Figure 6A process is shown for a handshake protocol for negotiating and defining configurations and parameters for maintaining a representation of a table stored in a transactional database at an analytical database, according to some embodiments.

[0010] Figure 7 is a flow diagram illustrating a process of initiating and executing a handshake protocol for negotiating and defining configurations and parameters for maintaining a representation of a table stored in a transactional database at an analytical database, according to some embodiments.

[0011] Figure 8 The use of a transport mechanism to provide snapshots and checkpoints from a transactional database to an analytical database is shown in accordance with some embodiments.

[0012] Fig.9A A process of processing transactional changes to a transactional table at a transactional database and providing the transactional changes in a checkpoint to a transport mechanism for replication at a representation of the transactional table at an analytical database is shown in accordance with some embodiments.

[0013] Fig. 9B A process is shown for receiving a checkpoint of transactional changes at an analytics database, which are then implemented to a representation of a transactional table maintained at the analytics database, in accordance with some embodiments.

[0014] Fig.10 is a flow diagram illustrating a process of implementing transactional changes to a representation of a transactional table, according to some embodiments, where delete events are first buffered and committed to a shadow table before being applied and committed to the representation as a batch.

[0015] Fig.11A -D shows a table representation maintained at the analysis database just before a given transaction number 1180 is implemented, and the corresponding shadow tables, checkpoints, and the state of the table as viewed by external clients of the analysis database, according to some embodiments.

[0016] Fig. 12A -D shows that just after transaction number 1180 is implemented according to some embodiments Fig.11A -D table representation, shadow tables, checkpoints, and status of table views.

[0017] Fig.13A -D shows at a point after transaction number 1180 is implemented according to some embodiments. Fig.11A -D table representation, shadow tables, checkpoints, and status of table views.

[0018] Fig.14 is a block diagram illustrating an example computing device that may be used in at least some embodiments.

[0019] Although embodiments are described herein by way of example with respect to several embodiments and illustrative figures, it will be appreciated by those skilled in the art that embodiments are not limited to the described embodiments or figures. It should be understood that the drawings and detailed descriptions of the drawings are not intended to limit the embodiments to the specific forms disclosed, but rather, are intended to cover all modifications, equivalents, and alternatives within the spirit and scope defined by the appended claims. The titles used herein are only for organizational purposes and are not intended to limit the scope of the specification or claims. The word "may" used throughout this application is used in a permissible sense (i.e., meaning possible) rather than in a mandatory sense (i.e., meaning must). Similarly, the words "include, including, and includes" mean including but not limited to.

[0020] It should also be understood that although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, without departing from the scope of the present invention, a first contact may be referred to as a second contact, and similarly, a second contact may be referred to as a first contact. Both the first contact and the second contact are contacts, but they are not the same contact. DETAILED DESCRIPTION

[0021] Various techniques related to hybrid transaction and analytical processing (HTAP) services are described. In some embodiments, a hybrid transaction and analytical processing system that may implement at least a transaction database and an analytical database may be used to maintain a table of transactional data at the transaction database and a replica of the table at the analytical database. According to some embodiments, such hybrid transaction and analytical processing services may be optimized for online transaction processing (OLTP) and online analytical processing (OLAP) related services. In order to maintain a replica or representation of the transactional table at the analytical database, a change data capture log of transactional changes made to the table at the transactional database may be provided to the analytical database and incrementally applied and committed to the representation.

[0022] Running analytical queries against a transactional data store of a transactional database may affect the performance of the transactional queries, affect the performance of the computing resources of the transactional database, and in some cases where it may be necessary to utilize materialized views and / or special indexes, cause the organization of database resources to become complex and / or challenging. In addition, it may be costly to scale the structure of the transactional data store of the transactional database so that it can be configured to handle analytical queries. On the other hand, "offloading" transactional data to an analytical database that is more optimized for analytical queries and analytical query management may be difficult to manually manage and / or result in lag (e.g., stale data). However, the technology presented in this article overcomes these challenges by utilizing an analytical database to run analytical queries against transactional data while minimizing the lag between the transactional data stored on the transactional database and the "shared" transactional data copy maintained on the analytical database, thereby resulting in real-time analysis of the data.

[0023] This specification continues with a general description of a service provider network that implements a hybrid transaction and analytical processing service that includes a transaction database service and an analytical database service, which is configured to maintain transaction data, allow querying of transaction data, and support multi-version concurrency control (MVCC). Next, various examples of hybrid transaction and analytical processing services are discussed, including different components / modules, or arrangements of components / modules that can be used as part of implementing the service. Next, several different methods and techniques for maintaining a representation of a transaction table of a transaction database service in an analytical database service are discussed, some of which are shown in the accompanying flow chart. For example, methods and techniques for executing a handshake protocol that can define parameters and functions of a hybrid transaction and analytical processing service are described. In addition, methods and techniques for buffering delete events of transaction changes received by an analytical database so that the delete events can be applied and submitted to the representation as a background operation of the analytical database are described. Finally, a description of an example computing system on which various components, modules, systems, devices, and / or nodes can be implemented is provided. Various examples are provided throughout the specification. It should also be understood by those of ordinary skill in the art that the preceding and following descriptions of the hybrid transaction and analytical processing service are logical descriptions and thus should not be construed as limitations on implementations of the hybrid transaction and analytical processing service or portions thereof.

[0024] Figure 1 A service provider network is shown that includes at least a transactional database service and an analytical database service so that clients of the service provider network can both maintain transactional data and run analytical queries against the transactional data in accordance with some embodiments.

[0025] In some embodiments, hybrid transaction and analytical processing services may be implemented within a service provider network, such as service provider network 100. In some embodiments, service provider network 100 may implement various computing resources or services, such as database services (e.g., relational database services, non-relational database services, map reduce services, data warehouse services), data storage services such as data storage service 120 (e.g., an object storage service or a block-based storage service that may implement a centralized data store for various types of data), and / or any other type of network-based service (which may include virtual computing services and various other types of storage, processing, analysis, communication, event processing, visualization, and security services not shown).

[0026] In some embodiments, a transactional database service, such as transactional database service 110, may be configured to store and maintain tables of transactional data items for clients of the transactional database service. For some clients of the transactional database service, if the tables of transactional data items are replicated and maintained in an analytical database service (e.g., analytical database service 150), both transactional data processing and query processing may be further optimized for the transactional data. In this way, the processing and / or computing resources of the transactional database service may remain focused on processing the transactional data without being distracted by potentially computationally intensive analytical query processing. By "outsourcing" such analytical query requests to the analytical database service, clients of the transactional database service may obtain near real-time analytical query results from the replicated tables in the analytical database service without limiting or consuming the computing resources of the transactional database service for transactional data processing.

[0027] In order to provide both the initial copy of the table (e.g., snapshot) to the analytical database service and the subsequent updates (e.g., checkpoints, or fragments / portions of the change data capture log) that should be applied to the snapshot in order to maintain the snapshot at the analytical database service, one or more additional services of the service provider network 100 may be used as a transport mechanism for the hybrid transactional and analytical processing service. For example, a data storage service, such as the data storage service 120, may be used to provide access to such snapshots and / or checkpoints for the analytical database system. In addition to (or in lieu of) the data storage service, a data streaming service, such as the data streaming service 130, may be used to stream the snapshots and / or checkpoints to the analytical database system. It should be understood by those of ordinary skill in the art that additional embodiments using other transport mechanisms may similarly implement the transmission of snapshots and checkpoints from the transactional database to the analytical database, and may include the use of other services 140 of the service provider network 100.

[0028] As shown in the figure, multiple access points (e.g., client endpoints) may be used so that clients can more directly access different services of the service provider network 100. For example, a client in client 170 may have an account for at least transaction database service 110 and analysis database service 150, and may be able to access these services of the service provider network 110 through network 160. In some embodiments, the same or different network connections may be used at these different access points. According to some embodiments, network 160 may represent the same network connection or multiple different network connections. For example, network 160 may generally cover various telecommunication networks and service providers that jointly implement the Internet. Network 160 may also include private networks, such as local area networks (LANs) or wide area networks (WANs) and public or private wireless networks. For example, a given client in client 170 and / or 180 and various network-based services of the service provider network 100 may be provisioned in an enterprise having its own internal network, respectively. In such embodiments, the network 160 may include the necessary hardware (e.g., modems, routers, switches, load balancers, proxy servers, etc.) and software (e.g., protocol stacks, accounting software, firewall / security software, etc.) to establish a networking link between a given client device and the Internet, as well as various network-based services between the Internet and the service provider network 100. It should be noted that in some embodiments, the clients 170 and / or 180 may communicate with the services of the service provider network 100 using a private network rather than the public Internet. For example, the clients 170, 180, and / or 190 may be provisioned within the same enterprise as the various services of the service provider network 100. In such cases, the clients 170, 180, and / or 190 may communicate with the various services of the service provider network 100 entirely through the private network 160 (e.g., a LAN or WAN that may use Internet-based communication protocols but is not publicly accessible).

[0029] In some embodiments, the system described herein may implement a network-based service that enables a client (e.g., a subscriber) to operate a data storage system in a cloud computing environment. In some embodiments, the data storage system may be a highly scalable and extensible enterprise-level database system. In some embodiments, queries may be stored for a database distributed across multiple physical resources, and the database system may be scaled up and down as needed. In various embodiments, the database system may work effectively with database schemas of various types and / or organizations. In some embodiments, a client / subscriber may submit queries in a variety of ways, for example, interactively submitting to the database system via a SQL interface. In other embodiments, external applications and programs may submit queries to the database system using an open database connection (ODBC) and / or a Java database connection (JDBC) driver interface.

[0030] Figure 2 Various components of a transactional database system including a database engine and a separate distributed database storage service are shown according to some embodiments.

[0031] In some embodiments, the transactional database system 200 described herein may implement a service-oriented architecture in some embodiments, in which the various functional components of the database system are essentially distributed. For example, the transactional database system 200 may be organized so that the basic operations of the database (e.g., query processing, transaction management, caching, and storage) are managed in layers that can be individually and independently scaled. For example, in some embodiments, the transactional database system 200 may include a database layer (which may include a single database engine head node and client-side storage system drivers), and a separate distributed storage system (which may include multiple storage nodes that collectively perform some operations that are traditionally performed in the database layer of existing systems).

[0032] As described in more detail herein, in some embodiments, some of the lowest level operations of a database (e.g., backup, repair, snapshot, recovery, log record manipulation, and / or various space management operations) may be offloaded from a database engine to a storage layer (or tier), such as a distributed storage system, and distributed across multiple nodes and storage devices. For example, in some embodiments, rather than the database engine applying changes to a database (or its data pages) and then sending the modified data pages to the storage layer, the application of changes to a stored database (and its data pages) may be the responsibility of the storage layer itself. In such embodiments, redo log records may be sent to the storage layer instead of modified data pages, after which redo processing (e.g., application of redo log records) may be performed in a distributed manner (e.g., by background processes). Log sequence numbers may be assigned to redo log records from a log sequence number space. In some embodiments, crash recovery (e.g., reconstruction of data pages from stored redo log records) may also be performed by the storage layer and may also be performed by distributed background processes.

[0033] In some embodiments, because only redo logs (not modified data pages) are sent to the storage layer, the network traffic between the database layer and the storage layer may be much less than existing database systems. In some embodiments, each redo log may be about one-tenth the size of the corresponding data page that has changes specified for it. It should be noted that the requests sent from the database layer and the distributed storage system may be asynchronous, and multiple such requests may be in flight at the same time.

[0034] Generally speaking, the primary requirement of a database, given a piece of data, is that it can eventually return that piece of data. To this end, a database may contain several different components (or layers), each of which performs a different function. For example, a traditional database may be thought of as having three layers: a first layer for performing query parsing, optimization, and execution; a second layer for providing transactionality, recovery, and persistence; and a third layer that provides storage on locally attached disks or on network attached storage. As noted above, previous attempts to scale traditional databases typically involve replicating all three layers of the database and distributing those replicated database instances across multiple machines.

[0035] In some embodiments, the transactional database system described herein may divide the functionality of the database system in a manner different from that in a traditional database, and may distribute only a subset of functional components (rather than a complete database instance) across multiple machines in order to implement scaling. For example, in some embodiments, a client-oriented layer may be configured to receive a request that specifies what data will be stored or retrieved but does not specify how to store or retrieve the data. This layer may perform request parsing and / or optimization (e.g., SQL parsing and optimization), while another layer may be responsible for query execution. In some embodiments, a third layer may be responsible for providing transactional and consistency of results. For example, this layer may be configured to enforce some of the so-called ACID properties, specifically, atomicity of transactions targeting the database, maintaining consistency within the database, and ensuring isolation between transactions targeting the database. In some embodiments, a fourth layer may then be responsible for providing persistence of stored data in the presence of various types of failures. For example, this layer may be responsible for change records, recovery from database crashes, management of access to the underlying storage volume, and / or space management in the underlying storage volume.

[0036] In various embodiments, a database instance may include multiple functional components (or layers), each of which provides a portion of the functionality of the database instance. In one such example, a database instance may include a query parsing and query optimization layer, a query execution layer, a transactional and consistency management layer, and a persistence and space management layer. As noted above, in some existing database systems, scaling a database instance may involve replicating the entire database instance one or more times (including all example layers), and then adding glue logic to stitch it together. In some embodiments, the system described herein may instead offload the functionality of the persistence and space management layer from the database layer to a separate storage layer, and may distribute the functionality across multiple storage nodes in the storage layer.

[0037] In some embodiments, the transactional database system described herein can maintain many structures of the upper half of the database instance, such as the query parsing and query optimization layer, the query execution layer, and the transactional and consistency management layer, but can redistribute at least part of the responsibility for backup, repair, snapshot, recovery, and / or various space management operations to the storage layer. Redistributing functionality in this manner and tightly coupling log processing between the database layer and the storage layer can improve performance, increase availability, and reduce costs compared to previous methods of providing scalable databases. For example, network and input / output bandwidth requirements can be reduced because only redo log records (which are much smaller in size than actual data pages) can be transported across nodes or retained in the latency path of write operations. In addition, data page generation can be performed independently on each storage node in the background (when the foreground processing allows) without blocking incoming write operations. In some embodiments, the use of non-overwriting storage of log structures can allow backup, repair, snapshot, point-in-time recovery, and volume growth operations to be performed more efficiently, for example, by using metadata manipulation rather than moving or copying data pages. In some embodiments, the storage layer can also be responsible for replicating data (and / or metadata associated with the data, such as redo log records) stored on behalf of clients across multiple storage nodes. For example, data (and / or metadata) may be replicated locally (e.g., within a single "availability zone" where a collection of storage nodes executes on its own physically distinct, independent infrastructure) and / or across availability zones within a single region or in different regions.

[0038] In various embodiments, the database system described herein may support standard or custom application programming interfaces (APIs) for various database operations. For example, the API may support operations for: creating a database, creating a table, altering a table, creating a user, dropping a user, inserting one or more rows into a table, copying values, selecting data from a table (e.g., querying a table), canceling or aborting a query, creating a snapshot, and / or other operations.

[0039] In some embodiments, the database layer of a database instance may include a database engine head node server that receives read and / or write requests from various client programs (e.g., applications) and / or subscribers (users), then parses the read and / or write requests and generates execution plans to perform the associated database operations. For example, a database engine head node may develop a series of steps necessary to obtain results for complex queries and joins. In some embodiments, a database engine head node may manage communications between the database layer of a database system and clients / subscribers, as well as communications between the database layer and a separate distributed storage system.

[0040] In some embodiments, the database engine head node may be responsible for receiving SQL requests from terminal clients through a JDBC or ODBC interface, and is responsible for performing SQL processing and transaction management (which may include locking) locally. However, rather than generating data pages locally, the database engine head node (or its various components) may generate redo log records, and may deliver them to appropriate nodes of a separate distributed storage system. In some embodiments, a client-side driver for a distributed storage system may be hosted on a database engine head node, and may be responsible for routing redo log records to a storage system node (or multiple nodes) that stores the fragments (or their data pages) for which those redo log records are directed. For example, in some embodiments, each fragment may be mirrored (or otherwise made durable) on multiple storage system nodes that form a protection group. In such embodiments, the client-side driver may track the nodes on which each fragment is stored, and may route the redo log to all nodes on which the fragment is stored (e.g., asynchronously and in parallel, substantially simultaneously) upon receiving a client request. Once the client-side driver receives an acknowledgment back from a write quorum of storage nodes in the protection group (which may indicate that the redo log record has been written to the storage node), the client-side driver may send an acknowledgment of the requested change to the database layer (e.g., to the database engine head node). For example, in an embodiment where data is made durable using a protection group, the database engine head node may not commit the transaction until and unless the client-side driver receives an acknowledgment from enough storage node instances that constitute a write quorum, which may be defined in the protection group policy for the data.

[0041] In some embodiments, the database layer (or more specifically, the database engine head node) may include a cache in which recently accessed data pages are temporarily maintained. In such embodiments, if a write request is received that targets a data page maintained in such a cache, the database engine may apply the changes to the copy of the data page maintained in its cache in addition to delivering the corresponding redo log record to the storage layer. However, unlike other database systems, the data page maintained in this cache may not be refreshed to the storage layer, and the data page may be discarded at any time (e.g., any time after the redo log record of the write request recently applied to the cached copy has been sent to the storage layer and confirmed). In different embodiments, the cache may implement any of a variety of locking mechanisms to control access to the cache in a manner that is at most one writer (or multiple readers) at a time. However, note that in embodiments that include such a cache, the cache may not be distributed across multiple nodes, but may only exist on the database engine head node of a given database instance. Therefore, there may be no cache coherence or consistency issues to manage.

[0042] In some embodiments, a client-side driver running on a database engine head node may expose a dedicated interface to the storage layer. In some embodiments, the client-side driver may also expose a traditional iSCSI interface to one or more other components (e.g., other database engines or virtual computing service components). In some embodiments, the storage of a database instance in the storage layer may be modeled as a single volume that can grow without limit in size and may have an unlimited number of IOPS associated with it. When creating a volume, a volume of a specific size, with specific availability / persistence characteristics (e.g., specifying how to replicate the volume), with an IOPS rate associated with it (e.g., both peak and continuous) and / or user-specified encryption may be created. For example, in some embodiments, a variety of different persistence models may be supported, and a user / subscriber may specify the number of replicas, zones or regions for its database and / or specify whether replication is synchronous or asynchronous based on its persistence, performance and cost goals.

[0043] In some embodiments, the client-side driver can maintain metadata about the volume, and can directly send asynchronous requests to each storage node necessary to fulfill the read request and write request, without the need for additional jumps between storage nodes. Volume metadata can indicate which protection groups and their corresponding storage nodes maintain which partitions of the volume. For example, in some embodiments, in response to a request to change the database, the client-side driver can be configured to determine the protection group and one or more nodes that are implementing the storage of the target data page, and the redo log record specifying the change is routed to those storage nodes. These read and write requests or separate synchronization requests can also include encrypted data, which contains a key for decrypting the data storage area of ​​the protection group to which the storage node belongs. Then, the storage node can be responsible for applying the changes specified in the redo log record to the target data page at some point in the future, including decrypting the received key and using the received key to decrypt the stored data to apply the changes specified in the redo log record. When the write is confirmed back to the client-side driver, the client-side driver can advance the point of volume persistence, and can confirm submission back to the database layer. As previously described, in some embodiments, the client-side driver may never send data pages to the storage node server. This not only reduces network traffic, but also eliminates the need for checkpoints or background writer threads that limited foreground processing throughput in previous database systems.

[0044] In some embodiments, because access to a log-structured data store of redo log records may consist of a series of sequential input / output operations (rather than random input / output operations), ongoing changes may be tightly packed together. It should also be noted that, compared to existing systems in which each change to a data page generates two input / output operations to a permanent data store (one for the redo log and one for the modified data page itself), in some embodiments, the system described herein may avoid this "write amplification" by merging data pages at a storage node of a distributed storage system based on receiving redo log records. The merge operation performed on the data page may utilize the received key to access the encrypted data page and redo log record at the storage node.

[0045] As previously described, in some embodiments, the storage layer of the transactional database system may be responsible for taking database snapshots. However, because the storage layer implements log-structured storage, taking a snapshot of a data page (e.g., a data block) may include recording a timestamp associated with the most recent redo log record applied to the data page / block (or a timestamp associated with the most recent operation that merged multiple redo log records to create a new version of the data page / block), and preventing garbage collection of the previous version of the page / block and any subsequent log entries until the recorded point in time. In such embodiments, taking a database snapshot may not require reading, copying, or writing data blocks as would be required when an off-volume backup strategy is employed. In some embodiments, the space requirements for a snapshot may be minimal, since only modified data will require additional space, but in addition to the active data set, the user / subscriber may be able to select how much additional space they want to reserve for snapshots on the volume. In different embodiments, snapshots may be discrete (e.g., each snapshot may provide access to all data in a data page as of a particular point in time) or continuous (e.g., each snapshot may provide access to all versions of data in a data page that exists between two points in time). In some embodiments, restoring to a previous snapshot may include logging a log record to indicate that all redo log records and data pages since the snapshot are invalid and may be garbage collected, as well as discarding all database cache entries after the snapshot point. In such embodiments, a roll forward may not be required because the storage system will apply the redo log records to the data blocks as requested and in the background across all nodes on a block-by-block basis, just as the storage system does in normal forward read / write processing, which may also utilize the received encryption key. Thus, crash recovery may be made parallel and distributed across nodes.

[0046] Figure 2An embodiment of a service system architecture that can be configured to implement a network-based service-based transactional database service is shown in FIG. In the illustrated embodiment, several clients (shown as clients 250a-250n) can be configured to interact with the transactional database system 200 via a network 260. The distributed storage service 210 can be implemented as a log structure storage using a single log sequence number space. It should be noted that in the case where one or more instances of a given component may exist, references to the component herein may be made in the singular or plural form. However, the use of any one form is not intended to exclude another form.

[0047] In various embodiments, Figure 2 The components shown may be implemented directly in computer hardware, as instructions executable directly or indirectly by computer hardware (e.g., a microprocessor or a computer system), or using a combination of these techniques. Figure 2 The components of may be implemented by a system comprising a plurality of computing nodes (or simply nodes), each of which may be similar to Fig.14 The computer system embodiments shown in and described below. In various embodiments, the functionality of a given service system component (e.g., a component of a database service or a component of a storage service) may be implemented by a specific node, or may be distributed across several nodes. In some embodiments, a given node may implement the functionality of more than one service system component (e.g., more than one database service system component).

[0048] In general, the client 250 may encompass any type of client that may be configured to submit a network-based service request (including a request for a database service) to a network-based service platform via the network 260. For example, a given client 250 may include a suitable version of a web browser, or may include a plug-in module or other type of code module that is configured to be an extension of the execution environment provided by the web browser or to be executed within the execution environment. Alternatively, the client 250 (e.g., database service client 250a to 250n) may include applications such as database applications (or their user interfaces), media applications, office applications, or any other applications that can utilize permanent storage resources to store and / or access one or more databases. In some embodiments, such applications may include sufficient protocol support (e.g., for a suitable version of the Hypertext Transfer Protocol (HTTP)) for generating and processing network-based service requests without having to implement comprehensive browser support for all types of network-based data. That is, the client 250 may be an application that is configured to interact directly with the network-based services of the service provider network 100. In some embodiments, client 250 may be configured to generate network-based service requests according to a representational state transfer (REST) ​​style network-based service architecture, a document- or message-based network-based service architecture, or another suitable network-based service architecture.

[0049] In some embodiments, client 250 (e.g., database service client) may be configured to provide network-based service-based storage access to a database to other applications in a manner that is transparent to these applications. For example, client 250 may be configured to integrate with an operating system or file system to provide storage according to a suitable variant of the storage model described herein. However, the operating system or file system may present different storage interfaces to the application program, such as the traditional file system hierarchy of files, directories and / or folders. In such embodiments, it may not be necessary to modify the application program to utilize the storage system service model. Instead, the details of the network-based service interface with the service provider network 100 may be coordinated by the client 250 and the operating system or file system on behalf of the application program running within the operating system environment.

[0050] Client 250 may transmit network-based service requests (e.g., read / repair data requests, etc.) to service provider network 100 and receive responses from the service provider network via network 260. In various embodiments, network 260 may include any suitable combination of networking hardware and protocols necessary to establish network-based communications between client 250 and transactional database system 200 of transactional database service 110.

[0051] In general, the transactional database service 110 may be configured to implement one or more service endpoints of a client of the service provider network 100, which may be configured to receive and process network-based service requests, such as requests to access a data page (or a record thereof). For example, the transactional database service 110 may include hardware and / or software configured to implement a particular endpoint so that HTTP-based network-based service requests directed to that endpoint are properly received and processed. In some embodiments, the transactional database service 110 may be implemented as a server system that is configured to receive network-based service requests from clients 250 and forward the network-based service requests to components of the transactional database system 200. In other embodiments, the transactional database service 110 may be configured to implement load balancing and other request management features of a number of different systems (e.g., in a distributed topology, such as a distributed topology) that are configured to dynamically manage large-scale network-based service request processing loads. Figure 2 and 3 ). In various embodiments, the transactional database service 110 may be configured to support REST-style or document-based (eg, SOAP-based) type network-based service requests.

[0052] In addition to serving as an addressable endpoint for clients' network-based service requests, in some embodiments, transactional database service 110 may implement various client management features. For example, transactional database service 110 may coordinate metering and accounting for client usage of network-based services (including storage resources), such as by tracking the identity of requesting client 250, the number and / or frequency of client requests, the size of data tables (or records thereof) stored or retrieved on behalf of client 250, the total storage bandwidth used by client 250, the storage class requested by client 250, or any other measurable client usage parameter. Transactional database service 110 may also implement a financial accounting and billing system, or may maintain a usage data database that may be queried and processed by external systems for reporting and billing of client usage activity. In certain embodiments, the transactional database service 110 may be configured to collect, monitor, and / or aggregate various storage service system operational metrics, such as metrics reflecting the rate and type of requests received from clients 250, the bandwidth utilized by such requests, system processing latency for such requests, system component utilization (e.g., network bandwidth and / or storage utilization within the storage service system), the rate and type of errors generated by requests, characteristics of stored and requested data pages or records thereof (e.g., size, data type, etc.), or any other suitable metrics. In some embodiments, such metrics may be used by system administrators to tune and maintain system components, while in other embodiments, such metrics (or relevant portions of such metrics) may be exposed to clients 250 so that such clients can monitor their use of the transactional database service 110.

[0053] In some embodiments, the transactional database service 110 may also implement user authentication and access control procedures. For example, for a given network-based service request to access a particular database, the transactional database service 110 may be configured to determine whether the client 250 associated with the request is authorized to access the particular database. The transactional database service 110 may determine such authorization by, for example, evaluating an identity, password, or other credential against a credential associated with the particular database, or evaluating the requested access to the particular database against an access control list for the particular database. For example, if the client 250 does not have sufficient credentials to access the particular database, the transactional database service 110 may deny the corresponding network-based service request, for example, by returning a response indicating an error condition to the requesting client 250. Various access control policies may be stored by the transactional database service 110 as a record or list of access control information.

[0054] It should be noted that while service provider network 100 may represent the primary interface by which clients 250 may access features of transactional database system 200 that implement transactional database service 110, the interface need not represent the only interface for such features. For example, an alternative API that may be different than the network-based service interface may be used to allow clients within the enterprise providing transactional database system 200 to bypass the network-based service.

[0055] Although not shown, in various embodiments, the distributed storage service 210 can be configured to interface with a backup data store, system, service, or device. Various data, such as data pages, log records, and / or any other data maintained by a distributed storage service internal client (e.g., transactional database service 110 or other virtual computing service) and / or an external client (e.g., clients 250a to 250n), can be sent to the backup data store.

[0056] It should be noted that in various embodiments, different storage policies may be implemented by the transactional database service 110 and / or the distributed storage service 210. Examples of such storage policies may include persistence policies (e.g., policies indicating the number of instances of a database (or its data pages) to be stored and the number of different nodes on which the instances of the database (or its data pages) will be stored) and / or load balancing policies (which may distribute the database or its data pages across different nodes, volumes, and / or disks in an attempt to balance request traffic). In addition, different storage policies may be applied by various services in the service to different types of stored items. For example, in some embodiments, the distributed storage service 210 may implement higher persistence for redo log records than for data pages.

[0057] In some embodiments, for example Figure 2As shown in , transactional database system 200 includes a respective database engine head node 220 and a distributed storage service 210 for each of a number of databases (which may or may not be visible to clients of the database system, which are shown as database clients 250a-250n). As shown in this example, one or more of database clients 250a-250n may access database engine head node 220 (e.g., head node 220a, head node 220b, or head node 220c, each of which is a component of a respective database instance) via network 260 (e.g., these components may be network addressable and accessible by database clients 250a-250n). However, in various embodiments, the distributed storage service 210 that may be employed by the transactional database system 200 to store database volumes (e.g., data pages of one or more databases, as well as redo log records and / or other metadata associated therewith) on behalf of database clients 250a-250n and to perform other functions of the transactional database system 200 described herein may or may not be network addressable and accessible to the storage clients 250a-250n. For example, in some embodiments, the distributed storage service 210 may perform various storage, access, change logging, recovery, log record manipulation, and / or space management operations in a manner that is invisible to the storage clients 250a-250n.

[0058] As described above, each database instance may include a single database engine head node 220, which receives requests (e.g., snapshot requests, etc.) from various client programs (e.g., applications) and / or subscribers (users), and then parses the requests, optimizes the requests, and generates execution plans to perform the associated database operations. Figure 2In the example shown, the query parsing, optimization and execution component 205 of the database engine head node 220a can perform these functions for queries received from the database client 250a and with the database instance of which the database engine head node 220a is a component. In some embodiments, the query parsing, optimization and execution component 205 can return a query response to the database client 250a, and the query response can include a write confirmation, a requested data page (or part thereof), an error message and / or other responses, as appropriate. As shown in this example, the database engine head node 220a can also include a client-side storage service driver 225, which can route read requests and / or redo log records to various storage nodes in the distributed storage service 210, receive a write confirmation from the distributed storage service 210, receive the requested data page from the distributed storage service 210, and / or return the data page, error message or other response to the query parsing, optimization and execution component 205 (which can return the data page, error message or other response to the database client 250a). The client-side storage service driver 225 may maintain mapping information about database volumes stored in the distributed storage service 210, so that a specific protection group for a partition maintaining the database volume may be determined. Read requests and redo log records may then be routed to storage nodes that are members of a protection group based on the partition of user data to which the read request is directed or to which the redo log record relates. The client-side storage service driver 225 may obtain encrypted keys for different protection groups of a data volume from the distributed storage service 210, and provide the encrypted keys to the respective storage nodes of the corresponding protection group, so that the client-side storage service driver sends the keys for the protection group to the storage nodes of each protection group when communicating with the storage nodes of the protection group.

[0059] In this example, the database engine head node 220a includes a data page cache 235, in which recently accessed data pages can be temporarily stored. Figure 2 As shown in , the database engine head node 220a may also include a transaction and consistency management component 230, which may be responsible for providing transactions and consistency in the database instance of which the database engine head node 220a is a component. For example, this component may be responsible for ensuring the atomicity, consistency, and isolation characteristics of the database instance and transactions directed to the database instance. Figure 2 As shown in , the database engine head node 220a may also include a transaction log 240 and an undo log 245, which the transaction and consistency management component 230 may employ to track the status of various transactions and roll back any locally cached results of uncommitted transactions.

[0060] It should be noted that Figure 2 Each of the other database engine head nodes 220 shown in FIG. 2 (eg, 220 b and 220 c ) may include similar components and may perform similar functions for queries received by one or more of the database clients 250 a - 250 n and for the corresponding database instances of which they are components.

[0061] In some embodiments, the distributed storage system (e.g., Figure 3 The distributed storage system 310 shown in ) can organize data in various logical data volumes, segments that are persistent among protection groups of storage nodes (which may include portions of user data space in the volume and segments for logs of the volume), fragments (which may be data stored on a single storage node in the protection group), and pages for storage on one or more storage nodes. For example, in some embodiments, each database is represented by a logical volume, and each logical volume is divided into segments on a set of storage nodes. The protection group may be composed of different storage nodes in the distributed storage service, which together make the segments persistent. Multiple fragments are used to make the segments persistent, where each fragment exists on a specific storage node among the storage nodes in the protection group.

[0062] In some embodiments, each data page is stored in a fragment so that each fragment stores a collection of one or more data pages and a change log (also referred to as a redo log) (e.g., a log of redo log records) for each data page stored therein. Thus, a change log may be a log record segmented to a protection group of which the fragment is a member. As described in detail herein, a storage node may be configured to receive a redo log record (which may also be referred to herein as a ULR) and merge the redo log record to create a new version of the corresponding data page and / or an additional or alternative log record (e.g., lazily and / or in response to a request for a data page or database crash). If the data volume is encrypted, such a merge operation may require obtaining an encryption key to perform the merge operation. In some embodiments, data pages and / or change logs may be mirrored across multiple storage nodes in a protection group (which may be specified by a client represented to maintain a database in a database system) according to a variable configuration. For example, in different embodiments, one, two, or three copies of data or change logs may be stored in each of one, two, or three different availability zones or regions according to a default configuration, a dedicated persistence preference, or a persistence preference specified by a client.

[0063] As used herein, the following terms may be used to describe the organization of data by a distributed storage system, such as distributed storage system 310 , according to various embodiments.

[0064] Volume: A volume can be a logical concept of a highly durable storage unit understood by users / clients / applications of a storage system. More specifically, a volume is a distributed storage area that appears to the user / client / application as a single consistent ordered log of write operations to various user pages of a database. Each write operation can be encoded in a user log record (ULR), which represents a logically ordered change to the content of a single user page within the volume. As noted above, ULRs may also be referred to as redo log records in this article. Each ULR may include a unique identifier (e.g., a logical sequence number (LSN)) assigned from the log sequence number space. Each ULR may be stored in one or more synchronization fragments in a distributed storage area of ​​a log structure, and the synchronization fragments form a protection group (PG), which maintains a partition (i.e., segment) of the user data space involved in the update indicated by the log record, so as to provide high persistence and availability for the ULR. A volume can provide an LSN-type read / write interface for a continuous byte range of variable size.

[0065] In some embodiments, a volume may consist of multiple extents, each of which is made persistent by a protection group. In such embodiments, a volume may represent a unit of storage consisting of a variable sequence of contiguous volume extents. Reads and writes to a volume may be mapped to corresponding reads and writes to the constituent volume extents. In some embodiments, the size of a volume may be changed by adding or removing volume extents from the end of the volume.

[0066] Fragment: A fragment may be a limited persistent storage unit assigned to a single storage node. Multiple fragments may be implemented in a protection group to persist segments. More specifically, a fragment provides limited best-effort persistence for a specific fixed-size byte range of data (e.g., as a permanent but non-redundant single point of failure of a storage node). In some cases, this data may be a mirror of user-addressable data, or in various embodiments, the data may be other data, such as volume metadata or erasure coding bits. A given fragment may be located on exactly one storage node. Within a storage node, multiple fragments may be located on each SSD, and each fragment may be limited to one SSD (e.g., a fragment may not span multiple SSDs). In some embodiments, a fragment may not need to occupy a contiguous area on an SSD; instead, an allocation map may exist in each SSD that describes the area owned by each fragment. As noted above, a protection group may consist of multiple fragments distributed across multiple storage nodes. In some embodiments, a fragment may provide an LSN-type read / write interface for a fixed-size contiguous byte range (where the size is defined at creation time). In some embodiments, each fragment may be identified by a fragment UUID (e.g., a universally unique identifier for the fragment).

[0067] Storage page: A storage page can be a block of memory, typically of a fixed size. In some embodiments, each page is a block of memory (e.g., of virtual memory, disk, or other physical memory) of a size defined by the operating system, and may also be referred to herein by the term "data block". More specifically, a storage page can be a group of consecutive sectors. Storage pages can be used as allocation units in SSDs, as well as units in log pages where headers and metadata exist. In some embodiments, and in the context of the database system described herein, the term "page" or "storage page" may refer to a similar block of a size defined by the database configuration, which size may typically be a multiple of 2, such as 4096, 8192, 16384, or 32768 bytes.

[0068] Log Page: A log page may be a type of storage page used to store log records (e.g., redo log records or undo log records). In some embodiments, the size of a log page may be the same as a storage page. Each log page may include a header containing metadata about the log page, such as metadata identifying the fragment to which it belongs. It should be noted that a log page is an organizational unit and may not necessarily be a unit of data included in a write operation. For example, in some embodiments, during normal forward processing, write operations may be written to the tail of the log one sector at a time.

[0069] Log Records: Log records (e.g., individual elements of a log page) may have several different classes. For example, a user log record (ULR) created and understood by a user / client / application of the storage system may be used to indicate a change to user data in a volume. A log record may contain metadata, such as a pointer or backlink indicating the previous LSN of the log record maintained at a particular fragment and / or the previous LSN in the log sequence number space. A control log record (CLR) generated by the storage system may also contain control information for tracking metadata such as the current unconditional volume persistent LSN (VDL). In some embodiments, a null log record (NLR) may be used as padding to fill unused space in a log sector or log page. In some embodiments, various types of log records may exist within each of these classes, and the type of log record may correspond to a function that needs to be called to interpret the log record. For example, one type may represent all the data of a user page in a compressed format using a particular compression format; a second type may represent a new value for a byte range within a user page; a third type may represent an increment operation on a sequence of bytes interpreted as an integer; and a fourth type may represent copying a byte range to another location within a page. In some embodiments, logging types may be identified by GUIDs (rather than integer or enumeration values), which may simplify version management and development, especially for URLs.

[0070] Payload: The payload of a log record can be data or parameter values ​​specific to a log record or a particular type of log record. For example, in some embodiments, there may be a set of parameters or attributes that most (or all) log records contain and that the storage system itself understands. These attributes can be part of a common log record header / structure, which can be relatively small compared to the sector size. In addition, most log records may contain additional parameters or data specific to the log record type, and this additional information can be considered to be the payload of the log record. In some embodiments, if the payload of a particular ULR is larger than the user page size, the particular ULR may be replaced with an absolute ULR (AULR) whose payload contains all the data of the user page. This enables the storage system to implement an upper limit on the size of the payload of the ULR, which is equal to the size of the user page.

[0071] It should be noted that in some embodiments, when storing log records in a segment log, the payload may be stored with the log header. In other embodiments, the payload may be stored in a separate location, and a pointer to the location where the payload is stored may be stored with the log header. In other embodiments, a portion of the payload may be stored in the header, and the remainder of the payload may be stored in a separate location. If the entire payload is stored with the log header, this may be referred to as in-band storage; otherwise, the storage may be referred to as out-of-band. In some embodiments, the payload of the maximum AULR may be stored out-of-band in a cold area of ​​the log (this is described below).

[0072] User Pages: A user page may be a (fixed-size) range of bytes and its alignment for a particular volume that is visible to users / clients of the storage system. A user page is a logical concept, and the bytes in a particular user page may or may not be stored as is in any storage page. The size of a user page for a particular volume may be independent of the storage page size for that volume. In some embodiments, the user page size may be configurable per volume, and different fragments on a storage node may have different user page sizes. In some embodiments, the user page size may be constrained to be a multiple of the sector size (e.g., 4KB) and may have an upper limit (e.g., 64KB). On the other hand, the storage page size may be fixed for the entire storage node and may not change unless the underlying hardware changes.

[0073] Data Page: A data page may be a type of storage page used to store user page data in compressed form. In some embodiments, each piece of data stored in a data page is associated with a log record, and each log record may contain a pointer to a sector (also referred to as a data sector) within the data page. In some embodiments, a data page may not contain any embedded metadata other than that provided by each sector. There may be no relationship between sectors in a data page. In practice, the organization into pages may exist only as an expression of the granularity of allocating data to segments.

[0074] Storage Node: A storage node can be a single virtual machine on which the storage node server code is deployed. Each storage node may contain multiple locally attached SSDs and may provide a network API for accessing one or more fragments. In some embodiments, various nodes may be on an active list or on a degraded list (for example, if the node is responding slowly or is otherwise impaired, but not completely unavailable). In some embodiments, a client-side driver may assist (or be responsible for) classifying nodes as active or degraded based on observed performance in order to determine whether and when the node should be replaced, and / or in order to determine when and how to redistribute data among various nodes. In some embodiments, multiple storage nodes may implement a protection group together.

[0075] SSD: As referred to herein, the term "SSD" may refer to a local block storage volume seen by a storage node, regardless of the type of storage employed by the storage volume, such as a magnetic disk, a solid-state drive, a battery-backed RAM, a non-volatile RAM device (e.g., one or more NV-DIMMs), or another type of permanent storage device. SSDs do not necessarily map directly to hardware. For example, in different embodiments, a single solid-state storage device may be broken up into multiple local volumes, where each volume is divided into multiple fragments and striped across multiple fragments, and / or a single drive may be broken up into multiple volumes simply for ease of management. In some embodiments, each SSD may store an allocation map at a single fixed location. This map may indicate which storage pages are owned by a particular fragment, and which of these pages are log pages (as opposed to data pages). In some embodiments, storage pages may be pre-allocated to each fragment so that forward processing may not require waiting for allocation. Any changes to the allocation map may need to be made persistent before the fragment uses the newly allocated storage page.

[0076] Figure 3 A distributed storage system of a transactional database system according to some embodiments is shown.

[0077] In some embodiments, the distributed storage system of the transactional database system may be similar to the distributed storage system 310 of the transactional database system 300, such as Figure 3In at least some embodiments, as part of a multi-tenant storage service, storage nodes 330-350 may store data for different clients. In some embodiments, transactional database system 300 may be a client of distributed storage system 310, which communicates with database engine head node 320 via interconnect 360. As shown in Figure 3 In the example shown in , the database engine head node 320 may include a client-side storage service driver 325. In this example, the distributed storage system 310 includes multiple storage system server nodes (including those server node storage systems shown as 330, 340 and 350), each of which includes storage for redo logs of data pages and their stored fragments, and hardware and / or software configured to perform various fragment management functions. For example, each storage system server node may include hardware and / or software configured to perform at least a portion of any or all of the following operations: replication (locally, e.g., within the storage node), merging redo logs to generate data pages, snapshots (e.g., create, repair, delete, etc.), log management (e.g., manipulating log records), crash recovery (e.g., determining candidate log records for volume recovery) and / or space management (e.g., for fragments). Each storage system server node may also have multiple additional storage devices (e.g., SSDs) on which data blocks may be stored on behalf of clients (e.g., users, client applications and / or database service subscribers). In some embodiments, the storage system server node can provide multi-tenant storage, thereby storing portions of different data volumes of different clients in the attached storage device. Correspondingly, the storage system server node can maintain a large number of permanent keys for different data volumes.

[0078] In some embodiments, Figure 3 As shown in , storage system server node 330 includes data pages 333, segment redo logs 335, segment management functions 337, monitors 349, and additional SSDs 371-378. Monitor 339 can report health statistics, performance measurements, and any other information to volume manager 312 for distributed storage system management. It should be understood by those of ordinary skill in the art that the label "SSD" may or may not refer to a solid-state drive, but may more generally refer to a local block storage volume regardless of its underlying hardware. Similarly, storage system server node 340 includes data pages 343, segment redo logs 345, segment management functions 347, and additional SSDs 381-388; and storage system server node 350 includes data pages 353, segment redo logs 355, segment management functions 357, and additional SSDs 391-398.

[0079] In some embodiments, each storage system server node in the distributed storage system 310 may implement a set of processes running on the node server's operating system that manages communications with the database engine head node 320 to, for example, receive redo logs, send back data pages, etc. In some embodiments, all data blocks written to the distributed storage system may be backed up to long-term and / or archival storage (e.g., in a remote key-value persistent backup storage system).

[0080] The distributed storage system 310 may also implement a storage control plane. The storage control plane may be one or more computing nodes configured to perform various different storage system management functions. For example, the storage control plane may implement a volume manager 312, which may be configured to maintain mapping information or other metadata for a volume, such as the current volume state, the current writer, a truncation table or other truncation information, or any other information of the volume as it persists in different segments, fragments, and protection groups that change. The volume manager 312 may be configured to communicate with a client of the storage system 310 (e.g., a client-side driver 325) so as to "mount" or "open" the client's volume, thereby providing the client-side driver 325 with mapping information, protection group policies, and various other information necessary to send write and read requests to the storage nodes 330-350. The volume manager 312 may be configured to provide the maintained information (including keys) to a storage client, such as a database engine head node 320 or a client-side driver 325, or to other system components, such as a recovery service agent implemented for a volume recovery / repair service 314. For example, volume manager 312 may provide a current volume status (eg, clean, dirty, or recovering), a current epoch indicator, and / or any other information about the data volume.

[0081] In some embodiments, the distributed storage system may implement a volume recovery / repair service 314. The volume recovery / repair service 314 may be configured to monitor or evaluate a current data volume state and, based at least in part on the evaluation, direct a recovery service agent to perform a recovery operation with respect to the data volume. For example, the volume recovery / repair 314 service may determine that the state of a particular data volume has remained in a recovery state for more than a time threshold and, in response, direct one or more recovery service agents to perform a recovery operation for the data volume.

[0082] In some embodiments, volume recovery / repair 314 may detect a recovery event for a data volume. For example, volume recovery / repair 314 may receive an indication from a client-side storage service driver 325 or a database engine head node 320 that a data volume cannot be reopened or used again by a write client. Additionally, the recovery event detection module may determine other recovery events that may include detecting that a lease for a data volume client-side storage service driver 325 or a database engine head node 320 has expired, or may receive a release request or command to evict a database engine head node 320 from another component of the database service 300. More generally, volume recovery / repair 314 may detect any event that may trigger or require the performance of a recovery operation.

[0083] The volume recovery / repair 314 may also implement a recovery service agent (not shown), which may be an individual or collection of computing systems, nodes, or devices configured to perform recovery operations. The recovery service agent may be provided or directed (from other computing resources of the distributed storage system 310 or another system of the service provider network 100) to perform recovery operations through the volume recovery / repair 314. If it is determined that the recovery operation for the same data volume has been completed, the recovery service agent may abort the execution of the recovery operation. In order to repair the data volume, it may be necessary to enable access to encrypted data of data stored at different storage nodes. Therefore, similar to the client-side storage service driver 325, the recovery service agent may receive a permanent key for an encrypted version of the data volume and send it to those storage nodes that store the data volume.

[0084] Figure 4A Various components of an analytical database system configured to store data blocks for clients of an analytical database service using warm and cold storage tiers, wherein the warm storage tier includes one or more node clusters associated with the clients, are shown in accordance with some embodiments.

[0085] In various embodiments, at least Figure 4A and 4B The components shown in the can be implemented directly in computer hardware (e.g., a microprocessor or computer system) as instructions that can be executed directly or indirectly, or using a combination of these techniques. For example, Figure 4A and 4B The components shown in the figure may be implemented by a system including a plurality of computing nodes (or nodes for short), each of which may be similar to Fig.14 400 and described below. In various embodiments, the functionality of a given system or service component (e.g., a component of the analytical database system 400) may be implemented by a particular node or may be distributed across several nodes. In some embodiments, a given node may implement the functionality of more than one service system component (e.g., more than one data store component).

[0086] The analytical database service 150 may be various types of data processing services that perform general or specialized data processing functions (e.g., querying transactional data tables, anomaly detection, machine learning, data mining, big data querying, or any other type of data processing operation). For example, the analytical database service 150 may include various types of database services (both relational and non-relational) for storing, querying, updating, and maintaining data, such as transactional data tables. Such services may be highly scalable and extensible enterprise-level database systems. Queries may be directed to databases in the analytical database service 150 that are distributed across multiple physical resources, and the analytical database system may be scaled up or down as needed.

[0087] In various embodiments, the analysis database service 150 may work effectively with database schemas of various types and / or organizations. In some embodiments, clients / subscribers may submit queries in a variety of ways, for example, interactively to the database system via an SQL interface. In other embodiments, external applications and programs may submit queries to the database system using an open database connectivity (ODBC) and / or Java database connectivity (JDBC) driver interface. For example, in some embodiments, the analysis database service 150 may implement a data warehouse service that utilizes one or more of the additional services of the service provider network 100 to perform a query or other portion of an access request with respect to data stored in a remote data store such as the cold storage tier 406 (or another data store within the data storage service 120, etc.) to implement query processing for distributed data sets.

[0088] In at least some embodiments, the analysis database service 150 can be a data warehouse service. Therefore, in the following description, the analysis database service 150 can be discussed in terms of various features or components that can be implemented as part of a data warehouse service, including a control plane, such as control plane 402. And processing node clusters 420, 430, and 440. It should be noted that such features or components can also be implemented in a similar manner for other types of data processing services, and therefore the following examples can be applicable to other types of data processing services, such as database services. The analysis database service 150 can implement one (or more) processing clusters attached to a database (e.g., a data warehouse). In some embodiments, these processing clusters can be designated as primary processing clusters and secondary processing clusters (or concurrent, additional, or burst processing clusters) that execute queries to the attached database warehouse.

[0089] In the embodiment where the analysis database service 150 is a data warehouse service, the data warehouse service can provide a variety of different data management services to the client, depending on its various needs. In some cases, the client may wish to store and maintain a large amount of data, such as transaction records, website analysis and measurement, sales record marketing, management reports, business process management, budget forecasts, financial reports, or many other types or types of data. The data use of the client can also affect the configuration of the data management system for storing data. For example, for certain types of data analysis and other operations, such as aggregation from the operation of a large data set of a small number of columns in each row, a multi-column database table can provide more efficient performance. In other words, the column information from the database table can be stored in the data block on the disk, rather than storing the entire row of the column in each data block (as in the traditional database solution). The following discussion describes various embodiments of the relational multi-column database system implemented as a data warehouse. However, various versions of the components discussed below can be equally suitable for implementing embodiments of various other types of relational database systems, such as row-oriented database systems. Therefore, the following examples are not intended to limit database systems of various other types or formats.

[0090] In some embodiments, storing table data in such a multi-column manner can reduce overall disk I / O requirements for various queries and can improve analytical query performance. For example, storing database table information in a multi-column manner can reduce the number of disk I / O requests performed when retrieving data into memory to perform database operations as part of processing a query (e.g., when retrieving all column field values ​​for all rows in a table), and can reduce the amount of data that needs to be loaded from disk when processing a query. Conversely, for a given number of disk requests, column field values ​​for more rows than necessary to process a query can be retrieved if each data block stores an entire table row. In some embodiments, using a compression method that matches the data type stored in the multi-column manner can further reduce disk requirements. For example, since each block contains uniform data (i.e., all column field values ​​of the same data type), disk storage and retrieval requirements can be further reduced by applying a compression method that is best suited for a particular column data type. In some embodiments, the space savings for storing data blocks containing only field values ​​of a single column on disk can be converted into space savings when the data is retrieved and then stored in system memory (e.g., when analyzing or otherwise processing the retrieved data).

[0091] The analytical database system 400 may be implemented by a variety of computing devices, such as custom or off-the-shelf computing systems, servers, or any other combination of computing systems or devices, such as described below with respect to Fig.14Various types of systems 1400 are described. Different subsets of these computing devices may be controlled by a control plane of analytical database system 400. For example, control plane 402 may provide a cluster control interface to clients or users who wish to interact with processing clusters, such as node clusters 420, 430, and 440 managed by control plane 402. For example, control plane 402 may generate one or more graphical user interfaces (GUIs) for clients, which may then utilize the one or more GUIs to select various control functions provided by a control interface for processing clusters 420, 430, and 440 hosted in data processing service 100. In some embodiments, control plane 402 may provide or implement access to various metrics collected for the performance of different features of data processing service 100, including processing cluster performance.

[0092] As discussed above, various clients (or customers, organizations, entities, or users) may wish to store and manage data using data processing service 100. Processing clusters 420, 430, and 440 may respond to various requests, including write / update / store requests (e.g., to write data to storage) or queries on data (e.g., such as server query language requests (SQL) for specific data). For example, multiple users or clients may access a processing cluster to obtain data warehouse services.

[0093] Processing clusters hosted by analytical database service 150, such as node clusters 420, 430, and 440, can provide an enterprise-level database query and management system that allows users to send data processing requests to be performed by the cluster, such as by sending queries. Processing clusters 420, 430, and 440 can perform data processing operations on data stored locally in the processing cluster and data stored remotely. For example, cold storage layer 406 may include backups or other data of databases stored in the cluster. In some embodiments, database data may not be stored locally in processing clusters 420, 430, or 440, but may be stored in cold storage layer 406 (e.g., where data is partially or temporarily stored in processing clusters 420, 430, or 440 to perform queries). Queries sent to processing clusters 420, 430, or 440 (or routed / redirected / assigned / assigned to processing clusters) can be for local data and / or remote data stored in the processing cluster. Therefore, the processing cluster can implement local data processing, such as local data processing, to plan and execute performance of queries on local data in the processing cluster and remote data processing clients.

[0094] The analytical database system 400 of the analytical database service 150 may implement different types or configurations of processing clusters. For example, different configurations 420, 430, or 440 may utilize various different configurations of computing resources, including but not limited to different numbers of computing nodes, different processing capabilities (e.g., processor size, power, custom or task-specific hardware, such as hardware accelerators for performing different operations such as regular expression searches or other data processing operations), different amounts of memory, different networking capabilities, etc. Therefore, for some queries, different configurations of processing clusters 420, 430, 440, etc. may provide different execution times. Figure 4A As shown in , node cluster 420 includes nodes 422, 424, and 426, node cluster 430 includes nodes 432, 434, 436, and 438, and node cluster 440 includes nodes 442 and 444. Different configurations of processing clusters can be maintained in different pools of available processing clusters to be attached to a database. In some embodiments, additional processing clusters can then be specifically assigned or allocated for use in executing queries to additional databases. The number of processing clusters attached to a database can change over time according to the selection techniques discussed below.

[0095] In some embodiments, the analysis database service 150 may have at least one processing cluster attached to the database, which may be a "primary cluster". In some embodiments, the primary cluster may be a reserved, allocated, permanent or otherwise dedicated processing resource that stores and / or provides access to the client's database. However, the primary cluster may be changed. For example, a different processing cluster may be attached to the database and then designated as the primary database (e.g., thereby allowing the old primary cluster to still be used as a "secondary" processing cluster or to be released to the processing cluster pool so that it can be attached to a different database). In some embodiments, techniques for resizing or changing to different configurations of the primary cluster may be performed. As determined, the available processing clusters that may also be attached to the database may be maintained (as previously noted) in different configuration type pools, which may be a set of preheated, preconfigured, initialized or otherwise prepared clusters that may be used to provide additional query performance capabilities in addition to the query performance capabilities provided by the primary cluster. The control plane 402 may manage the cluster pool by managing the size of the cluster pool (e.g., by adding or removing processing clusters based on the need to use different processing clusters).

[0096] According to some embodiments, as a database is created, updated, and / or otherwise modified, snapshots, copies, or other replicas of the database at different states may be stored in the cold storage tier 406. For example, a leader node or other processing cluster component may implement a backup agent or system that creates and stores database backups for a database to be stored as database data in the cold storage tier 406 and / or data storage service 120. The database data may include user data (e.g., tables, rows, column values, etc.) and database metadata (e.g., information describing a table that may be used to perform queries on the database, such as schema information, data distribution, range values, or other content descriptors for filtering portions of a table from a query, superblocks, etc.). In some embodiments, a timestamp or other sequence value indicating a version of the database data may be maintained so that the latest database data may be obtained, for example, by a processing cluster in order to perform a query. In at least some embodiments, the database data (e.g., the cold storage tier 406 data) may be considered the authoritative version of the data, and the data stored in the processing clusters 420, 430, and 440 for local processing (e.g., the warm storage tier 404) may be considered the cached version of the data.

[0097] The cold storage layer 406 may implement different types of data stores for storing, accessing, and managing data on behalf of the clients 410, 412, 414, etc., as a network-based service that enables the clients 410, 412, 414, etc. to operate a data storage system in a cloud or network computing environment. The cold storage layer 406 may also include various object or file data stores for placing, updating, and obtaining data objects or files. For example, one cold storage layer 406 may be an object-based data store that allows different data objects of different formats or types of data to be stored and managed based on a key value or other unique identifier that identifies the object, such as structured data (e.g., database data stored in different database schemas), unstructured data (e.g., different types of documents or media content), or semi-structured data (e.g., different log files, human-readable data in different formats such as JavaScript Object Notation (JSON) or Extensible Markup Language (XML)). In at least some embodiments, the cold storage layer 406 may be viewed as a data lake. For example, an organization may generate many different kinds of data that are stored in one or more collections of data objects in the cold storage layer 406. The data objects in the collection may include related or homogeneous data objects, such as a database partition of sales data, and unrelated or heterogeneous data objects, such as audio files and website log files. The cold storage layer 406 may be accessed via a programming interface (e.g., an API) or a graphical user interface. For example, the format-independent analytical database service 400 may access data objects stored in a data storage service via a programming interface.

[0098] As described above with respect to clients 170-190 and 250, clients 410, 412, 414, etc. may cover any type of client that can submit a network-based request to service provider network 200 via network 408 (e.g., also networks 160 and 260), wherein the request includes a request for a storage service (e.g., a request to query data analysis service 150, or a request to create, read, write, obtain, or modify data in cold storage tier 406 and / or data storage service 120, etc.).

[0099] Figure 4B An example of a node cluster of an analytical database system that performs queries on transactional database data according to some embodiments is shown. As shown in this example, a processing node cluster 430 may include a leader node 432 and compute nodes 434, 436, 438, etc. that can communicate with each other through an interconnect (not shown). The leader node 432 may implement a query plan 452 for generating a query plan, a query execution 454 for executing the query on the processing node cluster 430 that performs data processing, which may utilize remote query processing resources for remotely stored data (e.g., by utilizing one or more query execution time slots / queues 458). As described herein, each node in the main processing cluster 430 may include additional storage devices, such as additional storage devices 468a, 468b, and 468n, on which a database (or portion thereof) may be stored on behalf of a client (e.g., a user, a client application, and / or a storage service subscriber).

[0100] It should be noted that in at least some embodiments, query processing capabilities may be separate from the compute nodes, and thus in some embodiments, additional components may be implemented for processing queries. Additionally, it is possible that in some embodiments, none of the nodes in the processing cluster 430 is Figure 4B , but in reality different ones of the nodes in processing cluster 430 may serve as a leader node or otherwise direct the processing of queries for data stored in processing cluster 430. Although the nodes of a processing cluster may be implemented on separate systems or devices, in at least some embodiments, some or all of the processing clusters may be implemented as separate virtual nodes or instances on the same underlying hardware system (e.g., on the same server).

[0101] The leader node 432 can manage, for example, Figure 4A The discussed clients 410, 412, and 414, etc. The leader node 432 may receive the query 450 and return the query results 476 to the clients 410, 412, 414, etc. or to a proxy service (rather than communicating directly with the client application).

[0102] Leader node 432 may be a node that receives queries 450 (directly or routed to leader node 432 from various client programs (e.g., applications) and / or subscribers (users) and then parses the query and generates an execution plan (e.g., a query plan) to perform the associated database operations. More specifically, leader node 432 may perform a series of steps necessary to obtain the results of the query. Query 450 may be for data stored locally within a warm tier (e.g., at one or more of compute nodes 434, 436, or 438) implemented using local storage of processing cluster 430 and for data stored remotely in, for example, cold storage tier 406 (which may be implemented as part of data storage service 120, according to some embodiments). Leader node 432 may also manage communications between compute nodes 434, 436, and 438 that are directed to perform database operations on data stored in processing cluster 430. For example, node-specific query instructions 460 may be code generated or compiled by query execution 454 that is distributed by leader node 432 to various compute nodes among compute nodes 434, 436, and 438 to perform the steps required to execute query 450, including executing code at the individual compute nodes to produce intermediate results of query 450 that may be sent back to leader node 432. Leader node 432 may receive data and query responses or results from compute nodes 434, 436, and 438 in order to determine a final result 476 for query 450.

[0103] Database schemas, data formats, and / or other metadata information for data stored among the computing nodes, such as data tables stored in the cluster, may be managed and stored by the leader node 432. The query plan 452 may take into account remotely stored data by generating node-specific query instructions that include remote operations to be directed by individual computing nodes. Although not shown, in some embodiments, the leader node may implement a burst manager to send the query plan generated by the query plan 452 to be executed at another additional processing cluster, and return the results received from the burst processing cluster to the client as part of the results 476.

[0104] In at least some embodiments, result cache 456 may be implemented as part of leader node 432. For example, in some embodiments, when query results are generated, the results may also be stored in result cache 456 (or a pointer to a storage location where the results are stored in primary processing cluster 430 or in an external storage location). In some embodiments, result cache 456 may be used instead of other processing cluster capabilities by identifying queries to be executed that would otherwise be sent to another additional processing cluster, the query results being stored in result cache 456. In some embodiments, various caching strategies (e.g., LRU, FIFO, etc.) may be implemented for result cache 456. Although not described in detail herein, the results of a query may be stored in result cache 456 in addition to the query to be executed. Figure 4B , but the result cache 456 may be stored in other storage systems (eg, other storage services such as a NoSQL database and / or data storage service 120) and / or may store sub-query results.

[0105] Processing node cluster 430 may also include computing nodes, such as computing nodes 434, 436, and 438. The computing nodes may be implemented, for example, on a server or other computing device, such as described below with respect to Fig.14 464n, and each may include, for example, individual query processing "slices" defined for each core of a multi-core processor of a server, one or more query processing engines such as query engines 462a, 462b, and 464n to execute instructions 460 or otherwise execute portions of a query plan assigned to a computing node. Query engine 462 may access certain memory and disk space in order to process a portion of the workload of a query (or other database operation) sent to one or more of computing nodes 434, 436, or 438. Query engine 462 may access additional storage devices such as 468a, 468b, and 468n to perform local operations, such as local operations 466a, 466b, and 466n. For example, query engine 462 may scan data in additional storage device 468, access indexes, perform joins, semi-joins, aggregations, or any other processing operations assigned to computing nodes 434, 436, or 438.

[0106] The query engine 462a may also direct the execution of remote data processing operations by providing remote operations, such as remote operations 464a, 464b, and 464n, to remote data processing clients, such as remote data processing 470a, 470b, and 470n. The remote data processing 470 may be implemented by a client library, plug-in, driver, or other component that sends a request subquery or request for data 472a, 472b, and 472n to be executed by the cold storage layer 406. As noted above, in some embodiments, the remote data processing 470 may, in response, read, process, or otherwise obtain data 474a, 474b, and 474n from the cold storage layer 406, which may additionally process, combine, and / or include the data with the results of the location operation 466.

[0107] Compute nodes 434, 436, and 438 may send intermediate results from the query back to leader node 432 for use in producing a final result (eg, combining, aggregating, modifying, joining, etc.) Remote data processing client 470 may retry a data request 472 that is not returned within a retry threshold.

[0108] Additional storage 468 may be implemented as any type of storage and / or storage system suitable for storing data accessible to the computing nodes, including but not limited to: a Redundant Array of Inexpensive Disks (RAID) device, a disk drive (e.g., a hard disk drive or a solid-state drive) or a disk drive array such as Just a Bunch of Disks (JBOD) (used to refer to disks not implemented according to RAID), an optical storage device, a tape drive, a RAM disk, a storage area network (SAN), a network access storage device (NAS), or a combination thereof. In various embodiments, the disk may be formatted to store database tables (e.g., in a column-oriented data format or other data format).

[0109] Although described and illustrated in the context of a service provider network implementing analytical database services (such as data warehouse services), Figure 4A and 4B ,but Figure 4A and 4B The various components shown and described in the can be readily applied to other database services that can utilize the methods and systems described herein. Figure 4A and 4B Other embodiments of maintaining and querying representations of transactional data tables of a managed database are not intended to be limiting.

[0110] Figure 5 is a flow diagram illustrating a process of maintaining a representation of a portion of a transactional data table from a transactional database system within an analytical database system, according to some embodiments.

[0111] In some embodiments, such as for the embodiments described herein, maintaining a representation of a transaction table at an analysis database may include the following procedural steps. Figure 5 In the following embodiments shown in , it may be assumed that the services of the provider network, such as the transaction database service 110 and the analysis database service 150 of the service provider network 100, and the functions and techniques described for the services described herein, can be used to implement hybrid transaction and analysis processing services. However, it should be understood by those skilled in the art that other implementations and / or embodiments that meet the following procedural steps may also be incorporated into the description herein.

[0112] In block 500, a portion of a table maintained at a transactional database, such as transactional database system 200 of transactional database service 110, may be copied to an analytical database, such as analytical database system 400 of analytical database service 150, and then maintained at the analytical database. In some embodiments, the means for maintaining a representation (e.g., a copy of a portion of a table from a transactional database) at the analytical database may use the procedures described in blocks 502-510.

[0113] In block 502, transactional changes made to transactional tables stored and maintained in a transactional database are written to a change data capture log, such as transaction log 240 (see also herein for details on Figure 6 In block 504, the portion of the table that has been selected for copying to the analysis database is divided into segments so that the segments can be provided to the analysis database. In some embodiments, such segments may be referred to as snapshots because they refer to the state of the table at a given moment (e.g., at a certain transaction number in an embodiment where the table contains transaction data). The snapshot may be provided to the analysis database via a transmission mechanism. In some embodiments, the transmission mechanism may be similar to a data storage service of the service provider network 100, such as the data storage service 120, or a data streaming service, such as the data streaming service 130 (see also the description of the transmission mechanism 826 herein). It should be understood by those of ordinary skill in the art that, depending on a given embodiment, "snapshots" may be plural or singular. For example, according to some embodiments, if only one portion of a transaction table is copied to the analysis database and can be provided as a unit (e.g., without further division) via a transmission mechanism, then "snapshot" may refer to the sum of the segments. In a second example, if a given portion of a given transaction table is divided into more than one segment, then "snapshot" may refer to the segments that sum to the portion of the table provided via the transmission mechanism. Additional example embodiments could be given, and the above examples should not be construed as limiting.

[0114] In block 506, the checkpoint is also provided to the analysis database. In some embodiments, the checkpoint may be similar to the portion of the transaction changes listed in the change data capture log of the transaction database for a given table portion being replicated. In some embodiments of the corresponding compute nodes of the node cluster that have stored more than one snapshot to the analysis database, the corresponding checkpoints may also be partitioned based on this same mapping. In some embodiments, the checkpoints may be provided to the analysis database via the same or different transport mechanism as the snapshots. For example, the snapshots may be provided via a data storage service, and subsequent checkpoints may be streamed to the analysis database via a data streaming service.

[0115] In block 508, the snapshot and the checkpoint are stored in the analysis database. In some embodiments, the snapshot and its associated checkpoint may be stored across multiple computing nodes of a node cluster of the analysis database (e.g., computing nodes 434-438 of node cluster 430). The snapshot stored at the analysis database may now be referred to as a representation of the transactional portion of the table maintained at the transactional database (see description of transactional table representation 820 described herein).

[0116] In block 510, the transactional changes provided in the checkpoint are applied and committed to the representation (see also herein for Figures 11A-13D) such that the representation is updated and maintained as a replica of the table stored in the transactional database. The process of receiving, applying, and committing additional checkpoints can continue as long as the hybrid transactional and analytical processing service maintains the representation in the analytical database. In addition, at any point after the first set of snapshots are stored in the analytical database, clients of the hybrid transactional and analytical processing service can run queries against the transactional data in the representation because the analytical database is configured with a simultaneous read / write feature (e.g., respond to queries and write, apply, and / or commit new transactional changes to the representation).

[0117] Figure 6 A process is shown for a handshake protocol for negotiating and defining configurations and parameters for maintaining a representation of a table stored in a transactional database at an analytical database, according to some embodiments.

[0118] In some embodiments, a handshake protocol between a computing device of a transactional database and a computing node of an analytical database may be used to determine the mathematical logic of how a representation of a transactional table of the transactional database will be maintained at the analytical database. By determining such parameters before providing an initial snapshot and defining a procedure for providing and mapping snapshots and checkpoints to computing nodes of a cluster of nodes in the analytical database, the transactional database and the analytical database may remain loosely coupled during the maintenance of the representation at the analytical database.

[0119] In some embodiments, transactional database 600 may be similar to transactional database 200 and transactional database 300 of transactional database service 110, and the functionality thereof described herein. Computing device 602 may be similar to corresponding database engine head node 220. Interface 604 (e.g., an SQL interface to a database system) may serve as a submission platform for database clients 250 that provide incoming transactions to transactional database 600. Storage device 606 may be similar to distributed storage system 310, in which transactional tables 608 and corresponding change data capture logs 610 for transactional tables 608 are stored.

[0120] According to some embodiments, analysis database 612 may be similar to analysis database system 400 of analysis database service 150. Compute node 614 may represent a compute node of a given node cluster, such as compute nodes 434-438 of node cluster 430. According to some embodiments, interface 616 (e.g., an SQL interface to a database system) may serve as a client endpoint for clients 170 and 190, where the clients may submit queries, such as query 450. Storage 618 may be similar to attached storage 468 of compute nodes 434-438, and / or a remote storage device such as cold storage tier 406. Storage 618 may be configured such that it may store one or more snapshots of transaction table 608 in order to maintain a corresponding representation at the analysis database.

[0121] In some embodiments, computing device 602 and / or computing node 614 may initiate a handshake procedure to prepare to maintain one or more transaction tables 608 at analysis database 612. According to some embodiments, maintaining a representation of transaction table 608 may follow the methods described at least in blocks 500 and 1000. In order to efficiently and effectively maintain a representation of transaction table 608 at analysis database 612, the handshake procedure may include a negotiation between computing device 602 and computing node 614 to determine data type mappings, topology requirements, compatible / incompatible data definition language commands that may be written to change data capture log 610 and / or interpreted by computing node 614. According to some embodiments, negotiation 622-654 may represent examples of information that may be exchanged and / or determined via computing device 602 and computing node 614. It should be understood by one of ordinary skill in the art that handshake protocol 620 is intended to be a visual representation of a negotiation between computing device 602 at transaction database 600 and computing node 614 at analysis database 612. Other negotiations of handshake protocol 620 besides negotiations 622-654 may additionally be included in performing handshake protocol 620, and negotiations 622-654 are intended to be example embodiments of methods and techniques described herein related to performing handshake protocol (see also the description of the embodiments of the present invention). Figure 7 ). In addition, the handshake protocol 620 may occur at the computing device 602, the computing node 614, or at both the computing device 602 and the computing node 614 through the interactions described in the following paragraphs. In addition, the handshake protocol 620 may involve a first phase in which the computing device 602 provides information from all or part of the negotiations 622-640 to the computing node 614, and then involve a second phase in which the computing node 614 may respond with all or part of the negotiations 642-654, or vice versa. In other embodiments, the handshake protocol 620 may be similar to a more iterative process. For example, the computing device 602 may provide a list of utilized data definition language commands 624, and the computing node 614 may respond with a list of known data definition language commands 642, and another iteration may occur related to the data definition language commands to determine and / or confirm the results of the handshake protocol related to the data definition language commands. Then, similar processes may occur for negotiations 626 and 644, etc. until the handshake protocol is completed.

[0122] In some embodiments, computing device 602 may provide a list 622 of portions of a table to be replicated, wherein the portions are portions of transactional table 608 to be stored and maintained by storage device 618 and computing node 614 at analysis database 612. By determining the portions of transactional table 608 to be maintained at analysis database 612, the list 622 of portions of a table to be replicated may also be used to determine a list of corresponding change data capture logs of change data capture logs 610 to be sent as checkpoints in order to maintain a transactional table representation at analysis database 612 based on the information in negotiation 622. In addition, according to some embodiments, computing device 602 may provide information about a primary key in primary key information 628 that corresponds to the list 622 of portions of a table to be replicated. In some embodiments, the primary key may correspond to a unique row identifier of the corresponding transactional table 608, so that when applying a transactional change to the representation of the transactional table 608, computing node 614 may identify the corresponding row. For example, a given transaction table in transaction tables 608 may contain an additional column of the table with a corresponding row identifier that can be used as a primary key (e.g., for each row in a given transaction table, row 1, row 2, row 3, etc.). In a second example, a concatenation of some subset of the columns of each row can be used as a primary key (e.g., a concatenation of the data items in column 1, column 2, and column 3 of the table). In a third example, the primary key for a given transaction table can be a concatenation of all the columns in each row (e.g., a "hash" of all the data items in each row). In some embodiments, computing device 602 can use negotiation 628 to inform computing node 614 that there is no current primary key scheme for list 622 of portions of the table to be replicated. In such embodiments, computing device 602 and computing node 614 can determine during handshake protocol 620 to use a concatenation of all the columns in each row (e.g., the "hash" example described above) as a method of transmitting information about rows of a given transaction table (e.g., transaction changes). In some embodiments, negotiation 628 may be referred to as determining logic for generating a corresponding primary key via a provided primary key scheme or by determining to use a concatenation of all columns in each row, or the like.

[0123] According to some embodiments, the negotiation results regarding the primary key information 628 may be used during the maintenance of the representation at the analysis database 612 because when providing a checkpoint to the computing node 614, the primary key scheme can be trusted as an agreed form of communication when referring to the corresponding rows of transaction changes to which the computing node 614 should apply the checkpoint.

[0124] The computing device 602 may also provide a list 624 of data definition language commands used when writing transaction changes to the change data capture log 610, and the computing node 614 may provide a list 642 of known data definition language commands. According to some embodiments, the negotiations 624 and 642 may be used to generate compatible and / or incompatible data definition language command lists. Such compatible / incompatible data definition language command lists may be used with respect to checkpoints that provide / receive portions of the change data capture log 610 during maintenance of a representation of the transaction table 608 at the analysis database 612. Since compatible / incompatible data definition language commands may be written to the handshake results 660 at the end of the handshake protocol 620, if the computing device 602 determines that an incompatible data definition language command is included in a given checkpoint during maintenance of a representation of the transaction table 608 (or determines that there are data definition language commands in a given checkpoint that are not part of the compatible data definition language command list), the computing device 602 may preemptively trigger a new snapshot of the given table (e.g., providing information below regarding Figure 8 Alternatively, if the compute node 614 determines that an incompatible data definition language command has been received as part of a given checkpoint, the compute node 614 may reactively request a new snapshot (e.g., as described below with respect to Figure 8 Requesting a new snapshot as discussed above 832).

[0125] In some embodiments, the computing device 602 may also provide a transactional database sharding strategy 626, wherein the computing device 602 may propose a method of how to proportionally split the list 622 of portions of the table to be replicated for storage in the storage device 618 of the analytical database 612. It should be understood by those of ordinary skill in the art that the storage capacity and / or the manner in which the storage capacity is distributed across the SSDs 371-398 of the distributed storage system 310 at the transactional database 600 may be different from the storage capacity and / or the manner in which the storage capacity is distributed across the additional storage device 468 and the cold storage tier 406 at the analytical database 612, and therefore, a negotiation regarding the mapping of the storage of the transactional table 608 at the transactional database 600 to the storage of the representation of the transactional table 608 at the analytical database 612 may be included in the handshake protocol 620. As part of the negotiation, the computing node 614 may additionally or alternatively propose an analytical database slicing strategy 644 regarding the storage capacity and / or the manner in which the storage capacity is distributed across the additional storage device 468 and the cold storage tier 406 at the analytical database 612.

[0126] According to some embodiments, the computing device 602 may additionally provide a proposed snapshot procedure 630 that may also be based on other negotiations 622-654. For example, the mapping procedure determined via the transactional database sharding strategy 626 and the analytical database slicing strategy 664 may further determine the manner in which the snapshot 622 of the portion of the table to be replicated is proportionally partitioned (e.g., preparing to store and maintain the portion of the table at multiple computing nodes in the computing nodes 614). In a second example, according to some embodiments, the proposed snapshot procedure 630 may be based on the proposed transport mechanism 638 and the proposed transport mechanism 652 (see the description continued in the following paragraphs), wherein the partitioning and / or size constraints of the determined transport mechanism may determine the proposed snapshot procedure 630. Furthermore, the computing node 614 may additionally or alternatively propose the snapshot procedure 646 as part of the negotiation of the handshake protocol 620. For example, depending on how the representation 622 of the portion of the table to be replicated will be distributed across the computing nodes 614 of a given node cluster, the computing node 614 may propose an optimized method for receiving a snapshot from the transactional database 600. The computing nodes 614 may also provide information about the structure of the analysis database 612 (e.g., the computing nodes 614 may propose one or more node clusters that may be used to store and maintain the list 622 of portions of the table to be replicated) via the map 648 of the computing node structure. For example, the map 648 of the computing node structure may provide information about the number of computing nodes in a given node cluster, information about the storage capacity of the computing nodes, etc. According to some embodiments, such information about the map 648 of the computing node structure may be used to determine a method for providing snapshots and checkpoints to the analysis database 612.

[0127] In some embodiments, computing device 602 may propose a checkpoint procedure 632 based at least in part on negotiations 630 and 646. Once a mapping is determined to provide snapshots to computing nodes 614 of a given node cluster at analysis database 612, computing device 602 may propose a corresponding mapping for checkpointing. Such a mapping for checkpointing may include a method for partitioning change data capture log 610 into checkpoints that may be provided using the determined transport mechanism (see descriptions of proposed transport mechanism 638 and proposed transport mechanism 652 herein).

[0128] The handshake protocol 620 may also include a negotiation with a client whose transaction tables in the transaction table 608 are to be maintained at the analytical database 612 via the methods and techniques described herein. For example, if the list 622 of portions of tables to be replicated is related to a client 170 of the transactional database service 110, client information 634 of the client 170 (e.g., a user name, a list of database engine head nodes 220 related to the client, and / or account information of the service provider network 100) may be written to the handshake result 660. Continuing with this example, according to some embodiments, the client 170 may also be a client of the analytical database service 150, in which case the computing node 614 may provide a list 650 of the client's node clusters. Furthermore, in addition to (or in response to) determining that the client 170 is a client of the transactional database service 110 and the analytical database service 150, the computing device 602 may request a certain node cluster 636 from the list 650 of the client's node clusters. It will be appreciated by one of ordinary skill in the art that the negotiations 634 , 636 , and 650 may occur iteratively, in combination with one another, or individually during the overall process of executing the handshake protocol 620 .

[0129] In some embodiments, one or more transport mechanisms may be used to provide snapshots and checkpoints to the analysis database 612 (see the description of blocks 504 and 506 herein). As part of the handshake protocol 620, the computing device 602 may propose a transport mechanism 638, and / or the computing node 614 may propose a transport mechanism 652. For example, the computing device 602 may propose to provide a snapshot via a given service (e.g., data storage service 120) of the service provider network 100 (e.g., provide snapshot 828). The computing node 614 may similarly propose to receive the snapshot in a proposed transport mechanism 652 (e.g., receive snapshot 830) via a given service (e.g., a transport mechanism that is the same or different than the transport mechanism proposed by the proposed transport mechanism 638) of the service provider network 100. During the negotiation 638 and 652, an agreed transport mechanism for providing snapshots to the analysis database 612 may be determined and written to the handshake result 660. In some embodiments, the negotiation 638 and 652 may also be used to determine an agreed transport mechanism for providing checkpoints to the analysis database 612, wherein the transport mechanism may be the same or different transport mechanism determined for providing snapshots. For example, computing device 602 and computing node 614 may determine via negotiations 638 and 652 that snapshots may be provided to analytics database 612 via a first transport mechanism (e.g., data storage service 120), and that checkpoints may be provided to analytics database 612 via a second transport mechanism (e.g., data streaming service 130).

[0130] One of ordinary skill in the art will appreciate that additional information (e.g., other information 640 and other information 654) may additionally be used to determine the outcome of handshake protocol 620, and that negotiations 622-654 are intended to be example embodiments rather than an exhaustive list of negotiations that may occur during execution of handshake protocol 620.

[0131] In some embodiments, after executing handshake protocol 620, the results of the determined parameters for maintaining a representation of the transaction table of transaction database 600 at analysis database 612 may be written to a data store accessible to transaction database 600 and analysis database 612, such as data store 658, via write handshake results 656. As discussed above, computing device 602 may write a portion of handshake results 660, and computing node 614 may write an additional portion of the handshake results via write handshake results 656, thereby producing handshake results 660, or alternatively, computing device 602 or computing node 614 may write the results of handshake protocol 620, thereby producing handshake results 660. Data store 658 may be located at a storage device accessible to transaction database 600 and analysis database 612. For example, according to some embodiments, data store 658 may be located in a given storage device of data storage service 120. In a second example, according to some embodiments, data store 658 may be located in storage of transactional database service 110 and data store 658 may be made accessible to analytical database service 150 such that read access is given to both transactional database 600 and analytical database 612 .

[0132] like Figure 6, transactional database 600 may read access data store 662, and analytical database 612 may read access data store 664. According to some embodiments, read access to data stores 662 and 664 may allow computing device 602 and computing node 614 to refer to handshake result 660 during the process of maintaining a representation of transaction table 608 at analytical database 612. For example, computing device 602 may use handshake result 660 to verify that transactional changes in a given checkpoint that it will provide (e.g., via providing checkpoint 834) to analytical database 612 do not contain incompatible data definition language commands listed in handshake result 660. In a second example, according to some embodiments, computing node 614 may use handshake result 660 to verify a determined transport mechanism through which analytical database 612 may expect to receive snapshots (e.g., via receiving snapshot 830). Such example embodiments describe a "loose coupling" of transactional database 600 and analytical database 612 after completing handshake protocol 620. By establishing standard processes and procedures for maintaining a representation of the transaction table at the analysis database 612 during the handshake protocol 620, subsequent processes (e.g., providing a snapshot 828, providing a checkpoint 834, requesting a new snapshot 832, requesting a new checkpoint 838, etc.) can be automated.

[0133] Furthermore, according to some embodiments, the determination results of the handshake results 660 may not be edited and / or written by the computing device 602 or computing node 614 via the read access data storage area 662 or 664. In some embodiments, updates or changes to the structure and / or configuration of the transaction database 600, the analysis database 612, and / or any other service of the service provider network 100 used as a transport mechanism (e.g., the data storage service 120, the data streaming service 130, etc.) may cause the handshake results 660 to become outdated. In some embodiments, it is determined that one or more of the determination results of the handshake results 660 should be updated or changed, the computing device 602, the computing node 614, or both the computing device 602 and the computing node 614 may re-initiate a new handshake protocol 620. According to some embodiments, one or more of the determined results may then be updated, modified, or changed based on executing the new handshake protocol 620, and the handshake results 660 may be overwritten by the updated determination results of the new handshake protocol 620.

[0134] Figure 7 is a flow diagram illustrating a process of initiating and executing a handshake protocol for negotiating and defining configurations and parameters for maintaining a representation of a table stored in a transactional database at an analytical database, according to some embodiments.

[0135] In some embodiments, methods and techniques for performing the handshake protocol 620 may be similar to Figure 7In block 700, according to some embodiments, a handshake protocol may be initiated to determine parameters for maintaining a representation of a transaction table of a transaction database at an analysis database. Figure 6 As described above, the handshake protocol may be initiated by the transactional database side, the analytical database side, or both of the hybrid transactional and analytical processing service. In block 702, the handshake protocol is executed. Blocks 704-710 may represent embodiments of negotiations that may occur during execution of the handshake protocol according to some embodiments. Blocks 704-710 are not an exhaustive list of negotiations, and Figure 7 Additional negotiations not shown in FIG. 7 may occur during execution of the handshake protocol (eg, block 702 ).

[0136] In box 704, a mapping that distributes the computing nodes of a given node cluster across the analysis database may be determined. In some embodiments, box 704 may be at least similar to negotiations 632 and 648 and their descriptions herein. In box 706, one or more transmission mechanisms for providing snapshots and checkpoints to the analysis database may be determined. In some embodiments, box 706 may be at least similar to negotiations 638 and 652 and their descriptions herein. In box 708, during the execution of the handshake protocol, the computing device of the transaction database and the computing node of the analysis database may agree on a data definition language command list. In some embodiments, box 708 may be at least similar to negotiations 624 and 642. In box 710, additional information may be determined during the execution of the handshake protocol so that additional parameters and / or functions for maintaining a representation of the transaction table at the analysis database may be defined. In some embodiments, box 710 may involve any additional negotiations that have not yet been determined in negotiations 622-654. Block 710 may additionally reference any negotiations that will facilitate "loose coupling" of the transactional and analytical databases after the handshake protocol is completed, as well as autonomous / automatic functions related to maintaining a representation of the transactional table at the analytical database.

[0137] In block 712, at least the results of the determinations of blocks 704-710 may be stored in a data store accessible to the transaction database and the analysis database. In some embodiments, the data store of block 712 may be similar to the data store 658 storing the handshake results 660.

[0138] Figure 8 The use of a transport mechanism to provide snapshots and checkpoints from a transactional database to an analytical database is shown in accordance with some embodiments.

[0139] In some embodiments, transaction database 800, computing device 802, interface 804, storage device 806, transaction table 808, and change data capture log 810 may be similar to transaction database 600, computing device 602, and interface 604 and their functions described herein. Similarly, analysis database 812, computing node 814, and interface 816 may be similar to analysis database 612, computing node 614, and interface 616 and their functions described herein. In some embodiments, Figure 8 Embodiments may be described in which one or more snapshots corresponding to transaction table 808 have been provided to analysis database 812 and corresponding representations have begun to be maintained at analysis database 812 (e.g., via the methods and techniques described by at least block 500). Figure 8 As shown in , portions of transaction table 808 may be provided to analysis database 812 via providing snapshot 828, transmission mechanism 826, and receiving snapshot 830. Portions of transaction table 808 may then be stored in transaction table representation 820 within storage device 818 according to some embodiments.

[0140] According to some embodiments, to maintain the transactional table representation 820, a checkpoint containing transactional changes of the change data capture log 810 may be provided to the analysis database 812 via providing checkpoints 834, transmission mechanism 826, and receiving checkpoints 836. According to some embodiments, the checkpoint may then be stored in a checkpoint 822 within the storage device 818. In addition, the storage device 818 may be used to maintain a shadow table 824, wherein delete events of the transactional changes of the checkpoint 822 may be buffered and committed before being later committed to the transactional table representation 820 (see at least Figure 10-13D description).

[0141] In some embodiments, snapshots and checkpoints may be provided to the analysis database 812 via one or more transport mechanisms 826 that have been determined during execution of the handshake protocol 620. Figure 8 , the transaction database 800 and the analysis database 812 may read access to the data store 846 (e.g., via read access 842 and 844, respectively) in order to read the handshake result 848. In a first example of implementing the transmission mechanism 826 using the data storage service 120, the snapshots and / or checkpoints may be provided to the transmission mechanism 826 via provide snapshot 828 and provide checkpoint 834 and stored in the data store of the data storage service 120. In some embodiments, the analysis database 812 may be provided access to the data store of the data storage service 120 so that the snapshots and checkpoints may be received to the analysis database 812 via receive snapshot 830 and receive checkpoint 836. In a second example of implementing the transmission mechanism 826 using the data streaming service 130, the snapshots and / or checkpoints may be streamed to the analysis database 812.

[0142] In some embodiments, the transfer mechanism 826 may be similar to a "push" or "pull" mechanism. For example, the transfer mechanism 826 may be implemented by the transactional database service 110, and the computing device 802 may be configured to "push" the snapshots and checkpoints to the analysis database 812 via a direct connection. Alternatively, the transfer mechanism 826 may be implemented by the analysis database service 150, and the computing node 814 may be configured to "pull" the snapshots and checkpoints from the transactional database 800 to the analysis database 812 via a directional connection. In some embodiments, the transfer mechanism 826 may also be configured to read access the data store 840, so that client account information, mappings, topologies, and / or other relevant information related to the transfer of snapshots and checkpoints can be viewed by the transfer mechanism 826.

[0143] Fig.9A A process of processing transactional changes to a transactional table at a transactional database and providing the transactional changes in a checkpoint to a transport mechanism for replication at a representation of the transactional table at an analytical database is shown in accordance with some embodiments.

[0144] In some embodiments, transaction database 900 may be configured to maintain a transaction table, such as table A, for a client of transaction database service 110. According to some embodiments, transaction database 900 may be similar to at least Figure 2 and 3 The configuration described in the for transaction database 200 and transaction database 300 and has the described functions. In addition, computing device 904 can be similar to computing device 602 and / or computing device 802, and its functions described in this document for the computing devices. It should be understood by a person of ordinary skill in the art that Fig.9A This is intended for illustrative purposes, and transaction database 900 may store additional transaction tables in addition to Table A. Transaction database 900 may include additional computing devices in addition to computing device 904 , and / or computing device 904 may be configured to maintain additional transaction tables in addition to Table A.

[0145] In some embodiments, the transactional database 900 may receive a new transaction / transactional change 902 for table A. The new transaction may include one or more additional rows of data items that may be inserted into table A, and the transactional change may include one or more changes to table A (e.g., deleting a row of data items, updating a row of data items, etc.). According to some embodiments, the computing device 904 may then perform transactional changes 906 on table A 908, where portions of table A may be distributed across multiple storage system server nodes of the distributed storage system 310. In addition, for each transactional change 906 applied to table A 908, the transactional change is written to a change data capture log 912 via writing the transactional change to a change data capture log 910. At a given point during maintenance of table A, a checkpoint containing a portion of the change data capture log 912 may be provided to a transport mechanism 916 via providing a checkpoint 914 related to table A. In some embodiments, via at least one of the embodiments described herein, Figure 8 The described methods and techniques provide checkpoints to a transport mechanism 916. In addition, the frequency of checkpoints provided, the transport mechanism used to provide the checkpoints, and additional configuration of the checkpoints may be described herein with respect to at least Figure 6 and 7 and the results of the handshake protocol are determined by the described methods and techniques.

[0146] Fig. 9B A process is shown for receiving a checkpoint of transactional changes at an analytics database, which are then implemented to a representation of a transactional table maintained at the analytics database, in accordance with some embodiments.

[0147] In some embodiments, checkpoint 914 related to table A provided from transactional database 900 to transport mechanism 916 may be received by leader node 932 of node cluster 930 of analytical database (e.g., receives checkpoint 920 related to table A). Node cluster 930 may be similar to node cluster 430 and the functionality of node cluster 430 described herein (e.g., query processing and execution). Additionally, node cluster 930 may be a node cluster of analytical database system 400 within analytical database service 150, according to some embodiments.

[0148] The leader node 932 may use the change data capture log manager 934 to partition the checkpoint 920 related to table A according to the slices of the representation of table A stored at the corresponding computing nodes (e.g., computing nodes 934-938) of the node cluster 930. The leader node 932 may then provide the node-specific checkpoint instructions 960 to the corresponding computing nodes (e.g., computing nodes 934-938) so that the transactional changes of the checkpoint may be applied to the representation of table A maintained at the node cluster 930. In other embodiments, the transactional changes of the incoming checkpoint 920 may have been partitioned by the computing nodes, and the leader node 932 provides the node-specific checkpoint instructions 960.

[0149] According to some embodiments, upon receiving the node-specific checkpoint instruction 960 at the corresponding computing node of the node cluster 930, the computing device 962 may perform the checkpointed transactional changes 964 to the transactional table A representation 970. Performing the checkpointed transactional changes 964 may include at least the process described in box 1006, such as applying and submitting an "insert" event to the representation of table A. In some embodiments, the node-specific checkpoint instruction 960 may include a "delete" event, which may be buffered and submitted to the shadow table 968 via the buffered delete event 966. The buffered delete event in the shadow table 968 may later be applied and submitted to the transactional table A representation 970 as a background operation of the node cluster 930 (see the description of the embodiment of the present invention for details). Figures 11A-13D Such a process of receiving checkpoints and performing transactional changes to representations of a given transactional table may be repeated via the methods and techniques described herein (e.g., the process described in block 500).

[0150] According to some embodiments, the leader node 932 may also be configured to maintain a node-specific transaction number track 936. In order to understand the possible lag between the maximum transaction number applied to a given transaction table at the transaction database and the maximum transaction number applied to the corresponding representation of the transaction table at the analysis database, the node-specific transaction number track 936 may contain information about the maximum transaction number that has been committed at the corresponding computing node of the node cluster 930. Maintaining such information at the leader node 932 may allow the leader node 932 to organize node-specific checkpoint instructions 960 corresponding to the transaction changes that still need to be applied to the transaction table A representation 970 at the corresponding computing node. In some embodiments, based on the information stored in the node-specific transaction number track 936, the leader node 932 may request an additional checkpoint (e.g., via polling the transaction database via request new checkpoint 838) upon confirming that one or more computing nodes of the node cluster have committed all transaction changes in the current given checkpoint. Additionally, in some embodiments where the node cluster 930 is temporarily offline and / or an error occurs while performing transactional changes to table A, the leader node 932 may use information stored in the node-specific transaction number tracking 936 to determine the transaction number to which one or more compute nodes of the node cluster 930 should be reset (e.g., the corresponding maximum committed transaction number of the corresponding compute node).

[0151] Fig.10 is a flow diagram illustrating a process of implementing transactional changes to a representation of a transactional table, according to some embodiments, where delete events are first buffered and committed to a shadow table before being applied and committed to the representation as a batch.

[0152] In some embodiments, implementation of transactional changes received by the analytical database and used to update the representation and maintain the representation as a replica of the transactional table stored in the transactional database may include Fig.10 In addition, according to some embodiments, Figure 5 Block 510 shown in can be similar to the processes shown in blocks 1006 , 1008 , 1010 , and 1012 .

[0153] In block 1000, a representation of at least some portion of a transaction table stored at a transaction database is maintained at an analysis database. In some embodiments, the process for maintaining the representation may include the processes described in blocks 1002, 1004, 1006, 1008, 1010, and 1012, and may also include at least Figure 5In some embodiments, the transactional database described in block 1000 may be similar to transactional database system 200 of transactional database service 110, and the analytical database may be similar to analytical database system 400 of analytical database service 150, including the functionality of the components described herein. In addition, Figures 11A-13D An example embodiment is provided in which a representation of a given transaction table A is maintained at an analytical database.

[0154] In block 1002, a fragment of a portion of a transaction table is received as a snapshot to an analysis database. As described above, such a snapshot may be stored in one or more computing nodes of a node cluster at the analysis database, such as computing nodes 934-938 of node cluster 930, according to some embodiments. Figures 11A-13D In the example embodiment shown in , block 1002 may reference a snapshot of table A, which is maintained as a representation at the analysis database. In block 1004, a checkpoint corresponding to the snapshot described in block 1002 is also received at the analysis database. In some embodiments where the snapshot of block 1002 references table A, the checkpoint of block 1004 may be similar to a transactional change (e.g., checkpoint 1140) to be applied to the representation of table A in order to maintain a replication of table A at the analysis database.

[0155] In block 1006, the checkpoint transaction changes of block 1004 are applied to the representation of the portion of the table in transaction order. Figures 11A-13D , according to some embodiments, block 1006 (as well as blocks 1008, 1010, and 1012) may refer to implementing at least the transactional changes contained in checkpoint 1140 (e.g., transactions 1150-1180) to table A representation 1100. Block 1008 may include the process of applying and committing "insert" events (see below for a description of transactional changes within checkpoint 1140), while blocks 1010 and 1012 may include the process of buffering and committing "delete" events to a shadow table and then later applying and committing the "delete" events to a representation of table A (see at least shadow tables 1230 and 1230 below). Figures 13A-13D As shown in blocks 1008, 1010, and 1012, the insert operations for the transactional changes within a given checkpoint described by block 1006 may be applied and committed to the transactional table representation without being buffered or committed to the shadow table, while the delete operations may be buffered to the shadow table for later implementation to the representation of Table A. The buffered delete operations may be applied to the representation of Table A in transactional order as "lazy" operations (e.g., at a time when there is available processing power, and / or once a threshold limit of the shadow table is reached) and then committed as a batch.

[0156] Fig.11A-D shows a table representation maintained at the analysis database just before a given transaction number 1180 is implemented, and the corresponding shadow tables, checkpoints, and the state of the table as viewed by external clients of the analysis database, according to some embodiments.

[0157] Fig.11A An illustrative example of a given transaction table, Table A, is provided, which is stored at a transaction database and whose representation (e.g., a copy of Table A) is maintained at an analysis database via the methods and techniques described herein. Table A representation 1100 is intended as a conceptual example for illustrative purposes. It should be understood by those of ordinary skill in the art that Fig.11A Table A representation 1100 in can represent a visual reconstruction of a portion of a Table A representation that can be stored across multiple compute nodes of a given node cluster at an analytics database. For example, according to some embodiments, portions (e.g., slices, shards, etc.) of Table A representation 1100 can be maintained across compute nodes 934-938 and stored in transactional Table A representation 970 and / or cold storage tier 406. In addition, Table A in Fig.11A 1102, 1104, and 1106, but those skilled in the art will appreciate that Table A and / or other tables maintained at the analysis database may contain more than one column. Fig.11A 1100 and still utilize the methods and techniques described herein. Additionally, during the process of maintaining the table A representation 1100 at the analysis database, one or more columns may be added or removed from the table A representation 1100. According to some embodiments, the table A representation 1100 may also have columns for internal use by the analysis database, namely, insert tracking 1108 and delete tracking 1110. The insert tracking 1108 and delete tracking 1110 columns will be further detailed in the following paragraphs.

[0158] In some embodiments, table A representation 1100 may contain data items that may be organized into a multi-column table format. Fig.11A-D (e.g., after applying transaction number 1170 but before starting to apply transaction number 1180), Table A shows that 1100 may contain four rows, each row including three data items. For example, row 1112 contains the string 'Alpha' in column 1102, the integer '1' in column 1104, and another string 'Value_1' in column 1106. Similarly, row 1114 contains the string 'Alpha' in column 1102, the integer '2' in column 1104, and the string 'Value_1' in column 1106; row 1116 contains the string 'Beta' in column 1102, the integer '1' in column 1104, and the string 'Value_1' in column 1106; and row 1118 contains the string 'Beta' in column 1102, the integer '2' in column 1104, and the string 'Value_1' in column 1106. To simplify the description herein, data items in a given row, such as row 1112, may be referred to as 'Alpha|1|Value_1'. Likewise, Table A representation 1100 is intended for illustrative purposes, and additional columns containing other data types (e.g., floating point, character, Boolean variables, etc.) may also be incorporated into other embodiments of the examples described herein.

[0159] In some embodiments, table A representation 1100 may also contain columns for internal use, such as insert tracking 1108 and delete tracking 1110, which may track the transaction number at which a given row was added to and / or deleted from the table. Fig.11A As shown in , row 1112 is added during the implementation of transaction number 1150 and then deleted during transaction number 1160. In another example, row 1114 has been added during transaction number 1155 and Fig.11A At the time shown (e.g., after applying transaction 1170 but before starting to apply transaction 1180), row 1114 has not yet been deleted. "Hidden" columns, such as insert tracking 1108 and delete tracking 1110, can be used for at least several purposes: First, such transaction number tracking allows the analysis database to return query results based on transaction numbers. For example, an incoming query may request data items related to the state represented by Table A at transaction number 1175. At transaction number 1175, if viewed by a client of the analysis database service, the representation of Table A may be similar to transaction 1175 Table A view 1142, as shown in FIG. Fig.11D, where rows 1114 and 1118 are visible. An incoming query may return results containing data items from rows 1114 and 1118 but not rows 1112 or 1116 because, from the perspective of table A at transaction number 1175, rows 1112 and 1116 have been deleted from table A. Second, the hidden columns may also be used as a record in the event that table A representation needs to be restored back to the state it was in during a previously committed transaction. For example, if the transaction changes of table A representation 1100 have been applied and committed via transaction number 1160, but transaction numbers 1165 and 1170 have been applied but not yet committed, in the event that the analysis database is temporarily offline at this time (e.g., due to a temporary network failure, a power outage of a server affecting the analysis database, etc.), table A representation 1100 will be restored back to its state just after the last transaction was committed (e.g., transaction number 1160 in the given example).

[0160] In some embodiments, Fig. 11C 1140. An example of transactional changes that may be implemented to a given checkpoint (e.g., checkpoint 1140) of table A representation 1100 is shown in FIG. Transactional changes may include "insert," "delete," and "update" events (e.g., operations) that are further explained in the following paragraphs.

[0161] In a first example of an "insert" event, transaction 1150 contains instructions to insert (e.g., append, add, etc.) a new row into table A representation 1100, where the new row contains the following data items for columns 1102, 1104, and 1106, respectively: 'Alpha', '1', and 'Value_1'. As shown in row 1112 of table A representation 1100, the data items 'Alpha', '1', and 'Value_1' are keyed into table A representation 1100, and transaction number 1150 is recorded in the insert tracking 1108 column of row 1112 as the transaction number during the insertion of row 1112. After committing (or at least applying) the transaction changes contained in transaction 1150, the compute nodes of the node cluster at the analysis database will advance to the instructions contained in checkpoint 1140 for the next transaction number (e.g., transaction 1155 in this example). Similarly, transaction 1155 contains instructions to insert row 1114 into Table A representation 1100 using data items 'Alpha', '2', and 'Value_1', and transaction number 1155 is recorded in the insert tracking 1108 column of row 1114 as the transaction number during the insertion of row 1114.

[0162] In the second example containing an "update" event, transaction 1160 contains an instruction to update an existing row of table A representation 1100. In some embodiments, an "update" event may contain at least one "insert" operation and one "delete" operation. In addition, transaction 1160 uses the primary key to inform the computing nodes of the node cluster which row the update event involves. Fig. 11C As shown in , according to some embodiments, the instructions for transaction 1160 involve a row with primary key '{Alpha,1}', which is then understood by the compute nodes of the node cluster to represent row 1112. The instructions for a given update event then instruct the compute nodes of the node cluster to replace 'Alpha' in column 1102 of row 1112 with 'Beta'. In some embodiments, this update event may then include two steps: (1) deleting row 1112 containing data item 'Alpha|1|Value_1' from Table A representation 1100, and (2) inserting row 1116 containing data item 'Beta|1|Value_1' into Table A representation 1100. According to some embodiments, as shown in Table A representation 1100, a record of deleting row 1112 is recorded in the delete tracking 1110 column of row 1112, and a record of inserting row 1116 is recorded in the insert tracking 1108 column of row 1116. It should be understood by those skilled in the art that, according to different embodiments of the implementation of a given update event, the computing nodes of the node cluster may first delete row 1112 and then add row 1116, or first add row 1116 and then delete row 1112, because both embodiments still implement the application of the update event. In addition, the instruction for deleting row 1112 may instead be buffered and submitted to shadow table 1130 (e.g., where primary key '{Alpha, 1}' is stored in primary key 1132 column, and transaction number 1160 is stored in buffered delete tracking 1134 column), which will be described below with respect to Figures 12A-12D to discuss).

[0163] In some embodiments, checkpoint 1140 may subsequently contain, in transaction 1165, instructions to insert a new row into table A representation 1100, the new row containing the data item 'Beta|2|Value_1', which is shown as row 1118 in table A representation 1100. Similarly, the record of the insertion of row 1118 into table A representation 1100 is recorded in the insert tracking 1108 column of row 1118 inserted during the implementation of transaction number 1165. After committing (or at least applying) the transaction changes contained in transaction 1165, checkpoint 1140 may subsequently contain, in transaction 1170, instructions to delete the row of table A representation 1100 having primary key '{Beta,1}'. As shown in Table A representation 1100, row 1116 having data item 'Beta' in column 1102 and data item '1' in column 1104 is deleted from Table A representation 1100, as recorded in the delete tracking 1100 column of row 1116. In some embodiments, after implementing transaction changes with transaction numbers lower than transaction 1180, the compute nodes of the node cluster may continue to implement transaction changes in transaction 1180. Fig. 12A -D discusses transaction 1180 in more detail.

[0164] Checkpoint 1140 is intended to be an illustrative example of a checkpoint that contains a portion of a transactional change captured log of change data received from a transactional database via the methods and techniques described herein, and one of ordinary skill in the art will appreciate that checkpoints such as checkpoint 1140 may be written in other forms (e.g., structured query language (SQL)) as long as the data definition language (DDL) commands for a given checkpoint are interpretable by the analytical database. Further, according to some embodiments, checkpoint 1140 may be received via node-specific checkpoint instructions 960 to compute nodes 934-938. Additionally, for illustrative purposes, transactions 1150, 1155, 1160, 1165, and 1170 have been described in detail in the examples of FIG. Fig. 11C is crossed out to indicate that transactions 1150, 1155, 1160, 1165, and 1170 have been applied (and in some embodiments, committed) to the concept of Table A representation 1100. Fig. 11C The arrows of transaction 1180 in FIG. 1180 similarly indicate that the computing nodes of the node cluster will be Figures 11A-11D The depicted time is applied to the next transaction number represented by 1100 in Table A.

[0165] Fig. 12A -D shows that just after transaction number 1180 is implemented according to some embodiments Fig.11A -D table representation, shadow tables, checkpoints, and status of table views.

[0166] continue Fig.11A - The example embodiment shown in D, Fig. 12A-D shows the effect of applying transaction number 1180 to table A representation 1100 and shadow table 1130 according to some embodiments, where table A representation 1100 and shadow table 1130 may represent the state of table A representation and corresponding shadow table just before the application of transaction number 1180, while table A representation 1200 and shadow table 1230 may represent the state of table A representation and corresponding shadow table just after the application of transaction number 1180. In some embodiments, transaction number 1180 may include an "update" event applied to all non-deleted rows of table A representation 1200 (e.g., at the time transaction 1180 was applied to table A representation). As described above with respect to Fig.11A -D, an update event for transaction number 1180 may include respective insert and delete operations for each of the respective rows involved in the update event. For example, according to some embodiments, the undeleted rows of table A representation 1200 at the time just before the instruction for transaction number 1180 is implemented may be rows 1114 and 1118. Thus, according to some embodiments, respective insert and delete operations related to rows 1114 and 1118, respectively, may be applied to table A representation as part of implementing the transactional changes for transaction number 1180. As shown in table A representation 1200, rows 1220 and 1222 are inserted into table A representation 1200 in order to apply the respective insert operations for transaction number 1180, wherein the data items in column 1106 of rows 1114 and 1118 have both been changed from 'Value_1' in column 1106 of rows 1220 and 1222, respectively, to 'Value_2'. In some embodiments, additional "hidden" columns of table A representation 1200 may be used to track the operations of a given transaction. For example, in embodiments where row 1220 is inserted into Table A representation 1200 before row 1222, both as part of implementing transaction number 1180, in the "hidden" column operation tracking, row 1220 may be listed as operation 1 (e.g., 1180.1) of transaction 1180, and row 1222 may be listed as operation 2 (e.g., 1180.2) of transaction 1180. According to some embodiments, tracking operations within a given transaction number may also be referred to as assigning statement IDs to the operations of a given transaction number.

[0167] In some embodiments, as part of implementing a transactional change for transaction number 1180, a delete operation (e.g., the deletion of rows 1114 and 1118) may be performed via at least Fig. 9B and Fig.10 The methods and techniques described are buffered and submitted to the shadow table 1230, such as Fig. 12BAs shown in shadow table 1230, rows 1236 and 1238 represent rows 1114 and 1118 of table A representation 1200, respectively, where primary keys '{Alpha,2}' and '{Beta,2}' are stored in primary key 1132 column of rows 1236 and 1238, respectively, and transaction number 1180 is recorded in buffered delete tracking 1134 as the transaction number of rows 1114 and 1118 deleted from table A representation 1200. ... Fig.10 As discussed in block 1012 of FIG. 1014 , rows 1236 and 1238 may be retained in shadow table 1230 for a given amount of time before being applied and committed to table A representation 1200. Fig.13A -D discusses rows 1236 and 1238 of shadow table 1230 to table A representing the "batch" submission of 1200. In addition, table A represents rows 1112 and 1116 of 1200 in Fig.11A The embodiments shown in Fig. 12A The embodiments shown in do not change between the embodiments shown in because the instructions contained in transaction number 1180 do not apply to line 1112 or line 1116.

[0168] As discussed above with respect to Table A representation 1100, shadow table 1230 is intended as a conceptual example for illustrative purposes. One of ordinary skill in the art will appreciate that shadow table 1230 may represent a visual reconstruction of a portion of a shadow table that may be stored across multiple compute nodes of a given node cluster at an analytics database. For example, according to some embodiments, a portion of shadow table 1230 may be maintained across compute nodes 934-938 and stored in shadow table 968.

[0169] like Fig. 12C As shown in , after rows 1220 and 1222 are inserted into table A representation 1200 and rows 1236 and 1238 in shadow table 1230 are buffered and committed, the instructions contained in transaction number 1180 can be considered complete, and the compute nodes of the node cluster can move to the transaction number after transaction number 1180 (as indicated by the arrow on checkpoint 1140). In some embodiments, this can be transaction number 1181. In other embodiments, transaction number 1180 can be the final transaction number in node-specific checkpoint instructions 960, at which point leader node 932 can provide additional node-specific checkpoint instructions to compute nodes 934-938, and / or poll the analysis database for additional transaction changes to apply to table A representation.

[0170] In some embodiments, Fig.12DThe table A representation 1200 may be represented as viewed by a client of the analytical database service just after transaction number 1180 is performed. For example, the transaction 1181 table A view 1242 may include two rows corresponding to rows 1220 and 1222 of the table A representation. In some embodiments, rows (e.g., rows 1112 and 1114) indicated via the delete tracking 1110 column as deleted from the table A representation 1200 at or before transaction number 1180 may not be included in the transaction 1181 table A view 1242. Additionally, according to some embodiments, rows that have been marked for future deletion from the table A representation 1200 may be buffered to the shadow table 1230 (e.g., rows 1236 and 1238), and therefore may also not be included in the transaction 1181 table A view 1242. To further emphasize this point, this may mean that even though rows 1114 and 1118 may not have been recorded in the delete tracking 1110 column of table A representation 1200 as deleted at transaction number 1180, if the rows have been buffered and committed to shadow table 1230 (e.g., as shown by rows 1236 and 1238), then from the perspective of the client of the analytical database service, the rows may be considered deleted rows of table A representation 1200. Furthermore, if an incoming query were to request the results of table A representation 1200 based on the state of the table A representation just after the instructions contained in transaction number 1180 were completed, then based on the state of table A representation 1200 and shadow table 1230, the results for rows 1112, 1114, 1116, and 1118 may not be included in the query results.

[0171] Fig.13A -D shows at a point after transaction number 1180 is implemented according to some embodiments. Fig.11A -D table representation, shadow tables, checkpoints, and status of table views.

[0172] In some embodiments, rows 1236 and 1238 of shadow table 1230 to table A represent a "batch" submission of 1300 that may be similar to Fig.13A -D. Fig. 12A After the embodiment shown in -D where the corresponding insert operation of transaction number 1180 has been inserted into table A representation 1200 and the corresponding delete operation of transaction number 1180 has been buffered and submitted to shadow table 1230, Fig.13A -D shows a later point in time where rows 1236 and 1238 of shadow table 1230 are applied and committed to table A representation 1300. Fig.10 As discussed, when a given checkpoint (e.g., Fig. 13C1140) to the representation of Table A, the delete operations that have been buffered and submitted to the shadow table can then be applied to the representation of Table A in transactional order and submitted as a batch. In some embodiments, the buffered delete events of the shadow table 1330 can be applied to the representation of Table A 1300 as a "lazy" background operation, where the application of the delete events to the representation of Table A 1300 is delayed and then applied as a background operation (e.g., when computing / processing power is available for such delete operation application). In other embodiments, the delete events will continue to be buffered and submitted to the shadow table until the shadow table reaches a given threshold capacity, at which time the "batch" application of the delete events to the representation of Table A is triggered. It should be understood by those of ordinary skill in the art that different combinations of such reasons for first buffering the delete events to the shadow table and then submitting the delete events to the representation of Table A can also be included in such embodiments. For example, if the shadow table has not yet reached a given threshold capacity, but processing power is available to apply the delete events to the representation of Table A 1300, the available processing power can still be used to apply the delete events. After the buffer delete events are applied to the table A representation 1300, the buffer delete events are committed as a batch and removed from the shadow table 1330, as described in the following paragraphs.

[0173] As shown in Table A representation 1300, rows 1112, 1116, 1220, and 1222 are in Fig. 12A The embodiments shown in Fig.13A , because applying and committing rows 1236 and 1238 of shadow table 1230 to table A representation 1300 does not involve rows 1112, 1116, 1220, and 1222. However, applying rows 1236 and 1238 of shadow table 1230 to table A representation 1300 may involve recording transaction number 1180 in the delete tracking 1110 column of rows 1314 and 1318.

[0174] In some embodiments, applying a given buffered delete event of the shadow table to the table A representation may include three steps: (1) using the primary key in the primary key 1132 column, scanning (or parsing, searching, etc.) the representation of table A to obtain the row to which the delete event is to be applied, (2) applying (or writing, etc.) the delete event to the given row of the table A representation, and (3) committing the delete event. This process may be repeated in transaction order for multiple buffered delete events of the shadow table. For example, row 1236 of shadow table 1230 contains information that the delete event at transaction number 1180 has been buffered and committed to shadow table 1230, and involves a row of table A representation 1300 with primary key '{Alpha, 2}'. After scanning table A representation 1300 for the row with primary key '{Alpha, 2}' and confirming that primary key '{Alpha, 2}' corresponds to row 1314, transaction number 1180 is recorded in the delete tracking 1110 column of row 1314. In some embodiments, the process may be repeated for row 1238 of shadow table 1230, where primary key '{Beta,2}' is used to record transaction number 1180 in the delete tracking 1110 column of row 1318. These transactional changes to rows 1314 and 1318 of table A representation 1300 may then be committed as a batch. After committing the transactional changes, leader node 932 may update node-specific transaction number tracking 936 to the transaction number 1180 of the compute node associated with the embodiment shown in table A representation 1300 that has been committed, according to some embodiments.

[0175] In some embodiments, Fig.13D It can be shown that Table A is viewed by a client of the analysis database service just after committing transaction number 1180. It can be noted that Fig.13D Transaction 1181 Table A View 1342 with Fig.12D Transaction 1181 shown in Table A view 1232 remains unchanged because rows 1314 and 1318 are either buffered delete events marked as shadow tables (e.g., Fig. 12B ) or a committed delete event marked as a representation of table A (e.g. Fig. 13B ).

[0176] Embodiments of the hybrid transactional and analytical processing methods and systems described herein may be executed on one or more computer systems, which may interact with various other devices. Fig.14 One such computer system is shown. Fig.141400 is a block diagram illustrating a computer system that may implement at least a portion of the systems described herein according to various embodiments. For example, in different embodiments, computer system 1400 may implement a database engine head node of a database tier, or one of a plurality of storage nodes of a separate distributed storage system that stores databases and associated metadata on behalf of clients of the database tier. Computer system 1400 may be any of a variety of types of devices, including but not limited to a personal computer system, a desktop computer, a laptop or notebook computer, a mainframe computer system, a handheld computer, a workstation, a network computer, a consumer device, an application server, a storage device, a telephone, a mobile phone, or generally any type of computing device.

[0177] The computer system 1400 includes one or more processors 1410 (any of which may include multiple cores, which may be single-threaded or multi-threaded) coupled to a system memory 1420 via an input / output (I / O) interface 1430. The computer system 1400 further includes a network interface 1440 coupled to the I / O interface 1430. In various embodiments, the computer system 1400 may be a single processor system including one processor 1410, or a multiprocessor system including several processors 1410 (e.g., two, four, eight, or another suitable number of processors). The processor 1410 may be any suitable processor capable of executing instructions. For example, in various embodiments, the processor 1410 may be a general-purpose or embedded processor that implements any of a variety of instruction set architectures (ISAs), such as x86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In a multiprocessor system, each of the processors 1410 may, but not necessarily, implement the same ISA. The computer system 1400 also includes one or more network communication devices (e.g., network interface 1440) for communicating with other systems and / or components over a communication network (e.g., the Internet, a LAN, etc.). For example, a client application executing on the system 1400 may use the network interface 1440 to communicate with a server application executing on a single server or on a cluster of servers implementing one or more components of the database system described herein. In another example, an instance of a server application executing on the computer system 1400 may use the network interface 1440 to communicate with other instances of the server application (or another server application) that may be implemented on other computer systems (e.g., computer system 1490).

[0178] In the illustrated embodiment, the computer system 1400 also includes one or more permanent storage devices 1460 and / or one or more I / O devices 1480. In various embodiments, the permanent storage device 1460 may correspond to a disk drive, a tape drive, a solid-state memory, other mass storage device, or any other permanent storage device. The computer system 1400 (or a distributed application or operating system operating thereon) may store instructions and / or data in the permanent storage device 660 as needed, and may retrieve the stored instructions and / or data as needed. For example, in some embodiments, the computer system 1400 may host a storage node, and the permanent storage device 1460 may include an SSD attached to the server node.

[0179] The computer system 1400 includes one or more system memories 1420 that can store instructions and data that can be accessed by the processor 1410. In various embodiments, the system memory 1420 can be implemented using any suitable memory technology (e.g., one or more of cache, static random access memory (SRAM), DRAM, RDRAM, EDO RAM, DDR 10 RAM, synchronous dynamic RAM (SDRAM), Rambus RAM, EEPROM, non-volatile / flash memory, or any other type of memory). The system memory 1420 can contain program instructions 1425 that can be executed by the processor 1410 to implement the methods and techniques described herein. In various embodiments, the program instructions 1425 can be encoded in platform native binary, any interpreted language such as Java™ bytecode, or any other language such as C / C++, Java™, or any combination thereof. For example, in the illustrated embodiment, program instructions 1425 include program instructions that are executable to implement the functionality of a database engine head node of a database tier, or in different embodiments, implement the functionality of one of a plurality of storage nodes of a separate distributed storage system that stores databases and associated metadata on behalf of clients of the database tier. In some embodiments, program instructions 1425 may implement a plurality of separate clients, server nodes, and / or other components.

[0180] In some embodiments, program instructions 1425 may include instructions executable to implement an operating system (not shown), which may be any of a variety of operating systems such as UNIX, LINUX, Solaris™, MacOS™, Windows™, etc. Any or all of program instructions 1425 may be provided as a computer program product or software that may include a non-transitory computer-readable storage medium having instructions stored thereon, which may be used to program a computer system (or other electronic device) to perform processes according to various embodiments. A non-transitory computer-readable storage medium may include any mechanism for storing information in a machine (e.g., computer) readable form (e.g., software, processing application). In general, a non-transitory computer-accessible medium may include a computer-readable storage medium or a memory medium, such as a magnetic or optical medium, such as a disk or DVD / CD-ROM coupled to the computer system 1400 via an I / O interface 1430. Non-transitory computer-readable storage media may also include any volatile or non-volatile media that may be included as system memory 1420 or another type of memory in some embodiments of computer system 1400, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc. In other embodiments, program instructions may be communicated using optical, acoustic or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.) transmitted via a communication medium such as a network and / or a wireless link, such as may be implemented via network interface 1440.

[0181] In some embodiments, system memory 1420 may include a data store 1445 that may be implemented as described herein. For example, at various times and in various embodiments, information described herein as being stored by the database tier (e.g., on a database engine head node), such as transaction logs, undo logs, cached page data, or other information used to perform the functions of the database tier described herein, may be stored in the data store 1445 or in another portion of the system memory 1420 on one or more nodes, in permanent storage 1460, and / or on one or more remote storage devices 1470. Similarly, at various times and in various embodiments, information described herein as being stored by the storage tier (e.g., redo log records, merged data pages, and / or other information used to perform the functions of the distributed storage system described herein) may be stored in the data store 1445 or in another portion of the system memory 1420 on one or more nodes, in permanent storage 1460, and / or on one or more remote storage devices 1470. In general, system memory 1420 (e.g., data storage area 1445 within system memory 1420), permanent storage device 1460 and / or remote storage device 1470 may store data blocks, copies of data blocks, metadata associated with data blocks and / or their states, database configuration information, and / or any other information that can be used to implement the methods and techniques described herein.

[0182] In one embodiment, I / O interface 1430 may coordinate I / O traffic between processor 1410, system memory 1420, and any peripheral devices in the system, including through network interface 1440 or other peripheral interfaces. In some embodiments, I / O interface 1430 may perform any necessary protocol, timing, or other data transformations to convert data signals from one component (e.g., system memory 1420) into a format suitable for use by another component (e.g., processor 1410). In some embodiments, I / O interface 1430 may include support for devices attached through various types of peripheral buses, such as a variation of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, etc. In some embodiments, the functionality of I / O interface 1430 may be divided into two or more separate components, such as a north bridge and a south bridge. Additionally, in some embodiments, some or all of the functionality of I / O interface 1430 (e.g., the interface to system memory 1420) may be incorporated directly into processor 1410.

[0183] For example, the network interface 1440 may allow data to be exchanged between the computer system 1400 and other devices attached to the network, such as other computer systems 1490 (which may implement one or more storage system server nodes, database engine head nodes, and / or clients of the database system described herein). In addition, the network interface 1440 may allow communication between the computer system 1400 and various I / O devices 1450 and / or remote storage devices 1470. In some embodiments, the input / output devices 1450 may include one or more display terminals, keyboards, keypads, touch pads, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or retrieving data through one or more computer systems 1400. Multiple input / output devices 1450 may exist in the computer system 1400 or may be distributed on various nodes of a distributed system including the computer system 1400. In some embodiments, similar input / output devices may be separate from the computer system 1400 and may interact with one or more nodes of a distributed system including the computer system 1400 through a wired or wireless connection, such as through the network interface 1440. The network interface 1440 may typically support one or more wireless networking protocols (e.g., Wi-Fi / IEEE 802.11 or another wireless networking standard). However, in various embodiments, the network interface 1440 may support communication via any suitable wired or wireless general data network (e.g., other types of Ethernet). In addition, the network interface 1440 may support communication via a telecommunications / telephone network such as an analog voice network or a digital fiber optic communication network, via a storage area network SAN such as Fiber Channel, or via any other suitable type of network and / or protocol. In various embodiments, the computer system 1400 may include more, fewer, or different components than those shown in FIG. 20 (e.g., a display, a graphics card, a sound card, peripheral devices, other network interfaces such as ATM interfaces, Ethernet interfaces, frame relay interfaces, etc.).

[0184] It should be noted that any distributed system embodiment described herein or any component in its component may be implemented as one or more network services. For example, the database engine head node in the database layer of the database system may present the database service and / or other types of data storage services using the distributed storage system described herein to the client as a network service. In some embodiments, the network service may be implemented by software and / or hardware systems designed to support interoperable machine-to-machine interaction on the network. The network service may have an interface described in a machine-processable format such as a network service description language (WSDL). Other systems may interact with the network service in a manner specified by the description of the interface of the network service. For example, the network service may define various operations that other systems may call, and may define a specific application programming interface (API), and when requesting various operations, it may be expected that other systems follow the specific API.

[0185] In various embodiments, a network service may be requested or invoked using a message containing parameters and / or data associated with the network service request. Such messages may be formatted according to a particular markup language, such as Extensible Markup Language (XML), and / or may be encapsulated using a protocol, such as Simple Object Access Protocol (SOAP). To execute a network service request, a network service client may assemble a message containing the request using an Internet-based application layer transport protocol, such as Hypertext Transfer Protocol (HTTP), and transmit the message to an addressable endpoint, such as a Uniform Resource Locator (URL), corresponding to the network service.

[0186] In some embodiments, a web service may be implemented using representational state transfer ("RESTful") techniques rather than message-based techniques. For example, a web service implemented according to RESTful techniques may be invoked via parameters contained within an HTTP method (such as PUT, GET, or DELETE) rather than being encapsulated in a SOAP message.

[0187] The various methods shown in the figures and described herein represent example embodiments of the methods. The methods may be implemented in software, hardware, or a combination thereof. The order of the methods may be changed, and various elements may be added, reordered, combined, omitted, modified, etc.

[0188] Various modifications and alterations may be made, which will be apparent to those skilled in the art having the benefit of this disclosure. The invention is intended to cover all such modifications and alterations, and, therefore, the above description should be viewed in an illustrative rather than a limiting sense.

[0189] Embodiments of the present disclosure may be described in terms of the following:

[0190] Clause 1. A system comprising:

[0191] One or more computing devices, wherein the one or more computing devices are configured to:

[0192] Implementing a transactional database;

[0193] maintaining a table including data items at the transactional database; and

[0194] At the transactional database, writing the transactional changes made to the table to a change data capture log;

[0195] One or more computing nodes organized into a node cluster, wherein the one or more computing nodes are configured to:

[0196] Implementing analytical databases; and

[0197] maintaining, at the analytics database, a representation of at least a portion of the table, wherein maintaining comprises committing corresponding ones of the transactional changes of the change data capture log received at the analytics database to the representation;

[0198] At least one transport mechanism configured to:

[0199] receiving respective snapshots of the segments of the at least one portion of the table, wherein each snapshot comprises a segment of the at least one portion of the table;

[0200] making the corresponding snapshot accessible to the analysis database;

[0201] receiving a checkpoint associated with the corresponding snapshot, wherein the checkpoint includes a corresponding portion of the transactional changes of the change data capture log; and

[0202] making the checkpoint accessible to the analysis database; and

[0203] Wherein the one or more computing nodes are further configured to, in response to receiving an incoming analytical query related to at least one data item in the representation, provide a result of the incoming analytical query.

[0204] Clause 2. The system of clause 1, wherein:

[0205] The transactional changes for a given checkpoint include at least two delete events; and

[0206] Said maintaining said representation of said at least one portion of said table further comprises:

[0207] committing the at least two delete events to a shadow table at the analytics database; and

[0208] In response to the shadow table having a given threshold of committed delete events, the committed delete events of the shadow table are committed to the representation.

[0209] Clause 3. The system of clause 1 or clause 2, wherein the snapshots are respectively distributed across corresponding computing nodes in the one or more computing nodes of the node cluster.

[0210] Clause 4. A system according to any one of clauses 1 to 3, wherein:

[0211] The transaction change is marked with a corresponding primary key, the corresponding primary key corresponds to a corresponding row in the transaction database where the transaction change occurs; and

[0212] The committing of the respective ones of the transactional changes to the representation is based at least in part on use of the respective primary key.

[0213] Clause 5. A system according to any one of clauses 1 to 4, wherein:

[0214] The transaction database and the analytical database are part of a service provider network;

[0215] The data storage service of the service provider network is configured to implement a corresponding transport mechanism of the at least one transport mechanism; and

[0216] The corresponding snapshot or the checkpoint is stored in at least one data storage area of ​​the data storage service, wherein the at least one data storage area is accessible to the transactional database and the analytical database.

[0217] Clause 6. A system according to any one of clauses 1 to 4, wherein:

[0218] The transactional database and the analytical database are part of a service provider network; and

[0219] The data stream service of the provider network is used to implement a corresponding transport mechanism of the at least one transport mechanism; and

[0220] The respective snapshots or the checkpoints are transferred from the transactional database to the analytical database via the data streaming service.

[0221] Clause 7. A method comprising:

[0222] A representation of at least a portion of a table including data items is maintained at an analytics database implemented by one or more computing nodes organized into a node cluster, wherein:

[0223] The table is stored at a transactional database implemented by one or more computing devices; and

[0224] The maintenance includes:

[0225] writing, at the transactional database, transactional changes made to the table to a change data capture log;

[0226] making a snapshot of a segment of the at least one portion of the table accessible to the analytics database via at least one transport mechanism;

[0227] making a checkpoint associated with a respective snapshot accessible to the analytics database via a respective transport mechanism of the at least one transport mechanism, wherein the checkpoint includes a respective portion of the transactional changes of the change data capture log;

[0228] storing the respective snapshots and the checkpoints at the analytics database across the one or more compute nodes of a node cluster; and

[0229] committing the transactional changes of the corresponding checkpoint to the representation; and

[0230] In response to receiving an incoming query related to at least one data item in the representation, providing results for the incoming query.

[0231] Clause 8. The method of clause 7, wherein applying the transactional changes comprises:

[0232] committing at least two delete events of the transactional changes of a given one of the corresponding checkpoints to a shadow table; and

[0233] In response to the shadow table having a given threshold of committed delete events, the committed delete events in the shadow table are committed to the representation.

[0234] Clause 9. The method according to clause 7 or clause 8, wherein the method further comprises:

[0235] With respect to committing the transactional changes of the corresponding checkpoint to the representation, storing an indication that the transaction applied at the analysis database has a most recent transaction identifier; and

[0236] The transactional database is polled to determine whether an additional checkpoint including one or more transactional changes that have been applied at the transactional database has a later transaction identifier than the most recent transaction identifier committed at the analytical database.

[0237] Clause 10. The method of clause 9, wherein, in response to polling the transaction database,

[0238] making the additional checkpoint accessible to the analysis database via the respective one of the at least one transport mechanisms; and

[0239] The one or more transaction changes having the later transaction identifier than the latest transaction identifier committed at the analytics database are committed to the representation.

[0240] Clause 11. The method according to any one of clauses 7 to 10, wherein the method further comprises:

[0241] One or more data definition language commands that are incompatible with the checkpoint are determined via negotiation between the one or more computing nodes of the node cluster and the one or more computing devices.

[0242] Clause 12. The method according to clause 11, wherein the method further comprises:

[0243] In response to determining at the analysis database that a given transactional change for a given checkpoint includes a corresponding data definition language command of the incompatible one or more data definition language commands, an error message is provided.

[0244] Clause 13. A method according to any one of clauses 7 to 12, wherein:

[0245] The transactional database and the analytical database are part of a service provider network; and

[0246] The making the checkpoint accessible to the analytics database includes storing the checkpoint in at least one data storage area of ​​a data storage service of the service provider network.

[0247] Clause 14. A method according to any one of clauses 7 to 12, wherein:

[0248] The transactional database and the analytical database are part of a service provider network; and

[0249] The making the checkpoint accessible to the analytics database includes transmitting the checkpoint from the transactional database to the analytics database via a data streaming service of the service provider network.

[0250] Clause 15. A method according to any one of clauses 7 to 12, wherein:

[0251] The checkpoints are stored in a storage device used by the transactional database;

[0252] said making said checkpoint accessible to said analytical database occurs via a direct connection between said transactional database and said analytical database; and

[0253] The analysis database requests the checkpoint.

[0254] Clause 16. A method according to any one of clauses 7 to 12, wherein:

[0255] The checkpoints are stored in a storage device used by the transactional database;

[0256] said making said checkpoint accessible to said analytical database occurs via a direct connection between said transactional database and said analytical database; and

[0257] The transactional database provides the checkpoints.

[0258] Clause 17. The method according to any one of clauses 7 to 16, further comprising:

[0259] Executing a handshake protocol, wherein executing the handshake protocol comprises:

[0260] determining a mapping for partitioning the respective snapshots and associated checkpoints across the one or more compute nodes of the node cluster;

[0261] determining the at least one transport mechanism to be used for said making the snapshot accessible to the analytics database and said making the checkpoint accessible to the analytics database; and

[0262] Determinations of the handshake protocol are made accessible to the transaction database and the analysis database.

[0263] Clause 18. One or more non-transitory computer-readable storage media storing program instructions that, when executed on or across one or more processors, cause the one or more processors to:

[0264] A representation of at least a portion of a table comprising data items is maintained at an analysis database, wherein:

[0265] The table is stored in a transactional database; and

[0266] Maintenance includes:

[0267] At the transactional database, writing the transactional changes made to the table to a change data capture log;

[0268] making a snapshot of a segment of the at least one portion of the table accessible to an analytics database via at least one transport mechanism;

[0269] making a checkpoint associated with a respective snapshot accessible to the analytics database via a respective transport mechanism of the at least one transport mechanism, wherein the checkpoint includes a respective portion of the transactional changes of the change data capture log;

[0270] storing the snapshot and the checkpoint at the analytics database; and

[0271] committing the transactional changes of the corresponding checkpoint to the representation; and

[0272] In response to receiving an incoming query related to at least one data item in the representation, providing results for the incoming query.

[0273] Clause 19. The one or more non-transitory computer-readable storage media of Clause 18, wherein the program instructions, when executed on or across the one or more processors, additionally cause the one or more processors to:

[0274] With respect to committing the transactional changes of the corresponding checkpoint to the representation at the analysis database, causing a leader node of the one or more computing nodes to store an indication that the transaction committed at the analysis database has a latest transaction identifier; and

[0275] The leader node is caused to poll the transactional database to determine whether an additional checkpoint including one or more transactional changes that have been applied at the transactional database has a later transaction identifier than the most recent transaction identifier committed at the analytical database.

[0276] Clause 20. The one or more non-transitory computer-readable storage media of clause 19, wherein, in response to causing the leader node to poll the transaction database, the program instructions, when executed on or across the one or more processors, additionally cause the one or more processors to:

[0277] accessing the additional checkpoint; and

[0278] The one or more transaction changes having the later transaction identifier than the latest transaction identifier committed at the analysis database are committed.

[0279] Clause 21. A system comprising:

[0280] One or more computing devices configured to implement a transactional database, wherein the one or more computing devices implementing the transactional database are configured to:

[0281] maintaining a table including data items; and

[0282] writing transactional changes made to the table to a change data capture log;

[0283] One or more computing nodes organized into a node cluster and configured to implement an analytical database, wherein the one or more computing nodes of the node cluster are configured to:

[0284] maintaining a representation of at least a portion of the table, wherein maintaining comprises applying corresponding ones of the transaction changes of the change data capture log received at the analytics database to update the representation of the at least a portion of the table;

[0285] wherein the one or more computing devices implementing the transactional database and the computing nodes of the node cluster implementing the analytical database are further configured to execute a handshake protocol to perform the following operations:

[0286] determining a mapping for distributing respective portions of the transactional changes of the change data capture log to the one or more compute nodes of the node cluster, wherein:

[0287] determining the mapping based at least in part on a distribution of a plurality of snapshots across the one or more compute nodes of the node cluster, each snapshot comprising a fragment of the at least one portion of the table; and

[0288] the respective portion of the transactional changes comprises transactional changes organized into checkpoints, each checkpoint corresponding to a respective snapshot of the plurality of snapshots;

[0289] determining at least one transport mechanism to be used to provide the plurality of snapshots and checkpoints from the transactional database to the analytical database; and

[0290] determining one or more data definition language commands that are incompatible with the checkpoint; and

[0291] The one or more computing devices implementing the transactional database and / or the computing nodes of the node cluster implementing the analytical database store the determination result of the handshake protocol in a data storage area accessible to the one or more computing devices implementing the transactional database and the one or more computing nodes of the node cluster implementing the analytical database.

[0292] Clause 22. The system of clause 21, wherein the at least one transport mechanism is further configured to:

[0293] receiving the plurality of snapshots;

[0294] making the plurality of snapshots accessible to the analytics database;

[0295] receiving the checkpoint; and

[0296] The checkpoint is made accessible to the analysis database.

[0297] Clause 23. A system according to clause 21 or clause 22, wherein:

[0298] The transactional database and the analytical database are part of a service provider network; and

[0299] A corresponding transport mechanism of the determined at least one transport mechanism is a data storage service of the service provider network.

[0300] Clause 24. The system of clause 23, wherein the data storage area storing the determination result of the handshake protocol is in a storage device of the data storage service.

[0301] Clause 25. A system according to any one of clauses 21 to 24, wherein:

[0302] The transactional database and the analytical database are part of a service provider network; and

[0303] A corresponding transport mechanism of the determined at least one transport mechanism is a data stream service of the service provider network.

[0304] Clause 26. The system of any one of clauses 21 to 25, wherein the handshake protocol is further configured to:

[0305] determining logic for generating corresponding primary keys for rows of the at least one portion of the table; and

[0306] The determination logic is stored in the data storage area together with the determination result of the handshake protocol.

[0307] Clause 27. The system of clause 26, wherein the corresponding primary key generated is:

[0308] respective row identifiers of said rows of said at least one portion of said table;

[0309] a corresponding subset of the data items within the rows of the at least one portion of the table; or

[0310] a respective concatenation of all of the data items within the rows of the at least one portion of the table.

[0311] Clause 28. A method comprising:

[0312] A handshake protocol is initiated to maintain, at the analytical database, a representation of at least a portion of a table stored at the transactional database, wherein:

[0313] one or more computing devices configured to implement the transaction database;

[0314] One or more computing nodes organized into a node cluster are configured to implement the analytical database;

[0315] The handshake protocol is executed by the one or more computing devices and the one or more computing nodes, wherein the executing the handshake protocol comprises:

[0316] determining a mapping for distributing respective portions of the transactional changes of the change data capture log to the one or more compute nodes of the node cluster, wherein:

[0317] determining the mapping based at least in part on a distribution of a plurality of snapshots across the one or more compute nodes of the node cluster, each snapshot comprising a fragment of the at least one portion of the table; and

[0318] the respective portion of the transactional changes comprises transactional changes organized into checkpoints, each checkpoint corresponding to a respective snapshot of the plurality of snapshots;

[0319] determining at least one transport mechanism to be used to provide the plurality of snapshots and checkpoints from the transactional database to the analytical database; and

[0320] determining one or more data definition language commands that are incompatible with the checkpoint; and

[0321] causing the determination result of the handshake protocol to be stored in a data storage area accessible by the transaction database and the analysis database; and

[0322] Wherein, in response to the determining result of the storing the handshake protocol, the maintaining the representation of the at least one portion of the table comprises:

[0323] writing, at the transactional database, transactional changes made to the at least one portion of the table to the change data capture log; and

[0324] Respective ones of the transactional changes of the checkpoint are committed to the representation at the analysis database.

[0325] Clause 29. The method of clause 28, wherein said performing said handshake protocol further comprises:

[0326] determining logic for generating corresponding primary keys for rows of the at least one portion of the table; and

[0327] The determination logic is stored in the data storage area together with the determination result of the handshake protocol.

[0328] Clause 30. The method of clause 28 or clause 29, wherein said performing said handshake protocol further comprises:

[0329] providing information about the at least one portion of the table, wherein the information includes one or more primary keys of the at least one portion of the table; and

[0330] The information is stored in the data storage area together with the determination result.

[0331] Clause 31. The method of any one of clauses 28 to 30, wherein said maintaining said representation of said at least one portion of said table further comprises:

[0332] determining, at the transactional database, based at least in part on the determination of the handshake protocol, that a given transactional change for a given checkpoint having a transaction number identifier includes one of one or more incompatible data definition language commands; and

[0333] Based at least in part on the determination of the handshake protocol, making an updated snapshot of the at least one portion of the table accessible to the analysis database via a corresponding transport mechanism of the at least one transport mechanism, and wherein the updated snapshot has the transaction number identifier or a transaction number identifier that is later than the transaction number identifier.

[0334] Clause 32. The method of any one of clauses 28 to 31, wherein said maintaining said representation of said at least one portion of said table further comprises:

[0335] determining, at the analysis database, based at least in part on the determination of the handshake protocol, that a given transactional change for a given checkpoint having a transaction number identifier includes one of one or more incompatible data definition language commands; and

[0336] Based at least in part on the determination of the handshake protocol, requesting an updated snapshot of the at least one portion of the table via a corresponding transport mechanism of the at least one transport mechanism, and wherein the updated snapshot has the transaction number identifier or a transaction number identifier that is later than the transaction number identifier.

[0337] Clause 33. A method according to any one of clauses 28 to 32, wherein:

[0338] In response to storing the determination of the handshake protocol, making the plurality of snapshots accessible to the analytics database via respective ones of the at least one transport mechanism based at least in part on the determination of the handshake protocol; and

[0339] A first transactional change of a first checkpoint of the checkpoints has a transaction number identifier that is less than or equal to a latest transaction number identifier of the plurality of snapshots.

[0340] Clause 34. A method according to any one of clauses 28 to 33, wherein the at least one transmission mechanism comprises:

[0341] a data storage service accessible by the transactional database and the analytical database; or

[0342] A data stream service is accessible by the transactional database and the analytical database.

[0343] Clause 35. A method according to any one of clauses 28 to 34, wherein:

[0344] In response to the one or more computing devices configured to implement the transactional database coming back online after being offline for a period of time, the determination of the handshake protocol is confirmed without reinitializing a new handshake protocol.

[0345] Clause 36. The method according to any one of clauses 28 to 35, further comprising:

[0346] in response to determining that another transport mechanism is to be used to provide the checkpoint, wherein the another transport mechanism is different from the at least one transport mechanism, updating one or more of the determinations of the handshake protocol; or

[0347] In response to determining that there has been a change to the one or more data definition language commands that is incompatible with the checkpoint, one or more of the determinations of the handshake protocol are updated.

[0348] Clause 37. One or more non-transitory computer-readable storage media storing program instructions that, when executed on or across one or more processors, cause the one or more processors to:

[0349] A handshake protocol is initiated to maintain, at the analytical database, a representation of at least a portion of a table stored at the transactional database, wherein:

[0350] The handshake protocol includes:

[0351] determining a mapping for distributing respective portions of the transactional changes of the change data capture log to the one or more compute nodes of the node cluster, wherein:

[0352] determining the mapping based at least in part on distribution of a plurality of snapshots across one or more compute nodes of a cluster of nodes of the analytics database, each snapshot comprising a fragment of the at least one portion of the table; and

[0353] the respective portion of the transactional changes comprises transactional changes organized into checkpoints, each checkpoint corresponding to a respective snapshot of the plurality of snapshots;

[0354] determining at least one transport mechanism for providing the plurality of snapshots and checkpoints from the transactional database to the analytical database, wherein the checkpoints include corresponding portions of a change data capture log for the at least one portion of the table; and

[0355] determining one or more data definition language commands that are incompatible with the checkpoint; and

[0356] causing the determination result of the handshake protocol to be stored in a data storage area accessible by the transaction database and the analysis database; and

[0357] Maintaining the representation of the at least one portion of the table comprises:

[0358] writing, at the transactional database, transactional changes made to the at least one portion of the table to the change data capture log; and

[0359] Respective ones of the transactional changes of the checkpoint are committed to the representation at the analysis database.

[0360] Clause 38. One or more non-transitory computer-readable storage media of Clause 37, wherein the program instructions, when executed on or across the one or more processors, additionally cause the one or more processors to:

[0361] making the plurality of snapshots accessible to the analytics database via the at least one transport mechanism; and

[0362] The checkpoints are made accessible to the analysis database via the at least one transport mechanism.

[0363] Clause 39. The one or more non-transitory computer-readable storage media of clause 37 or clause 38, wherein maintaining the snapshot of the at least one portion of the table additionally causes the one or more processors to:

[0364] determining, at the transactional database based at least in part on the determination of the handshake protocol, that a given transactional change for a given checkpoint having a transaction number identifier includes one of the one or more incompatible data definition language commands; and

[0365] Based at least in part on the determination of the handshake protocol, making an updated snapshot of the at least one portion of the table accessible to the analysis database via a corresponding transport mechanism of the at least one transport mechanism, and wherein the updated snapshot has the transaction number identifier or a transaction number identifier that is later than the transaction number identifier.

[0366] Clause 40. The one or more non-transitory computer-readable storage media of any one of clauses 37 to 39, wherein maintaining the snapshot of the at least one portion of the table additionally causes the one or more processors to:

[0367] determining, at the analysis database based at least in part on the determination of the handshake protocol, that a given transactional change of a given checkpoint having a transaction number identifier includes one of the one or more incompatible data definition language commands; and

[0368] Based at least in part on the determination of the handshake protocol, requesting an updated snapshot of the at least one portion of the table via a corresponding transport mechanism of the at least one transport mechanism, and wherein the updated snapshot has the transaction number identifier or a transaction number identifier that is later than the transaction number identifier.

[0369] Clause 41. A system comprising:

[0370] One or more computing nodes organized into a node cluster, wherein the one or more computing nodes are configured to:

[0371] Implementing analytical databases; and

[0372] maintaining at the analytical database a representation of at least a portion of a table of a separate transactional database implemented via one or more computing devices, wherein to maintain the representation of the at least a portion of the table, the one or more computing nodes of the node cluster are additionally configured to:

[0373] receiving a respective snapshot of a segment of the at least a portion of the table of the separate transactional database and receiving a checkpoint associated with the respective snapshot, wherein:

[0374] The checkpoint includes transaction changes that have been applied at the separate transaction database;

[0375] The transactional changes for a given checkpoint include two or more delete events and one or more insert events; and

[0376] The transaction changes are marked with respective primary keys corresponding to respective rows in the separate transaction database where the transaction changes occur; and

[0377] Implementing the transactional changes of the given checkpoint to its corresponding snapshot, wherein implementing comprises:

[0378] committing the one or more insert events to the corresponding snapshot;

[0379] committing the two or more delete events to a shadow table;

[0380] In response to the shadow table having committed delete events for a given threshold of the two or more delete events, committing the committed delete events of the shadow table to the corresponding snapshot; and

[0381] In response to committing the committed delete event in the shadow table to the corresponding snapshot, removing the committed delete event from the shadow table and

[0382] Wherein, in response to receiving an incoming analysis query, the one or more computing nodes provide a result of the incoming analysis query based at least in part on the committed deletion event in the shadow table.

[0383] Clause 42. The system of Clause 41, wherein a given deletion event of the two or more deletion events is a deletion of a corresponding row of the representation.

[0384] Clause 43. The system of clause 41, wherein:

[0385] the transactional changes of the given checkpoint additionally include an update event, the update event including another delete event and another insert event to modify the at least one data item in the given row of the representation based at least in part on deleting the given row and inserting an updated version of the given row including the modified at least one data item; and

[0386] Implementing the transactional changes of the given checkpoint to its corresponding snapshot additionally comprises:

[0387] submitting the another delete event to the shadow table; and

[0388] The another insert event is committed to the corresponding snapshot.

[0389] Clause 44. A system according to any one of clauses 41 to 43, further comprising:

[0390] The transactional database, wherein the one or more computing devices implementing the transactional database are further configured to:

[0391] maintaining the table; and

[0392] The transactional changes are written to a change data capture log, wherein the change data capture log includes the transactional changes that have been applied to the separate transactional database.

[0393] Clause 45. The system of any one of Clauses 41 to 44, wherein the respective primary key is a respective row identifier of the representation.

[0394] Clause 46. The system of any one of Clauses 41 to 44, wherein the respective primary keys correspond to a subset of the data items within the respective rows in the separate transactional database for which the transactional changes occurred.

[0395] Clause 47. The system of any one of Clauses 41 to 44, wherein the respective primary key corresponds to a concatenation of all data items within the respective row in the separate transactional database for which the transactional change occurred.

[0396] Clause 48. A system according to any one of clauses 41 to 47, wherein:

[0397] The analytical database is part of a service provider network; and

[0398] The checkpoints are made accessible to the analysis database via a transport mechanism of the service provider network.

[0399] Clause 49. A method comprising:

[0400] A representation of at least a portion of a table including data items is maintained at an analytics database implemented by one or more computing nodes organized into a node cluster, wherein:

[0401] The table is stored in a separate transactional database implemented via one or more computing devices; and

[0402] The maintenance includes:

[0403] receiving respective snapshots of segments of the at least a portion of the table of the separate transactional database;

[0404] A checkpoint associated with the corresponding snapshot is received, wherein:

[0405] The checkpoint includes transaction changes that have been applied at the separate transaction database;

[0406] The transactional changes for a given checkpoint include two or more delete events; and

[0407] The transaction changes are marked with respective primary keys corresponding to respective rows in the separate transaction database where the transaction changes occur; and

[0408] Implementing the transactional changes of the given checkpoint to its corresponding snapshot, wherein the implementing comprises:

[0409] committing the two or more delete events to a shadow table; and

[0410] In response to the shadow table having committed delete events for a given threshold of the two or more delete events, committing the committed delete events in the shadow table to the corresponding snapshot; and

[0411] In response to receiving an incoming analytical query, providing results for the incoming analytical query based at least in part on the committed delete events in the shadow table.

[0412] Clause 50. The method according to clause 49, wherein:

[0413] The transactional changes to the given checkpoint additionally include an insert event; and

[0414] The method additionally includes submitting the insert event to the corresponding snapshot without submitting the insert event to the shadow table.

[0415] Clause 51. The method according to clause 49, wherein:

[0416] the transactional changes of the given checkpoint additionally include an update event, the update event including another delete event and an insert event to modify the at least one data item in the given row of the corresponding snapshot based at least in part on deleting the given row and inserting an updated version of the given row including the modified at least one data item; and

[0417] Implementing the transactional changes of the given checkpoint to the corresponding snapshot further comprises:

[0418] submitting the another delete event to the shadow table; and

[0419] The insert event is submitted to the corresponding snapshot without submitting the insert event to the shadow table.

[0420] Clause 52. The method of clause 49, wherein committing committed delete events in the shadow table to the corresponding snapshot comprises:

[0421] determining, using the corresponding primary key, a corresponding row of the corresponding snapshot where the committed delete event in the shadow table occurred;

[0422] applying the committed delete event in the shadow table to the corresponding snapshot; and

[0423] The applied deletion events are submitted as a batch to the corresponding snapshot.

[0424] Clause 53. The method according to any one of clauses 49 to 52, wherein the method further comprises:

[0425] Responsive to committing the committed delete event in the shadow table to the corresponding snapshot, removing the committed delete event from the shadow table.

[0426] Clause 54. The method of any one of clauses 49 to 53, wherein in response to receiving the incoming analytical query, providing the result of the incoming analytical query based at least in part on the committed delete event in the shadow table comprises:

[0427] parsing the corresponding snapshot;

[0428] parsing the shadow table; and

[0429] The results of the incoming analytical query are provided, wherein the results do not include rows corresponding to the committed delete events in the corresponding snapshot or in the shadow table.

[0430] Clause 55. A method according to any one of clauses 49 to 54, wherein:

[0431] maintaining a slice of the corresponding snapshot at a corresponding compute node of the one or more compute nodes; and

[0432] Respective portions of the shadow table, each corresponding to a respective slice, are maintained at the respective compute nodes of the one or more compute nodes.

[0433] Clause 56. One or more non-transitory computer-readable storage media storing program instructions that, when executed on or across one or more processors, cause the one or more processors to:

[0434] A representation of at least a portion of a table including data items is maintained at an analysis database, wherein:

[0435] At least the portion of the table is stored at a separate transactional database; and

[0436] Maintenance includes:

[0437] receiving respective snapshots of segments of the at least a portion of the table of the separate transactional database;

[0438] A checkpoint associated with the corresponding snapshot is received, wherein:

[0439] The checkpoint includes transaction changes that have been applied at the separate transaction database;

[0440] The transactional changes for a given checkpoint include two or more delete events; and

[0441] The transaction changes are marked with respective primary keys corresponding to respective rows in the separate transaction database where the transaction changes occur; and

[0442] Implementing the transactional changes of the given checkpoint to its corresponding snapshot, wherein applying comprises:

[0443] committing the two or more delete events to a shadow table; and

[0444] In response to the shadow table having committed delete events for a given threshold of the two or more delete events, committing the committed delete events in the shadow table to the corresponding snapshot; and

[0445] In response to receiving an incoming analytical query, providing results for the incoming analytical query based at least in part on the committed delete events in the shadow table.

[0446] Clause 57. One or more non-transitory computer-readable storage media of Clause 56, wherein the program instructions, when executed on or across the one or more processors, cause the one or more processors to:

[0447] implementing at the analytical database one or more nodes organized into a node cluster and a leader node; and

[0448] Cause a corresponding node of the one or more nodes to provide a corresponding most recently committed transaction change identifier to the leader node.

[0449] Clause 58. One or more non-transitory computer-readable storage media of Clause 57, wherein the program instructions, when executed on or across the one or more processors, cause the one or more processors to:

[0450] In response to the leader node receiving the corresponding most recently committed transaction change identifier from the one or more nodes,

[0451] causing an additional checkpoint to be received, wherein the checkpoint includes an additional transaction change having a transaction identifier that is later than the corresponding most recently committed transaction change identifier from the one or more nodes; and

[0452] The additional transactional changes are implemented to the corresponding snapshot.

[0453] Clause 59. One or more non-transitory computer-readable storage media according to any one of clauses 56 to 58, wherein to commit the committed deletion event in the shadow table to the corresponding snapshot, the program instructions further cause the one or more processors to:

[0454] determining, using the corresponding primary key, a corresponding row of the corresponding snapshot where the committed deletion event occurred;

[0455] applying the committed delete event in the shadow table to the corresponding snapshot; and

[0456] The applied deletion events are submitted as a batch to the corresponding snapshot.

[0457] Clause 60. One or more non-transitory computer-readable storage media as recited in any one of Clauses 56 to 59, wherein, in response to committing the committed deletion event in the shadow table to the corresponding snapshot, the program instructions further cause the one or more processors to:

[0458] The committed delete event is removed from the shadow table.

Claims

1. A system comprising: One or more computing devices, wherein the one or more computing devices are configured to: Implementing a transactional database; maintaining at the transactional database a table comprising data items; as well as At the transactional database, writing the transactional changes made to the table to a change data capture log; One or more computing nodes organized into a node cluster, wherein the one or more computing nodes are configured to: Implement analytical databases; as well as maintaining, at the analytics database, a representation of at least a portion of the table, wherein maintaining comprises committing corresponding ones of the transactional changes of the change data capture log received at the analytics database to the representation; At least one transport mechanism configured to: receiving respective snapshots of the segments of the at least one portion of the table, wherein each snapshot comprises a segment of the at least one portion of the table; making the corresponding snapshot accessible to the analytics database; receiving a checkpoint associated with the corresponding snapshot, wherein the checkpoint includes a corresponding portion of the transaction changes of the change data capture log; as well as enabling said checkpoint to be accessible to said analysis database; and Wherein the one or more computing nodes are further configured to, in response to receiving an incoming analytical query related to at least one data item in the representation, provide a result of the incoming analytical query.

2. The system of claim 1, wherein: The transactional changes for a given checkpoint include at least two delete events; and Said maintaining said representation of said at least one portion of said table further comprises: committing the at least two deletion events to a shadow table at the analysis database; as well as In response to the shadow table having a given threshold of committed delete events, the committed delete events of the shadow table are committed to the representation.

3. A system according to claim 1 or claim 2, wherein: The transaction change is marked with a corresponding primary key, the corresponding primary key corresponds to a corresponding row in the transaction database where the transaction change occurs; and The committing of the respective ones of the transactional changes to the representation is based at least in part on use of the respective primary key.

4. A system according to any one of claims 1 to 3, wherein: The transaction database and the analytical database are part of a service provider network; The data storage service of the service provider network is configured to implement a corresponding transport mechanism of the at least one transport mechanism; and The corresponding snapshot or the checkpoint is stored in at least one data storage area of ​​the data storage service, wherein the at least one data storage area is accessible to the transactional database and the analytical database.

5. A system according to any one of claims 1 to 3, wherein: The transactional database and the analytical database are part of a service provider network; and The data stream service of the provider network is used to implement a corresponding transport mechanism of the at least one transport mechanism; and The respective snapshots or the checkpoints are transferred from the transactional database to the analytical database via the data streaming service.

6. A method comprising: A representation of at least a portion of a table including data items is maintained at an analytics database implemented by one or more computing nodes organized into a node cluster, wherein: The table is stored at a transactional database implemented by one or more computing devices; and The maintenance includes: writing, at the transactional database, transactional changes made to the table to a change data capture log; making a snapshot of a segment of the at least one portion of the table accessible to the analytics database via at least one transport mechanism; enabling a checkpoint associated with a respective snapshot to be accessible to the analytics database via a respective transport mechanism of the at least one transport mechanism, wherein the checkpoint includes a respective portion of the transactional changes of the change data capture log; storing the respective snapshots and the checkpoints at the analytics database across the one or more compute nodes of a node cluster; and committing the transactional changes of the corresponding checkpoint to the representation; and In response to receiving an incoming query related to at least one data item in the representation, providing results for the incoming query.

7. The method of claim 6, wherein applying the transaction changes comprises: committing at least two delete events of the transactional changes of a given one of the corresponding checkpoints to a shadow table; as well as In response to the shadow table having a given threshold of committed delete events, the committed delete events in the shadow table are committed to the representation.

8. A method according to claim 6 or claim 7, wherein the method further comprises: With respect to committing the transactional changes of the corresponding checkpoint to the representation, an indication that the transaction applied at the analysis database has a latest transaction identifier is stored; as well as The transactional database is polled to determine whether an additional checkpoint including one or more transactional changes that have been applied at the transactional database has a later transaction identifier than the most recent transaction identifier committed at the analytical database.

9. The method according to claim 8, wherein: In response to said polling said transaction database, enabling the additional checkpoint to be accessible to the analysis database via the respective one of the at least one transport mechanisms; as well as The one or more transaction changes having the later transaction identifier than the latest transaction identifier committed at the analytics database are committed to the representation.

10. The method according to any one of claims 6 to 9, wherein the method further comprises: One or more data definition language commands that are incompatible with the checkpoint are determined via negotiation between the one or more computing nodes of the node cluster and the one or more computing devices.

11. The method of claim 10, wherein the method further comprises: In response to determining at the analysis database that a given transactional change for a given checkpoint includes a corresponding data definition language command of the incompatible one or more data definition language commands, an error message is provided.

12. The method according to any one of claims 6 to 11, wherein: The transactional database and the analytical database are part of a service provider network; and Said enabling said checkpoint to be accessible to said analytics database comprises storing said checkpoint in at least one data storage area of ​​a data storage service of said service provider network.

13. The method according to any one of claims 6 to 11, wherein: The transactional database and the analytical database are part of a service provider network; and Said enabling the checkpoint to be accessible by the analytical database comprises transmitting the checkpoint from the transactional database to the analytical database via a data streaming service of the service provider network.

14. A method according to any one of claims 6 to 11, wherein: The checkpoints are stored in a storage device used by the transactional database; said enabling said checkpoint to be accessible to said analytical database occurs via a direct connection between said transactional database and said analytical database; and The transaction database provides the checkpoint, or the analysis database requests the checkpoint.

15. The method according to any one of claims 6 to 14, further comprising: Executing a handshake protocol, wherein executing the handshake protocol comprises: determining a mapping for partitioning the respective snapshots and associated checkpoints across the one or more compute nodes of the node cluster; determining the at least one transport mechanism to be used for said enabling said snapshot to be accessible by said analytics database and said enabling said checkpoint to be accessible by said analytics database; and Determinations of the handshake protocol are made accessible to the transaction database and the analytical database.

Images