OpenAI
рассказала, как масштабирует PostgreSQL под нагрузку ChatGPT: один основной узел и почти 50 реплик для чтения в нескольких регионах.
Этой схемы хватило, чтобы обслуживать миллионы запросов в секунду для аудитории 800 млн пользователей.
Важно, что упор в статье не на волшебные настройки, а на инженерные решения вокруг СУБД.
Вот что оказалось ключевым:
✔️ Чтение отдельно от записи — трафик чтения разгружают на реплики, основной узел минимизируют по нагрузке на чтение и запись.
✔️ Вынос write-heavy и шардируемого — шардируемые нагрузки с преобладанием операций записи переносят в шардированные системы вроде Azure Cosmos DB. Новые нагрузки по умолчанию распределяют на шардированные системы, а в текущее развертывание PostgreSQL больше не разрешают добавлять новые таблицы.
✔️ Контроль дорогих запросов — по возможности избегают сложных многотабличных соединений. Если соединения нужны, рассматривают разбиение запроса и перенос сложной логики соединений на уровень приложения.
✔️ Проверка SQL от ORM — тщательно проверяют SQL, который генерируют ORM, и убеждаются, что он работает как ожидается.
✔️ Защита autovacuum — используют
idle_in_transaction_session_timeout, чтобы длительные простаивающие запросы не блокировали autovacuum.
✔️ Высокая доступность и чтение при сбоях — критические чтения обслуживаются с реплик даже при падении основного узла. Основной узел работает в HA с горячим резервом.
✔️ Изоляция по приоритетам — запросы с высоким и низким приоритетом направляют в отдельные экземпляры, чтобы низкоприоритетная ресурсоемкая нагрузка не просаживала критичный трафик.
✔️ Кеш без лавины промахов — используют механизм блокировки и аренды кеша, чтобы только один читатель, не нашедший данные по ключу, извлекал их из PostgreSQL и заново заполнял кеш, а остальные ждали обновления кеша.
Результат: Задержка на стороне клиента на уровне низких двузначных миллисекунд для p99 и доступность 99,999% в продакшене.
За последний год был один инцидент SEV-0, когда трафик записи вырос более чем в 10 раз, а за неделю зарегистрировались 100 млн новых пользователей.
Вывод для бизнеса: PostgreSQL выдерживает глобальный масштаб, когда ее усиливают правильной эксплуатацией. Реплики, HA, изоляция нагрузок, PgBouncer, защита кеша и строгие правила миграций превращают сильную СУБД в платформу, на которую можно опираться.
🐘 Мы на практике показываем, что PostgreSQL может быть основой для работы информационных систем. С нашими значимыми доработками в ядро СУБД и фичами для большого бизнеса система становится мощным инструментом для заказчиков. Подробнее — в
кейсах внедрения Postgres Pro.
