ClickHouse, PostgreSQL и другие СУБД для аналитики: как выбрать

Обновлено 3 сентября 2026 года.

Выбирать СУБД для аналитики стоит по запросам, правилам изменения данных и требованиям к результату. Число сотрудников компании или строк в таблице само по себе не определяет нужный продукт. Важно, сколько данных читает запрос, какие объединения выполняет, как часто данные меняются и сколько пользователей работает одновременно.

ClickHouse и PostgreSQL решают пересекающиеся задачи, но с разными приоритетами. ClickHouse ориентирован на аналитическое чтение и большие потоки данных; PostgreSQL — универсальная реляционная СУБД с транзакциями и развитым SQL. Иногда достаточно одной из них, иногда полезен отдельный аналитический контур. Вторую СУБД имеет смысл добавлять после измерения конкретного ограничения.

Сначала опишите нагрузку

Строковое и колоночное хранение

Строковое хранение удобно для получения и изменения небольшого числа полных записей. Колоночное позволяет читать выбранные столбцы и эффективно сжимать однотипные значения. Это часто полезно при сканировании большой доли таблицы и расчёте агрегатов.

Из этого не следует, что колоночная СУБД быстрее на каждом запросе. Селективный поиск по индексу, большие JOIN, сортировка, запись и конкуренция за память могут изменить результат. Существуют и системы с несколькими способами хранения: например, SQL Server с rowstore и columnstore, MariaDB с InnoDB и ColumnStore, Oracle с дополнительным In-Memory Column Store.

ClickHouse: аналитическое чтение и управление версиями данных

ClickHouse подходит для рассмотрения, когда основная нагрузка — фильтрация и агрегация больших наборов событий, телеметрии, операций или подготовленных витрин. Колоночное хранение, сжатие и пакетная обработка помогают уменьшать объём чтения. Практический результат зависит от схемы, ключа сортировки, распределения данных и самих запросов.

Неправильно описывать ClickHouse как базу, в которой нельзя обновлять данные. В ней есть несколько механизмов: добавление новых версий через специализированные движки, мутации ALTER TABLE … UPDATE и lightweight UPDATE … SET. Они отличаются стоимостью записи, последующего чтения и моментом применения изменений. Выбор описан в руководстве по обновлениям ClickHouse.

Например, ReplacingMergeTree удаляет старые версии строк с одинаковым ключом сортировки при фоновых слияниях. До слияния обычный запрос может увидеть несколько версий. Для корректного результата требуется FINAL или эквивалентная логика выбора актуальной версии. Наличие движка с названием Replacing не гарантирует, что любой SUM сразу посчитает текущие сделки правильно.

Отдельно проверяются транзакционные требования. У ClickHouse есть атомарность отдельных операций при определённых условиях и экспериментальные многооператорные транзакции с ограничениями. Это нельзя ни свести к «никакой ACID-поддержки», ни считать полной заменой транзакционной модели PostgreSQL. В разборе ClickHouse и PostgreSQL разработчик отдельно оговаривает различия фиксации и сохранности изменений; поэтому сравнивать время UPDATE без этих условий некорректно.

Перед применением ClickHouse проверьте:

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

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

PostgreSQL: транзакции, сложный SQL и аналитические витрины

PostgreSQL удобен, когда важны целостность связанных таблиц, частые изменения и разнообразная логика SQL. В нём есть оконные функции, CTE, разные виды JOIN, индексы, партиционирование и материализованные представления. Эти средства позволяют строить аналитические системы разного масштаба; их полезность определяется нагрузкой.

У PostgreSQL нет универсального предела «до 100 миллионов строк» или «до 1 ТБ». Официальные ограничения PostgreSQL описывают технические пределы отдельных объектов, а не допустимое время выполнения отчёта. Практический предел может наступить раньше из-за дисков, памяти, схемы или запросов. При этом миллиард строк сам по себе не означает, что СУБД перестанет работать.

MVCC помогает чтению и записи сосуществовать, но не отменяет блокировки и конкуренцию за CPU, память и I/O. Тяжёлый отчёт на рабочей базе способен мешать приложению. Аналитическая реплика или отдельная витрина помогают изолировать часть нагрузки, однако требуют контроля задержки и ресурсов. Реплика не заменяет резервную копию.

