Буквально на днях Яндекс открыл доступ для beta-пользователей к своему новому сервису — Яндекс.Облако. Так вышло, что это событие совпало с необходимостью выбора облачной платформы для одного из наших внутренних проектов и я решил сразу протестировать производительность решений Яндекса.
Для теста я взял PostgreSQL и старый добрый pgbench. Выбор на СУБД пал потому что было интересно протестировать и сравнить производительность не только виртуальных машин, то и managed database сервисов.
Disclaimer: автор не является ни профессиональным админом, ни DBA, ни специалистом по настройке облачных решений. Тестирование проводилось сугубо в личных целях и на объективность не претендует, поэтому прошу воспринимать статью «as is». Внутри не будет какого-то глубокого разбора, но будет экспресс-сравнение с Selectel VPC (на разных дисках) и различными конфигурациями AWS EC2/RDS в части производительности и стоимости решений. Возможно, это сэкономит кому-то немного времени.
Подробности Yandex.Cloud vs Selectel VPC vs AWS под катом.
Структура ресурсов Яндекс.Облака обычная для подобного рода сервисов:
Квоты ресурсов (глобальные)
Каталог (проект)
— Compute Cloud (виртуальные машины и диски)
— Managed Databases (кластеры баз данных, можно запускать базы Clickhouse, MongoDB и PostgreSQL)
— Object Storage (облачное хранилище)
— Virtual Private Cloud (облачные сети)
— API
Подробно описывать интерфейс не вижу смысла, тем более, что документация находится в свободном доступе и из неё многое и так понятно.
Для всех виртуальных инстансов в тесте были выделены следующие ресурсы:
vCPU: 8 cores
RAM: 32 Gb
Disk: SSD (конкретный класс — см. тестируемые инстансы).
OS: CentOS 7 minimal
Для managed database-сервисов запрашивалась максимально близкая конфигурация (у Яндекса и AWS как раз есть конфигурации с 8CPU/32RAM).
Тестируемая версия Postgres — 10.5. На виртуалки он ставился из пакета
Все результаты экспресс-теста одной таблицей (графики ниже):
В колонке Price представлена расчётная цена стоимости тестируемого решения в месяц в USD, включая хранилище на 100Gb. Для Amazon RDS, который тарифицируется по часам, стоимость часа умножалась на 720. Цены для расчёта взяты из следующих источников:
— для Yandex Cloud Managed Database
— для Yandex Cloud Compute Instance
— для Selectel VPC Instance
Результаты тестирования в виде графика:
Выводы, в общем-то, достаточно очевидны: universal SSD у Селектела для целей размещения СУБД лучше не брать :)
Ну а если серьёзно, то мне было интересно сравнить в первую очередь Selectel и Yandex. Как оказалось, оба решения идут практически ноздря-в-ноздрю как по производительности, так и по стоимости. Причём стоимость приятно удивила: цены на тестируемые конфигурации оказались вполне доступными.
Использовать аналогичную по параметрам конфигурацию в облаке AWS ожидаемо дороже (хотя я ожидал большей разницы в цене), но вот по производительности угнаться за AWS EC2 не смог ни один из российских провайдеров. Исключение — не понятный мне RDS, которому не помогает даже добавление provisioned IOPS — работает он всё равно медленно, а стоит при этом очень и очень дорого.
Еще пару слов про Яндекс: вообще, появления такого сервиса я ждал от них давно, очевидно было, что это лишь вопрос времени. Пока еще видно, что он сыроват (надеюсь, это относится только к веб-морде, а не к инфраструктуре в целом), потому как внутри ещё много багов и глюков. Пришлось плотно пообщаться с тех. поддержкой, чтобы понять, это баг или это я что-то не понимаю. Но, я уверен, всё это быстро отладят и на российском рынке IaaS появится еще одна достойная альтернатива.
Для теста я взял PostgreSQL и старый добрый pgbench. Выбор на СУБД пал потому что было интересно протестировать и сравнить производительность не только виртуальных машин, то и managed database сервисов.
Disclaimer: автор не является ни профессиональным админом, ни DBA, ни специалистом по настройке облачных решений. Тестирование проводилось сугубо в личных целях и на объективность не претендует, поэтому прошу воспринимать статью «as is». Внутри не будет какого-то глубокого разбора, но будет экспресс-сравнение с Selectel VPC (на разных дисках) и различными конфигурациями AWS EC2/RDS в части производительности и стоимости решений. Возможно, это сэкономит кому-то немного времени.
Подробности Yandex.Cloud vs Selectel VPC vs AWS под катом.
Структура сервисов Яндекс.Облака
Структура ресурсов Яндекс.Облака обычная для подобного рода сервисов:
Квоты ресурсов (глобальные)
Каталог (проект)
— Compute Cloud (виртуальные машины и диски)
— Managed Databases (кластеры баз данных, можно запускать базы Clickhouse, MongoDB и PostgreSQL)
— Object Storage (облачное хранилище)
— Virtual Private Cloud (облачные сети)
— API
Подробно описывать интерфейс не вижу смысла, тем более, что документация находится в свободном доступе и из неё многое и так понятно.
Сравниваемые конфигурации
Для всех виртуальных инстансов в тесте были выделены следующие ресурсы:
vCPU: 8 cores
RAM: 32 Gb
Disk: SSD (конкретный класс — см. тестируемые инстансы).
OS: CentOS 7 minimal
Для managed database-сервисов запрашивалась максимально близкая конфигурация (у Яндекса и AWS как раз есть конфигурации с 8CPU/32RAM).
Тестируемая версия Postgres — 10.5. На виртуалки он ставился из пакета
postgresql10-server, а на managed-кластерах выбиралась эта версия из списка. Методика тестирования
- На чистую ОС устанавливались пакеты
postgresql10-serverиpostgresql10 - Инициализировалась БД для бенчмарка с параметрами:
pgbench -i -s 100 - Три раза прогонялся бенчмарк с параметрами:
pgbench -c 10 -T 60 - Утилита
pgbenchзапускалась на той же виртуальной машине, где установлена СУБД, а для managed-кластеров — на виртуальной машине в том же облаке. - В таблицу результатов заносился лучший результат из трёх.
Результаты тестирования
Все результаты экспресс-теста одной таблицей (графики ниже):
| Resource | TPS | Price |
|---|---|---|
| AWS EC2 m5.2xlarge | 2822 | 343 |
| AWS EC2 m5d.2xlarge | 2752 | 403 |
| AWS EC2 t3.2xlarge | 2636 | 290 |
| AWS EC2 t2.2xlarge | 2259 | 320 |
| AWS EC2 m4.2xlarge | 2187 | 358 |
| Selectel VPC (fast SSD) | 1524 | 186 |
| Yandex Cloud Compute Instance | 1309 | 155 |
| Yandex Cloud Managed Database | 1226 | 234 |
| AWS RDS db.m4.2xlarge (3000 IOPS) | 1200 | 1007 |
| AWS RDS db.t2.2xlarge (3000 IOPS) | 1127 | 862 |
| AWS RDS db.t2.2xlarge (1000 IOPS) | 970 | 625 |
| AWS RDS db.m4.2xlarge (1000 IOPS) | 885 | 769 |
| Selectel VPC (universal SSD) | 247 | 164 |
В колонке Price представлена расчётная цена стоимости тестируемого решения в месяц в USD, включая хранилище на 100Gb. Для Amazon RDS, который тарифицируется по часам, стоимость часа умножалась на 720. Цены для расчёта взяты из следующих источников:
— для Yandex Cloud Managed Database
— для Yandex Cloud Compute Instance
— для Selectel VPC Instance
Результаты тестирования в виде графика:
Выводы
Выводы, в общем-то, достаточно очевидны: universal SSD у Селектела для целей размещения СУБД лучше не брать :)
Ну а если серьёзно, то мне было интересно сравнить в первую очередь Selectel и Yandex. Как оказалось, оба решения идут практически ноздря-в-ноздрю как по производительности, так и по стоимости. Причём стоимость приятно удивила: цены на тестируемые конфигурации оказались вполне доступными.
Использовать аналогичную по параметрам конфигурацию в облаке AWS ожидаемо дороже (хотя я ожидал большей разницы в цене), но вот по производительности угнаться за AWS EC2 не смог ни один из российских провайдеров. Исключение — не понятный мне RDS, которому не помогает даже добавление provisioned IOPS — работает он всё равно медленно, а стоит при этом очень и очень дорого.
Еще пару слов про Яндекс: вообще, появления такого сервиса я ждал от них давно, очевидно было, что это лишь вопрос времени. Пока еще видно, что он сыроват (надеюсь, это относится только к веб-морде, а не к инфраструктуре в целом), потому как внутри ещё много багов и глюков. Пришлось плотно пообщаться с тех. поддержкой, чтобы понять, это баг или это я что-то не понимаю. Но, я уверен, всё это быстро отладят и на российском рынке IaaS появится еще одна достойная альтернатива.
Комментарии (19)
dev1ant
30.10.2018 12:13pgbench -i -s 100
Это ведь ~ 1,5 ГБ данных. При 32 ГБ памяти все данные влезут в кэш.
pgbench -c 10 -T 60
10 соединений для данных ресурсов (8 ядер) явно маловато. По сути получился тест, который гарантированно упрётся в I/O на запись. В таком случае имеет смысл попробовать в Yandex Managed PostgreSQL при создании выбрать local-nvme, они быстрее.
Я бы для данных ресурсов инициализировал со scaling factor 1000. И ещё интересно было бы посмотреть стрельбу, которая в процессор упрётся, вроде такой:
pgbench -j 4 -c 32 -T 60 --select-onlydlukyanov Автор
30.10.2018 13:37В таком случае имеет смысл попробовать в Yandex Managed PostgreSQL при создании выбрать local-nvme, они быстрее.
Да, в первую очередь конечно интересовал диск. Результат Яндекса с 1226 TPS — это именно на диске local-nvme.
И ещё интересно было бы посмотреть стрельбу, которая в процессор упрётся
Отличная мысль, спасибо! Попробую как руки дойдут, дополню.dev1ant
30.10.2018 13:45Я правильно понял, что получилось 1309 TPS на виртуалке с network-nvme и 1226 TPS в managed postgresql с local-nvme?
dlukyanov Автор
30.10.2018 15:14<сообщение удалено>
Прошу прощения! Написал ответ и понял, что на MDB у меня тоже был network-nvme!
dlukyanov Автор
30.10.2018 15:55Вспомнил, почему хотел, но не смог протестировать local-nvme: похоже очередной баг в интерфейсе, не дает возможности запустить кластер с этим диском из-за якобы превышенных квот. Решают этот вопрос с тех. поддержкой, когда решится — протестирую с этим диском.
ybonar
30.10.2018 22:27Простите за рекламу удивили такие низкие показатели у Selectel/Yandex
Ради интереса выполнил тест у себя на площадке Ceph/SSD
postgres@pgbench:/root$ pgbench -c 10 -T 60 starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 100 query mode: simple number of clients: 10 number of threads: 1 duration: 60 s number of transactions actually processed: 147188 latency average = 4.077 ms tps = 2452.820979 (including connections establishing) tps = 2452.964261 (excluding connections establishing)Xop
31.10.2018 01:23на площадке Ceph/SSD
Т.е. данные постгреса лежали на томе RBD? И если не секрет — какой размер кластера и что за сетка между нодами?
ybonar
31.10.2018 09:18Если по SSD 1134GB RAW
Да данные базы лежат на rbd который подключен по infiniband сети стандарт FDR у нас все хранилище на infinibandXop
31.10.2018 12:32Если по SSD 1134GB RAW
Т.е. количество OSD тоже совсем небольшое, порядка 10?
В общем-то вопрос был к тому, что видел много FUDа, что ceph rbd не годится для баз данных, и ceph плохо работает на совсем маленьких кластерах, но ваш пример похоже показывает совершенно обратную картину.
achekalin
Какая-то у вас эскпресс-похвала получилась. И если с AWS опыт есть (т.е. понятно, за что платишь в т.ч. и в исторической перспективе, да и у AWS уже есть понимание, что они могут продавать и как), то с новопоявившимся сервисом период устаканивания ещё впереди.
И это — если с сервисом ничего не случится политически.
Спасибо за данные!
dlukyanov Автор
Вы правы, но AWS не работает в России, а для некоторых проектов это — обязательное требование :(
Что касается похвалы, то не очень понял, о чём вы? Я постарался привести только голые цифры. Наоборот, я указал, что у Яндекса еще полно косяков, пока каждый третий затык решается только через тех. поддержку.
youROCK
Строго говоря, есть еще альтернатива в виде аренды физических серверов и использования какого-нибудь Kubernetes поверх (или вообще по-старинке :)). По деньгам, начиная даже с не очень большого объема, получается не дороже, но намного понятней, производительней, и баги в основном только те, что вы сами допустили при настройке :).
dlukyanov Автор
Да конечно, альтернатив много… Но это уже оффтоп )