Amazon Technologies, Inc.

Tate Andrew Certain

Swaminathan Sivasubramanian

Bradley E Marshall

Matthew Scott Garman

Eric Jason Brandwine

Allan Henry Vermeulen

Sachin Jain

Roland Alexander Paterson-Jones

Nicholas J Maniscalco

Marc John Brooker

Christopher Richard Jacques De Kadt

Madhuvanesh Parthasarathy

Atle Normann Jorgensen

James Robert Hamilton

Timothy Daniel Cole

John Michael Morkel

Andrew Wayne Ross

Artem Danilov

Peter Nicholas Desantis

Fiorenzo Cattaneo

Akshat Vig

Kerry Quintin Lee

Roland Paterson-Jones

David R Richardson

Danny Wei

Go Hori

Yannis Papakonstantinou

David Nolan Sunderland

Tobias L Holgers

Nicholas Gordon

Benjamin Nelson Glowney

Alan Michael Judge

Douglas Brian Terry

Brad Eugene Marshall

Vaibhav Jain

Peter N DeSantis

James Christopher Sorenson

Norbert Paul Kusters

Sharatkumar Nagesh Kuppahally

Alexander Richard Keyes

Richard Shawn Bice

Raghav Vijay Pisolkar

Brad E Marshall

Stefano Stefani

Wei Xiao

Amit Gupta

Douglas Stewart Laurence

Somasundaram Perianayagam

Leonard Thomas Tracy

Jianhua Fan

Adam Douglas Morley

Rajaprabhu Thiruchi Loganathan

Anthony A Virtuoso

Ming-Chuan Wu

Ravi Math

Rishabh Jain

Matthew S Garman

Chase Kernan

Yevgeniy Mikhaylyuta

Ramanathan Padinjarel Somanathan

Arijit Choudhury

Derek William Richard Chen-Becker

Aaron Gifford Freshwater

Lokendra Singh Panwar

Michael Benjamin Deardeuff

Rashmi Krishnaiah Setty

Nathan Pellegrom Riley

Sanjay Shanthakumar

Ray Manpreet Singh Matharu

Sudhir Konduru

Abhijeet More

Murtaza Doctor

Anshul Gupta

Vaibhav Govil

Krishnan Seshadrinathan

Naveen Ganapathi Subramanian

Atreya Srivathsan

Phil Simko

Philip Simko

Asmita Barve

Sanket Vishram Chandorkar

Timothy Matthew Lewis

Hina Naseer

Karthikeyani Palanisami

David N Sunderland

Peter N Desantes

Matthew S Garmen

A database management system receives a request to perform a transaction. The database management system commits the transaction, and in response to committing the transaction, generates a cryptographic hash based on an attribute of the transaction. The cryptographic hash is stored in a leaf-region of a hash tree. In response to a request to verify the transaction, signatures are retrieved from the tree based on a traversal of the tree to locate the node corresponding to the transaction. The retrieved signatures are used to verify the transaction.

Cryptographic verification of database transactions

Techniques are described for managing access of executing programs to non-local block data storage. In some situations, a block data storage service uses multiple server storage systems to reliably store copies of network-accessible block data storage volumes that may be used by programs executing on other physical computing systems, and snapshot copies of some volumes may also be stored (e.g., on remote archival storage systems). A group of multiple server block data storage systems that store block data volumes may in some situations be co-located at a data center, and programs that use volumes stored there may execute on other computing systems at that data center, while the archival storage systems may be located outside the data center. The snapshot copies of volumes may be used in various ways, including to allow users to obtain their own copies of other users' volumes (e.g., for a fee).

Providing executing programs with access to stored block data of others

A new type system may be added to a type registry for a data processing service. A request to add the new type system may be received that describes the new type system for a data store. The new type system may be used to perform a data processing job that accesses the data store to obtain or store data as a source or target data store.

Registering additional type systems using a hub data model for data processing

Techniques are described for managing access of executing programs to non-local block data storage. In some situations, a block data storage service uses multiple server storage systems to reliably store network-accessible block data storage volumes that may be used by programs executing on other physical computing systems. A group of multiple server block data storage systems that store block data volumes may in some situations be co-located at a data center, and programs that use volumes stored there may execute on other physical computing systems at that data center. If a program using a volume becomes unavailable, another program (e.g., another copy of the same program) may in some situations obtain access to and continue to use the same volume, such as in an automatic manner in some such situations.

