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

​
Обзор бенчмарка

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

​
Бенчмарки

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

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

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

​
Настройка

Этот тест оценивает производительность при смешанной нагрузке чтения и записи на большом наборе данных объёмом 500 ГБ, нагружая как чтение, так и запись в подсистеме хранения. Конфигурация инстансов:
КонфигурацияPostgres, управляемый ClickHouseRDS с 16k IOPSAurora IO Optimized
Версия PG171717
vCPU161616
Оперативная память64 ГБ64 ГБ128 ГБ
Размер диска1 ТБ1 ТБ1 ТБ
Тип дискаNVMe (неограниченные IOPS)Сетевое хранилище (16 000 IOPS)Сетевое хранилище (IO Optimized)
Конфигурация теста: 
# Инициализация базы данных (набор данных 500 ГБ)
pgbench -i -s 34247

# Бенчмарк чтения и записи
pgbench -c 256 -j 16 -T 600 -M prepared -P 30

​
Тест 2: Интенсивный IO — только для чтения (набор данных 500 ГБ)

Повышение производительности по сравнению с RDS (16k IOPS):
  • TPS на 802% выше (в 9,0 раза быстрее)
Анализ: Для рабочих нагрузок с интенсивным чтением, ограниченных производительностью IO, разрыв в производительности резко увеличивается. Postgres, управляемый ClickHouse, обеспечил 84,8 тыс. TPS, тогда как RDS с 16 000 выделенными IOPS достиг лишь 9,4 тыс. TPS, несмотря на сопоставимые вычислительные ресурсы. Ключевое различие в том, что NVMe-хранилище ClickHouse масштабируется при более высоком параллелизме, тогда как сетевое хранилище по-прежнему ограничено лимитами выделенного IOPS. Даже с выделенным IOPS RDS все равно оказался в 9 раз медленнее ClickHouse, что наглядно показывает критическую важность архитектуры хранилища для рабочих нагрузок с интенсивным IO.

​
Настройка

Этот тест оценивает производительность чтения на большом наборе данных объёмом 500 ГБ, который не помещается в оперативной памяти, и создаёт высокую нагрузку на дисковый ввод-вывод. Конфигурация экземпляра:
КонфигурацияPostgres, управляемый ClickHouseRDS с 16k IOPS
Версия PG1717
vCPU1616
Оперативная память64 GB64 GB
Размер диска1 TB1 TB
Тип дискаNVMe (неограниченные IOPS)Сетевое хранилище (16,000 IOPS)
Конфигурация теста: 
# Инициализация базы данных (набор данных 500 ГБ)
pgbench -i -s 34247

# Бенчмарк только для чтения
pgbench -c 256 -j 16 -T 600 -M prepared -P 30 -S

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

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

​
Конфигурация

Этот тест оценивает производительность процессора, когда рабочий набор данных полностью помещается в оперативной памяти, что сводит к минимуму влияние дискового ввода-вывода. Конфигурация экземпляра:
КонфигурацияPostgres, управляемый ClickHouseRDS PostgreSQL
Версия PG1717
vCPU22
Оперативная память8 GB8 GB
Тип дискаNVMeсетевое хранилище (gp3)
Конфигурация теста: 
# Инициализация базы данных (набор данных 2 ГБ)
pgbench -i -s 136

# Прогревочный запуск для загрузки набора данных в память
pgbench -c 1 -T 60 -S -M prepared

# Запуск бенчмарка (только для чтения, подготовленные операторы)
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 идеально подходит для приложений, которые:
  • Обеспечивают работу быстрорастущих ИИ-нагрузок, где требуются высокая пропускная способность при ингестии данных, частые upsert-операции, обновление признаков в реальном времени и готовая аналитика благодаря бесшовной интеграции с ClickHouse для OLAP-нагрузок
  • Выполняют частые записи, обновления или смешанные операции чтения и записи
  • Требуют предсказуемого высокопроизводительного хранилища
  • В настоящее время упираются в ограничения IOPS у традиционных управляемых сервисов Postgres
Если вы предполагаете, что аналитика понадобится позже и ожидаете более глубокой интеграции с ClickHouse — что типично для современных ИИ-нагрузок, где транзакционные данные используются для панелей мониторинга в реальном времени, хранилищ признаков и ML-конвейеров, — Postgres by ClickHouse должен быть вашим выбором по умолчанию. Нативная интеграция избавляет от сложных ETL-конвейеров и обеспечивает бесшовный поток данных между вашей операционной базой данных и аналитическими запросами.

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

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

​
Экономическая эффективность

Помимо высокой производительности, Postgres, управляемый ClickHouse, предлагает более выгодное соотношение цены и производительности:
  • Более высокая пропускная способность на доллар: достигайте в 4–9 раз больше TPS по сравнению с RDS с 16k выделенным IOPS и Aurora IO Optimized
  • Предсказуемые затраты: не нужно выделять дополнительную емкость IOPS — неограниченный локальный IOPS уже включен
  • Меньшие требования к вычислительным ресурсам: достигайте целевой производительности на инстансах меньшего размера благодаря эффективному I/O
  • Меньшая потребность в репликах для чтения: более высокая пропускная способность одного инстанса снижает необходимость в горизонтальном масштабировании
Для рабочих нагрузок, которые сейчас упираются в ограничения по IOPS, переход на Managed Postgres может избавить от необходимости использовать дорогой выделенный IOPS или конфигурации IO Optimized, одновременно обеспечивая существенно более высокую производительность.

​
Ссылки

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

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

Последнее изменение 10 июня 2026 г.