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

Private preview in ClickHouse Cloud

TL;DR

• Сравнивали производительность управляемого ClickHouse сервиса Postgres с AWS RDS (16k provisioned IOPS) и Aurora IO Optimized с использованием стандартных тестов pgbench
• Производительность: Postgres на NVMe-хранилище в ClickHouse обеспечивает в 4.3–9 раз более высокую производительность для I/O-интенсивных нагрузок и на 12% выше для CPU-ограниченных сценариев
• Идеально подходит для быстро растущих AI-ориентированных рабочих нагрузок, которым требуются высокие скорости транзакций, доступ к данным с низкой задержкой и предсказуемая производительность без узких мест по I/O

Обзор тестирования производительности

Мы провели всестороннее тестирование производительности с использованием pgbench, стандартного инструмента нагрузочного тестирования PostgreSQL, чтобы оценить производительность при умеренном и высоком уровнях конкурентного доступа.

Тесты производительности

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

Тест 1: IO-интенсивный — чтение+запись (набор данных 500 ГБ)

Рост производительности по сравнению с RDS (16k IOPS):

• TPS выше на 326% (в 4,3 раза быстрее)

Рост производительности по сравнению с Aurora IO Optimized:

• TPS выше на 345% (в 4,5 раза быстрее)

Анализ: Смешанные нагрузки чтение/запись демонстрируют наиболее выраженные преимущества производительности NVMe-хранилища и представляют наиболее реалистичный сценарий для быстро растущих рабочих нагрузок, связанных с AI, которым одновременно необходимы высокопроизводительная ингестия данных и низкая латентность чтения. Postgres, управляемый ClickHouse, достиг 19,8K TPS при более высоком уровне параллелизма, что демонстрирует, как NVMe-хранилище эффективно масштабируется под нагрузкой. Это в 4,3–4,5 раза быстрее, чем RDS и Aurora. Решения с сетевым подключением хранилища испытывали трудности при операциях с интенсивной записью: RDS и Aurora достигали максимум 4,4K–4,6K TPS, несмотря на выделенную пропускную способность и даже при использовании конфигурации Aurora IO Optimized.

Настройка

Этот тест оценивает смешанную производительность чтения и записи с крупным набором данных объёмом 500 ГБ, нагружая как путь чтения, так и путь записи подсистемы хранения данных.

Конфигурация экземпляра:

Конфигурация	Postgres, управляемый ClickHouse	RDS с 16k IOPS	Aurora IO Optimized
PG Version	17	17	17
vCPUs	16	16	16
RAM	64 GB	64 GB	128 GB
Disk Size	1 TB	1 TB	1 TB
Disk Type	NVMe (без ограничений по IOPS)	Сетевой диск (16 000 IOPS)	Сетевой диск (IO Optimized)

Конфигурация теста:

# Initialize database (500 GB dataset)
pgbench -i -s 34247

# Read+Write benchmark
pgbench -c 256 -j 16 -T 600 -M prepared -P 30

Тест 2: IO-нагруженный — только чтение (набор данных 500 ГБ)

Улучшение производительности по сравнению с RDS (16k IOPS):

• TPS выше на 802% (в 9 раз быстрее)

Анализ: Разрыв в производительности резко увеличивается для ориентированных на чтение рабочих нагрузок, ограниченных по IO. PostgreSQL, управляемый ClickHouse, обеспечил 84,8K TPS, тогда как RDS с 16 000 выделенных IOPS достиг только 9,4K TPS, несмотря на эквивалентные вычислительные ресурсы. Ключевое отличие: NVMe-хранилище ClickHouse масштабируется при высокой степени параллелизма, тогда как сетевое хранилище остаётся ограниченным пределами выделенных IOPS. Даже с выделенными IOPS RDS всё равно был в 9 раз медленнее ClickHouse, что демонстрирует критическую важность архитектуры хранилища для IO-нагруженных рабочих нагрузок.

Настройка

В этом тесте оценивается производительность чтения на большом наборе данных объёмом 500 ГБ, который не помещается в память и, таким образом, нагружает подсистему дискового ввода-вывода.

Конфигурация экземпляра:

Конфигурация	Postgres, управляемый ClickHouse	RDS с 16k IOPS
PG Version	17	17
vCPUs	16	16
RAM	64 GB	64 GB
Disk Size	1 TB	1 TB
Disk Type	NVMe (неограниченный IOPS)	Сетевой диск (16 000 IOPS)

Конфигурация теста:

# Initialize database (500 GB dataset)
pgbench -i -s 34247

# Read-only benchmark
pgbench -c 256 -j 16 -T 600 -M prepared -P 30 -S

Тест 3: высокая нагрузка на CPU (данные помещаются в память)

Улучшение производительности:

• TPS на 12,3% выше, чем у RDS PostgreSQL