Партиционирование полезно, если запросы и обслуживание используют границы разделов; оно не ускоряет автоматически любой SELECT. Материализованное представление хранит результат запроса, но нуждается в обновлении. Сначала стоит определить, допустима ли задержка и сколько стоит пересчёт.

Для распределённой обработки существуют расширения и отдельные продукты на основе PostgreSQL. Например, Citus — расширение, а Greenplum и Arenadata DB — отдельные MPP-системы со своими версиями, ограничениями и эксплуатацией. Pgpool или пул соединений сами по себе не превращают обычную PostgreSQL в прозрачное распределённое хранилище.

MySQL и MariaDB: проверяйте конкретный движок и версию

MySQL может обслуживать аналитические запросы, особенно если данные уже находятся в нём и нагрузка соответствует ресурсам. Утверждение, что MySQL не поддерживает INTERSECT и EXCEPT, устарело: они доступны начиная с MySQL 8.0.31. В ветке 8 также появились оконные функции и CTE. См. документацию операторов множеств.

Это не означает полной совместимости SQL между MySQL и PostgreSQL. Проверять нужно используемые функции, планы выполнения, семантику дат, NULL, сортировки и требования BI. Вывод «один оптимизатор всегда лучше другого» без воспроизводимого набора запросов не помогает выбору.

MariaDB развивается отдельно от MySQL. ColumnStore — колоночный движок для аналитики с MPP-обработкой; документация описывает и JOIN между ColumnStore и строковыми движками. Он требует отдельного проектирования и эксплуатации, а не включается автоматически у любой таблицы MariaDB. См. архитектуру ColumnStore.

Сравнивайте конкретную поставку: MySQL с InnoDB, MariaDB с InnoDB, MariaDB ColumnStore и облачные аналитические сервисы — разные варианты. Возможности одного нельзя приписывать всем остальным, даже если часть SQL похожа.

SQL Server и Oracle: учитывайте действующую архитектуру

SQL Server поддерживает транзакционные и аналитические нагрузки, включая columnstore. Он работает и на Linux; выбор СУБД не означает обязательную Windows-инфраструктуру для каждого компонента. При этом состав функций зависит от редакции и платформы. См. SQL Server на Linux.

Лимиты тоже зависят от версии. Например, для Express в SQL Server 2025 указан предел базы 50 ГБ; переносить на все версии прежнее значение 10 ГБ неверно. LocalDB — облегчённый вариант Express, запускаемый в пользовательском режиме. Developer предназначен для разработки и тестирования, а не для производственного сервера. См. редакции SQL Server 2025.

Oracle поддерживает развитые механизмы аналитической обработки. Например, In-Memory Column Store создаёт дополнительное согласованное колоночное представление данных в памяти и не заменяет строковое хранение на диске. Доступность опций определяется конкретной поставкой и условиями лицензии. См. архитектуру Oracle In-Memory.

Миграцию работающей системы стоит оценивать по зависимостям: процедуры, функции, типы, права, ETL, драйверы, резервирование и расчёты BI. Перенос таблиц ещё не доказывает эквивалентность системы. Для приобретения, продления и поддержки проверяйте условия конкретного продукта и договора; технический обзор не устанавливает, что все существующие лицензии автоматически аннулированы или все обновления недоступны.

MPP, MongoDB и Redis: другие роли в аналитике

MPP-хранилища

MPP-система распределяет данные и выполнение запросов между узлами. Например, Arenadata описывает ADB как аналитическую MPP-СУБД на основе Greenplum с собственным развитием продукта. Это не другое название любой установки Greenplum. См. описание Arenadata.

Такой вариант стоит проверять для корпоративного хранилища с тяжёлыми объединениями и параллельными расчётами. Важны ключ распределения, перекос данных, пересылки между узлами и управление очередями. Кластер не освобождает от проектирования модели.

MongoDB

MongoDB умеет выполнять агрегации, а стадия $lookup объединяет документы коллекций. У неё также есть многодокументные транзакции. Поэтому противопоставление «SQL с JOIN и транзакциями против NoSQL без них» неверно.

