Architecture Overview

[Edit this page](https://github.com/ClickHouse/clickhouse-docs/blob/main/docs/managing-data/core-concepts/academic_overview.mdx)

This is the web version of our [VLDB 2024 scientific paper](https://www.vldb.org/pvldb/vol17/p3731-schulze.pdf). We also [blogged](https://clickhouse.com/blog/first-clickhouse-research-paper-vldb-lightning-fast-analytics-for-everyone) about its background and journey, and recommend watching the VLDB 2024 presentation by ClickHouse CTO and creator, Alexey Milovidov:

## ABSTRACT[​](#abstract "Direct link to ABSTRACT")

Over the past several decades, the amount of data being stored and analyzed has increased exponentially. Businesses across industries and sectors have begun relying on this data to improve products, evaluate performance, and make business-critical decisions. However, as data volumes have increasingly become internetscale, businesses have needed to manage historical and new data in a cost-effective and scalable manner, while analyzing it using a high number of concurrent queries and an expectation of real-time latencies (e.g. less than one second, depending on the use case).

This paper presents an overview of ClickHouse, a popular opensource OLAP database designed for high-performance analytics over petabyte-scale data sets with high ingestion rates. Its storage layer combines a data format based on traditional log-structured merge (LSM) trees with novel techniques for continuous transformation (e.g. aggregation, archiving) of historical data in the background. Queries are written in a convenient SQL dialect and processed by a state-of-the-art vectorized query execution engine with optional code compilation. ClickHouse makes aggressive use of pruning techniques to avoid evaluating irrelevant data in queries. Other data management systems can be integrated at the table function, table engine, or database engine level. Real-world benchmarks demonstrate that ClickHouse is amongst the fastest analytical databases on the market.

## 1 INTRODUCTION[​](#1-introduction "Direct link to 1 INTRODUCTION")

This paper describes ClickHouse, a columnar OLAP database designed for high-performance analytical queries on tables with trillions of rows and hundreds of columns. ClickHouse was [started](https://clickhou.se/evolution) in 2009 as a filter and aggregation operator for web-scale log file data and was open sourced in 2016. [Figure 1](#page-1-0) illustrates when major features described in this paper were introduced to ClickHouse.

ClickHouse is designed to address five key challenges of modern analytical data management:

1. **Huge data sets with high ingestion rates**. Many datadriven applications in industries like web analytics, finance, and e-commerce are characterized by huge and continuously growing amounts of data. To handle huge data sets, analytical databases must not only provide efficient indexing and compression strategies, but also allow data distribution across multiple nodes (scale-out) as single servers are limited to several dozen terabytes of storage. Moreover, recent data is often more relevant for real-time insights than historical data. As a result, analytical databases must be able to ingest new data at consistently high rates or in bursts, as well as continuously "deprioritize" (e.g. aggregate, archive) historical data without slowing down parallel reporting queries.
2. **Many simultaneous queries with an expectation of low latencies**. Queries can generally be categorized as ad-hoc (e.g. exploratory data analysis) or recurring (e.g. periodic dashboard queries). The more interactive a use case is, the lower query latencies are expected, leading to challenges in query optimization and execution. Recurring queries additionally provide an opportunity to adapt the physical database layout to the workload. As a result, databases should offer pruning techniques that allow optimizing frequent queries. Depending on the query priority, databases must further grant equal or prioritized access to shared system resources such as CPU, memory, disk and network I/O, even if a large number of queries run simultaneously.
3. **Diverse landscapes of data stores, storage locations, and formats**. To integrate with existing data architectures, modern analytical databases should exhibit a high degree of openness to read and write external data in any system, location, or format.
4. **A convenient query language with support for performance introspection**. Real-world usage of OLAP databases poses additional "soft" requirements. For example, instead of a niche programming language, users often prefer to interface with databases in an expressive SQL dialect with nested data types and a broad range of regular, aggregation, and window functions. Analytical databases should also provide sophisticated tooling to introspect the performance of the system or individual queries.
5. **Industry-grade robustness and versatile deployment**. As commodity hardware is unreliable, databases must provide data replication for robustness against node failures. Also, databases should run on any hardware, from old laptops to powerful servers. Finally, to avoid the overhead of garbage collection in JVM-based programs and enable bare-metal performance (e.g. SIMD), databases are ideally deployed as native binaries for the target platform.

Figure 1: ClickHouse timeline.

## 2 ARCHITECTURE[​](#2-architecture "Direct link to 2 ARCHITECTURE")

Figure 2: The high-level architecture of the ClickHouse database engine.

As shown by [Figure 2,](#page-2-0) the ClickHouse engine is split into three main layers: the query processing layer (described in Section [4)](#page-6-0), the storage layer (Section [3)](#page-1-1), and the integration layer (Section [5)](#page-9-0). Besides these, an access layer manages user sessions and communication with applications via different protocols. There are orthogonal components for threading, caching, role-based access control, backups, and continuous monitoring. ClickHouse is built in C++ as a single, statically-linked binary without dependencies.

Query processing follows the traditional paradigm of parsing incoming queries, building and optimizing logical and physical query plans, and execution. ClickHouse uses a vectorized execution model similar to MonetDB/X100 [[11]](#page-12-0), in combination with opportunistic code compilation [[53]](#page-13-0). Queries can be written in a feature-rich SQL dialect, PRQL [[76]](#page-13-1), or Kusto's KQL [[50]](#page-13-2).

The storage layer consists of different table engines that encapsulate the format and location of table data. Table engines fall into three categories: The first category is the MergeTree\* family of table engines which represent the primary persistence format in ClickHouse. Based on the idea of LSM trees [[60]](#page-13-3), tables are split into horizontal, sorted parts, which are continuously merged by a background process. Individual MergeTree\* table engines differ in the way the merge combines the rows from its input parts. For example, rows can be aggregated or replaced, if outdated.

The second category are special-purpose table engines, which are used to speed up or distribute query execution. This category includes in-memory key-value table engines called dictionaries. A [dictionary](https://clickhou.se/dictionaries) caches the result of a query periodically executed against an internal or external data source. This significantly reduces access latencies in scenarios, where a degree of data staleness can be tolerated. Other examples of special-purpose table engines include a pure in-memory engine used for temporary tables and the Distributed table engine for transparent data sharding (see below).

The third category of table engines are virtual table engines for bidirectional data exchange with external systems such as relational databases (e.g. PostgreSQL, MySQL), publish/subscribe systems (e.g. Kafka, RabbitMQ [[24]](#page-12-1)), or key/value stores (e.g. Redis). Virtual engines can also interact with data lakes (e.g. Iceberg, DeltaLake, Hudi [[36]](#page-12-2)) or files in object storage (e.g. AWS S3, Google GCP).