Мы знаем как готовить БД. Но индустрия изменилась: что бы я заложил в OLTP-БД с нуля

[Tzimie]

Статья хорошая но вопросы странные. Замочить от бизнеса. Например, в одной конторе процессинг real time и все помешаны на p95-p99 и latency в миллисекундах. В другой MSSQL более "бэкендный" уже после кафок всяких и там запросы уже с таймаутом 30 сек ок. А read-only реплика этого вообще для кубов и там запросы по часу.

[anishukserg]

@Tzimie, спасибо — полностью согласен, что “обязательность” сильно зависит от профиля нагрузки и SLO: где-то считают миллисекунды на p99, а где-то 30с таймаут норм, и отдельная RO-реплика живёт своей жизнью.

Моя цель этими вопросами как раз собрать разные “минимальные контракты продакшена” по классам (условно: latency‑critical OLTP / “обычный” backend OLTP / тяжёлые чтения и реплики) и понять, что люди считают ядром, а что — “обвязкой”. В продолжении, похоже, стоит явно разнести это по сценариям и задавать вопрос не “в целом”, а “для такого-то профиля”.

Если не сложно: для вашего самого “болючего” сценария (процессинг/latency‑critical или наоборот) какие 3 вещи вы бы назвали самыми критичными?

[Tzimie]

На самом деле MSSQL стоит своих денег (про особенности одной страны пока не говорим). Query store, resource governor, parameter sniffing... Ну в 2022 есть полипланы для разных параметров. Все из коробки. И люди кто работает с Постгрес как то странно смотрят когда их хотят навязать миграцию базы с MSSQL... Ну терабайт так 90...

А что думаете вы, раз столкнулись и с тем и с другим? Я все хочу уйти на PostgresSQL но слишком много работы по MSSQL пока, нет времени. И слышал что много людей приходят в состояние шока. Как с машины пересел нас велосипед

[anishukserg]

Да, SQL Server во многих местах реально выглядит как более “собранная машина” из коробки: Query Store, Resource Governor, много диагностики/управления планами, зрелые инструменты — и это экономит кучу времени и нервов, особенно на больших инсталляциях.

И это, кстати, прямо ложится в мой тезис про “конструктор”: в Postgres похожие свойства часто достигаются комбинацией ядра + расширений + внешних компонентов + практик эксплуатации. Работает, но требует дисциплины и “обвязки” — и на миграции это ощущается особенно остро.

Про “терабайт 90”: я бы не воспринимал переход как “просто захотели — переехали”. На таком объёме миграция обычно оправдана только при очень конкретной бизнес‑причине (стоимость лицензий/вендор‑лок, требования к платформе/деплою, унификация стека, дефицит MSSQL‑экспертизы и т.п.). На практике чаще заходят не big‑bang, а с новых сервисов/контуров, постепенно наращивая долю Postgres — и вместе с долей растёт и экспертиза, как управлять им на таком объёме.

Про “велосипед после машины”: соглашусь, но шок у людей обычно не от SQL как языка, а от разных “продакшен‑дефолтов” (соединения/пуллинг, vacuum и bloat, наблюдаемость/diagnostics, политики ресурсов).

При этом если запускаешь новый проект и продакшином ещё не пахнет, мне часто проще и приятнее поднять Postgres, чем поднимать SQL Server.

[anishukserg]

Да

[VVitaly]

OLTP нагрузка конечно бывает "разной", но если это "реальный" OLTP профиль он должен "по универсальности" приближаться к Oracle. К примеру (без "перекручивания" десятка параметров) оптимально поддерживать R/W нагрузку и как 1/9 и 3/7. Кэшировать данные один раз на множество сессий, не выделять один "тяжелый объект" в системных "словарях" БД на 10000 пользовательских сессий и т.п.
Дисковый IO давно уже не главный "тормоз" OLTP нагрузки. Oracle "тормозит" только на блокировках (важна частота/латенси памяти и CPU), а в PG эти блокировки и тормоза "умножаются" за счет vacuum и analyze. Сбор статистики это конечно не плохо, но произвольное/автоматическое изменение планов исполнения "на лету" - попытка упростить "тупым" разработчикам/администраторам работу с БД.