Abstract: Materialized views may be generated at a managed materialized view platform that accepts data streams as a source. When updating a materialized view with a data stream as a source, a stored portion of the stream is used to maintain a history of changes to be made. When a join operation needs to utilize the data stream source to determine an update to the materialized view, the data stream is preserved to complete the join and update the materialized view.

Abstract: Methods, systems, and computer-readable media for continuous functions in a time-series database are disclosed. A plurality of data points of a time series are stored into one or more storage tiers of a time-series database. The plurality of data points comprise a plurality of discrete measurements at respective timestamps. Using one or more query processors of the time-series database, a query of the time series is initiated. The query indicates a time range. Using the one or more query processors, a continuous function is determined that represents a segment of the time series in the time range. The continuous function is determined based at least in part on the plurality of data points. An operation is performed using the continuous function as an input.

Abstract: The maintenance of a materialized view created and managed by a materialized view management platform may be dynamically adjusted. The performance of updates to a materialized view are monitored to trigger different events to make adjustments to the performance of subsequent updates. The materialized view management platform can adequately scale to handle changes to data sources as inputs to the maintenance of the materialized view, as well as make other adjustments handle various changes in the capability of the target data store to receive updates to the materialized view (e.g., target data store outages).

Abstract: Managed materialized views may be generated from across heterogeneous data sources. A request to create a materialized view may be received and performed by a materialized view management platform, which may obtain and generate the materialized view from different data sources and store the materialized view in a target system. Changes to the data sources may be obtained at the materialized view management platform and updates to the materialized view may be determined. The materialized view in the target system may be updated.

Abstract: Methods, systems, and computer-readable media for a cloud-based database for spatial data lifecycle management. A spatial database receives elements of spatial data from a plurality of clients of the distributed spatial database. An individual element of the spatial data comprises one or more location values or one or more spatial objects. The spatial database stores the plurality of elements of spatial data using a plurality of storage resources. The spatial database receives a query. The spatial database determines one or more elements of spatial data matching the query from the plurality of elements of spatial data that were stored using the plurality of storage resources.

Abstract: Methods, systems, and computer-readable media for a cloud-based database for spatial data lifecycle management. A spatial database receives elements of spatial data from a plurality of clients of the distributed spatial database. An individual element of the spatial data comprises one or more location values or one or more spatial objects. The spatial database stores the plurality of elements of spatial data using a plurality of storage resources. The spatial database receives a query. The spatial database determines one or more elements of spatial data matching the query from the plurality of elements of spatial data that were stored using the plurality of storage resources.

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 fleet of query accelerator nodes is established for a data store. Each accelerator node caches data items of the data store locally. In response to determining that an eviction criterion has been met, one accelerator node removes a particular data item from its local cache without notifying any other accelerator node. After the particular data item has been removed, a second accelerator node receives a read query for the particular data item and provides a response using a locally-cached replica of the data item.

Abstract: A materialized view created by a materialized view management platform may be replicated across many different target systems. The materialized view management platform allows users to specify different target systems. To create the materialized view in the different target systems, the materialized view management platform can translate the materialized view into different formats in order to store the materialized view in the different formats. Updates to the different instances of the materialized view are then made to keep the different materialized view formats in the different target systems up-to-date.

Abstract: Materialized views may be generated at a managed materialized view platform that accepts data streams as a source. When updating a materialized view with a data stream as a source, a stored portion of the stream is used to maintain a history of changes to be made. When a join operation needs to utilize the data stream source to determine an update to the materialized view, the data stream is preserved to complete the join and update the materialized view.

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: Materialized views may be generated at a managed materialized view platform that accepts data streams as a source. When updating a materialized view with a data stream as a source, a stored portion of the stream is used to maintain a history of changes to be made. When a join operation needs to utilize the data stream source to determine an update to the materialized view, the data stream is preserved to complete the join and update the materialized view.

Abstract: Managed materialized views may be generated from across heterogeneous data sources. A request to create a materialized view may be received and performed by a materialized view management platform, which may obtain and generate the materialized view from different data sources and store the materialized view in a target system. Changes to the data sources may be obtained at the materialized view management platform and updates to the materialized view may be determined. The materialized view in the target system may be updated.

Abstract: Managed materialized views may be generated from across heterogeneous data sources. A request to create a materialized view may be received and performed by a materialized view management platform, which may obtain and generate the materialized view from different data sources and store the materialized view in a target system. Changes to the data sources may be obtained at the materialized view management platform and updates to the materialized view may be determined. The materialized view in the target system may be updated.

Abstract: Materialized views may be generated at a managed materialized view platform that accepts data streams as a source. When updating a materialized view with a data stream as a source, a stored portion of the stream is used to maintain a history of changes to be made. When a join operation needs to utilize the data stream source to determine an update to the materialized view, the data stream is preserved to complete the join and update the materialized view.

Abstract: Managed materialized views may be generated from across heterogeneous data sources. A request to create a materialized view may be received and performed by a materialized view management platform, which may obtain and generate the materialized view from different data sources and store the materialized view in a target system. Changes to the data sources may be obtained at the materialized view management platform and updates to the materialized view may be determined. The materialized view in the target system may be updated.

Abstract: The maintenance of a materialized view created and managed by a materialized view management platform may be dynamically adjusted. The performance of updates to a materialized view are monitored to trigger different events to make adjustments to the performance of subsequent updates. The materialized view management platform can adequately scale to handle changes to data sources as inputs to the maintenance of the materialized view, as well as make other adjustments handle various changes in the capability of the target data store to receive updates to the materialized view (e.g., target data store outages).

Abstract: A materialized view created by a materialized view management platform may be replicated across many different target systems. The materialized view management platform allows users to specify different target systems. To create the materialized view in the different target systems, the materialized view management platform can translate the materialized view into different formats in order to store the materialized view in the different formats. Updates to the different instances of the materialized view are then made to keep the different materialized view formats in the different target systems up-to-date.

Abstract: Methods, systems, and computer-readable media for a scalable architecture for a distributed time-series database are disclosed. Using a fleet of ingestion routers, time-series data generated by a plurality of client devices is stored into a plurality of durable partitions. The time-series data comprises a plurality of time series, and an amount of the ingestion routers is determined based at least in part on an ingestion rate of the time-series data. Using a fleet of stream processors, the time-series data from the durable partitions is stored into a plurality of storage tiers including a first storage tier and a second storage tier. A retention period for the first storage tier differs from a retention period for the second storage tier. An amount of the stream processors is determined based at least in part on the time-series data in the durable partitions.

Abstract: Methods, systems, and computer-readable media for edge processing in a distributed time-series database are disclosed. A first set of time-series data is generated by one or more client devices and is associated with one or more time series. A local time-series database stores the first set of time-series data into a local storage tier. The local time-series database generates a second set of time-series data derived from the first set of time-series data. A remote time-series database receives the second set of time-series data from the local time-series database via a network. The remote time-series database stores the second set of time-series data into one or more remote storage tiers.