Managing access of multiple executing programs to non-local block data storage

Changes made to a database table are accumulated, in durable storage, and snapshots of partitions of the table are obtained. For successive snapshots of a partition, the system accesses a previous snapshot, applies changes from the accumulated changes, and stores the updated snapshot to a durable data store. The accumulated changes and the successive partition snapshots are made available to restore the database to any point in time across a continuum between successive snapshots. Although each partition of the table may have a backup snapshot that was generated at a time different from when other partition snapshots were generated, changes from respective change logs may be selectively log-applied to distinct partitions of a table to generate an on-demand backup of the entire table at common point-in-time across partitions. Point-in-time restores of a table may rely upon a similar process to coalesce partition snapshots that are not aligned in time.

Continuous data protection

A transaction request compliant with a first version of a journal schema of a multi-data-store storage system is received at a journal manager. The journal schema indicates attributes of data objects which may be materialized at various data stores of the system. The journal manager stores an entry in the system's journal if the transaction meets acceptance criteria. Writes indicated in the entry are materialized at the data stores after verifying that the entry is compliant with the journal schema. After verifying that member data stores have approved a proposed change to the journal schema, another entry indicating a different version of the journal schema is added to the journal. Client-side components of the system obtain the current version of the journal schema to prepare the transaction requests.

Schema management for journal-based storage systems

Customers of a shared-resource environment can provision resources in a fine-grained manner that meets specific performance requirements. A customer can provision a data volume with a committed rate of Input/Output Operations Per Second (IOPS) and pay only for that commitment (plus any overage), and the amount of storage requested. The customer will then at any time be able to complete at least the committed rate of IOPS. If the customer generates submissions at a rate that exceeds the committed rate, the resource can still process at the higher rate when the system is not under pressure. Even under pressure, the system will deliver at least the committed rate. Multiple customers can be provisioned on the same resource, and more than one customer can have a committed rate on that resource. Customers without committed or guaranteed rates can utilize the uncommitted portion, or committed portions that are not being used.

Committed processing rates for shared resources

An interface for requesting, and technique for generation of, a backup of a past state of a database table are provided. Changes made to a database table are accumulated, in durable storage, and snapshots of partitions of the table are obtained. The accumulated changes and the successive partition snapshots are used to generate a past state of the database at any point in time across a continuum between successive snapshots. Although each partition of the table may have a snapshot that was generated at a time different from when other partition snapshots were generated, changes from respective change logs may be selectively log-applied to distinct partitions of a table to generate backup in the past of the entire table at common point-in-time across partitions.

Past-state backup generator and interface for database systems

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.

Customer-related partitioning of journal-based storage systems

A storage service is configured to receive one or more instructions specifying transformations that are to be applied to data sets stored by the storage service when the data sets are made available outside of particular storage locations within the storage service. In response to triggering events that make the data sets available outside of the particular storage locations, the storage services causes the transformations to be performed on the data sets prior to the data sets being accessible at one or more destination locations outside of the particular storage locations where the data sets are stored. In some embodiments, the transformations are performed on hardware included in the storage service or are performed on external hardware at the direction of the storage service.

Storage service supporting data transformations

Commitments against various resources can be dynamically adjusted for customers in a shared-resource environment. A customer can provision a data volume with a committed rate of Input/Output Operations Per Second (IOPS) and pay only for that commitment (plus any overage), for example, as well as the amount of storage requested. The customer can subsequently adjust the committed rate of IOPS by submitting an appropriate request, or the rate can be adjusted automatically based on any of a number of criteria. Data volumes for the customer can be migrated, split, or combined in order to provide the adjusted rate. The interaction of the customer with the data volume does not need to change, independent of adjustments in rate or changes in the data volume, other than the rate at which requests are processed.

Managing committed request rates for shared resources

Managing access of multiple executing programs to nonlocal block data storage

A distributed database receives a first command and second command sent by a client for processing in the context of a transaction. The distributed database validates the transaction by computing a digest based on signatures of the first and second commands, and comparing the computed digest to a digest received from the client. The transaction is committed upon validation.

Distributed database transaction validation

Growing community of inventors

Seattle, WA, United States of America

Tate Andrew Certain