Users with high rates of mission-critical transactions have split their data into two separate systems
one database for OLTP
another data warehouse for OLAP
While this allows for decent transaction rates,
this separation has many disadvantages:
Data freshness issues due to the delay caused by
only periodically initiating the Extract Transform Load(ETL)-data staging
Excessive resource consumption due to maintaining two separate information systems
Hyper achieves both at the same time: unprecedentedly high transaction rates as high as 100,000 per second
and very fast OLAP query response times on a single system executing both workloads in parallel
Better than VoltDB's TPC-C and OLAP query response time better than MonetDB
Achieves both at the same time: unprecedentedly high transaction rates as high as 100,000 per second and
very fast OLAP query response times on a single system executing both workloads in parallel.
How it is done?
HyPer relies on in-memory data management without the ballast of traditional database systems caused
by DBMS-controlled page structures and buffer management
SQL table definitions are transformed into simple vector-based virtual memory representations –
which constitutes a column oriented physical storage scheme.
OLAP query processing is separated from mission-critical OLTP transaction processing using multi-version concurrency control
Transactions and queries are specified in SQL or a PL/SQL-like scripting language and are efficiently compiled into efficient LLVM assembly code.
HyPer's transaction processing is fully ACID-compliant. Queries are specified in standard SQL-92 plus many extensions from following standard SQL standards.
Architecture
Replacing Tableau Data Engine (TDE) with Hyper DB as Extract Engine
Main-memory-based relational DBMS for mixed OLTP and OLAP workloads.
All-in-one New-SQL database system that entirely deviates from classical disk-based DBMS architectures by introducing:
Machine code generation for data-centric query processing
Multi-version concurrency control, leading to exceptional performance.
OLTP performance >= dedicated transaction processing systems
OLAP performance matches with best query processing engines
Achieves OLTP and OLAP performance simultaneously on the same database state
SQL table definitions are transformed into simple vector-based virtual memory representations
– which constitutes a column oriented physical storage scheme.
Architecture - Contd.
Transactions and queries are specified in SQL or
a PL/SQL-like scripting language and are efficiently compiled into efficient LLVM assembly code.
OLAP query processing is separated from mission-critical OLTP transaction processing using multi-version concurrency control (MVCC).
Fully ACID-compliant. Queries are specified in SQL-92 plus some extensions from subsequent standards.
