Все датасеты, конфигурации и результаты тестирования в данной статье актуализированы по состоянию на 2022 год. Если вам интересно, вы можете воспроизвести тестирование, скачав актуальные наборы данных и следуя последним инструкциям соответствующих проектов/бенчмарков (например, ClickHouse, StarRocks, TPC‑H, SSB). Мы будем признательны за обратную связь: поделитесь, пожалуйста, вашими результатами и замечаниями.

Новый выбор среди колоночных СУБД

С момента появления Hadoop прошло уже более тринадцати лет. Поставщики и участники экосистемы активно вносили вклад, создавая разнообразные open-source плагины и формируя сложные технологические стеки. С одной стороны, это помогло многим пользователям решать прикладные задачи; с другой — из-за высокой сложности стеков и значительных затрат на сопровождение Hadoop постепенно утратил часть рынка. Для пользователей все более актуальной становится высокопроизводительная, простая и масштабируемая СУБД, способная адресовать ключевые бизнес‑потребности. Поэтому все больше внимания привлекают распределенные колоночные базы данных.

Введение в ClickHouse

ClickHouse — колоночная СУБД с открытым исходным кодом, созданная компанией Yandex (крупнейшая поисковая система России). По сравнению с многими коммерческими MPP‑СУБД (например, Vertica, InfiniDB) ClickHouse демонстрирует значительный прирост производительности. Помимо Yandex, все больше компаний внедряют ClickHouse и другие колоночные СУБД. Для типичных аналитических задач со строгой структурой данных и редкими изменениями можно денормализовать связанные таблицы в широкую таблицу и загрузить ее в ClickHouse.

Преимущества ClickHouse по сравнению с традиционными решениями big data:

• Богатые настройки, зависимость только от ZooKeeper.

• Линейная масштабируемость: расширение кластера путем добавления серверов.

• Высокая отказоустойчивость: асинхронная репликация в режиме актив‑актив (multi‑master) между шардами.

• Отличная производительность одиночной таблицы: векторизованные вычисления, поддержка семплирования и приближенных вычислений.

• Богатая функциональность: поддержка множества табличных движков.

Введение в StarRocks

StarRocks — высокопроизводительная корпоративная MPP‑СУБД «для всех сценариев», поддерживающая горизонтальное онлайн‑масштабирование, высокую доступность «финансового уровня», совместимая с протоколом MySQL и его экосистемой. Она предоставляет полностью векторизованный движок и федеративные запросы к различным источникам данных. StarRocks ориентирована на единое решение для всех OLAP‑сценариев и подходит для задач с высокими требованиями к производительности, актуальности, конкурентности и гибкости.

Преимущества StarRocks по сравнению с традиционными решениями big data:

• Не зависит от экосистемы big data; при этом федеративные запросы к внешним таблицам совместимы с big data‑ландшафтом.

• Несколько моделей данных, поддерживающих моделирование по разным измерениям.

• Онлайн‑масштабирование с автоматическим балансом нагрузки.

• Поддержка высококонкурентных аналитических запросов.

• Высокая актуальность: поддержка загрузки данных с задержками уровня секунд.

• Совместимость с протоколом MySQL 5.7 и экосистемой MySQL.

Сравнение функциональности StarRocks и ClickHouse

Обе системы обеспечивают высокую производительность и не зависят от экосистемы Hadoop; нижний уровень шардированного хранения поддерживает высокую доступность с репликацией актив‑актив (multi‑master). Однако в функциональности, производительности и типовых сценариях есть различия.

• ClickHouse лучше подходит для сценариев с широкими таблицами. OLTP‑данные, поступающие через инструменты Change Data Capture (CDC), можно денормализовать во Flink и записывать как широкую таблицу в ClickHouse.

• У StarRocks более сильные возможности join, поэтому она лучше поддерживает звездные и снежинки‑модели, позволяя гибко учитывать изменения данных измерений.

Широкая таблица vs звездная модель

ClickHouse: денормализация в широкую таблицу для избежания join

В OLAP‑сценариях соединения фактовых и измерительных таблиц неизбежны (в отличие от OLTP‑нагрузок, где преобладают point‑запросы). Основное различие между ClickHouse и StarRocks — в обработке join. Хотя ClickHouse поддерживает семантику join, его возможности по объединению больших таблиц ограничены: сложные join часто приводят к OOM. Обычно на этапе ETL фактовые и измерительные таблицы денормализуют в широкую таблицу, чтобы избежать сложных запросов в ClickHouse.

