Что не так с постом от OpenAI про PostgreSQL на 800 млн пользователей

Недавно вышла статья про 800 миллионов юзеров ChatGPT на одном постгресе. Помимо очевидного пиара размера ChatGPT и достоинств Azure очевиден мессадж “А слыхали, постгрес крут — миллиард юзеров держит”. И действительно, в статье есть интересное, но в целом это не только ода PostgreSQL 😉 Ниже — саммари и комментарии в критическом, провокацонном ключе! Nuff said, погнали.

🤩 1 один primary + ~50 read-replicas по миру. OpenAI держит один мастер (Azure PostgreSQL Flexible Server) и почти 50 реплик чтения в разных регионах, при этом заявляет миллионы QPS на read-heavy нагрузке от 800 млн пользователей.

🤩 Главный враг — каскады аварий. Сценарий: сбой выше → промах кэша → лавина чтения; или всплеск дорогих join’ов → умираем по CPU; или write-storm от релиза/маркетинга → деградация. Дальше таймауты и ретраи раскручивают “петлю смерти”. Тут мы понимаем, что львиная доля запросов оседает в кеше, что если б кеша не было - постгресу приходит кабзда, и собственно можно расходиться со всем заявлением о могуществе PostgreSQL.

🤩 Postgres “упирается” в MVCC на записи — write-heavy уводят в шардированные системы. MVCC причиной write amplification / bloat / сложностей autovacuum и постепенно мигрируют шардируемые write-heavy нагрузки в Azure Cosmos DB, а в текущий Postgres даже не разрешают добавлять новые таблицы (новые ворклоады по умолчанию — в шардированные хранилища). Тут мы понимаем, что где-то ещё есть какой-то шардированный сторадж, это космос, и грустнеем ещё больше.

🤩 Главный анти-паттерн: джойнус гигантус вульгарис, особенно из ORM. Приводят пример запроса с join 12 таблиц, пики которого приводили к серьёзным инцидентам. Рецепт: ломать сложные join’ы, часть логики переносить в приложение, ревьюить SQL. Тюнить аймауты вроде idle_in_transaction_session_timeout, чтобы “idle in transaction” не блокировали vacuum.

🤩 Интересные моменты “уличной магии”
🤩 PgBouncer для защиты от connection storms и лимитов (в Azure упоминают 5000 коннектов на инстанс). В их бенчмарках коннект-латентность упала примерно с 50 ms до 5 ms.
🤩 Workload isolation: разделяют high-priority и low-priority трафик на разные инстансы (борьба с noisy neighbor).
🤩 Caching + locking/leasing: при промахах по одному ключу в БД ходит только один “победитель”, остальные ждут — защита от cache-miss storm.
🤩 Rate limiting на нескольких слоях (приложение/пулер/прокси/запросы) + возможность блокировать конкретные “query digests”, чтобы быстро гасить дорогие паттерны.
Отличные советы, но почему баунсер, он же херово скейлится по ядрам? Впрочем, можно по-дедовски много инстансов наподнимать - да всё нагрузку-то оказывается уже унесли.

🤩 Много реплик: привет, Релей. Primary стримит WAL на каждую реплику; с ростом их числа растёт нагрузка на сеть/CPU и риск лагов. Поэтому они вместе с Azure делают каскад (промежуточные реплики, или релеи, ретранслируют WAL дальше), чтобы масштабироваться до “сотни+” реплик без убийства primary, но отмечают усложнение failover. Тут я подумал, что я будто машине времени лет на 20 назад переместился.

🤩Минное поле альтеров. Даже маленький ALTER может вызвать полный table rewrite. Разрешают только лёгкие операции, вводят таймаут 5 секунд на schema changes, индексы — только CONCURRENTLY, а backfill’ы — под строгими лимитами.

Ну! Надавали по рукам программистам со своими ORM, увели writes в волшебный космос, наставили релеев, чтобы репликация не убивала систему, немного уличной магии — и можно и порадоваться: p99 на клиенте “низкие десятки миллисекунд”, five-nines availability и всего один SEV-0 за 12 месяцев (вирусный запуск ImageGen, пришло +100 млн пользователей за неделю).

Так-то! Статья супер, но много вопросов к постгресу при чтении “между строк” 🙂

🔥всё правильно пишешь
👍и всё равно постгрес - вещь!

—
обучение devhands