Abstract: A journal service maintains a journal that holds a number of journal entries. Access to the journal entries is controlled by providing a lead resource with access to a named role associated with the journal. A pool of alternate resources containing potential replacements for the lead resource is maintained. A succession order may be established for the pool of alternate resources, and individual resources in the pool of alternate resources may be managed based at least in part on their position within the succession order. The succession order may be established using various criteria that are indicative of a likelihood that a particular alternate resource will be available if the lead resource fails, such as the presence of shared points of failure between the current lead resource and an alternate resource. The lead resource may be replaced with an alternate resource as a result of various impeachment events.

Abstract: A database management system receives a request to create an index for a virtual view of a database table. In response to the request, the database management system identifies relationships between the columns of the virtual view and columns of the database table. The database management system generates an index on the database table, where columns are included in the generated index based on the identified relationships and the definition of the virtual view. Queries of the virtual view are assisted by the generated index of the underlying table.

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 journal service manages a journal that holds a number of journal entries. Journal entries are provided to the journal service by one or more producer services, and the journal service provides journal entries to one or more consumer services. Lead consumers retrieve journal entries from the journal service by specifying a named cursor which identifies a location within the journal from which the journal entries are retrieved. The journal service may select a lead producer and a lead consumer from a collection of candidate producers and consumers using a fitness score determined for each candidate producer and consumer. The fitness score may be based at least in part on the processing capability, predicted reliability, and cost of each candidate producer and consumer. The journal service may replace a lead consumer or producer with an alternate consumer or producer in response to a variety of events.

Abstract: A client-side component of a journal-based multi-data-store database identifies an application schema corresponding to a first application whose data is stored at the database. The application schema includes a writes section indicating a data object to which writes are to be issued from the first application. A journal schema defining one or more data objects for which a concurrency-control protocol is implemented by a journal manager of the database is obtained. Before a transaction request of the application is submitted to the journal manager, the client-side component verifies that the application schema is compatible with the journal schema.

Abstract: A database table, such as may be implemented by a non-relational database, is provided to present information and states associated with that information as memorialized in a cryptographically secured ledger. The semantics of the database table elements, as well as the relationships between various objects therein, may be defined and/or enforced by a schema, a database engine, and/or an application layer. For example, the disclosed methods and systems may be used to implement an asset tracking tool that does not require trust of the implementing system for verification of the system's contents.

Abstract: A distributed, web-services based storage system. A system may include a web services interface configured to receive, according to a web services protocol, a given client request for access to a given data object, the request including a key value corresponding to the object. The system may also include storage nodes configured to store replicas of the objects, where each replica is accessible via a respective unique locator value, and a keymap instance configured to store a respective keymap entry for each object. For the given object, the respective keymap entry includes the key value and each locator value corresponding to replicas of the object. A coordinator may receive the given client request from the web services interface, responsively access the keymap instance to identify locator values corresponding to the key value and, for a particular locator value, retrieve a corresponding replica from a corresponding storage node.

Abstract: To checkpoint a shared state in a distributed system, a node may first isolate itself from communication with other nodes of a distributed system. The node may then store a checkpoint of the shared state. The node then restarts and attempts to initialize its operating state from the stored checkpoint. In response to successfully initializing its operating state, the node restores communication with one or more other nodes of the distributed system. The node then indicates to the one or more other nodes that the stored checkpoint of the shared state is valid.

Abstract: Systems and processes are described for establishing and using a secure channel. A shared secret may be used for authentication of session initiation messages as well as for generation of a private/public key pair for the session. A number of ways of agreeing on the shared secret are described and include pre-sharing the keys, reliance on a key management system, or via a token mechanism that uses a third entity to manage authentication, for example. In some instances, the third party may also perform endpoint selection by providing a particular endpoint along with the token. The particular cipher suite applied in a particular implementation may be configurable. The process is applicable to either implicit key confirmation (e.g., handshake negotiation) or explicit key confirmation (e.g., full negotiation).

Abstract: A distributed, web-services based storage system. A system may include a web services interface configured to receive, according to a web services protocol, a given client request for access to a given data object, the request including a key value corresponding to the object. The system may also include storage nodes configured to store replicas of the objects, where each replica is accessible via a respective unique locator value, and a keymap instance configured to store a respective keymap entry for each object. For the given object, the respective keymap entry includes the key value and each locator value corresponding to replicas of the object. A coordinator may receive the given client request from the web services interface, responsively access the keymap instance to identify locator values corresponding to the key value and, for a particular locator value, retrieve a corresponding replica from a corresponding storage node.

