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.