Table engine определяет, где находятся данные, как таблица принимает INSERT и как отдаёт строки при SELECT. Две таблицы с одинаковыми колонками могут вести себя по-разному из-за ENGINE. Перед работой с незнакомой таблицей полезно выполнить SHOW CREATE TABLE.
MergeTree: собственное аналитическое хранение
Общая основа — отсортированные parts, разреженный индекс и фоновые merges. Различается обработка строк одинакового сортировочного ключа при слиянии.
| Движок | Дополнительная механика | Применение |
|---|---|---|
| MergeTree | Сохраняет строки без бизнес-дедупликации | Неизменяемые события |
| ReplacingMergeTree | Выбирает одну версию строки | Последнее состояние сущности |
| SummingMergeTree | Складывает выбранные числовые меры | Счётчики и аддитивные витрины |
| AggregatingMergeTree | Объединяет состояния агрегатных функций | Средние, уникальные, квантили |
| CollapsingMergeTree | Схлопывает согласованные пары со знаком 1 и -1 | Источник умеет отправлять отмену состояния |
| VersionedCollapsingMergeTree | Учитывает знак и версию | Более сложный порядок доставки изменений |
| GraphiteMergeTree | Укрупняет временные ряды по настройкам | Специализированные Graphite-сценарии |
В ветке 25.8 есть также CoalescingMergeTree: он совмещает последние ненулевые значения отдельных колонок. Последнее здесь определяется порядком вставок, а не произвольной колонкой времени события. Это другая семантика, чем выбор одной полной строки ReplacingMergeTree. Перед применением нужна проверка модели обновлений.
Replicated-варианты добавляют копирование данных между репликами. Базовая семантика остаётся: ReplicatedSummingMergeTree тоже требует правильно читать частичные суммы. SharedMergeTree связан с ClickHouse Cloud; его нельзя считать простой заменой ReplicatedMergeTree в локальном Docker.
Log и Memory
TinyLog, StripeLog и Log — простые дисковые движки без развитой механики индекса и фонового обслуживания MergeTree. Они пригодны для ограниченных задач, но не стандартный выбор большой долговременной аналитической таблицы.
Memory хранит содержимое в оперативной памяти и теряет его при перезапуске сервера. Он подходит для небольших временных данных; требуемый объём должен помещаться в RAM.
Set и Join
Set хранит множество ключей для правой стороны IN:
CREATE TABLE allowed_types (event_type String) ENGINE = Set;
INSERT INTO allowed_types VALUES ('click'), ('view');
SELECT 'click' IN allowed_types AS allowed;Запрос возвращает 1: значение click входит в множество. Set убирает повторяющиеся значения. Обычный SELECT * FROM allowed_types не поддерживается: таблица предназначена для проверки принадлежности. По умолчанию она сохраняет данные на диск и восстанавливает структуру в памяти после рестарта, в отличие от Memory.
Join заранее готовит структуру для JOIN и joinGet. Например, Join(ANY, LEFT, source) фиксирует тип соединения и ключ. Запрос должен использовать совместимые параметры. Дубликаты при ANY не превращают таблицу в надёжное хранилище последней версии: нужно понимать политику замены. Структура расходует память и требует обновления при изменении справочника.
Специальные задачи
Distributed направляет запросы к шардам; долговременные факты обычно лежат в локальных MergeTree-таблицах. При фоновой отправке INSERT у Distributed могут быть локальные файлы очереди. Merge читает несколько таблиц как общий набор. Null принимает и отбрасывает строки, хотя связанная materialized view может обработать вставленный блок.
Buffer накапливает данные в RAM перед записью в целевую таблицу. Он усложняет гарантии сохранности и наблюдение за загрузкой; для многих маленьких INSERT проще рассмотреть async inserts. Dictionary показывает словарь как таблицу. File работает с разрешённым серверным файлом, URL обращается к HTTP-источнику.
Интеграции
Kafka и RabbitMQ связывают ClickHouse с сообщениями. S3 работает с объектными файлами, S3Queue добавляет обработку очереди файлов. MySQL, PostgreSQL, MongoDB, Redis, SQLite, ODBC и JDBC дают разные способы доступа к внешним системам. HDFS — к распределённой файловой системе. Чтение Iceberg, Delta Lake и Hudi требует учитывать формат метаданных и возможности конкретной версии.
Внешние движки дают доступ к данным источника. Для повторной аналитики часто строят загрузку во внутреннюю таблицу. Table functions вроде s3(...) позволяют читать источник без постоянного CREATE TABLE.
Набор движков зависит от версии и сборки. Системная таблица показывает доступные движки:
SELECT name FROM system.table_engines ORDER BY name;Движок базы данных
CREATE DATABASE тоже имеет ENGINE. Atomic — распространённый вариант для управления метаданными таблиц. Replicated database engine распространяет DDL через координацию, но не превращает обычную MergeTree-таблицу в реплицированную. Для копирования её данных нужен соответствующий table engine.
Ordinary относится к старой модели метаданных. Database engines внешних СУБД могут представлять внешний каталог. Движок базы управляет каталогом, движок таблицы — её данными.