Amazon Technologies, Inc.

Naresh Chainani

Ippokratis Pandis

Gaurav Saxena

Mohammad Rezaur Rahman

Mengchu Cai

Mingda Li

Fabian Oliver Nagel

George Constantin Caragea

Pavel Sokolov

Eric Ray Hotinger

Martin Grund

Venkatraman Govindaraju

William Michael McCreedy

Sanjay Wangoo

Chunbin Lin

Andrew Edward Caldwell

Krishna Chaitanya Gudipati

Kiran Kumar Chinta

Bruce William McGaughy

Orestis Polychroniou

Anurag Windlass Gupta

Yan Valerie Leshinsky

Gokul Soundararajan

Bhaven Avalani

Michail Petropoulos

Balakrishnan Narayanaswamy

Frederick Ryan Johnson

Mohammad Foyzur Rahman

Induja Sreekanthan

Jingyi Qing

Aditya Subrahmanyan

Vivek Ramamoorthy

Srividhya Srinivasan

Davide Pagano

Naga Raju Bhanoori

Neeraja Rentachintala

Christos Stavrakakis

Dengfeng Li

Chao Duan

Nemanja Boric

Naveen Muralimanohar

Siyi Zhang

Yehan Zhang

Vaishali Ravindra Narkhede

Nikolaos Armenatzoglou

Zhixing Ma

Pulkit Jagdishchandra Bhavsar

Sebastian Hillig

Meng Tong

Huiyuan Wang

Hanna Loboda

Hui Shi

Demala Palliye Gurunnanselage Shermal Ruwantha Fernando

Qichen Zhang

Raj Narayan Sett

Sushim Mitra

Ankil Shah

John Thomas

Yao Xiao

Monish Gupta

Database data of a database service may be privately shared across provider network regions. A database producer can authorize an account of to access a database in another region of the provider network. The consumer of the database can associate the database in order to accept the permission to access the database. The database can then be created as an external table at a consumer database engine and metadata for the database privately shared between producer and consumer database engines that can be used to query the external table.

Privately sharing database data across provider network regions

Improved crash resilience is implemented in shared memory processing systems. A processing application including a plurality processing groups may be configured, and a processing group including a plurality of processes may allocate memory from a global shared memory to a group-private shared memory arena. Then, an abnormal execution condition for a failing process of the processing group may be detected during execution of a processing job. Responsive to the detection, a recovery of execution of the processing group may be performed while continuing execution of processing groups of the application. The recovery may include restoring the processing group to a normal execution state and returning the allocated memory of the group-private memory arena to the global shared memory.

Crash resilience in shared memory processing systems

Dynamic selection of topologies for database data may be performed for performing queries. Different possible query plans for different assignments of topologies are determined for a query. One of the query plans is selected according to a cost-based model that assigns costs to different uses of the different topologies. The query is then performed using the selected query plan.

Dynamic selection of database data topologies for performing queries

Idle periods may be for management actions at processing clusters for managed databases. A leader node of a processing cluster for a managed database may monitor a network endpoint at a proxy service associated with a database managed by the database service. An idle period for the database may be detected. A management action for the processing cluster may be determined to be performed during the detected idle period. The leader node may cause the determined management action to be performed.

Detecting idle periods at network endpoints for management actions at processing clusters for managed databases

Database query processing may be scaled using additional processing clusters. A database query is received at a processing cluster. A determination is made as to whether additional processing clusters will be used to process the database query. Operations to cause compute nodes of the processing cluster to instruct operations at the additional processing clusters are included in a plan generated to perform database queries determined to use additional processing clusters. The plan is executed to be perform the database query causing compute nodes of the processing cluster to send instructions to corresponding additional processing clusters in order to generate and return a response to the database query.

Scaling database query processing using additional processing clusters

Dynamic plan interpretation may be implemented to perform queries. A query is received at a database system. A plan to perform the query is generated. For at least a portion of the plan to perform the query, a domain-specific language may be applied to interpret and execute the portion of the plan to perform the query using one or more previously compiled executors instead of generating and compiling code to execute the portion of the plan. Returning a result of the query according to the execution of the plan.

Dynamic selection of plan interpretation to perform queries

Burst performance of a database query may be determined according to a size of the database query. A query to a database may be received. A size may be determined for the query. If the size is less than a size threshold assigned to a first query engine, then the query may be performed at the first query engine. If the size is greater than or equal to the size threshold assigned to the first query engine, then the query may be performed at a second query engine.

Burst performance of database queries according to query size

A database management system receives a command defining a view of the database. The view definition is accepted without determining whether references to schema elements within the view definition are resolvable to existing elements of the database schema. A query of the view is received. In response to the query of the view, the database management system resolves references to schema elements in the view definition by determining whether the references correspond to data available for processing the query.

Late-binding database views

A primary query engine may receive a query and determine whether the query is eligible for performance at a secondary query engine. If eligible, the primary query engine may evaluate the availability of the first query engine to perform the query. The first query engine may determine whether to assign the query to the primary query engine or to the secondary query according to availability evaluation. For queries assigned to the secondary query engine, the primary query engine may send a request to the secondary query engine to being processing of the query.

Dynamically assigning queries to secondary query processing resources

Compiled portions of code generated to perform a query plan at a query engine may be shared with other query engines. A data store, separate from the query engines, may store compiled portions of query code generated for different queries. If a query engine does not have a locally stored compiled portion of query code, then the separate data store may be accessed in order to obtain a compiled portion of query code, allowing reuse of compiled query code across different queries engines for queries directed to different databases.

Sharing compiled code for executing queries across query engines

Online restore may be performed between databases with different topologies while applying a custom data distribution. A request to restore a database into a different topology of nodes may be received. A plan to move different portions of the database from a current topology to the new topology made using a general distribution scheme. The plan may be performed to move the different portions of the database into the new topology and the database made available for access using the new topology. A background process may be applied to modify the distribution of the database at the new topology to match a custom distribution scheme that was implemented at the current topology.

Online restore to different topologies with custom data distribution

Database systems may dynamically management concurrency levels for performing queries. A query may be received at a database system and a memory usage for the query may be predicted. A determination may be made as to whether available memory is enough to satisfy the predicted memory usage for the query. If the available memory is enough to satisfy the predicted memory usage for the query, then an increase in a concurrency level for performing queries at the database system may be made. The query may be allowed to execute concurrently with other queries according to the increased concurrency level.

Dynamic concurrency level management for database queries

Context dependent execution time prediction may be applied to redirect queries to additional query processing resources. A query to a database may be received at a first query engine. A prediction model for executing queries at the first query engine may be applied to determine predicted query execution time for the first query engine. A prediction model for executing queries at a second query engine may also be applied to determine predicted query execution time for the second query engine. One of the query engines may be selected to perform the query based on a comparison of the predicted query execution times.

Context dependent execution time prediction for redirecting queries

Scaling of query processing resources for efficient utilization and performance is implemented for a database service. A query is received via a network endpoint associated with a database managed by a database service. Respective response times predicted for the query using different query processing configurations available to perform the query are determined. Those query processing configurations with response times that exceed a variability threshold determined for the query may be excluded. A remaining query processing configuration may then be selected to perform the query.

Scaling query processing resources for efficient utilization and performance

Performance measures are predicted for queries to prioritize query performance at a database system. A trained machine learning model for the database system may be applied to a query to determine a predicted performance measure for the query. The predicted performance measure may be compared with other predicted performance measures for other waiting queries to determine a priority for executing the query.

Predicting query performance for prioritizing query execution

Growing community of inventors

Mountain View, CA, United States of America

Naresh Chainani