Abstract: Optimistic concurrency may be implemented for multiple writers to a database. Writes to a database from different writers may succeed unless a conflict is detected at the data store for the database. For detected conflicts, a request to resolve the conflict between writes may be submitted to a primary writer, which may determine and provide a resolution of the conflict to the conflicting writers. The data store may then be updated to commit the selected write identified by the resolution of the conflict.

Abstract: Systems and methods are disclosed to implement, in a multi-writer database system, a database engine node that optimistically sends queued purge operations to a backend storage system without waiting for acknowledgement of previous operations from the storage system. If a conflict is later detected for a particular operation, the database engine node may retry some portion of the purge operations in the queue. In embodiments, the purge operations are performed as part of a garbage collection phase of a multi-version concurrency control (MVCC) protocol, where unneeded versions of objects previously generated for isolated snapshots are deleted. In embodiments, the operations in the queue may be grouped so that a rejection of one operation in the group will cause the entire group to be retried. Because these purge operations are idempotent and directed to objects that are invisible, they may be freely retried in arbitrary order, without maintaining any rollback state.

Abstract: Methods, systems, and computer-readable media for dynamic prefetching for database queries are disclosed. A query of a database is started according to a first prefetch policy. Before completing the query, the first prefetch policy is changed to a second prefetch policy. A portion of the query is performed according to the second prefetch policy.

Abstract: Methods, systems, and computer-readable media for dynamic prefetching for database queries are disclosed. A query of a database is started according to a first prefetch policy. Before completing the query, the first prefetch policy is changed to a second prefetch policy. A portion of the query is performed according to the second prefetch policy.

Abstract: Storage level query processing may be implemented for processing database queries. Nodes that can access a database may perform parallel processing for at least a portion of a database query. An indication may be received that specifies parallel processing for the database query. The nodes can then be caused to perform the portion of the query as part of providing a result in response to the database query instead of a node, such as a query engine node, that received the database query.

Abstract: A service provider network implements seamless scaling via proxy replay of session state. Upon a trigger, such as a determination to scale a server, a scaled server may be spun up and an identifier of the scaled server provided to a first (existing) server. The first server sends the identification of the second server, and session state information for each of the connections between the first server and the request router, to the request router. For each of the connections, the request router establishes a new connection between the request router and the second (scaled) server, and replays the session state information for the connection to the second server. The request router then routes traffic between each existing client connection (e.g., the same existing client connection which carried traffic delivered to the first server) and the corresponding new connection to the second server.

Abstract: Proxy-based scaling may be performed for databases. A proxy may be implemented for a database that can establish a connection between the proxy and a database engine to perform a database queries received from a client at the proxy. A scaling event may be detected for the database responsive to which the proxy may establish a connection with a new database engine which may, in some embodiments, have different capabilities or resources that address the features or criteria that triggered the scaling event. Session state may be copied from the database engine to the new database engine so that the new database engine may be able to provide access to the database on behalf of requests received from the client through the proxy.

Abstract: Proxy-based scaling may be performed for databases. A proxy may be implemented for a database that can establish a connection between the proxy and a database engine to perform a database queries received from a client at the proxy. A scaling event may be detected for the database responsive to which the proxy may establish a connection with a new database engine which may, in some embodiments, have different capabilities or resources that address the features or criteria that triggered the scaling event. Session state may be copied from the database engine to the new database engine so that the new database engine may be able to provide access to the database on behalf of requests received from the client through the proxy.

Abstract: Automatic consistency is implemented for forwarding writes in a database system. A read-only node may support both read and write requests to a database. The read only node may forward write requests to a read-write node. The read-only node may determine whether to include the forwarded requests in a version of the database for a read request automatically according to a consistency specified for a read request.

Abstract: Systems and methods are disclosed to implement, in a database system, a database engine node that generates write tracking transactions to atomically enforce cross-page constraints for write operations. In embodiments, the database system may include multiple database engine nodes that optimistically perform page writes without checking for potential conflicts at a shared storage system. The storage system is configured to detect and report conflicting writes on the same page. To cause the storage system to report cross-page conflicts for a write, the database engine node creates a transaction that includes the write and a write tracker (WT) operation for a tracked page. The WT operation will cause the storage system to report any conflicting writes to the tracked page before the actual write is accepted by the storage system. If a reported conflict is not favorably resolved, the database engine node will abort the entire transaction, including the actual write.

Abstract: Batch processing of undo log records may be performed for rolling back a database transaction. When a rollback operation for a database transaction is performed, undo log records from an undo log to rollback the database transaction are divided into different groups of undo log records. Different requests for the different undo log records are sent to a storage system to be performed. If a conflict is detected for an undo log record in a group, an indication of the conflicting undo log record may be provided to indicate the conflict. The group of undo log records may be resent with a request to reapply the undo log records in the group. When all groups have been identified as successfully completed, then the rollback operation may be considered completed.

