Cloud Database Query Layer for Platform Independence

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current technologies lack a generic, platform-independent interface for interacting with cloud databases, requiring re-writing code for different libraries and making data migration between clouds time-consuming, costly, and prone to introducing bugs.

Innovation Solution

A modified version of Structured Query Language (SQL) is used to provide a query layer for cloud databases, incorporating a cost-based optimizer that converts row-store queries into column-store queries, enabling efficient data retrieval and reducing selection and join operations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If cloud databases use different proprietary APIs and syntax (e.g., Hadoop syntax, Amazon EC2 syntax), then each cloud database can be optimized for its specific architecture, but code must be re-written for each library and platform independence is lost

Engineering Contradiction:
Improveplatform independenceVSAvoidcode complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal SQL query layer that can interact with multiple different cloud database systems (Hadoop, Amazon EC2, and other column-store databases) through a single standardized interface. This allows the same SQL code to work across different platforms without rewriting, achieving platform independence while maintaining the ability to query various cloud database architectures.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent introduces an intermediary SQL query layer that sits between the user and the underlying cloud database systems. This intermediary layer translates standardized SQL queries into the specific syntax and APIs required by different cloud databases, eliminating the need for users to directly interact with proprietary APIs and reducing code complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If traditional row-store databases are used, then existing applications can be hosted without modification, but query performance on cloud column-store databases is suboptimal

Engineering Contradiction:
Improvequery performanceVSAvoiddatabase compatibility
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent changes the fundamental parameter of data storage organization by converting row-store database structures into column-store database structures. This transformation optimizes query performance for cloud databases by storing data in columns rather than rows, enabling efficient data retrieval while the SQL layer maintains compatibility with existing applications.

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If data is migrated from one cloud database to another using proprietary APIs, then data can be moved between platforms, but the process is time-consuming, costly, and prone to introducing bugs

Engineering Contradiction:
Improvedata portabilityVSAvoidmigration time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent enables universal data portability between different cloud databases through a standardized SQL interface. Data can be queried and migrated between Hadoop, Amazon EC2, and other column-store databases using the same SQL syntax, eliminating the need for proprietary API knowledge and reducing migration time and errors.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS9372890B2Methods, systems, and computer-readable media for providing a query layer for cloud databases
Publication Date: 2016.06.21 INFOSYS LTD
  • US9372890B2 patent drawing
  • US9372890B2 patent drawing
  • US9372890B2 patent drawing

AI summary

A method, non-transitory computer readable medium, and apparatus for receiving data from a cloud database. One or more queries requesting data from the cloud database are received. The one or more queries are converted from a row-store database query into a column-store database query. An optimal join plan is identified for the one or more queries using a cost based optimizer based on metadata for one or more relations in the cloud database. The optimal join plan is executed using a cloud application programming interface.