Abstract: A materialized view management service (MVMS) is capable of monitoring resource allocation changes of a source data object at a source data store and responsively generating resource change alerts to the owner of a target data object (the materialized view) in the target data store. Resource allocation changes may include autoscaling changes to the source data object's partition scheme, throughput limit, storage limit, and the like. The MVMS generates resource change alerts in response to these detected events and pushes the alerts to interested subscribers. Depending on the embodiment, the alerts may be pushed to human administrators, or the target data store itself, which may be configured to automatically adjust the resource allocation of the target data object to match the source data object. Advantageously, the disclosed alerts allow view owners to gain real time visibility of resource auto-scaling at the data source and appropriately react to such changes.

Abstract: A geographically distributed data store including a number of geographically distributed regions may be implemented using replication groups that include multiple regions configured according to replication criteria. First tier replication of particular changes to data stored in the distributed data store may be performed in compliance with the replication criteria, where management of replication state is performed with respect to replication across the replication groups. Independent of the first tier replication, individual replication groups may implement second tier replication of changes to data where management of replication state is performed with respect to replication within the particular replication group. Replication group configuration may be determined using the replication criteria which may include thresholds for replication resource utilization, replication latency and utilization of data change logs.

Abstract: Index management for non-relational database systems may be automatically performed. Performance of queries to a non-relational database may be evaluated to determine whether to create or remove an additional index. An additional index may be automatically created to store a subset of data projected from the non-relational database to utilize when performing a query to the non-relational database instead of accessing data in the non-relational database.

Abstract: Consistent queries to replicated data may be performed according to global clock values. Time values for updates performed at a data set may be identified according to a global clock. The updates may be replicated to a replicated portion of a data set. Queries directed to the replicated portion of the data set may be performed in response to determining that the time values for updates indicate that the replicated portion of the data set is consistent with a time value identified for the query according to the global clock.

Abstract: Updates to projected data subsets may be ordered using conditional operations. When updates to a data set are received, a determination is made according to a schema for a projected subset of the data set as to whether the update is to be propagated to the projected subset of the data set. If the update is to be propagated, a comparison of a version identifier for the update may be made with a version identifier for the subset to determine whether performance of the update is consistent with an ordering of updates performed to the first data set. If the comparison indicates the performance of the update is consistent, then the update may be performed to the projected subset. If not, then the update may not be performed.

Abstract: Offline building of a projected data subset may be performed. A request to create a data set that is a projected subset of data from a source data set may be received. A data store separate from the data store storing the source data set may store a copy of the source data set that is used to replicate items to the projected subset of data according to a schema for the projected data subset. Updates made to the source data set may also be replicated to the projected data subset according to the schema. Conflicts between replicated items and replicated updates to the projected data set may be resolved by comparing a version identifier for the replicated update and replicated item to determine what to store in the projected data subset.

Abstract: Replicas may be added to a multi-leader replica group for a data set. A new replica may be added to a group of replicas by copying a version of the data set according to a point in time to the new replica. As updates may occur at different ones of the replicas when the new replica is added, updates that occurred at a source replica for the snapshot and other replicas may be replicated by the different replicas according to the point in time at which the snapshot is created without blocking updates at any of the replicas in the replica group.

Abstract: A service provider network may provider one or more global cloud services across multiple regions. A client may submit a request to create multiple replicas of a service resource in respective instantiations of a service in the multiple regions. The receiving region of the request may determine the capacities of the multiple regions as to serving respective replicas of the service resource. The receiving region may provide a response to the client based on the determined capacities of the regions.

Abstract: Offline building of a projected data subset may be performed. A request to create a data set that is a projected subset of data from a source data set may be received. A data store separate from the data store storing the source data set may store a copy of the source data set that is used to replicate items to the projected subset of data according to a schema for the projected data subset. Updates made to the source data set may also be replicated to the projected data subset according to the schema. Conflicts between replicated items and replicated updates to the projected data set may be resolved by comparing a version identifier for the replicated update and replicated item to determine what to store in the projected data subset.

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: Various systems and methods of tracking database partition change log dependencies are described herein. A system is disclosed herein, according to some embodiments. A change log for a database partition of the plurality of database partitions is stored to a log store. An indication that a split of the database partition into two or more child database partitions has occurred is received. Responsive to the split of the database partition, the change log is split into two or more corresponding child change logs. A portion of the change log is deleted responsive to a determination that a respective complete snapshot is stored for each child database partition corresponding to a child change log of the change log and a determination that a retention window for the portion of the change log has passed.

Abstract: Offline building of a projected data subset may be performed. A request to create a data set that is a projected subset of data from a source data set may be received. A data store separate from the data store storing the source data set may store a copy of the source data set that is used to replicate items to the projected subset of data according to a schema for the projected data subset. Updates made to the source data set may also be replicated to the projected data subset according to the schema. Conflicts between replicated items and replicated updates to the projected data set may be resolved by comparing a version identifier for the replicated update and replicated item to determine what to store in the projected data subset.

Abstract: Various systems and methods of tracking database partition change log dependencies are described herein. A system is disclosed herein, according to some embodiments. A change log for a database partition of the plurality of database partitions is stored to a log store. An indication that a split of the database partition into two or more child database partitions has occurred is received. Responsive to the split of the database partition, the change log is split into two or more corresponding child change logs. A portion of the change log is deleted responsive to a determination that a respective complete snapshot is stored for each child database partition corresponding to a child change log of the change log and a determination that a retention window for the portion of the change log has passed.

Abstract: Various systems and methods to efficiently store backups of partitions of a database are disclosed. An indication to take a current snapshot of a partition of the database is received. A log size and operation type statistics are determined for a portion of the change log for the partition. A snapshot type is determined for the partition based at least in part on the log size and the operation type statistics, where the snapshot type specifies a log-based snapshot or a full snapshot. The snapshot is stored as metadata indicating a point in the change log if the determined snapshot type is log-based snapshot or stored as complete data of the partition if the determined snapshot type is full snapshot.