Какую СУБД выбрать для бизнеса: независимое тестирование производительности PostgreSQL и YDB СУБД Яндекса

Почему классический PostgreSQL не закрывает все потребности бизнеса

Анализ технических характеристик показывает, что главный вопрос эксплуатации «ванильного» PostgreSQL — это ограниченные возможности масштабирования вычислительных ресурсов. Вертикальное масштабирование PostgreSQL сильно ограничено, а горизонтальное масштабирование невозможно при сохранении ACID-гарантий на любые транзакции внутри базы. В 2017 году исследователи Питер Бейлис и Тодд Варшавски из Стэнфордского университета представили весьма примечательную работу под названием «ACIDRain: Concurrency-Related Attacks on Database-Backed Web Applications». В рамках исследования они изучили 12 широко используемых платформ электронной торговли, разработанных на четырёх различных языках программирования и функционирующих на свыше 2 миллионах веб-ресурсов. В результате анализа было обнаружено и подтверждено существование 22 критических уязвимостей типа ACIDRain, которые дают возможность злоумышленникам обходить ограничения подарочных карт и похищать товары. Как отмечается в публикации, пять из выявленных 22 уязвимостей были связаны с недостаточными уровнями изоляции транзакций.

Результаты тестирования подтверждают эти ограничения. При проверке вертикальной масштабируемости PostgreSQL на многопроцессорном сервере выяснилось, что оптимальной конфигурацией является двухсокетная машина. При увеличении до 4, 6 и 8 сокетов производительность не росла, а снижалась. Соответственно, вертикальное масштабирование — не оптимальный сценарий для крупного бизнеса и высоконагруженных систем, где объемы данных и нагрузки могут увеличиваться многократно. Тем более, самых мощных серверов рано или поздно перестанет хватать и бизнесу придется переключиться на стратегию горизонтального масштабирования.

𝓲

Фото: ФОРС Дистрибуция

Коммерческие форки PostgreSQL частично решают эти проблемы через шардирование и дополнительные инструменты, например PgBouncer, но это требует инвестиций в инженерные команды и не обеспечивает линейную масштабируемость без потери гарантий ACID. Иначе говоря, для сервисов и приложений федерального масштаба нужна система, которая бы давала возможность на лету добавлять ресурсы без увеличения нагрузки на ее сопровождение и сохраняя эффективность вложений в существующую инфраструктуру.

YDB|СУБД Яндекса: новая архитектура для высоконагруженных систем

YDB СУБД Яндекса построена по принципиально иному принципу, который уже применяется при построении отказоустойчивых и масштабируемых решений — принципу распределенной системы. Это система управления базами данных, изначально созданная для работы в многоузловом кластере, позволяющая линейно и неограниченно наращивать пропускную способность при обработке и объемы хранения данных без увеличения задержек и с сохранением отказоустойчивости в любом количестве дата-центров. Анализ применимости показывает, что YDB становится оптимальным выбором для компаний с быстрым или непредсказуемым ростом постоянных или пиковых нагрузок, увеличивающимися объемами обрабатываемых данных, необходимостью анализировать данные в разных разрезах (благодаря поддержке гетерогенных OLAP и OLTP-нагрузок) и высокой стоимостью простоя базы данных. К таким компаниям относятся крупные банки с расчетными центрами, телеком-операторы с антифрод-системами, промышленные предприятия с распределенными дата-центрами и IoT-экосистемами.

Результаты независимого тестирования: цифры, которые отвечают на вопросы — какую СУБД выбрать?

Лаборатория тестирования «ФОРС Дистрибуция» провела комплексное сравнение PostgreSQL 18 (beta1) и YDB 24.3.15 с использованием стандартизированного теста TPC-C реализованного в Benchbase+. Выбор 18-й версии PostgreSQL был обусловлен заявлениями разработчиков о 30% повышении производительности ввода-вывода.

При тестировании на одинаковом оборудовании (см.врезку*) PostgreSQL 18 показал результаты 58 594 tpmC при 5300 складах в синхронной репликации и 61 104 tpmC при 5500 складах в асинхронной репликации. Эффективность составила 86-86.4%, а задержки в 90-м перцентиле достигали 3500 мс. В свою очередь YDB на трех узлах продемонстрировал 56 024 tpmC при 5000 складах (это максимальное количество складов и операций, которое может быть получено на данном оборудовании в пределах заданных критериев) с эффективностью 87.13% и задержками в 90-м перцентиле 3000 мс.

𝓲

Фото: ФОРС Дистрибуция

