Одной из причин быстрой работы ClickHouse являются движки таблиц, оптимизированные на конкретные операции с данными. Сегодня рассмотрим, чем они отличаются и какой из них выбирать для разных сценариев.
Движки БД ClickHouse
Прежде чем разбираться с движками таблиц ClickHouse, вспомним само назначение этого термина. Движок БД или механизм хранения отвечает за управление данными в базе: хранение, извлечение и манипулирование данными. Именно он обеспечивает эффективную работу с данными, реализуя оптимальную производительность, безопасность и согласованность операций.
Движок БД представляет собой набор низкоуровневых процессов, которые фактически хранят и получают значения кортежей. Движок БД обеспечивает работу с таблицами, а движок таблицы определяет место и способ хранения табличных данных, поддерживаемые запросы и индексы, методы выполнения запросов, включая конкурентный доступ и параметры репликации.
ClickHouse в качестве движка БД использует Atomic, впервые представленный в версии 20.5. Начиная с версии 20.10, он стал ядром базы данных по умолчанию. По сравнению с ранее используемым движком Ordinary, он имеет более сложную файловую структуру, зато быстрее выполняет DDL-запросы, без блокировки DROP и RENAME TABLE, позволяет использовать UUID в путях Zookeeper, чтобы при расширении кластера выполнять любые манипуляции с таблицами: переименовывать, воссоздавать с тем же именем и пр. Движок Atomic поддерживает диалект SQL и настраиваемые движки таблиц, что мы рассмотрим далее.
Вместо Atomic можно использовать движки баз данных: MySQL, MaterializedMySQL, Lazy, PostgreSQL и Replicated. Движки MySQL, MaterializedMySQL и PostgreSQL позволяют подключаться к базам данных на удалённом MySQL/PostgreSQL-сервере и выполнять запросы INSERT и SELECT для обмена данными между ClickHouse и внешними БД. Это удобно при работе одного приложения с несколькими хранилищами данных. Движок MaterializedMySQL пока находится в статусе экспериментального и не рекомендуется для производственного использования. Он создает базу данных ClickHouse со всеми таблицами и данными, которые есть в MySQL, превращая сервер ClickHouse в реплику MySQL, включая чтение binlog-файла и выполняя DDL и DML-запросы.
Движок Replicated основан на Atomic и тоже пока считается экспериментальным. Он поддерживает репликацию метаданных через DDL-лог, записываемый в ZooKeeper и выполняемый на всех репликах базы данных. На одном сервере ClickHouse может одновременно работать и обновляться несколько реплицированных баз, но для любой из них есть только одна реплика.
Движок Lazy сохраняет таблицы только в оперативной памяти через несколько секунд после последнего доступа. Он может использоваться только с небольшими таблицами типа Log (движки семейства Log), которые редко запрашиваются. Синтаксис использования Laze-движка при создании БД немного отличается от других возможных. А использовать движки MySQL, MaterializedMySQL, PostgreSQL и Replicated можно, указав нужны в команде создания базы данных. Например, следующая команда создает БД test_database с движком PostgreSQL, поскольку сами данные лежат в базе данных PostgreSQL под названием postgres_db, доступной пользователю user с паролем password по сокету host:port:
CREATE DATABASE test_database
ENGINE = PostgreSQL('host:port', 'postgres_db, 'user', 'password'[, `schema`, `use_table_cache`]);
Опционально можно задать схему БД PostgreSQL и кэширование структуры таблиц БД.
Движки таблиц
Как уже было отмечено выше, движок таблицы по сути определяет ее тип, т.е. как и где будут храниться данные, какие запросы будут поддерживаться и каким образом. В ClickHouse есть несколько движков таблиц, сгруппированных в семейства:
- MergeTree – универсальные движки для высоконагруженных задач: MergeTree, ReplacingMergeTree, SummingMergeTree, AggregatingMergeTree, CollapsingMergeTree, VersionedCollapsingMergeTree и GraphiteMergeTree. Они быстро вставляют данные и обрабатывают их в фоновом режиме, чтобы ускорить последующий доступ к вновь вставленным записям. Эти движки поддерживают репликацию данных в БД с движком Replicated, а также партиционирование и транзакционные вставки. Как мы уже отмечали в прошлой статье, выбор движка зависит от типового варианта использования таблицы. Например, MergeTree отлично подходит для хранения временных рядов в ClickHouse, поддерживая высокую скорость вставки и запросов на больших объемах данных. Также с этим движком можно использовать модификатор FINAL для SELECT-запросов, о чем мы рассказываем здесь. А SummingMergeTree хорошо работает с простыми агрегациями. Для работы с данными временных рядов инструмента мониторинга Graphite рекомендуется GraphiteMergeTree, а CollapsingMergeTree может снизить объем потребляемого пространства за счет удаления строк, эквивалентных по ключу сортировки.
- Log — простые движки с небольшим набором функций: TinyLog, StripeLog и Log. Они эффективны, когда надо быстро записать много небольших таблиц (менее 1 миллиона строк) и прочитать их позже целиком. Log-движки хранят данные на диске, поддерживают распределенные файловые системах HDFS и S3. При записи новые данные добавляются в конец файла. Конкурентный доступ к данным обеспечивается за счет блокировок. Во время INSERT-запросов таблица блокируется, а другие запросы на чтение и запись ожидают разблокировки таблицы. При отсутствии запросов на запись количество конкурентных запросов на чтение не ограничено. Операции мутации данных и индексы не поддерживаются, поэтому SELECT-запросы не эффективны для выборки диапазонов. Из-за неатомарной записи данных есть риск получить таблицу с повреждёнными данными, если вдруг операция записи прервется, к примеру, из-за отказа сервера. Движок TinyLog менее эффективен по сравнению с StripeLog и Log: он медленный и не поддерживает параллельного многопоточного чтения данных. Из-за того, что TinyLog хранит каждый столбец в отдельном файле, он потребляет столько же ресурсов (файловых дескрипторов), как StripeLog и Log. TinyLog подходит для простых сценариев с низкой нагрузкой. Log и StripeLog поддерживают параллельное чтение. Log сохраняет каждый столбец таблицы в отдельном файле, а StripeLog хранит все данные в одном файле. Поэтому StripeLog использует меньше файловых дескрипторов операционной системы, но Log эффективнее считывает данные.
- Интеграционные движки для взаимодействия со сторонними системами: брокеры сообщений (Kafka, RabbitmQ), СУБД (MySQL, PostgreSQL, MongoDB, RocksDB), распределенная файловая система Hadoop (HDFS), облачное объектное хранилище AWS S3, а также универсальные драйверы для связи с базами данных ODBC и JDBC. О работе с движком RocksDB читайте в нашей новой статье.
- Движки для специальных операций с файлами, URL-адресами, а также данными различных типов в оперативной памяти и буфере (Distributed, Materialized, View, Dictionary, Merge, File, Null, Set, Join, URL, View, Memory, Buffer).
Выбор движка указывается при создании таблицы в DDL-запросе:
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [NULL|NOT NULL] [DEFAULT|MATERIALIZED|EPHEMERAL|ALIAS expr1] [compression_codec] [TTL expr1] [COMMENT 'comment for column'],
name2 [type2] [NULL|NOT NULL] [DEFAULT|MATERIALIZED|EPHEMERAL|ALIAS expr2] [compression_codec] [TTL expr2] [COMMENT 'comment for column'],
...
) ENGINE = engine
COMMENT 'comment for table'
Для уже созданной таблицы изменить движок нельзя. Да и вообще область применения команды изменения таблицы ALTER TABLE довольно ограничена: этот SQL-запрос поддерживается только для таблиц с движком семейства MergeTree, а также Merge и Distributed для шардирования таблиц с целью повышения производительности и горизонтальной масштабируемости емкости БД. Поэтому при создании таблицы дата-инженер должен учитывать все варианты ее использования и возможные риски, чтобы выбрать наиболее подходящий движок. Как это сделать, вы узнаете на нашем курсе.
Освойте администрирование и эксплуатацию ClickHouse для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
