Abstract: A materialization configuration request is received via a programmatic interface from a client of a journal-based multi-data-store database. The request indicates a partitioning rule to be used to select, for respective writes indicated in committed transaction entries of a journal, the materialization node at which the writes are to be stored. A control plane component of the database verifies that a set of materialization nodes corresponding to the partitioning rule has been established, and initiates the propagation of writes from the journal to the materialization nodes by respective write appliers.

Abstract: Documents may be maintained in a repository and retrieved based on searches that specify labels as criteria. Documents may be associated with groups of labels identified as topics. Searches may be performed using binary-encoded matrices specifying relationships between documents and topics, topics and labels and differential information indicating differences between topics and labels associated with documents. An initial result estimate may be based on forming a product of a documents-topics matrix and a topics-labels matrix. The initial estimate may be corrected by applying the differential information.

Abstract: A transaction request compliant with a first version of a journal schema of a multi-data-store storage system is received at a journal manager. The journal schema indicates attributes of data objects which may be materialized at various data stores of the system. The journal manager stores an entry in the system's journal if the transaction meets acceptance criteria. Writes indicated in the entry are materialized at the data stores after verifying that the entry is compliant with the journal schema. After verifying that member data stores have approved a proposed change to the journal schema, another entry indicating a different version of the journal schema is added to the journal. Client-side components of the system obtain the current version of the journal schema to prepare the transaction requests.

Abstract: A transaction request compliant with a first version of a journal schema of a multi-data-store storage system is received at a journal manager. The journal schema indicates attributes of data objects which may be materialized at various data stores of the system. The journal manager stores an entry in the system's journal if the transaction meets acceptance criteria. Writes indicated in the entry are materialized at the data stores after verifying that the entry is compliant with the journal schema. After verifying that member data stores have approved a proposed change to the journal schema, another entry indicating a different version of the journal schema is added to the journal. Client-side components of the system obtain the current version of the journal schema to prepare the transaction requests.

Abstract: A query restriction descriptor indicating one or more attributes of a data object of a multi-data-store storage system is determined at a client-side component of the system. The query restrictions descriptor is used to prepare at least a read set descriptor of a proposed transaction. The read set of the proposed transaction includes a query with a predicate directed to the one or more attributes. A transformation function is applied to the predicate, and the result of the transformation is included in the read set descriptor. The proposed transaction is sent to a journal manager of the system, which performs read-write conflict detection using the read set descriptor and write set descriptors of one or more previously-committed transactions.

Abstract: A journaled database system may comprise data nodes that maintain a collection of data and provide read access to the data to a client in accordance with a read schema and write access to the client in accordance with a write schema. A change to the schemas may be proposed. A materialization schema may be identified based on correlated determinations that both of the read schema and the write schema are satisfiable based on the materialization schema. The proposed changes may be accepted when the read schema and write schema are simultaneously satisfiable.

Abstract: A journaled database system may comprise data nodes that collectively maintain a collection of data and provide clients with read and write access to the collection. Correlated classification functions may be associated with read and write operations, such that items affected by a write operation are classified similarly to items accessed during a read operation. Read and write signatures may be formed based on the classification. Conflicts may be detected by comparing the read and write signatures for equivalent or overlapping classifications.

Abstract: A transaction request is received at a journal-based state management system. The transaction request includes a register processing section indicating an operation to be performed at a journal register allocated to the transaction submitter to store state information of an application. Based on the results of a conflict detection operation performed with respect to the transaction request and on the result of the operation on the journal register, the transaction request is accepted for commit. The value of the journal register is stored at a node of the state management system and provided to the transaction submitter.

Abstract: A device may participate in a shared data state in which editing operations performed locally are distributed and synchronized with other devices participating in the shared data state. Data may be maintained in log-structured storage files on each device. Changes made locally may be conditionally appended to log-structured storage and committed or rolled back during synchronization. Devices may exchange sets of related change descriptors preceded by associated contextual information. Conflicts may be resolved through application of conflict resolution rules or through a user-involved process. User notification of conflict resolution may be based on user intent inferred from contextual information and associated change descriptors.

Abstract: A journaled database may comprise a computing node that forms a local version of a global state, synchronized with respect to the high-water mark of a data node that maintains the global state. Instructions to modify the state that have been committed, subsequent to forming the local version of the state, may be represented in a merge signature. An uncommitted transaction may be checked for conflicts with respect to a last-ordered committed instruction to modify the data state. Validation with respect to earlier instructions represented by the merge signature may be skipped.

Abstract: A data store manager of a multi-data-store storage system detects an error condition associated with applying a state change indicated in a particular journal entry of the storage system to a first data store. A first redaction entry inserted in the journal at some point after the particular entry is identified. The first redaction entry indicates the particular entry as a redaction target. After verifying that the journal does not include another redaction entry targeting the first redaction entry, processing of the particular entry is terminated and processing of later-inserted entries can proceed.

Abstract: A snapshot manager examines a set of entries of a journal of a multi-data-store storage system. Each entry is formatted in a data-store-independent transaction language and various entries contain a respective indication of a committed change to a data object or to a journal schema. Corresponding to various data objects that are materialized at least at a data store of the storage system, respective compact state change representations are generated based on the set of journal entries affecting the data objects. A given compact state change representation, also formatted in the transaction language, may represent cumulative effects of several changes. A snapshot of the journal, comprising the compact state representations, is stored.

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 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 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: 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: 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: 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.