PostgreSQL и YDB продемонстрировали определенные показатели по параметру производительности tpmC (см. рис. 2). Однако картина меняется при тестировании масштабируемости:при увеличении кластера YDB с 3 до 9 узлов производительность YDB линейно возрастает: три узла обеспечивают 43 770 tpmC при 4000 складах, шесть динамических узлов дают 96 564 tpmC при 8000 складах, а девять динамических узлов показывают 148 914 tpmC при 12000 складах, демонстрируя рост в 3.4 раза (см. рис. 3). Следует отметить, что тест горизонтальной масштабируемости выполняется только для YDB. PostgreSQL не умеет горизонтально масштабироваться, поэтому добавление дополнительных серверов может только обеспечить создание дополнительных копий данных. Операции по изменению данных будут выполняться только на одном сервере PostgreSQL, а для него максимальные значения были получены в предыдущем тесте.

1 тест — это сравнение PostgreSQL vs YDB на одинаковом наборе оборудования.

2 тест — линейная маштабируемость YDB, которая недоступна для PostgreSQL.

Как было сказано выше, при достижении предельной производительности сервера PostgreSQL возможно масштабировать только при снижении эффективности для бизнеса: вручную переписывая приложение или пользуясь сторонними надстройками, снижающими удельную производительность Еще раз напомним, что при шардировании PostgreSQL вы получаете масштабируемость и производительность, но платите за это сложностью и частичной потерей гарантий ACID. Это как выбор между одним надежным сейфом и десятью маленькими — больше места, но сложнее контролировать.

Тестирование подтвердило линейный рост количества обрабатываемых транзакций при добавлении новых узлов в кластер YDB. Важно отметить, что девятиузловая конфигурация YDB работала на более слабом оборудовании с SSD вместо NVMe и сетью 10 Гбит/с вместо 25 Гбит/с, но показала двукратное превосходство над PostgreSQL. Не стоит смущаться этим моментом. Разное оборудование объясняет лишь факт того, что в одном тесте YDB мы получили максимальную производительность на 3 сервера на 4000 складов, а на другом 5000 складов.

𝓲

Фото: ФОРС Дистрибуция

Отказоустойчивость: несравнимые архитектуры

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

YDB демонстрирует принципиально иной подход. В рекомендуемой конфигурации 9 узлов (mirror-3-dc) система может потерять целый дата-центр и еще один сервер в оставшихся ЦОДах без потери работоспособности. При выходе узла из строя кластер переходит в состояние yellow, но продолжает обрабатывать запросы. Это демонстрирует основное преимущество архитектуры распределенной СУБД — с ее помощью становится возможным строить системы с исключительно высокой доступностью.

Экономика выбора: какая СУБД выгоднее?

Результаты тестирования показывают интересную экономическую модель. Для достижения производительности 61 000 tpmC можно отдать предпочтение PostgreSQL — эта производительность достигается на одном сервере. Достижение же производительности 150 000 tpmC потребует при использовании PostgreSQL топовое оборудование с NVMe-дисками и максимальной оптимизацией, в то время как YDB достигает этого результата на 9 серверах среднего класса с обычными SSD.

О лаборатории тестирования «ФОРС Дистрибуция»

«ФОРС Дистрибуция» — один из ведущих российских технологических дистрибуторов с более чем 30-летней историей. Компания специализируется на комплексных решениях в области управления данными и обладает уникальной экспертизой в тестировании и внедрении СУБД различных классов.

Лаборатория тестирования ФОРС оснащена современным оборудованием и использует стандартизированные методики, что обеспечивает объективность и воспроизводимость результатов. Команда включает сертифицированных экспертов, в том числе Oracle Certified Master, что гарантирует высочайший уровень компетенций в области баз данных.

Выводы для бизнеса

Конечно, следует помнить, что это синтетический тест, и не стоит его напрямую привязывать к задачам и потребностям реального бизнеса. Тем не менее, результаты независимого тестирования «ФОРС Дистрибуция» позволяют сделать несколько ключевых выводов. Для работы с мало- и средненагруженными системами (в рамках тестирования это уровень до 61 000 tmpC) PostgreSQL остается проверенным вариантом. Для крупного корпоративного бизнеса с высокими нагрузками (> 61 000 tpmC в методике приведенного теста) и требованиями к отказоустойчивости YDB предлагает эффективные возможности линейного роста производительности при неограниченном горизонтальном масштабировании. Экономическая целесообразность YDB проявляется при необходимости обработки больших объемов данных — можно использовать горизонтальное масштабирование. В целом можно сделать вывод, что распределенные СУБД, такие как YDB, могут заменть монолитные. К тому же зрелость российских СУБД достигла уровня, позволяющего не просто заменить западные аналоги, но и получить новые возможности для быстрой адаптации инфраструктуры бизнеса к непредсказуемым условиям, прогнозирования ее роста и сохранения эффективности управления бизнес-критичными сервисами и приложениями. PostgreSQL остается проверенным временем решением, которое заслуженно занимает лидирующие позиции в своей нише. Для многих задач с предсказуемыми нагрузками и умеренными объемами данных это оптимальный выбор — надежный, хорошо документированный, с большим сообществом разработчиков.

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