Преимущества широких таблиц:

• Поля подготавливаются в ETL; аналитикам не нужно погружаться в низкоуровневую логику для выполнения анализа.

• Широкие таблицы содержат больше бизнес‑данных, что делает модель более наглядной.

• Эквивалентность запросу к одной таблице: нет межтабличных соединений, выше производительность.

Ограничения широких таблиц:

• Возможна избыточность и логические ошибки при связях «один‑ко‑многим» во время join на этапе построения широкой таблицы.

• Сложность сопровождения структуры: при изменениях данных измерений широкую таблицу приходится перестраивать.

• Широкие таблицы проектируются под известные сценарии и могут не покрывать внезапные/ад‑hoc запросы.

StarRocks: звездная/снежинки‑модель для гибкой поддержки изменений измерений

Денормализация ускоряет запросы, но уменьшает гибкость. В сценариях с высокими требованиями к гибкости (например, частые изменения статусов заказов или самообслуживаемая BI‑аналитика) широкая таблица часто не подходит. В таких случаях лучше применять звездную или снежинки‑модель. Совместимость со звездной/снежинки‑моделью у StarRocks заметно лучше, чем у ClickHouse.

В StarRocks доступны три типа join:

• «broadcast join» (широковещательный): при соединении «маленькая таблица + большая таблица» маленькая таблица рассылается в память всех узлов.

• «shuffle join»: при соединении «большая + большая» строки с одинаковыми ключами перераспределяются на одни и те же узлы.

• «colocation join»: чтобы избежать сетевых и I/O‑накладных расходов shuffle, при создании таблиц данные, требующие соединения, можно хранить в одной группе со‑локализации (colocation group) и выполнять join локально.

CREATE TABLE tbl (k1 int, v1 int sum)
DISTRIBUTED BY HASH(k1)
BUCKETS 8
PROPERTIES(
    "colocate_with" = "group1"
);

Большинство MPP‑движков используют оптимизатор на правилах — rule‑based optimizer (RBO). Чтобы лучше выбирать тип join, StarRocks предоставляет оптимизатор на стоимости — cost‑based optimizer (CBO). Пользователям при разработке SQL‑запросов не нужно задаваться порядком ведущей/ведомой таблиц и типом join: CBO, опираясь на собранные статистики (метрики), переписывает запрос и оптимизирует порядок и тип соединений автоматически.

Поддержка высокой конкурентности

Конкурентность в ClickHouse

Чтобы глубже извлекать ценность данных, компании подключают больше аналитиков, исследующих данные с разных сторон. Это повышает требования к QPS (число запросов в секунду). В интернет‑ и финансовых компаниях десятки, а то и сотни тысяч сотрудников — не редкость; на пиках одновременная нагрузка может достигать нескольких тысяч запросов.

Традиционные MPP‑СУБД задействуют все узлы при вычислениях, поэтому конкурентность всего кластера близка к конкурентности одного узла. Формально увеличить конкурентность можно ростом числа реплик, но это повышает нагрузку RPC, резко влияя на производительность и стоимость.

В ClickHouse в целом не рекомендуют высококонкурентные аналитические запросы; для кластера с тремя репликами QPS обычно держат ниже 100. Даже один тяжелый запрос может потреблять до половины CPU сервера. Эффективных «штатных» способов резко повысить конкурентность нет; часто используют обходной путь — материализуют результаты в MySQL, повышая конкурентность на уровне этой системы.

Конкурентность в StarRocks

По сравнению с ClickHouse, StarRocks обслуживает тысячи одновременных аналитических запросов, а в ряде сценариев — до десятков тысяч. На уровне хранения StarRocks применяет стратегию «сначала партиционирование, затем бакетирование», повышающую локальность доступа; префиксные индексы позволяют быстро фильтровать и искать данные, снижая I/O и повышая производительность.

Рекомендации:

• При проектировании следует выбирать партиционирование и бакетирование так, чтобы они покрывали типовые запросы — это максимизирует эффект отсечения и минимизирует объем сканирования.

• StarRocks поддерживает предагрегацию в стиле MOLAP. Для сложных аналитических запросов целесообразно использовать материализованные представления (materialized views) для предварительной агрегации: базовая таблица с десятками миллиардов строк может превратиться в сотни/тысячи строк за счет RollUp, что резко снизит задержку и повысит конкурентность.

Высокочастотные изменения данных

Обновление данных в ClickHouse