Анализ: Даже в сценариях, ограниченных производительностью CPU, где дисковый I/O минимален, Postgres, управляемый ClickHouse, показал лучший результат — 36,5K TPS. Несмотря на то, что оба сервиса достигли 100% загрузки CPU, NVMe-хранилище ClickHouse обеспечило более высокую производительность за счёт лучших показателей попаданий в кэш. Преимущество в 12% по сравнению с RDS демонстрирует эффективность базовой инфраструктуры даже тогда, когда нагрузка в основном приходится на CPU.

Настройка

Этот тест оценивает производительность CPU, когда рабочий набор полностью помещается в оперативную память, что минимизирует влияние дисковых операций ввода-вывода.

Конфигурация экземпляра:

Конфигурация	Postgres, управляемый ClickHouse	RDS PostgreSQL
PG Version	17	17
vCPUs	2	2
RAM	8 GB	8 GB
Disk Type	NVMe	Сетевой диск (gp3)

Конфигурация теста:

# Initialize database (2 GB dataset)
pgbench -i -s 136

# Warm-up run to load dataset into memory
pgbench -c 1 -T 60 -S -M prepared

# Run benchmark (read-only, prepared statements)
pgbench -c 32 -j 16 -T 300 -S -M prepared -P 30

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

Основные выводы

Во всех трёх сценариях бенчмарка Postgres, управляемый ClickHouse, стабильно демонстрировал более высокую производительность:

1. IO-интенсивные нагрузки на чтение и запись: TPS в 4,3–4,5 раза выше по сравнению с RDS (16k IOPS) и Aurora IO Optimized
2. IO-интенсивные нагрузки на чтение: TPS в 9 раз выше по сравнению с RDS с 16k IOPS
3. Нагрузки, ограниченные CPU: TPS на 12% выше, чем у RDS

Когда Postgres by ClickHouse особенно эффективен

Postgres by ClickHouse идеально подходит для приложений, которые:

• Обслуживают быстро растущие AI-нагрузки, требующие высокопроизводительной ингестии данных с частыми upsert-операциями, обновлениями feature-признаков в реальном времени и «из коробки» доступной аналитикой за счёт бесшовной интеграции с ClickHouse для OLAP-нагрузок
• Выполняют частые операции записи, обновления или смешанные операции чтения/записи
• Нуждаются в предсказуемом высокопроизводительном хранилище
• В настоящее время ограничены по IOPS на традиционных управляемых сервисах Postgres

Если вы ожидаете потребность в аналитике позже и планируете более глубокую интеграцию с ClickHouse — что типично для современных AI-нагрузок, где транзакционные данные питают дашборды в реальном времени, хранилища признаков (feature store) и ML-конвейеры, — Postgres by ClickHouse должен быть вашим выбором по умолчанию. Нативная интеграция устраняет сложные ETL-конвейеры и обеспечивает бесшовный поток данных между вашей операционной базой и аналитическими запросами.

Преимущество архитектуры NVMe

Преимущество в производительности обусловлено фундаментальным архитектурным отличием:

Аспект	NVMe-хранилище (Managed Postgres)	Сетевое хранилище (Provisioned IOPS)
IOPS	от 100k до практически неограниченного значения	16 000 выделенных
Сетевые переходы	Нет (локальное устройство)	Каждая дисковая операция требует сетевого раунда
Масштабирование производительности	Масштабируется линейно с уровнем параллелизма	Ограничено выделенными IOPS

Для получения дополнительной информации о преимуществах производительности NVMe-хранилища см. NVMe-powered performance.

Рентабельность

Помимо чистой производительности, Postgres, управляемый ClickHouse, обеспечивает превосходное соотношение цена–производительность:

• Более высокая пропускная способность на доллар: Обеспечивает в 4–9 раз больший TPS (транзакций в секунду) по сравнению с RDS с 16k provisioned IOPS и Aurora IO Optimized
• Предсказуемые затраты: Нет необходимости выделять дополнительную ёмкость IOPS — неограниченные локальные IOPS уже включены
• Меньшие требования к вычислительным ресурсам: Целевая производительность достигается на экземплярах меньшего размера благодаря эффективному вводу-выводу (I/O)
• Сниженная потребность в репликах для чтения (read replicas): Более высокая пропускная способность одного экземпляра снижает необходимость горизонтального масштабирования

Для рабочих нагрузок, которые в данный момент ограничены лимитами IOPS, переход на Managed Postgres может устранить необходимость в дорогих provisioned IOPS или конфигурациях, оптимизированных под I/O, обеспечивая при этом значительно более высокую производительность.

Ссылки

Полные данные по бенчмарку, конфигурации и подробные метрики доступны в нашей таблице с результатами бенчмарка.

Дополнительные ресурсы

• PeerDB: сравнение управляемых сервисов Postgres
• Документация pgbench
• Обзор управляемого Postgres
• Масштабирование экземпляра Postgres