В этой части мы поговорим о движке таблиц ClickHouse. Как и в любой другой базе данных, ClickHouse использует движки для определения методов хранения, репликации и работы с параллельными запросами для таблиц. У каждого движка есть свои плюсы и минусы, и выбирать их следует исходя из ваших задач. Более того, движки сгруппированы в семейства, объединённые общими ключевыми характеристиками. Итак, начнём с первого и самого популярного семейства: Семейство MergeTree Это основной и наиболее мощный движок ClickHouse. Если вы создаете таблицу и не знаете, что выбрать — начинайте с MergeTree или его модификаций. Основная идея — оптимизация для интенсивной записи данных (INSERT). Под капотом используется структура LSM-дерево (Log-Structured Merge-Tree). В отличие от B-деревьев в классических базах данных (MySQL, PostgreSQL), LSM сначала буферизирует записи в памяти, а затем крупными, отсортированными "пакетами" записывает на диск. Это дает огромный выигрыш в скорости вставки и уменьшает фрагментацию. Теперь рассмотрим ключевых представителей семейства. 1. MergeTree (базовый)Пример создания таблицы: CREATE TABLE users ( user_id Int32, name String, age Int32, city String ) ENGINE = MergeTree PRIMARY KEY (user_id, city) ORDER BY (user_id, city, name) Как работает? Данные разбиваются на части (parts) и сортируются по ORDER BY. Каждая часть делится на гранулы (блоки данных). Для гранул создаются засечки (marks) — "отметки" по первичному ключу. Это разреженный индекс. При запросе с условием по первичному ключу ClickHouse быстро находит нужные гранулы через бинарный поиск по засечкам и загружает только их.Правило: Первичный ключ (PRIMARY KEY) должен быть префиксом или совпадать с ключом сортировки (ORDER BY). Если PRIMARY KEY не указан, вместо него используется ORDER BY. 2. ReplacingMergeTree (для дедупликации) DDL В этом движке строки с одинаковыми ключами сортировки заменяются последней вставленной строкой. Рассмотрим пример: CREATE TABLE user_sessions ( user_id Int32, session_id String, status String, last_activity DateTime ) ENGINE = ReplacingMergeTree ORDER BY (user_id, session_id); Предположим, вы вставляете строку в эту таблицу: INSERT INTO user_sessions VALUES (101, 's1', 'active', '2024-01-15 10:00:00'); Теперь вставим другую строку с теми же ключами сортировки: INSERT INTO user_sessions VALUES (101, 's1', 'inactive', '2024-01-15 11:30:00'); Теперь последняя строка заменит предыдущую. Обратите внимание: если вы выполните выборку, то можете увидеть обе строки: Это происходит потому, что ClickHouse выполняет процесс замены во время слияния частей (merge), которое происходит в фоновом режиме асинхронно, а не мгновенно. Чтобы сразу увидеть финальный результат, вы можете использовать модификатор FINAL: SELECT * from user_sessions FINAL WHERE user_id=101; Примечание: Вы можете указать столбец в качестве версии при определении таблицы, чтобы управлять логикой замены строк. Применение ReplacingMergeTree широко используется для дедупликации. Поскольку ClickHouse не очень эффективен при частых обновлениях, вы можете обновить столбец, вставив новую строку с такими же ключами сортировки, и ClickHouse удалит устаревшие строки в фоновом режиме. Конечно, обновление самих ключей сортировки является проблемой, поскольку в этом случае старые строки не будут удалены. В следующей части мы продолжим разбор семейства MergeTree и рассмотрим: CollapsingMergeTree — для контролируемых обновлений и удалений AggregatingMergeTree — для предварительной агрегации данных А также затронем более легковесные семейства Log и Integration для работы с внешними системами. #ClickHouse #БазыДанных #Аналитика #MergeTree #Оптимизация