В OLAP‑СУБД изменяемые данные (mutable data) обычно нежелательны; ClickHouse не исключение. Ранние версии не поддерживали UPDATE/DELETE. Начиная с 1.15, появились операции MUTATION (через ALTER TABLE) для обновления/удаления — это «тяжелые», асинхронные операции, подходящие для нечастых пакетных изменений и отличающиеся от стандартных SQL‑UPDATE/DELETE.

Кроме того, обновления/удаления можно реализовать через CollapsingMergeTree, VersionedCollapsingMergeTree и ReplacingMergeTree, адаптируя схему под бизнес: новые записи вставляются через INSERT и «компенсируют» или «заменяют» старые. Компенсация/замена происходит во время фонового Merge; до Merge новые и старые записи сосуществуют.

Под разные сценарии ClickHouse предлагает разные подходы.

Офлайн‑нагрузка:

• Инкрементальная синхронизация: движок ReplacingMergeTree; Spark синхронизирует данные в Hive, далее Spark потребляет инкремент из Hive и пишет в ClickHouse. Нагрузка на нижний контур невелика, но желательно, чтобы данные измерений почти не менялись.

• Полная синхронизация: движок MergeTree; Spark периодически загружает данные в Hive, в ClickHouse выполняется truncate таблицы, после чего Spark загружает данные за последние дни. Нагрузка выше, но не нужно учитывать изменения измерений.

Реалтайм‑нагрузка:

• VersionedCollapsingMergeTree: Spark единоразово загружает накопленные данные, затем инкремент поступает из Kafka (или другой очереди сообщений — MQ). Необходимо обеспечить семантику exactly‑once; на стыке офлайна/онлайна возможны случаи несхлопывания.

• ReplacingMergeTree вместо VersionedCollapsingMergeTree: упрощает конвейер и устраняет аномалии на стыке офлайна/онлайна, однако не гарантирует отсутствие дублей.

Обновление данных в StarRocks

В StarRocks операции обновления проще. Система предоставляет несколько моделей, покрывающих потребности в детальном хранении, агрегации и обновлениях. Модель обновлений поддерживает UPDATE/DELETE по первичному ключу; благодаря оптимизациям хранения и индексации обеспечиваются эффективные запросы при параллельных обновлениях. В e‑commerce‑сценариях со сверхчастыми изменениями статусов заказов (до сотен миллионов обновлений в день) это критично.

Модели данных в StarRocks:

До версии 1.19 обновления по ключу выполнялись через модель Unique (Merge‑on‑Read): каждому батчу присваивается версия; для одного PK могут существовать несколько версий, а при запросе выполняется merge с выбором записи последней версии. Начиная с 1.19 появилась модель Primary Key, поддерживающая UPDATE/DELETE по PK и лучше соответствующая реалтайм‑сценариям частых обновлений. По сравнению с Merge‑on‑Read (Unique) стратегия delete‑and‑insert в PK‑модели обеспечивает примерно трехкратный прирост производительности. Для сценариев CDC‑репликации из фронтовой OLTP‑БД в StarRocks рекомендуется модель Primary Key.

Обслуживание кластера

По сравнению с одиночными СУБД, любая распределенная система требует кратно больших усилий на сопровождение. Большее число узлов увеличивает вероятность отказов — необходима продуманная автоматическая схема failover. По мере роста данных система должна поддерживать онлайн‑масштабирование (расширение/сокращение) с сохранением стабильности и доступности.

ClickHouse: расширение узлов и перераспределение данных

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

Типовые подходы при добавлении узлов:

• Установить TTL на таблицы (если бизнес‑правила позволяют): старые данные будут постепенно очищаться, новые — распределяться и на новые узлы; в итоге нагрузка выровняется.

• Создать временную таблицу, скопировать в нее данные из исходной, затем удалить исходную. При больших объемах/числе таблиц это дорого и не подходит для реалтайм‑изменений.

• Настроить веса (weights), направляя новые записи на новые узлы. Поддержка весов трудоемка.

С точки зрения времени, ресурсов и актуальности ClickHouse не слишком подходит для онлайн‑расширения/сокращения и перераспределения данных. Поскольку система не обнаруживает изменения топологии, логику перераспределения часто приходится закладывать во внешний CMDB. Желательно заранее оценивать объемы данных и требуемое число узлов.

StarRocks: онлайн‑масштабирование

