Прирост производительности управляемых сервисов по работе с данными Yandex Cloud

В августе — октябре 2025 года мы прогнали серию синтетических тестов на двух платформах: standard‑v3 и standard‑v4a. Проверили:

• Yandex Managed Service for PostgreSQL,
• Yandex Managed Service for MySQL^®,
• Yandex Managed Service for Valkey^™,
• Yandex StoreDoc,
• Yandex Managed Service for OpenSearch,
• Yandex Managed Service for ClickHouse^®.

Для нагрузочного тестирования использовали HammerDB, memtier_benchmark, YCSB и OpenSearch Benchmark.

Мы стремились к «стандартной» методике и воспроизводимости. Для этого фиксировали размеры кластеров, зоны доступности и длительность прогона. Результаты оценивали по набору метрик.

В статье расскажем, какие приросты показала платформа standard‑v4a на OLTP‑нагрузках. Разберём, чем отличаются платформы на Valkey^™ в сценариях с низкой конвейеризацией и при пакетной записи, покажем, как изменились хвостовые задержки в StoreDoc и OpenSearch. В конце поделимся выводами для проектирования.

Как тестировали платформы

Мы использовали стандартные профили и открытые инструменты:

• Для PostgreSQL и MySQL^® — нагрузку типа TPC‑C в HammerDB. Это стандартный тест для эмуляции OLTP‑паттернов, то есть сценариев обработки транзакций. Тест включал две минуты на «разогрев» и пять минут основного прогона. Мы настраивали параметры VU (число параллельных виртуальных пользователей) и warehouse (количество «складов» в базе данных).
• Для Valkey — инструмент memtier_benchmark. Мы тестировали на датасете из 1 млн ключей размером 1 КиБ. Использовали разные профили: read‑heavy, write‑only и RMW. Тесты проводились с разной глубиной пайплайна — 1, 8, 16 и 32.
• Для StoreDoc — YCSB, открытый бенчмарк для NoSQL‑систем. Мы использовали 1 млн записей (recordcount) и 5 миллионов операций (operationcount) в разных сценариях (workloads A/B/F). Тесты запускали с разным числом потоков: 32, 48, 96 и 128. Измеряли пропускную способность (throughput) и перцентили задержки p95 и p99.
• Для OpenSearch — OpenSearch Benchmark. Тесты проводили на большом наборе данных http_logs, который содержит почти 250 млн документов. Мы использовали два сценария для оценки индексирования, когда производительность упирается в CPU: index‑append и append‑no‑conflicts‑index‑reindex‑only.

Важный технический нюанс: подключение HammerDB к MySQL выполняли по TLS с шифром TLS_AES_128_GCM_SHA256. Все финальные замеры проводили с параметром autocommit=ON.

Конфигурации, которые мы использовали для каждого сервиса

Стоит отметить важную деталь. В высокодоступной топологии, когда мастер находится в зоне D, а реплика в зоне A, разница в производительности CPU на коротких OLTP‑прогонах почти незаметна. Это происходит потому, что задержки на репликацию и передачу данных по межзонной сети «маскируют» реальные ограничения процессора.

Чтобы получить чистое сравнение производительности Compute, мы проводили дополнительные тесты. Для этого использовали одноузловые стенды или размещали мастер в той же зоне (D), где находился генератор нагрузки.

Ещё один нюанс касается выбора параметра warehouse в TPC‑C. Профиль с одним warehouse создаёт высокую нагрузку на одни и те же данные. Это провоцирует локальные конфликты, в основном блокировки строк. Профиль с сотней warehouses, напротив, распределяет нагрузку, что снижает «борьбу» за одни и те же ресурсы. Такой профиль позволяет лучше оценить «чистую» производительность CPU. Мы приводим оба результата, чтобы можно было сопоставить разные транзакционные паттерны с нашими стендами.

Yandex Managed Service for PostgreSQL

В сервисе на профиле с одним warehouse платформа standard‑v4a стабильно превосходит standard‑v3.

