The HyPer DBMS is an in-memory database which aims to achieve high performance for both OLTP and OLAP workload; it creates a consistent snapshot of the transactional data by forking the OLTP process, so that the OLAP queries could operate on the consistent virtual memroy snapshot. Besides, the HyPer DB group proposed a serializable Multi-Version Concurrency Control (MVCC) model which could provide full serializability isolation. Furthermore, they designed the Adaptive Radix Tree (ART) which is a high speed index for main-memory-based database systems. Last but not least, HyPer uses Just-In-Time (JIT) compilation to generate LLVM codes for the incoming queries, which boosts the performance of the database and minimizes the memory traffic.
HyPer is a DBMS project from the Technical University of Munich (TUM) database group. In the beginning, their objective was to build a hybrid in-memory database; during the process of developing HyPer, they published lots of paper about different parts of the system. HyPer is not open source, but it provides a WebInterface (http://hyper-db.de/interface.html) where we could execute queries on the HyPer system. HyPer is still in active development and the next big step of the HyPer group is to extend the functionality of HyPer to "exploratory workflows that are deeply integrated into the database kernel".
HyPer creates consistent backups and checkpoints by taking efficient snapshots.
Multi-version Concurrency Control (MVCC)
HyPer used MVCC scheme to handle both OLTP and OLAP queries.
HyPer is not a non-relational database (a.k.a NoSQL database) like MongoDB which is document-oriented database or HBase which uses column family; instead, HyPer is a relational database; however, the relations are not always maintained as arrays of entire records; the table layout in HyPer would change according to the workload, so HyPer is also the so-called New-SOL database.
No documentations from HyPer specifically state that HyPer supports foreign key constrains, but in their fast serializable MVCC paper, they mentioned a senario where an transacion deletes a primary key and another concurrent transacion inserts a foreign key which refers to that primary key.
The adaptive radix tree (ART) index is the default indexing structure in HyPer. Two important features of ART are adaptive node structure and path compression.
HyPer supports a novel serializability validation mechanism which is adapted from precision locking. Instead of tracking dependencies like the Serializable Snapshot Isolation (SSI) implemented in PostgreSQL, HyPer would "read predicates and validate the predicates against the undo log entries".
It's positive that HyPer supports sort-merge joins; as for the hash join, they implemented a NUMA-aware hash join algorithm, but they didn't mentioned whether they have integrated hash join into HyPer or not.
HyPer uses physical logging to support data durability.
HyPer uses Just-In-Time (JIT) code compilation to compile transacions and queries into efficient LLVM assembly code.
HyPer uses SQL or a PL/SQL-like scripting language to execute queries
As described in the HyPer homepage, "HyPer is a main-memory-based relational DBMS for mixed OLTP and OLAP workloads."
In HyPer, the storage layout would change according to the access patterns; for OLTP workload, it uses row store approach by organizing relations as arrays of entire records; as for the OLAP workload, it uses column store approach by partitioning relations into vactors of attribute values.
The stored procedures in HyPer are written in a custom, iterator-free language called HyPerScript.
ScyPer (Scaled-out HyPer) is a version of HyPer, which horizontally scales out on shared-nothing commodity hardware
HyPer supports normal views where a query would define a virtual table.
Technical University of Munich