Arenadata QuickMarts

В ADQM есть мониторинг(ADQM Notebook, ADQM Control), средства управления и расширения кластера.

ADQM – кластер с архитектурой shared nothing: каждый узел владеет своей частью данных и обрабатывает ее локально. Масштабирование идет по трем осям.

Шарды – горизонтальный рост емкости и скорости обработки. Для типичной аналитики (сканирование, фильтры, агрегаты) производительность растет почти пропорционально числу узлов.

Реплики – масштабирование чтения и отказоустойчивость. Дополнительные реплики внутри шарда увеличивают пропускную способность на чтение; при отказе узла запросы обслуживают оставшиеся.

Вертикально – ClickHouse распараллеливает запрос по всем ядрам узла, поэтому апгрейд серверов дает прирост без изменения топологии.

• Автоматическая репликация данных на добавляемые в кластер сегмент-сервера без необходимости остановки кластера.

• Нативная отказоустойчивость без доработок ПО с поддержкой асинхронной репликации.

Стабильные версии ClickHouse обычно выпускаются один раз в месяц; версии с долговременной поддержкой, как правило, выходят в марте и августе. Структура имени: YY.MM.PATCHES-TYPE, где YY – год, MM – месяц, PATCHES – идентификатор, возможно содержащий точку, TYPE – слово stable, или lts, или, например, prestable. Пример: 26.3.3.20-lts.

Arenadata базирует релизную политику ADQM на основе версий ClickHouse LTS. Версия 26.3.3.20_arenadata1_b1 соответствует версии ClickHouse 26.3.3.20-lts.

Документация ADQM, Документация ClickHouse, Telegram-чат, Issues в GitHub-репозитории ClickHouse

Arenadata DB в основном используется в следующих сценариях:

• сложные запросы, обрабатывающие большие объемы данных, в том числе содержащие сложные аналитические функции;

• ETL/ELT-процессы загрузки данных, наиболее эффективно себя показывает при возможности in-database обработки;

• эффективные соединения больших таблиц, особенно в случаях объединения по заведомо заданному ключу распределения;

• аналитические функции на процедурных языках, в том числе и с помощью уже готовых библиотек алгоритмов MADLib.

Arenadata QuickMarts в основном используется в следующих сценариях:

• выполнение запросов, сканирующих большие объемы данных, с отсечкой по ключу сортировки и партициям;

• full-scan операции при условии использования фильтров;

• ad-hoc аналитика;

• работа со структурированными логами и событиями.

Средства репликации ClickHouse зарекомендовали себя как надежные. С версии 26.3.3.20 пользователи получили возможность управлять бэкапами из ADCM.

Да, но они устроены иначе, чем в OLTP-СУБД: построчных обновлений «на месте» нет.

Для удаления есть легкая операция DELETE FROM [db.]table WHERE filter_expr.

Для массовых изменений есть мутации: ALTER TABLE [db.]table [ON CLUSTER cluster] UPDATE column = expr [, ...] WHERE filter_expr и ALTER TABLE ... DELETE WHERE filter_expr.

Если бизнес-логика требует регулярного обновления строк, используется идиоматичный подход: движки ReplacingMergeTree и CollapsingMergeTree.

Классических многооператорных транзакций, как в OLTP-СУБД, нет, т.к. для аналитической нагрузки они, как правило, не нужны.

При этом ClickHouse предоставляет ряд гарантий. Вставка одним INSERT в пределах одной партиции атомарна. Каждый SELECT работает со снапшотом – набором кусков данных, зафиксированным на момент старта запроса. Для надежности загрузки есть дедупликация повторно вставленных блоков.

Типичный процесс строится не на транзакциях, а на идемпотентности: атомарные батчевые вставки плюс повторные запуски с дедупликацией дают семантику exactly-once без BEGIN/COMMIT.

ADQM умеет взаимодействовать со следующими системами по промышленным протоколам: Kafka, RabbitMQ, MySQL, MongoDB, PostgreSQL, Hadoop (HDFS), S3, HTTP, JDBC, внешний исполняемый файл или исполняемый сценарий.

Поддержка аутентификации осуществляется при помощи LDAP и Kerberos. Внешняя база данных пользователей и паролей может располагаться в Microsoft Active Directory.

Для загрузки из ADB (Greengage DB) наиболее производительным и удобным решением является ADB ClickHouse Connector.

При использовании HTTP или собственного бинарного ClickHouse-протокола важно обеспечивать редкую (до нескольких десятков раз в секунду) вставку большими блоками. Kafka и RabbitMQ имеют удобные настройки для группировки данных. Недавно появившиеся с ClickHouse асинхронные вставки не меняют эти подходы.

Жестких лимитов на число строк и объем таблицы нет – таблицы в сотни миллиардов строк и десятки терабайт являются штатной практикой. Практические ограничения другие:

• Ширина таблицы. Рекомендуемый максимум – порядка 1000 колонок, формального лимита нет. И причина здесь память – порядка 2 МБ ОЗУ на колонку при каждой записи куска данных (вставка, слияние).
• Партиционирование. Ключ партиционирования должен быть грубым (месяц, день) – ориентир порядка сотен партиций на таблицу.
• Количество кусков данных. При превышении лимита активных кусков в партиции вставки отклоняются с ошибкой TOO_MANY_PARTS. Это не лимит объема, а защита от частых мелких вставок.