При нагрузке в 20 VU standard‑v4a показала 54 753 NOPM и 130 232 TPM. На той же нагрузке standard‑v3 — 25 210 NOPM и 62 049 TPM. При росте нагрузки до 40 VU значения составили 55 357 и 131 784 у standard‑v4a против 37 318 и 89 984 у standard‑v3.

Интересно посмотреть и на хвостовые задержки — метрики p95 и p99. В этом профиле HammerDB доминирует процедура PAYMENT, которая занимает более 80% времени всего прогона. Её 99‑й перцентиль — достигающий 1300–1400 мс — определяет общие «хвосты» при росте числа виртуальных пользователей. На standard‑v4a эти «хвосты» оказались сопоставимы или ниже, чем на standard‑v3, но при более высокой пропускной способности.

Всё это говорит о том, что у standard‑v4a есть хороший запас для масштабирования. Платформа обеспечивает более предсказуемые задержки при росте параллелизма нагрузки.

Yandex Managed Service for MySQL^®

В сервисе на профиле с сотней warehouses прирост на standard‑v4a заметен во всём диапазоне параллельности:

• При 30 VU standard‑v4a выдаёт 13 620 NOPM и 31 676 TPM.
• Для standard‑v3 эти показатели — 6301 NOPM и 14 764 TPM.

При 50 VU разрыв сохраняется: 18 635 NOPM и 43 356 TPM у standard‑v4a против 10 773 NOPM и 25 154 TPM у standard‑v3.

Интересно, что на тесте с 30 VU MySQL на standard‑v4a активнее загружал vCPU: ≈38% против ≈28% на standard‑v3. Но, несмотря на это, средняя задержка была заметно ниже — 60 мс против ≈140 мс.

Yandex Managed Service for Valkey^™

В этом сервисе платформы ведут себя по‑разному. Производительность зависит от глубины пайплайна и типа операций, особенно на малых конфигурациях с 4 vCPU.

Результаты тестов Valkey на standard‑v3 и standard‑v4a

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

Таким образом, для Valkey выводы зависят от сценария. Для кеширования с одиночными GET‑запросами на малых узлах (4 vCPU) standard‑v3 показывает лучшую производительность. В то же время standard‑v4a демонстрирует преимущество при пакетной записи и работе с атомарными счётчиками. На конфигурациях с 16 vCPU обе платформы показывают паритет, с небольшими отклонениями по хвостовым задержкам.

Далее рассмотрим, как платформы повели себя в документном хранилище StoreDoc на профилях YCSB.

Yandex StoreDoc

На сценариях YCSB A, B и F standard‑v4a показала прирост пропускной способности на 30–40%.

Также мы зафиксировали снижение хвостовых задержек (p95) как при чтении, так и при обновлении.

Например, в сценарии A прирост операций в секунду составил 36–43% в диапазоне 32–128 потоков. При этом задержка p95 при чтении снизилась на ≈6–28%.

В сценарии F прирост достиг ≈36–43% при заметном снижении задержек p95.

Это подтверждает, что standard‑v4a лучше масштабируется при росте параллелизма. Прирост виден и в смешанных RMW‑сценариях (чтение‑изменение‑запись), и в профилях с высокой долей чтения.

Теперь посмотрим на OpenSearch, где мы сделали основной акцент на индексировании.

Yandex Managed Service for OpenSearch

В этом сервисе мы использовали набор данных http_logs, состоящий почти из 250 млн документов. Сценарий index‑append (добавление в индекс) оказался тем тестом, где производительность упиралась в CPU. Это позволило нам чётко увидеть разницу между платформами:

