Amazon Technologies, Inc.

Microsoft Technology Licensing, LLC

Vaibhav Jain

James Christopher Sorenson

Amit Gupta

Somasundaram Perianayagam

Rishabh Jain

Akshat Vig

Sharatkumar Nagesh Kuppahally

Alexander Richard Keyes

Stefano Stefani

Tate Andrew Certain

Douglas Brian Terry

Nicholas Gordon

Ravi Math

Chase Kernan

Nathan Pellegrom Riley

Vikas Jain

Lewis Bruck

Peter Zhivkov

Mouna Sidi Hida

Remi Paucher

Wei Xiao

Richard Fang

Rajaprabhu Thiruchi Loganathan

Adam Douglas Morley

Akhilesh Mritunjai

Ming-Chuan Wu

Fahad Ahmed

Almero Gouws

Go Hori

Rui Zhu

Thomas Anand Jeyaseelan

Derek William Richard Chen-Becker

Lokendra Singh Panwar

Tony Petrossian

Rashmi Krishnaiah Setty

Benjamin Donald Wood

Palak Agrawal

Daniel Martin Strommen

Irina Petronela Salvan

Fernando Israel Osorio Cedeno

Alec Richard Lindberg

Emre Aydinceren

Chang-Ling Wu

Joon Ahn

Joseph Mifsud

Hemanshu Khimraj Chawda

Joseph Carl Fant, Iv

Matthew Mitgang

Anshul Gupta

Sagar Mundra

Krishnan Seshadrinathan

Ayan Sircar

Christophe Alain Berthoud

Abhishek Mehrotra

Aniruddha Deshpande

Padmini Rajanna

Jérôme Vasseur

Pawan Kaunth

Kaylie J Wilson

Gregory H R Mialon

Kapil Singh

Naveen Ganapathi Subramanian

Pierce Butler Johnson

Thomas Jeffrey Rothwell

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.

Tracking database partition change log dependencies

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.

Offline index builds for database tables

A client of a distributed database service may conveniently enable replication of data from a source table to a destination (e.g., a different service/database table) by submitting a request enable replication for the source table. In response to the request to enable replication, the database service enables replication for the source table. To replicate a change, the database service may modify a format of the change based on a data storage format of the destination that is different than a data storage format of the database service. The database service monitors the performance of the replication and based on the performance, the database service may automatically modify the capacity to perform the replication of changes to the destination (e.g., by assigning additional resources to replication).

Replicating changes from a database to a destination and modifying replication capacity

Various embodiments are described regarding admitting for performance ordered operations of atomic transactions across a distributed database. In some embodiments, a node of a distributed system receives and accumulates requests for operations over a period of time. The node can then order the requests based on certain criteria, such as by timestamps of associated transactions. The node can then perform an admission control on the ordered requests, until a capacity of the node to perform the requests for operations is exceeded. During the admission control process, those requests for operations received within the period of time that are not admitted can be rejected by the node.

Admitting for performance ordered operations of atomic transactions across a distributed database

Non-relational database operations are invoked to provide results consistent with commands specified in a relational query language. A request to access data in a non-relational database is received that includes one or more commands specified in a query language for accessing data according to a relational data scheme. The request may be evaluated to determine one or more Application Programming Interfaces (APIs) to invoke operations at the non-relational database that provide a result consistent with the commands specified in the query language. The determined APIs are executed and a result returned for the request based on the execution of the APIs.

Invoking supported non-relational database operations to provide results consistent with commands specified in a relational query language

A distributed database maintains a table on a first plurality of partitions. A request to restore the table to a point-in-time is received. The database determines, based on log data of the partitions, a maximum version number of an operation processed by the partitions. The log data is processed to exclude, from the restoration, operations whose transactions were started after the point-in-time, by setting the version number of those operations to be greater than the maximum version number. The log data is then applied to a second plurality of partitions, where the version number of each applied operation is less than or equal to the determined maximum version number.

Transactionally consistent point-in-time restore

A computer-implemented technique is described herein for defining and applying constraints that regulate a supervisee's interaction with applications. In one implementation, the technique provides a user interface presentation to a supervisor that lists a set of applications that run on plural application execution platforms. The user interface presentation also allows the supervisor to set platform-agnostic constraint information for any identified application. The platform-agnostic constraint information, once set for an application, constrains interaction by a supervisee with all versions of that same application. That is, the constraint information is said to be agnostic with respect to platform in the sense that it applies to a variety of application execution platforms that run the application. In one example, the platform-agnostic constraint information specifies a permitted amount of an activity that the supervisee is permitted to perform across all versions of an application.

Managing application constraints across platforms

Methods, systems and storage media for limiting access to one or more of devices and applications for a period of time are disclosed. Some examples may include: receiving electronic assignment information indicating that at least one assignment associated with a user is incomplete, identifying a block of time based on the at least one incomplete assignment and assigning a focus time session to the identified block of time, causing at least one of an application or device to become disabled based on a configuration profile applied during the focus time session, receiving an indication that the at least one incomplete assignment associated with the user has been completed and causing the previously disabled at least one of the application or device to become enabled.

Enabling focus time based on school assignment completion information

Systems and methods for managing timestamps for a sequential update stream in a distributed system. A system includes a plurality of storage nodes of a data stream service of a provider network. Each storage node includes one or more processors and memory storing instructions executable by the one or more processors. The instructions cause the one or more processors to create a shard, at the storage node, for storing records of a sequential update stream recording changes to a database partition. The instructions also cause the one or more processors to assign a timestamp for the shard based on a local clock of the storage node. The instructions further cause the one or more processors to adjust the timestamp for the shard to a time later than a timestamp for a previous shard of the sequential update stream stored at a different storage node of the plurality of storage nodes.

Managing timestamps in a sequential update stream recording changes to a database partition

A distributed database system maintains data for a logical table by storing, on a plurality of storage nodes, a collection of key-item pairs. An operation to delete a range of these items is processed by first storing, on each of the plurality of storage nodes, a tombstone record indicative of the items to be deleted. The tombstones are committed once each of the plurality of nodes has stored the tombstone. Items within the range are treated as deleted. A cleanup operation deletes items within the range and updates the tombstone.

Range deletes on a distributed database

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.

Scalable architecture for propagating updates to replicated data

Systems and methods are described for processing voice input to detect and remove voice recognition errors in the context of a product attribute query. Spoken-word input may be processed to tentatively identify a query regarding a product and an attribute. A hierarchical product catalog is then used to identify categories that include the identified product, and an affinity score is determined for each category to indicate the relative strength of the relationship between the category and the attribute. The affinity score for each category is determined based on historical questions submitted to a question and answer service with regard to other products in the category. An affinity score for the product-attribute pairing is then determined based on a weighted average of the affinity scores for the product categories, and the affinity score is used to determine whether the question is valid and the voice input has been correctly processed.

Voice input processing

Transaction operations may be graphed in order to determine performance compliance of transactions. An event to analyze transactions may be detected. Transactions to analyze for the event may be identified and a description of transaction operations for the identified transactions may be obtained. A graph of the transaction operations may be generated to indicate the dependencies between transactions and an evaluation of the graph may be performed to determine whether the transactions were performed with serializable isolation.

Graphing transaction operations for transaction compliance analysis

Growing community of inventors

Seattle, WA, United States of America

Vaibhav Jain