В этой статье сравним и разберём опенсорные СУБД для задач, связанных с аналитикой, на понятном для новичков языке.
269 открытий372 показов
В 2025 году выбор правильной открытой базы данных для аналитики становится критически важным для успеха любого проекта. PostgreSQL, ClickHouse и DuckDB — три лидера в этой области. PostgreSQL славится своей надежностью и гибкостью, ClickHouse — высокопроизводительными аналитическими возможностями, а DuckDB — простотой использования и интеграции. Сегодня мы рассмотрим, какая из этих баз данных лучше всего подойдет для аналитиков в текущем году.
Ваши ставки. Кто победит?PostgreSQLClickHouseDuckDBОтветить
PostgreSQL: Универсальная объектно-реляционная СУБД
PostgreSQL — объектно-реляционная СУБД (система управления базами данных). Термин реляционная означает, что мы записываем данные в виде взаимосвязанных таблиц со строгой схемой. В этой схеме у нас есть столбцы и ячейки, где занесены значения определённого типа: строки, числа, даты. Прямо как в Excel.
«Объектность» PostgreSQL заключается в том, что в качестве значений мы можем записывать не только числа, строки, даты, но и сложно структурированные данные, например, JSON или XML файлы. Ещё здесь есть наследование, мы можем создавать дочерние таблицы, которые повторяют структуру и данные родительских. Другая фишка PostgreSQL — пользовательские типы. В нём допускается прописывать свои типы данных и работать с ними. По логике это немного напоминает ООП с классами, объектами и наследованием.
Есть возможность писать свои функции для обработки данных, подключать сторонние библиотеки, причём делать это на разных языках. В общем, с расширяемостью и гибкостью здесь всё очень неплохо.
PostgreSQL используют в интернет-магазинах, финансовых системах, банковских и геопространственных приложениях, системах управления контентом в блогах, социальных сетях и аналитике. Это универсальный гибкий инструмент.
Вишенка на торте — PostgreSQL доступен с открытым исходным кодом. Его можно установить, не заморачиваясь с лицензиями и оплатой, настроить под себя и пользоваться.
ClickHouse: Скорость и аналитика от Яндекса
ClickHouse родился в стенах Яндекса в середине 2000-х. Изначально это была внутренняя разработка для Яндекс.Метрики — чтобы быстро обрабатывать миллиарды событий, подсчитывать статистику и выдавать отчёты, не теряя в скорости. В 2016 году разработку опубликовали на GitHub с опенсорс лицензией.
Особенность ClickHouse заключается в его колоночно-ориентированной архитектуре. Традиционные СУБД работают с данными построчно. Это значит, что каждая строка — как бы отдельная сущность с данными.
Допустим, нам надо считать данные с одного столбца. Классические СУБД пойдут искать ячейки столбца по строкам, вместо того, чтобы выбрать этот столбец.
Пример логики работы строковой СУБД
ClickHouse спроектирован иначе. Он хранит данные в столбцах, а не в строках. Благодаря этому в задачах с аналитикой, нам не надо считывать все строки, чтобы добраться до конкретной ячейки в столбце. Мы считываем меньше ячеек, тратим меньше ресурсов и получаем большую производительность.
Пример логики работы колоночной СУБД
ClickHouse поддерживает векторизацию. Это значит, что он нарезает БД (базу данных) на векторы — отдельные куски. СУБД сразу обрабатывает весь кусок целиком, вместо того чтобы по очереди заниматься каждой ячейкой. Здесь есть Simd-оптимизация — технология, которая позволяет процессору выполнять операции сразу над несколькими элементами данных параллельно.
Благодаря колоночной архитектуре и хорошей оптимизации ClickHouse быстро работает с данными. Его применяют в аналитике Uber, Bloomberg, Google, Netflix, VK, Avito, Т-банк, ну и, конечно же, Яндекс.
DuckDB: Локальная аналитика
DuckDB — ещё одна СУБД с открытым исходным кодом. Как и ClickHouse использует колоночную архитектуру, векторизацию и Simd-оптимизацию. Благодаря этому, хорошо справляется с аналитическими задачами.
Главная фишка DuckDB в том, что он предназначен для работы на стороне клиента и оптимизирован под обычные ПК и ноутбуки. DuckDB популярен среди аналитиков, которые работают с данными локально, например, через Python или R. Его можно подключить как библиотеку и работать с данными внутри проекта.
Сравнение возможностей СУБД
Производительность в тестах
Для сравнения я использовал ClickBench. Это набор данных с тестами для разных СУБД, весом более 70 гб и количеством около 100 млн строк.
В качестве оборудования выбрал c6a.4xlarge. Здесь 32 гб. ОЗУ, 16-ядерный процессор и диск объёмом 500 гб.
Результаты тестов
Тест предполагает, что СУБД обрабатывает данные при помощи 42 запросов. Cold Run — обработка некэшированных данных, Hot Run — работа с кэшированными данными, Storage Size — сжатие в гигибайтах (1 Гиб ≈ 1.073 Гб).
DuckDB оказался самым шустрым в тесте Cold Run, он обрабатывает некэшированные данные за 372 секунды, тогда как у ClickHouse 470 сек., а у PostgreSQL 937 сек.
Однако, ClickHouse оказывается быстрее в тесте Hot Run — когда данные в кэше. У него 372 сек., тогда как у DuckDB 470 сек. а у PostgreSQL всё те же 937 сек.
Также ClickHouse лучше всех работает с памятью. Он смог сжать 70 гб. данных до 13.48 гибибайт. На втором месте DuckDB, у него 22.03 Гиб. PostgreSQL не только не сжал данные, но и раздул их до 99.18 Гиб (примерно 106 гб). Возможно, ClickHouse и DuckDB проще сжимать информацию, так как у них колоночный подход к работе с данными, ведь в столбце повторяющиеся значения могут встречаться чаще, чем в строке. Увеличение объёма данных в PostgreSQL возможно вызвано тем, что СУБД наплодило много метатегов к данным.
В общем, PostgreSQL сильно уступает в производительности ClickHouse и DuckDB. С памятью работает тоже хуже.
Масштабируемость систем
PostgreSQL — хороший вариант для вертикального масштабирования
Отлично подходит для вертикального масштабирования. Это значит, что если у нас увеличивается нагрузка и сервер уже не вывозит, то мы можем просто его прокачать: купить побольше ОЗУ, диск, процессор помощнее. Либо можно купить другой более мощный сервер и перенести данные на него.
Такова особенность классических реляционных моделей, они изначально проектировались с учётом вертикальной масштабируемости.
Обратная сторона — проблемы с горизонтальным масштабированием. Это когда мы покупаем несколько серверов послабее, распределяем между ними нагрузку и создаём кластер. Чтобы такое провернуть, понадобится дополнительная настройка через инструменты вроде Citus или Pgpool.
ClickHouse масштабируется вертикально и горизонтально
Тоже хорошо подходит для вертикального масштабирования, как и PostgreSQL. Однако он также поддерживает шадрирование и репликацию. Шадрирование означает, что ClickHouse может нарезать базу данных на кусочки и распределять эти кусочки между разными узлами. Репликация означает, что СУБД может копировать их на другие сервера в кластере.
Благодаря этому ClickHouse также хорошо подходит и для горизонтального масштабирования, когда нагрузка распределена на несколько серверов. Но есть нюанс. Здесь может быть задержка при синхронизации между узлами и сложности с изоляцией транзакций.
DuckDB — только вертикальное масштабирование на обычных ПК и ноутбуках
Мы можем установить DuckDB на обычный ПК и прокачивать компьютер сколько угодно. В этом плане с вертикальным масштабированием никаких проблем нет. Но вот создать кластер и масштабировать горизонтально не получится, так как СУБД предназначена для индивидуального локального использования.
Экосистема и удобство использования
PostgreSQL выделяется своей зрелой экосистемой. Он кроссплатформенный, можно установить на Windows, MacOS, Linux, Docker. После установки необходима небольшая настройка под свои задачи.
Мы можем управлять СУБД через графический интерфейс pgAdmin.
Интерфейс Postgresql
Он поддерживает создание и редактирование объектов, просмотр структуры, визуализацию схемы. Для этого даже необязательно вводить SQL запросы, хотя это тоже можно. Также есть консольный клиент psql.
PostgreSQL поддерживает интеграцию с BI системами, например, Tableau, Metabase, Power BI, и расширения наподобие PostGIS и TimescaleDB.
У PostgreSQL всё хорошо с расширяемостью, мы вправе писать свои функции, индексы, подключать сторонние модули. Здесь можно писать код не только на SQL, но и на Python, C, C++, Java, JS, Rubi, R, Lua.
Документация — одна из лучших, а сообщество активно помогает на форумах и конференциях. Однако для аналитики нужна оптимизация, импорт больших данных может быть медленным.
ClickHouse ориентирован на аналитику больших данных в реальном времени, что отражается в его экосистеме. Поддерживает установку на Windows, MacOS, Linux, Docker.
ClickHouse готов к работе «из коробки» для аналитических задач. Можно ничего не настраивать и сразу создать таблицу, но при условии, что СУБД будет работать только на одном устройстве. Если мы собираемся запустить ClickHouse на кластере, то придётся немного повозиться с настройками шадринга и репликации. Есть поддержка как SQL, так и других языков, но только через клиентские библиотеки.
Документация подробная, но сообщество меньше, чем у PostgreSQL. Разных наворотов тоже меньше, поэтому ClickHouse больше про минимализм. Есть много вариантов графических интерфейсов от сторонних разработчиков.
Сторонний интерфейс agx
Например, на изображении интерфейс agx.
DuckDB можно установить на Windows, MacOS, Linux. Установка напоминает подключение библиотеки к проекту. Просто пишем команду pip install duckdb для Python или install.packages(“duckdb”) для R и всё установлено локально, без сервера. Поддерживает и другие языки через клиентские библиотеки.
Он разработан с акцентом на простоту и локальное использование, поэтому здесь можно сразу начать работу, без настройки.
В марте 2025 года у DuckDB появился свой графический интерфейс. В нём тоже можно писать SQL запросы, смотреть результаты и организовывать проекты в виде блокнотов.
Интерфейс DuckDB
Также есть интерфейсы от сторонних разработчиков и консольный клиент.
Поддержка транзакций (ACID)
ACID — это набор свойств, которые обеспечивают надёжность транзакций в базах данных:
- Atomicity (Атомарность): Все операции в транзакции выполняются полностью, или ни одна из них не выполняется. Если что-то идёт не так, изменения откатываются.
- Consistency (Согласованность): После каждой транзакции база данных остаётся в согласованном состоянии, соблюдая все ограничения (например, уникальность ключей, внешние ключи).
- Isolation (Изоляция): Транзакции изолированы друг от друга, то есть незавершённые транзакции не видны другим.
- Durability (Долговечность): После завершения транзакции все изменения сохраняются, даже в случае сбоя системы.
ACID особенно важен для OLTP — обработки транзакций в реальном времени. Такие транзакции есть, например, в банковских системах, где требуется строгая согласованность и надёжность. В аналитических сценариях (OLAP) требования к ACID могут быть менее строгими, так как приоритет отдаётся скорости и масштабируемости.
PostgreSQL изначально разработан для OLTP-нагрузок, где транзакционность критически важна. Он полностью поддерживает ACID, но в ущерб скорости обработки данных, что может снижать производительность в аналитических задачах.
ClickHouse жертвует полной поддержкой ACID ради скорости и масштабируемости. Это делает его идеальной СУБД для аналитических задач, но ограничивает использование в OLTP-сценариях.
Колоночная архитектура позволяет быстро считывать и обрабатывать данные, но вот чтобы их добавлять, изменять, удалять нужно взаимодействовать со строками.
Когда мы изменяем или удаляем данные, у нас создаётся новая строка, но старая никуда не девается, а просто помечается как изменённая или удалённая. В конце, при слиянии, ClickHouse всё же в фоне удаляет устаревшие данные, но из-за особенностей движка у нас есть промежуточное состояние, когда одновременно есть и старые, и новые строки. Это нарушает принципы атомарности и согласованности. Если представить, что ClickHouse отвечал бы за операции с оплатой в интернет-магазине, мы могли получить ситуацию, когда 2 пользователя купили один товар.
DuckDB балансирует между скоростью (для OLAP) и частичной поддержкой ACID (для надёжности). Он поддерживает транзакции, но с ограничениями. Например, СУБД не может работать сразу с несколькими пользователями, что делает её подходящей для одиночной аналитики, но не для OLTP.
Из-за колоночной архитектуры здесь также, как и в ClickHouse есть сложности в плане поддержки атомарности.
Какую СУБД выбрать для аналитики
Выбирая между PostgreSQL, ClickHouse и DuckDB надо определиться, что важнее: транзакционная надёжность, аналитическая скорость или локальная простота.
PostgreSQL: для небольших данных и универсальности
PostgreSQL подойдёт для аналитики не сильно больших данных, например, в интернет-магазине, при условии, что это не маркетплейс размером с OZON. Это особенно хороший вариант для проектов, где нужна гибкость или поддержка транзакций по стандарту ACID.
ClickHouse: для больших данных в реальном времени
ClickHouse хороший вариант для аналитиков данных и дата-инженеров, которые работают с большим потоком информации в реальном времени. Идеальный вариант для веб-аналитики. Например, здесь можно анализировать лог сайта с большим числом строк. Но не подойдёт, если нужны ACID транзакции. Быстро читает и обрабатывает данные, но медленно их изменяет, создаёт и удаляет.
DuckDB: для локальной аналитики на ноутбуке
Подойдёт дата-сайентистам и аналитикам, работающим локально, без настройки сервера. Однако DuckDB не годится для больших объёмов данных, его не получится развернуть на кластере, про поддержку ACID тоже можно забыть.
PostgreSQL отлично подходит для транзакционных приложений, особенно когда нет особенно высоких требований по масштабируемости или скорости. Когда они появляются, нужно будет искать более сложные решения.
Кстати, для ИИ-приложений, в частности, для Retrieval-Augmented Generation (RAG), pg_vector для PostgreSQL — довольно популярное стартовое решение.
Если нужна «просто СУБД» — PostgreSQL отличное решение «по умолчанию».
ClickHouse — хороший выбор для быстрой аналитики. Например, чтобы строить отчёты и графики в BI-инструментах. Популярная также комбинация PostgreSQL и ClickHouse как лидеров в своих нишах. В этой комбинации PostgreSQL отвечает за исходную обработку данных в приложении, затем передаёт данные в ClickHouse, который поддерживает последующую аналитику.
Для более специфических задач — ultra-low latency, потоковая обработка данных, комбинированные решения — могут потребоваться другие, более сложные инструменты. Примеры: CockroachDB, YugabyteDB (оба — распределённые версии PostgreSQL), Apache Ignite (для ultra-low latency SQL и транзакции), Apache Druid (для быстрой аналитики).
DuckDB — скорее нишевый инструмент для data scientists и data engineers. Например, он подходит для обработки больших объёмов данных в скриптах на Python, когда это нужно сделать локально. Если вы разрабатываете приложения, то, скорее всего, вам DuckDB не нужен.
Я много лет разрабатываю распределённые базы данных (GridGain и Apache Ignite). Помог запустить множество систем, использовавших PostgreSQL и ClickHouse, или заменял их своим продуктом.
PostgreSQL — отличный продукт, очень гибкий. Но, чтобы раскрыть его потенциал нужна или очень сильная команда, или хороший внешний вендор, поэтому у Postgres Professional всё хорошо. Большинству компаний для нетиповых задач, особенно low-latency/real-time, проще найти альтернативное решение.ClickHouse классно делает ровно одну вещь — быстро обрабатывает SQL запросы на больших данных. Им не решить все задачи аналитики в компании — долгосрочное хранение, трансформация данных и многое другое нужно будет решать другими инструментами.Лукьянов СтаниславДиректор по продуктам компании GridGain
PostgreSQL, ClickHouse и DuckDB — три очень разные системы, каждая со своей логикой и зоной применения. Тут не про «что лучше», а скорее — «что подойдёт именно под вашу задачу».
PostgreSQL
Это универсальный инструмент. Если не знаете, с чего начать — скорее всего, начинать стоит с него. Он хорошо справляется с большинством типовых задач: хранение данных, транзакции, запросы, индексы, API. Работает стабильно, предсказуемо, и его знают почти все разработчики. Проблемы начинаются, когда данных становится очень много, особенно если есть тяжёлые аналитические запросы — тогда он уже не так эффективен. Масштабируется скорее вертикально, и не всегда удобно тюнить для сложной аналитики.
ClickHouse
Если у вас огромные объёмы данных и вы хотите быстро гонять по ним аналитику — это ваш инструмент. СУБД для чтения, не для транзакций. Отлично показывает себя в задачах мониторинга, логирования, аналитики в реальном времени. Очень быстрая, но требует больше внимания: настроек, понимания архитектуры, знание её ограничений (например, с JOIN’ами и транзакциями). Это уже не «поставил и работает», тут придётся повозиться.
DuckDB
Это интересный новичок — очень лёгкая, быстрая аналитическая СУБД, которая отлично работает локально, особенно в связке с Python или Jupyter. Я бы назвал её «SQLite для дата-сайентистов». Не требует сервера, можно просто подключить к CSV, Parquet или Pandas DataFrame и писать SQL-запросы. Для быстрого анализа данных — идеально. В продакшене пока использовать её с осторожностью, но для локальной аналитики — инструмент номер один.
Когда что выбирать?
Если вы делаете обычное приложение — PostgreSQL. ClickHouse — лучший выбор для аналитики в реальном времени, дашбордов, логирования, мониторинга, и других сценариев с интенсивными SELECT-запросами. DuckDB — отличный выбор для дата-сайентистов, аналитиков и быстрой локальной аналитики. Особенно хорош в ситуациях, когда нужно быстро что-то «пощупать» без подъёма инфраструктуры.Рубаков АлексейОснователь компании NETRACK — ведущий оператор комплексных решений в области ЦОД.