Базу выбирают по работе, которую она должна выполнять. Для одной нагрузки важнее много коротких транзакций, для другой — большие соединения и преобразования, для третьей — частые агрегаты по потоку событий. Название «аналитическая» или размер таблицы сами по себе ещё не определяют победителя.
Три исходных профиля
PostgreSQL часто служит операционной базой: приложение читает и меняет отдельные записи, использует индексы, ограничения и короткие транзакции. Он также умеет выполнять аналитику и параллельные запросы. Но стандартное параллельное выполнение внутри сервера не равно распределению таблицы между segment host в Greenplum.
Greenplum организует распределённое SQL-хранилище: данные и работа делятся между сегментами, а план включает Motion. Он подходит для массовой загрузки, соединений и расчёта витрин над большими наборами. Нужно спроектировать распределение, выбрать хранение и обслуживать кластер как единую систему.
ClickHouse ориентирован на аналитическое чтение колоночных данных. Для семейства MergeTree существенны порядок хранения, ключ сортировки, части данных и их слияния. Распределённая работа также требует решений о шардах и репликах. Механизмы исполнения и хранения у него отличаются от Greenplum, хотя обе системы решают аналитические задачи.
Сравнивать механизмы, а не запреты
| Вопрос | PostgreSQL | Greenplum | ClickHouse |
|---|---|---|---|
| Где выполняется работа | В стандартной установке на одном сервере, возможен параллелизм | На сегментах с обменом между исполнителями | Зависит от таблиц и топологии, возможна распределённая обработка |
| Что проектируют для чтения | Запросы, индексы, статистику, партиции | Дополнительно распределение и Motion, heap/AO | Порядок хранения, части, движок и способы пропуска данных |
| Как оценивать изменения | Транзакции, версии и обслуживание | Распределённые транзакции и выбранный метод хранения | Конкретный механизм изменений и его видимость |
| Как проверять аналитику | Реальный план и ресурсы сервера | План, сеть, skew и ресурсы сегментов | План, чтение гранул, части и ресурсы участников |
Утверждения «в Greenplum нет индексов», «ClickHouse не умеет JOIN» и «PostgreSQL не умеет аналитику» мешают выбору. Поддерживаемая возможность и её подходящая стоимость — разные вопросы. Нужно взять конкретную операцию и проверить её в нужной версии и конфигурации.
Изменения данных особенно важно сравнивать по семантике. В ClickHouse существуют механизмы UPDATE и DELETE, но у разных способов отличаются стоимость, момент завершения и видимость результата. Например, классические update mutations связаны с переписыванием затронутых частей. Нельзя оценивать их по ожиданиям от обычного построчного UPDATE другой СУБД.
У Greenplum наличие транзакций также не делает поток одиночных изменений автоматически эффективным. На стоимость влияют распределённая координация и формат хранения. AO с частой перезаписью имеет другой цикл обслуживания, чем большая неизменяемая история.
Большие JOIN и повторяющиеся агрегаты
Если хранилище постоянно соединяет несколько крупных таблиц, нужно понимать их расположение. В Greenplum удачная дистрибуция может сохранить часть JOIN локальными, а неподходящая — вызвать дорогой обмен. План и статистика помогают увидеть этот выбор.
Если основная работа — многократные агрегаты по узкому набору колонок, важны пропуск ненужных данных, проекция, сжатие и организация чтения. Колоночный формат может уменьшить объём чтения. Но выигрыш зависит от фильтров и структуры таблицы; один и тот же SQL на разных физических моделях сравнивает не только движки, но и качество проектирования.
Иногда стоимость переносится из чтения в подготовку данных. Предварительно рассчитанный агрегат ускоряет отчёт, но требует обновления и ограничивает детализацию. Поэтому при сравнении учитывают, сколько работы система выполнила до замера и как поддерживается свежесть результата.
Что включить в проверку
Берут несколько запросов, отражающих будущую нагрузку: большой JOIN, чтение диапазона, агрегацию и типичное изменение. Используют одинаковый логический набор данных и сверяют результаты, включая NULL, дубликаты, типы и временные границы. Совпадение числа строк ещё не доказывает одинаковую семантику.
Далее задают условия: число одновременных работ, требования к свежести, частоту загрузки, состояние кеша и объём возвращаемого результата. Быстрый одиночный запуск не отвечает на вопрос, успеет ли система под дневной конкуренцией. Первый запуск после загрузки также может отличаться от последующих.
Измеряют полный цикл: подготовку и загрузку, чтение, повторный запуск, изменения и обслуживание. Дополнительно учитывают диск, CPU, память, сетевой обмен и работу инженеров по эксплуатации. Без этих условий сравнение «быстрее в несколько раз» нельзя перенести на другую систему.
Решение может быть составным
Операционная база, аналитическое хранилище и быстрая витрина могут быть разными компонентами. Но каждая дополнительная копия требует доставки, контроля свежести и сверки. Разделение оправдано, когда выигрыш конкретной нагрузки покрывает стоимость этой связи.
После модуля у тебя есть основа для обсуждения Greenplum: кто исполняет запрос, как распределены строки, зачем нужен Motion, что отсекают партиции и как формат влияет на чтение и изменения. Эти вопросы позволяют объяснить выбор системы через наблюдаемую работу. Если доступен учебный кластер, закрепи их в практике Greenplum.