Abstract: A resource manager arranges the resources in a computer system into one or more resource pools. The resource manager allocates a number of active resources and a number of backup resources to a particular resource pool. For each resource managed by the resource manager, the resource manager acquires information that describes the capacity and reliability of the resource. Capacity and reliability information for the particular resource pool is determined based on the capacity and reliability information associated with the resources assigned to the pool. In response to a request, the resource manager may provide an application with resources from several resource pools. The likelihood that the resource manager will be able to provide sufficient resources to the application may be determined based at least in part on the reliability information associated with the several resource pools.

Abstract: Systems and processes are described for establishing and using a secure channel. A shared secret may be used for authentication of session initiation messages as well as for generation of a private/public key pair for the session. A number of ways of agreeing on the shared secret are described and include pre-sharing the keys, reliance on a key management system, or via a token mechanism that uses a third entity to manage authentication, for example. In some instances, the third party may also perform endpoint selection by providing a particular endpoint along with the token. The particular cipher suite applied in a particular implementation may be configurable. The process is applicable to either implicit key confirmation (e.g., handshake negotiation) or explicit key confirmation (e.g., full negotiation).

Abstract: Based at least in part on an optimization goal determined for a storage group comprising a plurality of data stores for which writes requests are coordinated by a log-based transaction manager, one or more lifecycle transitions are identified for data objects stored in a first data store. In accordance with a first lifecycle transition, a data object is to be transferred from the first data store to a second data store based at least in part on a duration for which the data object has been resident at the first data store. A transition agent is assigned by a configuration manager to implement the first lifecycle transition.

Abstract: A first role manager of a distributed service determines that a leadership assignment decision is to be made with respect to a particular node of the service. The first role manager identifies a particular role indicator value from a first subset of a set of role indicator values according to a value selection order of a role assignment policy of the service. The first role manager is not permitted to assign values from a different subset of the first set of role indicator values. The particular role indicator value is transmitted to the particular node, enabling the particular node to fulfill at least a first category of service requirements corresponding to the role of leader node.

Abstract: A pipeline management service improves the operation of a processing pipeline by monitoring the operation of one or more journal services within the processing pipeline, and adjusting operational parameters of the one or more journal services. In various examples, the pipeline management service determines a model of the processing pipeline by identifying the producers and consumers associated with each of the one or more journal services, and determines a processing flow through the one or more journal services based at least in part on the identities of the associated producers and consumers. The pipeline management service acquires backlog information from each of the one or more journal services, and may adjust the operational parameters of a journal service associated with an identified processing bottleneck. In some examples, the pipeline management service adjusts capacity and reliability parameters of the one or more journal services to improve the operation of the processing pipeline.

Abstract: A partitioning policy for materializing writes indicated in journal entries of a multi-data-store database is determined. The policy indicates a partitioning attribute of a data object. A write applier associated with a materialization node of the database processes journal entries according to the partitioning policy. If the value of the partitioning attribute associated with a write of a particular journal entry indicates that the write belongs to a partition materialized at the materialization node, the write applier propagates the write to the materialization node for storage at the node's storage devices.

Abstract: An analytics tool of a journal-based multi-data-store database obtains respective rejection cause descriptors for a set of transactions rejected by the journal manager of the database due to read-write conflicts. A particular rejection cause descriptor indicates a query predicate used for a read set of a transaction request which was rejected by a journal manager of the database due to a read-write conflict between the read set and a previously-committed transaction. The analytics tool prepares a database contention analysis using the rejection cause descriptors, and transmits the analysis to a client.

Abstract: A particular node of a journal-based multi-node distributed storage system requests the addition of an acceptability verification request entry to the journal, indicating a proposed state change of the system. The particular node examines contents of entries added to the journal after the acceptability verification request entry. After determining that a targeted set of acceptability verification response entries have been added to the journal, indicating that the potential state change meets acceptance criteria at respective other nodes of the system, the particular node requests an addition of a committed transaction entry to the journal, indicating an approval of the proposed state change.

Abstract: In response to a read request directed to a first data store of a storage group, a state transition indicator is identified, corresponding to a modification that has been applied at the data store before a response to the read is prepared. A read descriptor that includes the state transition indicator and read repeatability verification metadata is prepared. The metadata can be used to check whether the read request is a repeatable read. The read descriptor is transmitted to a client-side component of the storage group.

Abstract: At a client-side component of a storage group, a read descriptor generated in response to a read request directed to a first data store is received. The read descriptor includes a state transition indicator corresponding to a write that has been applied at the first data store. A write descriptor indicative of a write that depends on a result of the read request is generated at the client-side component. The read descriptor and the write descriptor are included in a commit request for a candidate transaction at the client-side component, and transmitted to a transaction manager.