ТОП-10 минусов ClickHouse: ограничения в аналитике Big Data

Вчера мы разобрали, чем хорош ClickHouse и почему. Сегодня рассмотрим обратную сторону скорости, расширяемости и других преимуществ этой аналитической СУБД от Яндекса для обработки запросов по структурированным большим данным в реальном времени. Также читайте в нашей статье, как обойти недостатки и ограничения этой системы или понизить степень их влияния на свой Big Data проект.

10 недостатков Кликхаус, важных для аналитики Big Data

Основными минусами ClickHouse считаются следующие [1]:

отсутствие транзакций – Кликхаус является OLAP, а не OLTP-системой, и не поддерживает транзакционность записей, т.к. ориентирован, в первую очередь, на считывание данных. Поэтому попытки использовать ClickHouse в транзакционных OLTP-сценариях нецелесообразны.
отсутствие точечных операций обновления и удаления данных (UPDATE и DELETE) по отдельным записям. В 2018 году появилась стали доступны пакетные операции ALTER UPDATE и ALTER DELETE, которые выполняются асинхронно, не блокируют вставки, запросы и друг друга [2]. Возможно массовое удаление и изменение данных для очистки более не нужного или в соответствии с требованиями GDPR [3].
Ограниченная поддержка операций JOIN, в частности, в запросах, которые требуют перемещения большого количества данныхмежду узлами кластера, например, join между двумя большими таблицами [4]. Впрочем, соединения таблиц можно избежать, подключив таблицу как внешний словарь, причем из любой базы данных, даже сторонней, например, MySQL, PostgreSQL или внешнего файла [5].
строгая типизация с необходимостью явного приведения. Хотя это ограничение и доставляет некоторые неудобства в процессе разработки, оно предохраняет от многих ошибок на этапе выполнения программы.
зависимость от оперативной памяти — для некоторых операций промежуточные данные должны помещаться в оперативную память. В частности, при агрегации необходимо, чтобы результат выполнения запроса помещался в RAM на одном сервере. При этом сам объём исходных данных для запроса может быть любым, в т.ч. очень большим. Также стоит упомянуть, что соединения таблиц ограничены оперативной памятью сервера [6].
отсутствие оконных функций и зависимых подзапросов – ClickHouse поддерживает декларативный язык структурированных запросов, который во многом совпадает со стандартом ANSI SQL, но не во всем. Это стоит учитывать при написании запросов к базе данных [3].
отсутствие полноценного оптимизатора запросов. Частично эта проблема решается с помощью материализованных представлений, о которых мы рассказывали здесь. Например, при большом объеме сырых данных в СУБД скорость выполнения агрегированных запросов по ним может снижаться. Движок AggregatingMergeTreeагрегирует данные материализованного представления по ключу сортировки. Благодаря этому можно группировать данные по определенным полям, делая возможным выполнять сложные запросы по большому промежутку времени [7]. В других случаях можно проанализировать, в чем именно проблема снижения скорости выполнения запросов: процессор, память, жесткий диск или сеть. К примеру, по умолчанию ClickHouse использует только физические процессорные ядра, без учёта одновременной многопоточности (hyper-threading). Некоторые запросы могут существенно ускориться, если увеличить количество потоков. Также возможны проблемы с дисками RAID 5 или RAID 6, которые отлично масштабируются по последовательным (и даже случайным) чтениям, но плохо – по записям. Наличие универсального оптимизатора запросов в ClickHouse сэкономило бы время разработчика или аналитика Big Data, позволяя не погружаться в такие тонкости. Но пока этого инструмента в СУБД нет [8].
низкая скорость точечного чтения одиночных строк по своим ключам из-за разреженного индекса делает [3];
низкая производительность небольших вставок, т.к. из-за столбцового принципа хранения данных в ClickHouse. Каждый столбец – это минимум один файл, поэтому, например, для вставки 1 строки с 100 столбцами потребуется открыть и записать не менее 100 файлов [6].
подверженность атакам на HTTP-интерфейс, включая SQL-инъекции. В частности, табличная функция url для обращения к удалённым узлам по HTTP и HTTPS позволяет провести атаку SSRF через SQL-инъекцию. Также HTTP-интерфейс ClickHouse делает возможным атаку Reflected File Download, если пароль не установлен, сохранен в браузере пользователя или известен злоумышленнику. Аналогичным образом из-за HTTP-интерфейса ClickHouse может подвергнуться атакам подделки запросов на стороне сервера (SSRF, Server-Side Request Forgery) и между сайтами (CSRF, Cross-Site Request Forgery) [2].

Построение хранилища данных на базе Clickhouse

Код курса

CLICH

Ближайшая дата курса

9 декабря, 2024

Продолжительность

24 ак.часов

Стоимость обучения

72 000 руб.

Как обойти эти ограничения ClickHouse и других СУБД в реальных проектах по оперативной обработке и надежному хранению больших данных, вы узнаете на практических курсах по администрированию и эксплуатации Big Data систем в нашем лицензированном учебном центре повышения квалификации и обучения руководителей и ИТ-специалистов (разработчиков, архитекторов, инженеров и аналитиков) в Москве:

Построение хранилища данных на базе Clickhouse

Источники