Amazon Technologies, Inc.

Omer Ahmed Zaki

Yannis Papakonstantinou

Karthik Gurumoorthy Subramanya Bharathy

Rohan Deshpande

Rajib Dugar

Shivateja Reddy Ummenthala

Swaminathan Sivasubramanian

Allan Henry Vermeulen

Khawaja Salman Shams

Brian S O'Neill

Kiran Kumar Muniswamy Reddy

Prashant Pandey

David Craig Yanacek

Johanna S Olson

Johnny Ying Wu

Anand Sasidharan

Hendrik De Kock

Timothy Andrew Rath

Upendra Bhalchandra Shevade

Mustafa Ozan Ozen

Gregory Rustin Rogers

Jonathan Andrew Fritz

Gaurav Gupta

Gaurav Saxena

Lonnie J Princehouse

Aanchal Gupta

Hendrik Jacobus De Kock

Kevin Christen

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.

Cloud-based database for spatial data lifecycle management

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.

Scalable architecture for a distributed time-series database

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.

Continuous functions in a time-series database

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.

Maintaining data stream history for generating materialized views

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

Dynamically adjusting performance of materialized view maintenance

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.

Managed materialized views created from heterogenous data sources

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.

Cross-data-store operations in log-coordinated storage systems

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.

Independent evictions from datastore accelerator fleet nodes

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.

Replicating materialized views across heterogeneous target systems

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.

Automated configuration of log-coordinated storage groups

Managed materialized views created from heterogeneous data sources

Based at least in part on an optimization goal determined for a storage group comprising a plurality of data stores for which writes requests are coordinated by a log-based transaction manager, one or more lifecycle transitions are identified for data objects stored in a first data store. In accordance with a first lifecycle transition, a data object is to be transferred from the first data store to a second data store based at least in part on a duration for which the data object has been resident at the first data store. A transition agent is assigned by a configuration manager to implement the first lifecycle transition.

Growing community of inventors

Bellevue, WA, United States of America

Omer Ahmed Zaki