Abstract: A block storage service provides block-level storage to a plurality of distinct computing instances for a plurality of distinct users. For each of one or more of the plurality of distinct computing instances, information about data being stored in the block storage service is determined. Based on the information about the data being stored in the block storage service, a block storage transaction enhancement for the data being stored in the block storage service is determined. The block storage service performs the selected block storage transaction enhancement with respect to the data being stored in the block storage service.

Abstract: Techniques are described for managing access of executing programs to non-local block data storage. In some situations, a block data storage service uses multiple server storage systems to reliably store copies of network-accessible block data storage volumes that may be used by programs executing on other physical computing systems, and snapshot copies of some volumes may also be stored (e.g., on remote archival storage systems). A group of multiple server block data storage systems that store block data volumes may in some situations be co-located at a data center, and programs that use volumes stored there may execute on other computing systems at that data center, while the archival storage systems may be located outside the data center. The snapshot copies of volumes may be used in various ways, including to allow users to obtain their own copies of other users' volumes (e.g., for a fee).

Abstract: A database management system stores an entry in a journal. The journal, upon storage of the entry, comprises a leaf node with a hash value based at least in part on the entry, and a hierarchy of interior nodes based at least in part upon the leaf node. In response to a request to delete the entry, the entry is deleted but the hash value is retained. A cryptographic proof of a second entry stored in the journal is based at least in part on the retained hash value.

Abstract: A database management system stores an entry in a journal. The journal, upon storage of the entry, comprises an ordered plurality of leaf nodes and a hierarchy of interior nodes based upon the leaf nodes. A node in the ordered plurality of nodes comprises a hash value computed based on the hash of a corresponding entry and a hash of a prior leaf node. A cryptographic proof of the entry comprises successive application of a hash operator to one or more hashes of the leaf nodes.

Abstract: A database management system stores an entry in a journal. Upon storage of the entry, the journal comprises a plurality of threaded leaf nodes and a hierarchy of interior nodes comprising hash values computed from the threaded leaf nodes. A first set of hash values is provided to prove that the entry is stored in a first version of the journal. A second set is provided to prove that the entries stored in the first version of the journal are unmodified and stored in a second version of the journal.

Abstract: A database management system receives a request to perform a transaction. The database management system commits the transaction, and in response to committing the transaction, generates a cryptographic hash based on an attribute of the transaction. The cryptographic hash is stored in a leaf-region of a hash tree. In response to a request to verify the transaction, signatures are retrieved from the tree based on a traversal of the tree to locate the node corresponding to the transaction. The retrieved signatures are used to verify the transaction.

Abstract: A storage management system monitors an indicator of whether data storage is or will exceed a threshold of storage utilization as stored on a current implementation resource, such as a storage server. The indicator may be used to determine whether none, some or all of the data storage should be moved from the current implementation resource to an available implementation resource.

Abstract: Commitments against various resources can be dynamically adjusted for customers in a shared-resource environment. A customer can provision a data volume with a committed rate of Input/Output Operations Per Second (IOPS) and pay only for that commitment (plus any overage), for example, as well as the amount of storage requested. The customer can subsequently adjust the committed rate of IOPS by submitting an appropriate request, or the rate can be adjusted automatically based on any of a number of criteria. Data volumes for the customer can be migrated, split, or combined in order to provide the adjusted rate. The interaction of the customer with the data volume does not need to change, independent of adjustments in rate or changes in the data volume, other than the rate at which requests are processed.

Abstract: Changes made to a database table are accumulated, in durable storage, and snapshots of partitions of the table are obtained. For successive snapshots of a partition, the system accesses a previous snapshot, applies changes from the accumulated changes, and stores the updated snapshot to a durable data store. The accumulated changes and the successive partition snapshots are made available to restore the database to any point in time across a continuum between successive snapshots. Although each partition of the table may have a backup snapshot that was generated at a time different from when other partition snapshots were generated, changes from respective change logs may be selectively log-applied to distinct partitions of a table to generate an on-demand backup of the entire table at common point-in-time across partitions. Point-in-time restores of a table may rely upon a similar process to coalesce partition snapshots that are not aligned in time.

Abstract: Schema incompatibilities are generating views at target data stores are detected. A view definition may be received at a view management system that specifies data to obtain from source data stores and identifies a target data store to store the view. The view management system may identify an incompatibility between a schema for the data, specified in the view definition, with a type system for the target data store. The view management system may provide an indication of the incompatibility with the type system for the target data store.

Abstract: A storage controller is implemented for controlling a storage system. The storage controller may be implemented using a distributed computer system and may include components for servicing client data requests based on the characteristics of the distributed computer system, the client, or the data requests. The storage controller is scalable independently of the storage system it controls. All components of the storage controller, as well as the client, may be virtual or hardware-based instances of a distributed computer system.