Для BI нужно проверить работу с вложенными документами, разворачивание массивов и доступный коннектор. Иногда расчёт удобно выполнять в aggregation pipeline, иногда — переносить данные в табличную витрину. Решение зависит от требуемых запросов и нагрузки; само название NoSQL не определяет скорость.

Redis

Redis часто используют для кеша, счётчиков и выдачи заранее рассчитанных показателей. Его роль может быть шире простого key-value: в актуальных поставках есть средства работы с временными рядами и поиска. Однако схему хранения истории, расход памяти, сохранность и поведение при вытеснении нужно проектировать отдельно. Потеря кеша допустима только тогда, когда результат можно восстановить из надёжного источника.

Лицензия Redis зависит от версии. По официальной странице лицензий, ветки 7.2 и ранее остаются под BSD-3-Clause; для 7.4 используются RSALv2 или SSPLv1; начиная с Redis 8 доступен также вариант AGPLv3. Называть любой Redis BSD-продуктом некорректно.

Как подключать СУБД к BI

Наличие SQL или ODBC ещё не гарантирует одинаковые режимы работы. Проверяйте конкретный коннектор, его версию, драйвер, способ аутентификации, шлюз и поддержку преобразований.

Источники: PostgreSQL в Power Query, MySQL в Power Query, ClickHouse и Power BI, ClickHouse в Superset, подключения DataLens.

Import загружает данные в модель Power BI; DirectQuery формирует запросы к источнику при взаимодействии с отчётом с учётом кеширования и ограничений. Это не «построчная передача» и не гарантия мгновенной свежести. В Superset производительность зависит от источника, запросов и кеша, а база метаданных Superset не является автоматически хранилищем бизнес-данных.

DataLens также кеширует результаты запросов. Поэтому утверждение «сервис вообще ничего не хранит и всегда показывает текущую БД» неверно. Для облачной, открытой и коммерческой локальной поставок сверяйте набор подключений и условий отдельно. Облачные места не становятся бесплатными из-за наличия открытого исходного кода.

Сравнение вариантов по рабочей задаче

Как провести честный пилот

1. Выберите реальные запросы. Нужны не только быстрые примеры, но и типичные фильтры, JOIN, сортировки и отчёты с высокой конкуренцией.
2. Сначала сравните результаты. Суммы, число строк, NULL, дубли, время, валюта и округление должны совпасть с эталоном. Проверяйте удалённые и исправленные записи.
3. Уравняйте условия. Зафиксируйте версии, оборудование, объём и распределение данных, настройки сохранности и допустимую задержку.
4. Разделите холодный и прогретый запуск. Кеш базы и BI способен существенно изменить время; оба режима нужно описать.
5. Запустите параллельную работу. Измеряйте не только среднее время, но и медленные ответы, ошибки, очереди и загрузку ресурсов.
6. Проверьте поступление изменений. Измерьте весь путь до отчёта, повтор загрузки после сбоя и время исправления уже опубликованных данных.
7. Оцените эксплуатацию. Включите стоимость инфраструктуры, лицензий, загрузок, мониторинга, поддержки и проверенного восстановления.

Чужой кейс может подсказать идею, но ускорение в нём относится к конкретной схеме, запросам и настройкам. Без воспроизводимых условий нельзя обещать «в 100 раз быстрее», фиксированный коэффициент сжатия или одинаковую производительность на любом объёме.

Открытый код и российские поставки

Открытый код, бесплатное использование, коммерческая поддержка, наличие в реестре и сертификация — разные свойства. Проверять их нужно у выбранного продукта, редакции и версии. Upstream PostgreSQL и коммерческий дистрибутив на его основе не тождественны по условиям поставки.

Не все российские СУБД основаны на PostgreSQL: например, разработчик РЕД Базы Данных указывает основой Firebird. Аналогично, происхождение ClickHouse не означает автоматического соответствия любым требованиям к конкретной закупке или поставке.

Выбор можно считать обоснованным, когда система правильно считает необходимые показатели, выдерживает согласованную нагрузку, восстанавливается после сбоя и имеет понятную стоимость сопровождения. Название СУБД и размер компании этого не заменяют.