White paper Technical A Peek under the hood White paper Technical Contents A peek under the hood 01 02 03 Introduction 3 Being really fast 5 Providing a Great User Experience 12 Massively Parallel Processing MPP 5 Self-Optimization 13 Large-Scale In-Memory Advanced Analytics 04 Architecture 9 and Data Science 14 Supporting Business Integration Filters, Joins and Sorting 10 and Day-to-Day Operation 16 Query Optimizer and Interfaces and Tool Query Cache 11 Integration 17 Data Ingestion and Data Integration 18 The Virtual Schema Framework for Data Virtualization & 05 Hybrid Clouds 20 Summary 13 Fail Safety, Dual Data Center Operation and Backup/Restore 24 SQL Preprocessor 25 01 White paper Technical 3 Introduction Exasol was founded in founders recognized that database designed specifically Nuremberg, Germany, in the year new opportunities were made for analytics. Exasol holds 2000 – a time when two trends possible by these trends. With performance records in the in hardware were starting to RAM falling in cost and rising in TPC-H online transaction emerge: capacity and cluster computing processing benchmark from being merely a commodity, it the Transaction Processing Major improvements in was now conceivable to apply Performance Council (TPC) for processing power were no the principles and architectures decision-support databases, longer coming from ever of high-performance computing outperforming competitors by increasing clock speeds of to database design. In the years orders of magnitudes and scaling central processing units (CPUs), that followed, the company up to hundreds of terabytes of but instead from parallel and exclusively focused on delivering data. distributed systems. ultra-fast, massively scalable The goal of this paper is to offer analytic performance. a deeper understanding of a After a long period of slow selection of design principles, improvement, random-access Today, successful companies core features, and technologies memory (RAM) started becoming around the world rely upon that underpin Exasol’s analytical much larger and cheaper with Exasol’s innovative in-memory performance and, at the same each successive generation. analytic database solution to time, take a glimpse at what run their businesses faster Exasol has to offer beyond raw With backgrounds in high- and smarter. The company’s performance. performance computing and flagship product, Exasol, is a scientific computing, Exasol’s high-performance in-memory 01 White paper Technical 4 Introduction APPLICATIONS CUTTINGEDGE TECHNOLOGY Advanced Predictive Real-Time Business Data Science Logical Data Analytics Analytics Ad hoc Reporting Intelligence Warehouse World's fastet in-memory engine Analytics SQL R Python Java Lua Skyline Geopatial - The parallel in-memory database Extendable analytics platform Physical Storage Data Virtualization Framework EXAStorage Virtual Schemas Unbeatable scalability DATA OLTP, CRM, M2M, Click Streams, Text, Geolocation Hadoop SCM,ERP ... Sensors Web Logs Social Media data systems TCO For Exasol, great performance is not an end Minimal in itself, but - as indicated by the diagram - TCO one important characteristic of a complete analytic system. 02 White paper Technical 5 Being really fast In their quest for speed over the last two decades, Exasol’s engineers came up with a number of techniques and solutions in order to achieve specific tasks with maximum performance and over the course of time a number of general principles emerged. Massively Parallel Processing - MPP The design of Exasol is inspired by Still, global synchronization is an expensive system architectures from the field of operation as all participants have to wait high-performance computing. In order for the others to be in some well-defined to maximize hardware usage, parallel state. Therefore, Exasol is designed to processing and high-performance avoid global synchronizations during query communication techniques are used at processing as much as possible. different levels of the architecture. These techniques have been designed and built In turn, every machine is programmed from scratch exactly for the requirements according to the SMP (symmetric of Exasol. multiprocessing) paradigm. Processes and threads exploit the high performance At the cluster level, Exasol essentially features offered by modern multi-core follows the SPMD (single program, multiple shared-memory architectures, which data) paradigm. Different machines in the results in the maximum utilization of cluster execute the same program, while existing standard server hardware. Per their internal state is independent most CPU, all the SIMD (single instruction, of the time. Machines communicate via multiple data) features of modern standard asynchronous streaming/message passing. processors are utilized, which allows Exasol Exasol is designed to operate without any to deliver the highest performance rate at dedicated “master node” which would every level. constitute a single point of failure and a performance bottleneck. Instead, Exasol’s cluster technology can be installed across hundreds of machines, all working in parallel to answer a query without a significant performance overhead. 02 White paper Technical 6 Being really fast Large-Scale In-Memory Architecture One popular misconception about in- memory analytic databases is the idea that they have to hold all permanent and temporary data in RAM all the time, effectively putting very tight constraints on the size of the data that can be stored and 10.000.000 ns 64 ns processed in such systems. For Exasol, such constraints are no issue at all. 100 ns L3 HDD After more than two decades of research 16 ns and investment in in-memory technology, L2 Exasol has reached a high level of maturity 4 ns and versatility and Exasol has gained a L1 deeper understanding of what in-memory CPU2 1.6 ns is really about: In-memory is not a single 200.000 ns technical feature of a system but instead Core Core an overall design approach for storage and Core Core processing algorithms, an approach that SSD CPU1 is at work throughout the whole system. MOTHERBOARD The basic assumption that in-memory rests upon is the following: 02 White paper Technical 7 Being really fast Large-Scale In-Memory Architecture By the time data needs being accessed, it resides in RAM or even CPU cache. Exasol’s approach to in-memory therefore involves: Algorithms that work under the assumption Machinery that – in the background – that data access is very cheap (in terms of time) works very hard to make the in-memory assumption a reality most of the time To facilitate such a design, the following basic approaches are used across Exasol’s architecture: 1. Data compression: 2. Transparent replication: 3. Pre-fetching: By utilizing different levels of It is cheap to store small data several Exasol is very good at predicting the compression, the trade-off between times, which can reduce query future access of data. Pre-fetching is low space requirements and high execution times dramatically (see performed on all levels of granularity: performance is adjusted for different section 2.5). Users of Exasol are never a. RAM - L2 cache operations. affected by replication as the system b. Block device - RAM handles all the details and even stops c. Data from remote machines - In general, compression is a key replicating data when it becomes too temporary local buffers enabling factor for in-memory large. (see section 2.4) databases as it reduces the need for hard disk drive accesses and also reduces the pressure on CPU caches. 02 White paper Technical 8 Being really fast Large-Scale In-Memory Architecture Pipelining Given today’s multi-core architectures, it is Python Python JULIA mandatory to avoid cases of synchronous 2.x 3.x waiting whenever possible in order to best utilize the available processing power. Exasol’s execution pipeline manages a number of worker threads and buffers for intermediate results, thereby eliminating the need for direct thread communication and increasing the amount of parallel processing. Additionally, the execution pipeline comes with built-in support for distributed computing. Intermediate results can be (User Defined sent off to any other machine in the cluster Scalar function) for further processing. Such pipelines are Exasol Execution Stage Exasol Execution Stage Exasol Execution Stage very handy for global computations like (Pipe Scan) (Aggregator) global JOINs or the Skyline operator (see section x.x). 02 White paper Technical 9 Being really fast Large-Scale In-Memory Architecture Data Locality Careless design and implementation of Similarly, Exasol contains elements that algorithms may lead to situations in which ensure that certain pieces of data are processing units have to wait for certain available on a machine when accessed, data to become available. Therefore effectively providing a cluster-wide pre- a strategy to avoid cache misses is an fetch for remote data. Similar behaviors important topic for in-memory databases. are supported by the internal memory management components. Exasol’s operators are carefully designed and coded to anticipate when certain By predicting the immediate future state of pieces of data are needed and go to great a complex computation at different levels lengths to ensure that the right data is of granularity, Exasol achieves a high level available in the proper layer of the memory of data locality, which is one of the key hierarchy at the right moment. The factors for its performance problem of data locality emerges at several levels in the system. For instance, there are special CPU instructions that direct the processor cache to pre-fetch certain memory locations so that data is already in the processor cache when needed. 02 White paper Technical 10 Being really fast Filters, Joins and Sorting Filters and joins are two of the core are optimized for different scenarios columns), but such actions should never be operations of relational databases. Exasol concerning the size and distribution of mandatory in Exasol. is equipped with a number of different the involved tables. All tables in Exasol are algorithms for these operations.