History

EsgynDB has 20+ years of innovation and patented technology. HP invested more than $300 million into this technology just since 2006. The result is a database that has extensive capabilities and has been hardened across a wide variety of workloads, from OLTP, with its Tandem NonStop heritage.

Concurrency Control

Data Model

EsgynDB is relational, supports ANSI SQL and ACID transactions. EsgynDB can query HBase structured tables and native HBase tables in the same query, but can also update them in the same ACID transaction. HBase tables can be defined as EsgynDB external tables. EsgynDB can access in the same query structured, semi-structured and unstructured data.

Foreign Keys

Isolation Levels

Joins

Query Compilation

EsgynDB’ s optimizer is based on the Cascades optimization framework. SQL Normalizer – the parsed SQL statement is passed to the normalizer which performs unconditional transformations, including subquery transformations, of the SQL into a canonical form which renders the SQL in a form that can be optimized internally. SQL Analyzer – analyzes alternative join connectivity patterns, table access paths and methods, matching partition information, etc. to be used by the optimizer’s rules. The results are passed to the plan generator for consideration in costing various plan alternatives. Table Statistics – captured equal-height histogram statistics identify data distributions for column data and correlations between columns. Sampling is used for large tables to reduce the overhead of generating the statistics. Cardinality Estimator – cardinalities, data skew, and histograms are computed for intermediate results throughout the operator tree. Cost Estimator – estimates node, I/O, and message cost for each operator while accounting for data skew at the operator level. Plan Generator – using cost estimates the optimizer considers alternative plans and chooses the plan which has the lowest cost. Where feasible the optimizer will select plans that incorporate SQL pushdown, sort elimination, and in-memory storage vs. overflow to disk. Also, it determines the optimal degree of parallelism including serial plans.

Query Execution

EsgynDB’ s SQL executor uses a dataflow and scheduler-driven task model to execute the optimized query plan. Each operator of the plan is an independent task and data flows between operators through in-memory queues (up and down) or by inter-process communication. Queues between tasks allow operators to exchange multiple requests or result rows at a time. A scheduler coordinates the execution of tasks and runs whenever it has data in one of its input queues. In most cases, the EsgynDB executor can process queries with data flowing entirely through memory, providing superior performance and reduced dependency on disk space and I/O bandwidth. Only for a large hash join or sort, where EsgynDB detects memory pressure, does it gracefully overflow to disk. The executor incorporates several types of parallelism, such as partitioned, pipeline and operator parallelism.

Query Interface

EsgynDB supports more than 150 built-in functions that include aggregate, character, date-time, mathematical, and OLAP functions. These include all ANSI functions as well as many commonly used functions from other databases, such as DECODE and TO_CHAR from Oracle. With support for BI and analytical workloads EsgynDB now sports more OLAP functions such as LEAD and LAG. It supports multiple windows in an OLAP query. It has functionality common to such workloads, such as ROLLUP and GROUPING. INTERSECT and EXCEPT operations have been added.

Storage Architecture

Storage Model

EsgynDB database objects are stored into native Hadoop database structures. These include the following formats: • HBase that provides a Big Table, or wide-column key-value, data model • ORC or Parquet files which provides a column store data model • text files used for staging data such as comma separated value or log data • key-value sequence file

Stored Procedures

System Architecture

Elastic scalability: nodes and storage across the cluster can be dynamically increased or decreased with no downtime, while transactions and queries are being processed. The very next transaction or query will leverage the reconfigured compute or storage resources.

Views