Как и HDFS, кластер StarRocks при изменении топологии поддерживает онлайн‑масштабирование, минимизируя влияние на бизнес. Данные хранятся по схеме «партиционирование → бакетирование». После бакетирования по ключу выполняется hash, и строки с одинаковым результатом попадают в один фрагмент — tablet (фрагмент данных). Tablet — минимальная единица избыточности; обычно хранятся три реплики, репликация между узлами идет по протоколу кворума (Quorum).

При падении узла недостающие tablet автоматически восстанавливаются на других доступных узлах (прозрачный failover). При добавлении узлов Frontend (FE) автоматически планирует и мигрирует tablet на новые узлы, обеспечивая балансировку. Чтобы снизить влияние миграции на производительность, рекомендуется выполнять масштабирование в периоды низкой нагрузки или динамически настраивать параметры планировщика, контролируя скорость миграции.

Сравнение производительности ClickHouse и StarRocks

Тест производительности SSB на одной таблице

Поскольку возможности join в ClickHouse ограничены и не позволяют корректно выполнить TPC‑H, здесь используется SSB (Scale‑Sail Benchmark) 100G на одной таблице.

Тестовая среда (3 узла, Alibaba Cloud):

• CPU: 64 ядра Intel® Xeon® Platinum 8269CY @ 2.5 ГГц, кэш: 36 608 КБ

• Память: 128 ГБ

• Сеть: 100 Гбит/с

• Диск: SSD облачные диски повышенной производительности

• Версия ClickHouse: 21.9.5.16-2.x86_64 (18‑Oct‑2021)

• Версия StarRocks: 1.19.2

Тестовые данные:

Результаты:

• В 9 из 14 запросов StarRocks превосходит ClickHouse по производительности.

  	ClickHouse	StarRocks
  Q1.1	1.022	0.37
  Q1.2	0.105	0.05
  Q2.1	4.107	3.51
  Q2.2	3.421	3.06
  Q2.3	3.175	2.28
  Q3.1	5.196	3.86
  Q3.2	2.159	2.88
  Q3.3	1.61	1.95
  Q3.4	0.036	0.05
  Q4.1	6.304	4.75
  Q4.2	1.761	1.43
  Q4.3	0.969	0.98
  Q5.1	1.107	0.45
  Q5.2	2.499	1.86
  Q5.3	5.009	2.44

Тест производительности TPC-H на нескольких таблицах

ClickHouse менее пригоден для многотабличных join в рамках данного теста; многие запросы TPC‑H либо не исполняются, либо приводят к OOM. Ниже — результаты тестирования StarRocks для TPC‑H.

Тестовая среда (3 узла, Alibaba Cloud):

• CPU: 64 ядра Intel® Xeon® Platinum 8269CY @ 2.5 ГГц, кэш: 36 608 КБ

• Память: 128 ГБ

• Сеть: 100 Гбит/с

• Диск: SSD облачные диски повышенной производительности

• Версия ClickHouse: 21.9.5.16-2.x86_64 (18‑Oct‑2021)

• Версия StarRocks: 1.19.2

Датасет: TPC‑H 100G.

Результаты:

Тест производительности загрузки

И ClickHouse, и StarRocks поддерживают полную загрузку через DataX, а инкремент — через инструменты Change Data Capture (CDC) в очередь сообщений (MQ) с последующим потреблением в целевой СУБД.

Датасет:

• ClickHouse Native Format: один xz‑архив ≈ 85 ГБ; после распаковки — 1,4 ТБ, 3,1 млрд строк, CSV.

Способы загрузки.

ClickHouse: внешняя таблица HDFS. В распределенной таблице в качестве Sharding Key можно выбрать только один столбец integer; по наблюдениям кардинальность ключей низкая, поэтому используется распределение через rand().

CREATE TABLE github_events_all AS github_events_local
ENGINE = Distributed(
    perftest_3shards_1replicas,
    github,
    github_events_local,
    rand()
);

Определение внешней таблицы HDFS:

