Abstract: Disclosed are methods, systems and non-transitory computer readable memory for an assistive brain computer interface. For instance, a system may include a set of sensors, wherein the set of sensors are configured to obtain sensor data; a stylus configured to collect stroke data; and a user device. The user device may be configured to: receive the stroke data from the stylus and the sensor data from the set of sensors; generate renders of strokes based on the stroke data and the sensor data; and display the renders of the strokes to a user.

Abstract: A load handling system may comprise an upper horizontal guide rail and a lower horizontal guide rail coupled with storage racking, a vertical guide rail assembly slidably coupled with the upper horizontal guide rail and the lower horizontal guide rail, a first horizontal drive motor coupled with the vertical guide rail assembly configured to move the vertical guide rail assembly horizontally along the upper horizontal guide rail and the lower horizontal guide rail, a load handling platform slidably coupled with the vertical guide rail assembly, a vertical drive motor coupled with the load handling platform configured to move the load handling platform vertically along the vertical guide rail assembly to position the load handling platform so that a load handling device coupled with the load handling platform is position to manipulate a load located in the storage racking.

Abstract: Queries may be made against a non-relational database without impacting the capacities of the non-relational database by enabling performance of queries to a non-relational database via an external query management, backup management, and a non-relational database backup hosted in an external data storage. The query management and backup management of the non-relational database service may split transactional load to the non-relational database and analytical load, and furthermore allow selection of a desired data freshness for queries including various time ranges, such as seconds, minutes, or days.

Abstract: Time and value ordering may be applied for items stored in data backups. A change log that persists changes to a data set may be updated with changes and used to update an in-memory table for the data set, which describes changes to items up to a current time. An event may be detected to seal the in-memory table from subsequent updates and a persistent data object that orders the items in the in-memory according to both keys of the respective items and the respective time values of the items, as stored in the change log, may be generated and stored as part of a backup for the data set.

Abstract: 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.

Abstract: Time and value ordering may be applied for items stored in data backups. A change log that persists changes to a data set may be updated with changes and used to update an in-memory table for the data set, which describes changes to items up to a current time. An event may be detected to seal the in-memory table from subsequent updates and a persistent data object that orders the items in the in-memory according to both keys of the respective items and the respective time values of the items, as stored in the change log, may be generated and stored as part of a backup for the data set.

Abstract: A distributed database encrypts tables using table encryption keys protected by a client master encryption key. The client may revoke and subsequently restore authorization to access the client master encryption key. A sweeper process of the distributed database examines encrypted tables and identifies changes to the status of a corresponding client master encryption key. A response to an identified change in status is initiated.

Abstract: Columns of a non-relational data store may be efficiently dropped. A drop column request for a table stored in a non-relational database may be received. In response to the drop column request, schema information for the table may be updated to filter out the column from subsequent read responses to read requests. A backup of the table is created and evaluated to identify those items in the table that include the column. The column is then deleted from the identified items.

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: A system receives a request to import data file(s) from a source data store into a target database. The system reserves a first portion of computing resources that host the target database to import the data file(s). The reservation of the first portion of computing resources permits the import throughput rate of the data file(s) through the first portion of computing resources while maintaining a second portion of the computing resources to support client access to the target database at an access throughput rate. The system initiates import of the data file(s) from the source data store to the target database through one or more storage nodes at the import throughput rate according to the first portion of computing resources. The target database is able to receive access requests from one or more clients during the import of the data file(s) to the target database.

Abstract: 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.

Abstract: A distributed database encrypts a table using a table encryption key protected by a client master encryption key. The encrypted table is replicated among a plurality of nodes of the distributed database. The table encryption key is replicated among the plurality of nodes, and is stored on each node in a respective secure memory. In the event of node failure, a copy of the stored key held by another member of the replication group is used to restore a node to operation. The replication group may continue operation in the event of a revocation of authorization to access the client master encryption key.

Abstract: 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.

Abstract: A distributed database encrypts tables using table encryption keys protected by a client master encryption key. The client may revoke authorization to access the client master encryption key. Subsequent to a revocation of authority to access the client master encryption key, the distributed database generates interim snapshots of the table using the table encryption key. Also subsequent to the revocation, the distributed database generates a backup of the table using a backup encryption key protected by the client master encryption key.

Abstract: Methods, systems, and computer-readable media for renaming a database table with minimized application downtime are disclosed. A database receives a table rename request for a table having a first table name. Routing metadata comprises a mapping of the first table name to a table identifier and a mapping of the table identifier to one or more partitions. The table rename request indicates a second table name. The database generates updated routing metadata responsive to the table rename request. The updated routing metadata comprises a mapping of the second table name to the table identifier and the mapping of the table identifier to the one or more partitions. The database receives, from a client application, one or more access requests indicating the second table name. The database routes the one or more access requests to the one or more partitions based at least in part on the updated routing metadata.

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

Abstract: 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.

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.