Abstract: Systems, methods, and computer storage media are disclosed. A computer storage medium includes instructions that, when executed, perform actions including maintaining a first view based on a first table of a database. The actions include performing a first transaction within the database. The actions include performing a second transaction within the database, and the second transaction relies on data from the first view. Performing the second transaction includes beginning the second transaction. In response to occurrence of both (i) the first transaction committing a first modification to the first table subsequent to the beginning of the second transaction and (ii) the second transaction causing a modification to the first view based on the first modification, performing the second transaction includes continuing the second transaction based on the data from the first view excluding the modification to the first view and completing the second transaction.

Abstract: A storage engine may implement dynamic splitting of contentious data pages. Data pages may store data for a table of a data store as part of an indexing structure for the table. Access to the table may be provided by locating the corresponding data pages via the indexing structure. Access contention for different data pages may be monitored. Data pages may be identified for splitting based on the monitoring. A split operation for an identified data page may be formed to store the data on the identified data page on two different data pages so that subsequent access requests for the data are divided between the two data pages. Monitoring of access contention may also be performed to identify data pages for merging in order to consolidate access requests to a single data page.

Abstract: Systems and methods are disclosed to implement, in a database system, database engine nodes that implement multi-page writes as an atomic operation. In embodiments, the database system may include multiple database engine nodes that optimistically perform page writes locally without checking for potential conflicts at a shared storage system. The storage system will detect and report conflicting writes on a single page. To ensure that a group of writes to multiple pages occur atomically, the database engine node maintains a transaction context for the group, so that if a page conflict is later detected for any write in the group, the entire group will be rolled back at the database engine node and the storage system. In embodiments, the transaction context will track subsequent writes generated by the node to any page written by the group, so that these subsequent writes are also rolled back with the group.

Abstract: Systems, methods, and computer-readable media are disclosed for an improved database. The systems, methods, and computer-readable media described herein may enhance the response time of databases and improve user experiences. In an example method described herein, a database may receive a search request for data stored in the database. The database may be stored in association with a b-tree to facilitate searching and retrieving data from the database. The method may include allocating a portion of a first memory for read ahead operations and performing the read ahead operations, wherein the read ahead operations comprise loading, into the portion of the first memory, data associated with one or more siblings of a current node, wherein the one or more siblings of the current node are one or more nodes that have a same number of parent nodes as the current node.

Abstract: A data store may implement on-demand data schema modifications. Request to change a schema for a data set in a data store may be received and a description of the change recorded as part of a schema history for the data set. The request to change the schema may then be acknowledged. When access requests directed to the data set are received at the data store, the schema history for the data set may be evaluated. If the schema history indicates that data that is to be accessed in order to service the data store needs to include one or more changes in the schema history, then a version of the schema that includes the one or more changes may be applied to the data.

Abstract: A lock-free data structure may be used to provide concurrent access to a data retention index for a data store. Different processes may obtain keys to the data retention index from the lock-free data structure. The different processes may update entries in the data retention index corresponding to the keys to identify data objects to retain in the data store. The data retention index may be evaluated to determine data objects not identified in the data retention index and reclaim portions of the data store that store the determined data objects for storing other data.

Abstract: Read-only nodes of a distributed database system may perform replicated database startup for common database storage. A read-only node may request a view of a database from a master node to initialize the read-only node for servicing queries. An indication of the view may be received and portions of data maintained for the distributed database may be read from a common data store maintaining the data for the database according to the indicated view of the database. In-memory data structures at the read-only node for servicing queries may be initialized based on the portions of data read from the common data store. The read-only node may then be made available for servicing queries.

Abstract: A system for updating a database instance with a patch or new binary image. A database instance includes a database engine and a client-side storage layer driver to manage database state information and volume geometry state information associated with client process connections to a volume of a storage layer of a database system during the patching process. The database engine and the client-side storage service driver save database state information and volume geometry state information, execute the new binary image, and restore the updated database engine with the database state information and volume geometry state information. The new binary image may be executed using a fork/exec model, wherein file descriptors used to identify sockets used in existing client connections are preserved, enabling restoration of the client connections without interruption or downtime.

Abstract: Systems, methods, and computer storage media are disclosed. A computer storage medium includes instructions that, when executed, perform actions including maintaining a first view based on a first table of a database. The actions include performing a first transaction within the database. The actions include performing a second transaction within the database, and the second transaction relies on data from the first view. Performing the second transaction includes beginning the second transaction. In response to occurrence of both (i) the first transaction committing a first modification to the first table subsequent to the beginning of the second transaction and (ii) the second transaction causing a modification to the first view based on the first modification, performing the second transaction includes continuing the second transaction based on the data from the first view excluding the modification to the first view and completing the second transaction.