Abstract: Scalable architecture for propagating updates may be implemented for data replicated from a data set. A node may receive updates to items in a data set that have been committed to the data set. The node may determine whether the update should be applied to a replicated portion of the data set. For updates that should be applied, the node may identify another node that hosts the replicated portion of the data set and send a request to the other node to perform a conditional atomic operation to apply the update to the item in the replicated portion of the data set. The condition may compare a version identifier associated with an update and a current version identifier for the item at the other node. If the condition evaluates true, then the update to the item in the replicated portion may be performed.

Abstract: A database management system stores an entry in a journal. The journal, upon storage of the entry, comprising a hierarchy of nodes. A node in the hierarchy comprises a hash value computed by application of a symmetric hash operator to hash values of first and second child nodes. The symmetric hash operator generates equivalent output irrespective of the order of the operands. A cryptographic proof of the entry comprises successive application of the symmetric hash operator to a list of hashes from the hierarchy.

Abstract: Changes made to a database table are accumulated, in durable storage, and snapshots of partitions of the table are obtained. For successive snapshots of a partition, the system accesses a previous snapshot, applies changes from the accumulated changes, and stores the updated snapshot to a durable data store. The accumulated changes and the successive partition snapshots are made available to restore the database to any point in time across a continuum between successive snapshots. Although each partition of the table may have a backup snapshot that was generated at a time different from when other partition snapshots were generated, changes from respective change logs may be selectively log-applied to distinct partitions of a table to generate an on-demand backup of the entire table at common point-in-time across partitions. Point-in-time restores of a table may rely upon a similar process to coalesce partition snapshots that are not aligned in time.

Abstract: Transaction requests may be ordered in a distributed database according to an independently assigned sequence. Different distributed system nodes, such as a transaction coordinator and a storage node may independently assign sequence numbers to requests to access a distributed database. A storage node may receive the request from a transaction coordinator with an assigned sequence number and another request to which the storage node may assign a sequence number. The storage node can then order performance of the requests based on the sequence numbers.

Abstract: A database management system receives a request to perform a transaction. The database management system commits the transaction, and in response to committing the transaction, generates a cryptographic hash based on an attribute of the transaction. The cryptographic hash is stored in a leaf-region of a hash tree. In response to a request to verify the transaction, signatures are retrieved from the tree based on a traversal of the tree to locate the node corresponding to the transaction. The retrieved signatures are used to verify the transaction.

Abstract: Transaction requests may be ordered in a distributed database according to an independently assigned sequence. Different distributed system nodes, such as a transaction coordinator and a storage node may independently assign sequence numbers to requests to access a distributed database. A storage node may receive the request from a transaction coordinator with an assigned sequence number and another request to which the storage node may assign a sequence number. The storage node can then order performance of the requests based on the sequence numbers.

Abstract: A shared resource service allows multiple clients to agree on rules for accessing a shared resource (e.g., a shared database or a shared service). The shared resource service also allows the clients to make changes to the rules (e.g., via consensus or majority vote). The clients use the shared resource service to enforce the rules, without having to trust each other to follow the rules when accessing the shared resource. First, the clients agree on a set of initial rules for accessing the shared resource and a set of initial rules for making changes to the rules. After the rules are initialized, then the clients can begin using the shared resource in accordance with the agreed upon rules. In response to a request for accessing the shared resource or a request for changing rules, the shared resource service enforce the applicable rules.

Abstract: A geographically distributed system using a hybrid, multi-master design is disclosed. The system may use global tables, for which both reads and writes may be performed locally, but with a single region serving as a master region. All strongly consistent reads and writes may be sent to the master region, whereas eventually consistent reads and writes may be performed in any region with a replica. The master region may not be statically assigned but may move from region to region. The master region may be assigned manually by client preference or may be assigned and updated automatically based on the time of day or workload characteristics.

Abstract: Changes made to a database table are accumulated, in durable storage, and snapshots of partitions of the table are obtained. For successive snapshots of a partition, the system accesses a previous snapshot, applies changes from the accumulated changes, and stores the updated snapshot to a durable data store. The accumulated changes and the successive partition snapshots are made available to restore the database to any point in time across a continuum between successive snapshots. Although each partition of the table may have a backup snapshot that was generated at a time different from when other partition snapshots were generated, changes from respective change logs may be selectively log-applied to distinct partitions of a table to generate an on-demand backup of the entire table at common point-in-time across partitions. Point-in-time restores of a table may rely upon a similar process to coalesce partition snapshots that are not aligned in time.