• Один узел, только индексация (index‑only): standard‑v4a показал пропускную способность выше на ≈73% (141 тыс. против 82 тыс. docs/sec). Хвостовая задержка p99 была ниже на ≈39% (615 мс против 1011 мс). Медианная задержка на standard‑v4a составила 262 мс против 451 мс на standard‑v3.
• Три узла, только индексация (index‑only): средняя пропускная способность на standard‑v4a была выше на ≈44% (254 644 против 176 987 docs/sec). Задержка p99 — ниже на ≈35% (320 мс против 490,6 мс).
• Три узла, полный тест: прирост пропускной способности составил ≈65% (267 тыс. против 162 тыс. docs/sec). Задержка p99 оказалась ниже на ≈34% (305 мс против 462 мс).

Вывод стабильный: при длительном индексировании узлы на standard‑v4a поддерживают более высокий и ровный темп записи. При этом они демонстрируют меньшие хвостовые задержки.

Yandex Managed Service for ClickHouse^®

Для первого теста использовали Star Schema Benchmark (SSB) — специализированный бенчмарк для тестирования производительности аналитических СУБД (OLAP) и хранилищ данных.

Конфигурации ClickHouse^®

Данные сгенерировали с помощью инструмента dbgen с коэффициентом масштабирования 100 — это 60 млн строк.

Создали пять таблиц:

• customer,
• lineorder,
• part,
• supplier,
• date.

Запросы генерировали с помощью команды ./qgen -s 100. Шаблоны запросов брали из инструкции, включая запросы с Q1.1 до Q4.3.

Наиболее показательный запрос вида:

`SELECT`
`C_NATION,`
`S_NATION,`
`D_YEAR,`
`sum(LO_REVENUE) AS REVENUE`
`FROM`
`customer,`
`lineorder,`
`supplier,`
`date`
`WHERE`
`LO_CUSTKEY = C_CUSTKEY`
`AND LO_SUPPKEY = S_SUPPKEY`
`AND LO_ORDERDATE = D_DATEKEY`
`AND C_REGION = 'ASIA' AND S_REGION = 'ASIA'`
`AND D_YEAR >= 1992 AND D_YEAR <= 1997`
`GROUP BY`
`C_NATION,`
`S_NATION,`
`D_YEAR`
`ORDER BY`
`D_YEAR ASC,`
`REVENUE DESC;`

Этот SSB‑запрос (семейство Q3.x) считает годовую выручку от заказов между странами внутри региона Азия. В нём присутствуют все пять созданных таблиц, среди которых происходит фильтрация, агрегация и сортировка данных.

Во время выполнения теста загрузка CPU составила порядка 90–95% на протяжении всего времени выполнения, загрузка RAM — 60–70%.

Время выполения запроса:

• на кластере с standard‑v4a — 59,995 секунд,
• на кластере с standard‑v3 — 212,244 секунд.

Для второго теста использовали ClickBench — открытый бенчмарк для тестирования производительности аналитических СУБД (OLAP) на реальных запросах.

Конфигурации ClickHouse

Тестирование проводили по методике из официального репозитория ClickHouse. Создали таблицу hits с данными, загрузили данные из набора файлов Parquet и вставили их в таблицу hits.

Скрипт (run.sh) инициирует запросы из файла queries.sql. Он исполняет каждый запрос несколько раз и печатает массив из времени выполнения в секундах (или null при ошибке) — по одной строке на запрос. Размер таблицы: 14 497 374 306 байт.

По результатам запросов суммарное среднее время по всем тестам составляет:

• standard‑v4a — 219,0046667 секунды,
• standard‑v3 — 312,4466667 секунды.

Разница между значениями составляет 35% — это говорит о более быстрой обработке запросов на standard‑v4a.

Практические выводы

Платформа standard‑v4a показывает стабильный рост пропускной способности и снижение задержек в управляемых реляционных и NoSQL‑сервисах, а также при индексировании в OpenSearch. Для in‑memory‑кеша (Valkey) выбор зависит от профиля нагрузки. При операциях одиночного чтения (GET) на небольших узлах (4 vCPU) преимущество остаётся у standard‑v3. Для пакетных записей и атомарных операций лучше подходит standard‑v4a. На узлах с 16 vCPU производительность платформ практически одинакова.

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