Abstract: A transaction request is received at a log-based transaction manager, indicating a logical constraint to be satisfied before the corresponding transaction is committed. The transaction manager identifies a subset of transaction records stored in a persistent change log that are to be examined to evaluate the logical constraint. Based at least in part on the result of a comparison of one or more constraint-related data signatures included in the transaction request with corresponding data signatures in the subset of transaction records, a decision is made to commit the requested transaction.

Abstract: A journaled database system may comprise data nodes that maintain a collection of data structured in accordance with a schema. A change to the schema may be applied by a journal module while a journal consumer continues to operate using a prior version of the schema. A buffer may be formed and have stored therein records describing state change instructions according to the prior view of the schema. An index of correspondence between the records in the buffer and in the source journal may be maintained.

Abstract: A forking coordinator of a journal-based multi-data-store database determines that a forking criterion for a first journal has been met. The coordinator stores an indication that processing of transaction requests directed to a particular subset of the database is suspended. The coordinator instantiates a second journal for storing committed transaction entries for the particular subset. Metadata of the second journal indicates that transaction entries with sequence numbers in a particular range are stored in the first journal. The coordinator stores an indication that transaction processing associated with the particular subset of the system is to be resumed using the second journal.

Abstract: A test coordinator for an application whose data is to be stored at a journal-based multi-data-store database using an optimistic concurrency control protocol identifies a test descriptor. The test descriptor indicates a particular order of a plurality of events associated with the application's data, such as reads from various data stores and propagations of committed writes from the database journal to the data stores. The test coordinator uses a set of control mechanisms to cause the events to occur in a selected execution environment in the particular order, and stores an indication of a state reached by the application in response to the events.

Abstract: A journaled database system may comprise data nodes that maintain a collection of data structured in accordance with a schema. A change to the schema may be applied by a journal module while a journal consumer continues to operate using a prior version of the schema. A buffer may be formed and have stored therein records describing state change instructions according to the prior view of the schema. An index of correspondence between the records in the buffer and in the source journal may be maintained.

Abstract: A journal manager of a multi-data-store storage appends a committed transaction entry to a journal, indicating a state change which has been approved for commit using an optimistic concurrency control algorithm. A first representation of the state change is generated and stored at one materialization node. A different representation of the same state change, comprising at least one attribute for which a value is not included in the first representation, is generated and stored at a different materialization node.

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: A configuration manager of a storage service receives a set of service requirements, comprising one or more of: a performance requirement for one or more types of storage operations, or an access interface type requirement Based on the service requirements, a candidate storage configuration that includes one or more data store instances and a first log-based transaction manager is generated. Subsequent to an approval of the first storage configuration by a client, the establishment of the data store instances and the log-based transaction manager is initiated.

Abstract: A metadata manager of a file system receives a directory move request, indicating a source directory (SD) and a proposed parent directory (PPD). Each directory in the directory tree is assigned a respective move rank (MR) in accordance with a rank-order preserving rule. The metadata manager checks whether the MR of the SD or the PPD is to be changed to avoid violating the rule. If an MR change is required, one or more directory-pair operations are implemented to determine whether the move can be successfully completed. In each directory-pair operation, the MRs of a pair of directories is examined and an attempt is made to modify one of the MRs of the pair in accordance with the rule. If enough MRs can be changed, the move is completed by adding the SD as a child of the PPD.

Abstract: A data store manager of a multi-data-store journal-based database performs a sequential analysis of committed transaction entries of a journal. A particular entry includes a directive to determine a value of an attribute of a data object based on a result obtained from a value generator, and does not specify the value of the attribute. The data store manager determines the value using a local version of the value generator, and stores the value in a materialized version of the data object. In response to a programmatic read request, the data store manager provides the materialized version of the data object.

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 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: A configuration manager of a storage service receives a set of service requirements, comprising one or more of: a performance requirement for one or more types of storage operations, or an access interface type requirement Based on the service requirements, a candidate storage configuration that includes one or more data store instances and a first log-based transaction manager is generated. Subsequent to an approval of the first storage configuration by a client, the establishment of the data store instances and the log-based transaction manager is initiated.

Abstract: A system may comprise a storage device on which counters are stored. A counter may be associated with an identifier. A computing node of the system may receive a request to modify the counter. In response to the request, a read signature may be stored and may comprise a hash of the identifier and a tolerance of the counter to change. A write signature may be stored in response to the request, and may comprise a hash of the identifier and a magnitude of the requested modification. A conflict may be detected by comparing a sum of the magnitudes of requested changes to the tolerance of the read operation.

Abstract: A journal manager of a multi-data-store storage system receives a transaction which includes a message to be stored in the storage system's journal if the transaction request is accepted for commit. The journal manager performs a conflict detection operation, accepts the transaction request, and stores a corresponding committed transaction entry including the message in the journal. A write applier associated with a registered materialization node of the journal reads the committed transaction entry and applies a write indicated in the entry. A registered message subscriber of the journal reads the committed transaction entry asynchronously with respect to the write applier, and reads the contents of the message without applying the write.

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 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: Data stores that are to be configured as members of a storage group on behalf of a client are identified. The client indicates one or more types of cross-data-store operations to be performed. A transaction manager that makes acceptance decisions for write requests directed to the members based at least partly on contents of a log is instantiated, and respective write transformers are set up for at least some of the types of cross-data-store operations. During a particular time period, the workload at the storage group is monitored, and the number and types of cross-data-store operations is determined. The results of the monitoring are used to determine a billing amount for the client based on a selected pricing policy.

Abstract: A jury candidate server (JCS) of a distributed state manager (DSM) implements a plurality of jury configuration evaluation iterations. In a particular iteration, the JCS generates one or more jury configuration options (JCOs) representing changes to a current jury, and assigns quality metrics to the JCOs based at least in part on a prioritized set of criteria among which location diversity has the highest priority. If a JCO meets a quality threshold, a corresponding jury transition is proposed for approval by the current jury.

Abstract: A method and system for dynamic pricing of web services utilization. According to one embodiment, a method may include dynamically predicting utilization of a web services computing resource that is expected to occur during a given interval of time, and dependent upon the dynamically predicted utilization, setting a price associated with utilization of the web services computing resource occurring during the given interval of time. The method may further include providing the price to a customer.