Сегодня на мероприятии Supabase Select мы анонсировали Multigres для обеспечения высокой доступности и масштабируемого пулинга соединений, а также OrioleDB для высокопроизводительного хранения данных. Мы запустили dbarena — сайт с открытыми бенчмарками для сравнения производительности и стоимости услуг у различных провайдеров управляемого Postgres.

Каждый проект на Supabase начинается с одной базы данных Postgres. По мере роста проекта вертикальное увеличение доступных ресурсов RAM и CPU может помочь, но это не является решением всех проблем.

Масштабирование Postgres — это не одна конкретная задача; пользователи сталкиваются с новыми вызовами на разных этапах масштабирования и при различных рабочих нагрузках. Наши пользователи часто сообщают о необходимости помощи в масштабировании количества одновременных клиентских подключений, снижении накладных расходов от раздувания таблиц (bloat) и частых операций VACUUM, увеличении пропускной способности чтения и записи, предотвращении зацикливания идентификаторов транзакций (wraparound) и обеспечении бесперебойной работы за счет высокой доступности.

Наша цель — устранить любые ограничения масштабируемости на пути наших пользователей. Это означает борьбу с «узкими местами» на каждом уровне Postgres, разработку в открытом доступе и предоставление улучшений в виде полностью открытого исходного кода для широкого сообщества разработчиков.

Multigres — это операционная система с открытым исходным кодом для Postgres, созданная командой разработчиков Vitess. Она «из коробки» добавляет в Postgres масштабируемый пулинг соединений и автоматизированный отказ по нескольким узлам (failover). С Multigres вам не нужно запускать отдельный пулер, а ваше приложение может поддерживать гораздо больше клиентов, чем способна выдержать одна инстанция Postgres.

Многие разработчики знакомы с базовой архитектурой Primary/Standby HA и ее известными проблемами. Традиционно, если основная база данных выходит из строя до того, как данные были реплицированы на резервную, эти строки могут быть потеряны. В отличие от этого, Multigres использует обобщенный протокол консенсуса, построенный поверх синхронной репликации Postgres. Если узел Multigres выходит из строя, кластер согласовывает, какие именно записи были зафиксированы, прежде чем принимать новые, а затем за секунды повышает реплику до основного узла. Вы сохраняете каждую зафиксированную запись после переключения.

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

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

Multigres находится в стадии закрытого альфа-тестирования по приглашениям. Он работает с Supabase Auth, Storage и Edge Functions и предназначен для тестирования во время альфа-версии, а не для рабочих нагрузок в продакшене. Запросите доступ.

OrioleDB — это масштабируемый движок хранения данных с открытым исходным кодом для Postgres. Он заменяет традиционное кучное хранилище (heap storage) Postgres и устраняет его фундаментальные ограничения, такие как раздувание таблиц, накладные расходы VACUUM и зацикливание txid, присущее ограниченному диапазону 32-битных идентификаторов транзакций.

При использовании кучного хранилища Postgres никогда не обновляет строку на месте: каждое обновление записывает новую версию строки и оставляет старую в виде «мертвого кортежа» (dead tuple). В активно используемых таблицах с частыми обновлениями и удалениями это со временем создает значительное раздувание, а очистка требует постоянной активности VACUUM. VACUUM — одна из самых частых причин деградации производительности и сбоев Postgres под нагрузкой. Команды обычно смягчают это с помощью тщательной настройки, запланированного запуска pg_repack и избыточного выделения вычислительных ресурсов.

Журнал отмены (undo log) в OrioleDB устраняет эту проблему в корне. Вместо того чтобы оставлять мертвые кортежи, операции обновления и удаления записывают записи отмены на уровне страниц, которые система автоматически переиспользует. Это полностью устраняет раздувание, и VACUUM больше не требуется.

Разрешение чтения страниц без блокировок также делает OrioleDB более эффективным при высокой конкуренции, особенно в сценариях с интенсивным вводом-выводом (IOPS). OrioleDB обеспечивает до 1,8 раза более высокую пропускную способность, чем кучное хранилище Postgres в наших публичных бенчмарках, основанных на TPC-C, опубликованных на dbarena.com.

OrioleDB по умолчанию использует 64-битные идентификаторы транзакций (XID), поэтому он избегает проблемы зацикливания Postgres. При 32-битных XID зацикливание наступает примерно после 4 миллиардов транзакций и заставляет базу данных агрессивно «замораживать» старые строки. При использовании кучного хранилища XID хранятся непосредственно в каждом кортеже, поэтому расширение их с 32 до 64 бит добавило бы 8 байт к каждой версии строки. Это простое изменение на 8 байт каскадно распространяется на миллиарды версий строк с мертвыми кортежами, что приводит к увеличению количества страниц, большему объему операций ввода-вывода, повышенной нагрузке на кэш и увеличению размеров индексов.

Поскольку OrioleDB заменяет MVCC на основе VACUUM в кучном хранилище на журнал отмены, он полностью обходит это ограничение: метаданные транзакций могут использовать 64-битные XID, не наследуя устаревший формат кортежей кучного хранилища.

OrioleDB находится в активной разработке командой Supabase и участниками open source сообщества с 2021 года. В Supabase работают создатели движка, включая крупного контрибьютора Postgres Александра Короткова, которые выпустили восемнадцать бета-релизов.

публикует открытые, воспроизводимые бенчмарки баз данных для разных провайдеров: код бенчмарка, опубликованная методология, загружаемые необработанные данные по каждому результату и ссылки для сравнения. На момент запуска сравниваются Supabase, Amazon RDS и Google Cloud SQL. Для каждого запуска dbarena сообщает количество транзакций на доллар, общую ежемесячную стоимость, количество транзакций в минуту, p95, характеристики оборудования и строит график пропускной способности во времени.

У разработчиков, оценивающих хостинги Postgres, мало надежных источников для сравнения провайдеров. Бенчмарки от вендоров часто проводятся в благоприятных условиях, бенчмарки сообщества — это разовые снимки, а тщательная внутренняя оценка требует недель работы.

dbarena следует трем правилам: каждый опубликованный результат можно проверить независимо, сравнения нормализованы по стоимости, а методология является публичной.

Multigres: закрытая альфа-версия. Запросите доступ.
OrioleDB: создайте новый проект и выберите OrioleDB при создании. Публичная бета-версия. Документация.
dbarena: публично, на .