ClickHouse Certified key terms

The core ClickHouse table engine family. It stores rows sorted by a primary key, writes each insert as an immutable part, and merges parts in the background to keep read and storage costs bounded.

An immutable on-disk directory holding a sorted slice of a MergeTree table. Every insert creates one or more parts, and background merges combine them into larger parts.

The ordered column list that defines how rows are physically sorted inside each part. ClickHouse builds a sparse index over it so queries can skip large ranges of data.

An index that stores one entry per block of rows (a granule) rather than per row. It is tiny, stays in memory, and lets ClickHouse locate candidate granules quickly before reading them.

The smallest unit of data read from a part, by default 8192 rows. The sparse index and most skipping indexes mark granules as matching or not, so reads happen in whole granules.

A named horizontal split of a MergeTree table, usually by month or day, stored as separate directories. Partitioning enables cheap dropping of old data and limits the scope of merges.

Query-time elimination of whole partitions that cannot satisfy the partition-key filter. It avoids reading any granules in those partitions and is one of the largest performance wins in ClickHouse.

An optional secondary index (min-max, set, bloom filter, ngram) that records summaries per granule so the reader can skip granules whose values cannot match the predicate.

A MergeTree variant that keeps only the row with the highest version value among rows sharing the same sorting key, deduplicating during merges rather than at insert time.

A MergeTree variant that stores a sign column of +1 or -1 and cancels row pairs with identical sorting keys during merges, implementing update and delete as appended rows.

A MergeTree variant that merges rows with the same sorting key by combining their aggregate-function states, which is the basis of incremental materialized views for pre-aggregation.

A MergeTree variant that replaces rows sharing a sorting key with a single row whose numeric columns hold the sum, useful for additive counters and simple rollups.

A background process that reads several parts of a table, combines them into one sorted part, and removes the originals. Merges apply engine-specific logic such as deduplication or collapsing.

An asynchronous operation that rewrites existing parts to apply an UPDATE, DELETE, or column change. It is heavy compared with inserts and should be batched and monitored.

A DELETE statement that marks matching rows as deleted using a mask instead of rewriting parts immediately. The rows are filtered out on read and physically removed during later merges.

A query modifier that forces ClickHouse to return fully merged results at read time, so ReplacingMergeTree, CollapsingMergeTree, and lightweight deletes are applied before the result is returned. It costs extra work.

A stored query that runs on inserts into a source table and writes its output into a target table, commonly used to maintain incremental aggregates or reshaped data automatically.

A materialized view that recomputes its full result on a schedule instead of on every insert. It suits expensive or non-incremental transformations and can replace its target atomically.

The serialized intermediate value of an aggregate function, such as a partial sum or a quantile sketch. Storing states with -State and combining them with -Merge enables incremental aggregation.

An aggregate that trades exactness for speed and memory, such as uniq for distinct counts or quantile for percentiles. Results are close estimates with bounded error rather than exact values.

ClickHouse's default approximate distinct-count function. It combines an array, a hash table, and a HyperLogLog sketch to give low error with small memory and fast merging.

A table or column rule that automatically deletes, moves, or re-aggregates old data based on a time expression, applied during merges. It is the standard way to bound retention.

A per-column compression setting such as LZ4, ZSTD, Delta, DoubleDelta, Gorilla, or T64. Choosing codecs by data shape cuts storage and I/O substantially.

A data type wrapper that dictionary-encodes a column with few distinct string values, storing small integer codes instead of repeated text and speeding up filtering and grouping.

A type wrapper that allows NULL in a column by storing a separate null mask. It adds overhead and complicates indexes, so it is often replaced by a default value plus a flag column.

A table that holds no data itself but routes reads and writes across a cluster to underlying local tables, providing a single logical view over sharded data.

One horizontal slice of a distributed dataset, held on its own set of servers. Sharding spreads data and query load, while the distributed table fans queries out and merges results.

A copy of a shard kept on another server for redundancy and read scaling. ReplicatedMergeTree replicas stay consistent by coordinating through ClickHouse Keeper.

The built-in coordination service compatible with ZooKeeper that stores replication metadata and leader election state. It is required for replicated tables and distributed DDL.

A MergeTree engine that keeps identical parts on multiple replicas by logging insert and merge operations in Keeper, so each replica fetches and applies the same changes.

Processing data in batches of column values rather than row by row, so the CPU runs tight loops over arrays and uses SIMD. This is a main reason ClickHouse scans fast.

Storing each column's values contiguously on disk instead of storing whole rows. It lets queries read only the columns they need and compresses similar values well.

Online analytical processing: workloads that scan large volumes, aggregate many rows, and return few grouped results. ClickHouse is designed for this pattern rather than transactional point updates.

A statement that shows the query plan or pipeline. EXPLAIN indexes = 1 reveals how many granules each part contributes and how many were skipped, which is essential for tuning.

A system table recording each executed query with duration, rows read, bytes read, memory usage, and errors. It is the primary source for finding slow or expensive queries.

A system table listing merges and mutations currently in progress, including elapsed time, progress, and memory. It helps diagnose merge backlogs and stalled mutations.

A setting that buffers small inserts server-side and flushes them as larger batches, reducing the number of parts created by high-frequency streaming writers.

A table engine that consumes messages from Kafka topics. Combined with a materialized view it streams data into MergeTree tables, a common real-time ingestion pattern.

An in-memory engine that batches rows and flushes them into a destination table when thresholds are reached. It smooths bursts of small inserts but loses buffered data on restart.

A filter attached to a user or role that is silently added to every query on a table, restricting which rows that principal can see.

A named bundle of privileges that can be granted to users or other roles. Roles simplify access management and can be activated per session.

A limit on resource usage per user or role over a time interval, such as query count, rows read, or execution time. Quotas protect shared clusters from runaway clients.

The managed ClickHouse service that runs compute in separated warehouses over shared object storage, handling scaling, backups, and upgrades while exposing standard SQL and HTTP interfaces.

The table engine family used in ClickHouse Cloud. Data parts live in object storage and metadata is coordinated separately, so compute nodes stay stateless and scale quickly.