CREATE TABLE github_events_hdfs
(
    file_time DateTime,
    event_type Enum('CommitCommentEvent' = 1, 'CreateEvent' = 2, 'DeleteEvent' = 3, 'ForkEvent' = 4,
                    'GollumEvent' = 5, 'IssueCommentEvent' = 6, 'IssuesEvent' = 7, 'MemberEvent' = 8,
                    'PublicEvent' = 9, 'PullRequestEvent' = 10, 'PullRequestReviewCommentEvent' = 11,
                    'PushEvent' = 12, 'ReleaseEvent' = 13, 'SponsorshipEvent' = 14, 'WatchEvent' = 15,
                    'GistEvent' = 16, 'FollowEvent' = 17, 'DownloadEvent' = 18, 'PullRequestReviewEvent' = 19,
                    'ForkApplyEvent' = 20, 'Event' = 21, 'TeamAddEvent' = 22),
    actor_login LowCardinality(String),
    repo_name LowCardinality(String),
    created_at DateTime,
    updated_at DateTime,
    action Enum('none' = 0, 'created' = 1, 'added' = 2, 'edited' = 3, 'deleted' = 4, 'opened' = 5, 'closed' = 6, 'reopened' = 7, 'assigned' = 8, 'unassigned' = 9,
                'labeled' = 10, 'unlabeled' = 11, 'review_requested' = 12, 'review_request_removed' = 13, 'synchronize' = 14, 'started' = 15, 'published' = 16, 'update' = 17, 'create' = 18, 'fork' = 19, 'merged' = 20),
    comment_id UInt64,
    body String,
    path String,
    position Int32,
    line Int32,
    ref LowCardinality(String),
    ref_type Enum('none' = 0, 'branch' = 1, 'tag' = 2, 'repository' = 3, 'unknown' = 4),
    creator_user_login LowCardinality(String),
    number UInt32,
    title String,
    labels Array(LowCardinality(String)),
    state Enum('none' = 0, 'open' = 1, 'closed' = 2),
    locked UInt8,
    assignee LowCardinality(String),
    assignees Array(LowCardinality(String)),
    comments UInt32,
    author_association Enum('NONE' = 0, 'CONTRIBUTOR' = 1, 'OWNER' = 2, 'COLLABORATOR' = 3, 'MEMBER' = 4, 'MANNEQUIN' = 5),
    closed_at DateTime,
    merged_at DateTime,
    merge_commit_sha String,
    requested_reviewers Array(LowCardinality(String)),
    requested_teams Array(LowCardinality(String)),
    head_ref LowCardinality(String),
    head_sha String,
    base_ref LowCardinality(String),
    base_sha String,
    merged UInt8,
    mergeable UInt8,
    rebaseable UInt8,
    mergeable_state Enum('unknown' = 0, 'dirty' = 1, 'clean' = 2, 'unstable' = 3, 'draft' = 4),
    merged_by LowCardinality(String),
    review_comments UInt32,
    maintainer_can_modify UInt8,
    commits UInt32,
    additions UInt32,
    deletions UInt32,
    changed_files UInt32,
    diff_hunk String,
    original_position UInt32,
    commit_id String,
    original_commit_id String,
    push_size UInt32,
    push_distinct_size UInt32,
    member_login LowCardinality(String),
    release_tag_name String,
    release_name String,
    review_state Enum('none' = 0, 'approved' = 1, 'changes_requested' = 2, 'commented' = 3, 'dismissed' = 4, 'pending' = 5)
)
ENGINE = HDFS('hdfs://XXXXXXXXXX:9000/user/stephen/data/github-02/*', 'TSV');

StarRocks: режим Broker Load.

LOAD LABEL github.xxzddszxxzz (
    DATA INFILE("hdfs://XXXXXXXXXX:9000/user/stephen/data/github/*")
    INTO TABLE `github_events`
    (event_type,repo_name,created_at,file_time,actor_login,updated_at,action,comment_id,body,path,position,line,ref,ref_type,creator_user_login,number,title,labels,state,locked,assignee,assignees,comments,author_association,closed_at,merged_at,merge_commit_sha,requested_reviewers,requested_teams,head_ref,head_sha,base_ref,base_sha,merged,mergeable,rebaseable,mergeable_state,merged_by,review_comments,maintainer_can_modify,commits,additions,deletions,changed_files,diff_hunk,original_position,commit_id,original_commit_id,push_size,push_distinct_size,member_login,release_tag_name,release_name,review_state)
)
WITH BROKER oss_broker1 ("username"="user", "password"="password")
PROPERTIES
(
    "max_filter_ratio" = "0.1"
);

Результаты:

• При загрузке датасета GitHub производительность загрузки StarRocks и ClickHouse сопоставима.

Выводы

ClickHouse и StarRocks — современные реляционные OLAP‑СУБД с высокой производительностью и независимостью от экосистемы Hadoop. По результатам данного сравнения, в ряде сценариев StarRocks демонстрирует преимущество. В общем случае:

• ClickHouse оптимален для сценариев с широкой таблицей и редкими изменениями измерений.

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