Скачать Postgres для разработчиков:
c нуля до продвинутого [Balun.Courses] [Олег Мифле]

Принц

Администратор
Регистрация
16 Дек 2016
Сообщения
191.044
Реакции
465.822
Складчина: Postgres для разработчиков:
c нуля до продвинутого [Balun.Courses] [Олег Мифле]



Изучаем все тонкости на реально встречающихся кейсах — от тормозящих запросов и масштабирования БД до проблем
с индексами и транзакциями.

Подойдет middle/senior-разработчикам и архитекторам, если:

БД начала тормозить
Поставили индексы, чтобы ускорить чтение, а в проде упала скорость записи. Или произошло и то, и другое
Проблемы с транзакциями
По классике поставили Serializable для защиты от всех аномалий, а в подарок получили низкую пропускную способность
Много данных
Как их разложить, чтобы они занимали меньше места
Нужно масштабироваться
Пора скейлить БД, но страшно что-то сломать
Случился инцидент в БД
Ошибки чинятся вручную, миграции ломают прод — куда смотреть и как не наломать еще больше дров
PgSQL как черный ящик
Пользуешься «вслепую» и не понимаешь, как БД работает под капотом. Сложно обосновать выбор при проектировании архитектуры
Минимальные требования:

Любой ЯП
Базовый SQL
Базовый Computer Science
Джунам может быть сложно:

Программа рассчитана на тех, кто уже сталкивался с проблемами использования Postgres.
Если хочешь «набить шишки» заранее — приходи.
В рамках курса разберем:

PgSQL под капотом
Почему простой Update может раздуть таблицу в разы, куда девается место и почему «база тормозит без причины»
Индексы
Как выбирать индексы под задачу, когда они спасают, а когда — забивают память и замедляют вставки
Запросы и производительность
Как читать план выполнения запроса, находить ошибки в SQL и ускорять запросы, не трогая индексы и схему
Транзакции и конкурентный доступ
Причины дедлоков и двойных списаний, какой уровень изоляции реально нужен, и как проектировать конкурентные операции без гонок и зависаний
Надёжность и масштабирование
Почему реплика может сделать еще хуже, когда внедрять партиционирование, и почему коннекты к базе заканчиваются
Мониторинг и troubleshooting
Как собрать health check по набору запросов и найти источник инцидента — на какие метрики смотреть и как интерпретировать
И все это — на задачах, которые постоянно встречаются в prod’e:

«Раздуешь» БД до массовых Update / Delete
Оптимизируешь 5 плохих запросов без добавления индексов
Доведешь 1 запрос до «production-grade» со стабильной пагинацией и корректными join’ами
Переработаешь одну из схем и подготовишь безопасную для прода миграцию
Подберешь индексы для запросов, внедришь и измеришь результаты
Реализуешь конкурентный доступ с выбором уровня изоляции, настроишь реплику и починишь production-инцидент
Из чего состоит курс:

Живые созвоны
Длятся по 1.5−2 часа и проходят 2 раза в неделю в свободное от работы время. Есть запись.
9 уроков в online-формате
Построили курс от проблем, которые встречаются на практике. Отточим все на учебном стенде.
Практика на реальных кейсах
Q&A-сессии
Online-встречи для ответов на вопросы по домашним заданиям и лекциям. Фидбек дает преподаватель — никаких кураторов и помощников.
В итоге освоишь Postgres на продвинутом уровне:

Внутреннее устройство и практическое применение
Тонкости, лучшие практики, паттерны и антипаттерны при использовании
Не будет потребности в чтении доплитературы — узнаешь все, что сейчас есть и используется
Можешь работать с любой реляционной БД — основополагающие концепции везде едины
Программа:

Урок №1. База по PgSQL и реляционным БД
Урок №2. Внутреннее устройство PgSQL
Урок №3. Запросы и производительность без индексов
Урок №4. Проектирование модели данных
Урок №5. Индексы
Урок №6. Транзакции и конкурентный доступ
Урок №7. Надёжность и масштабирование
Урок №8. Мониторинг и troubleshooting
Урок №9. Бонус. PostgreSQL в System Design


Спойлер: Подробно
Урок №1. База по PgSQL и реляционным БД

Теория:

зачем разработчику понимать Postgres глубже "ORM + SELECT"
история и философия Postgres: расширяемость, надёжность, MVCC
реляционная модель в прикладном виде: сущности, связи, ключи, ограничения
базовый DDL: таблицы, PK/FK, UNIQUE/CHECK, типы данных
Практика:

поднимаем учебный стенд: docker-compose, доступ, расширения, генерация данных
Домашнее задание:

поднять стенд
применить миграции (стартовый DDL)
загрузить тестовые данные
выполнить набор "sanity" SQL-запросов и прислать результаты
Результат:

понимаешь роль схемы, ключей и ограничений в качестве продукта
можешь описать предметную область в виде минимального DDL под конкретный сценарий
Урок №2. Внутреннее устройство PgSQL

Разбираем, почему простой UPDATE может раздуть таблицу в разы, куда девается место и почему «база тормозит без причины» — через внутреннюю кухню MVCC, WAL и autovacuum, которые обычно скрыты от разработчика.

Теория:

архитектура процессов: backend, shared buffers, bgwriter/checkpointer/walwriter, autovacuum
как данные лежат на диске концептуально: heap/pages, почему “update” не перезаписывает строку
MVCC: снимки, видимость версий, dead tuples
WAL: зачем нужен, crash recovery, связь с репликацией
Практика:

...
Домашнее задание:

«раздуть» БД до массовых UPDATE / DELETE
измерить рост и базовые метрики (до / после)
коротко описать, почему так произошло (MVCC + dead tuples)
Результат:

умеешь объяснить MVCC и последствия для чтения / записи
знаешь, какие системные представления смотреть для базовой диагностики активности
Урок №3. Запросы и производительность без индексов

Разбираем, как читать план запроса, находить структурные ошибки в SQL и ускорять запросы, не создавая ни одного индекса и не трогая схему.

Теория:

как думать про запрос: селективность, кардинальности, объём промежуточных данных
EXPLAIN (ANALYZE, BUFFERS): как читать план на уровне разработчика
типовые причины медленных запросов без индексов
техники оптимизации без индексов
Практика:

...
Домашнее задание:

оптимизировать 5 «плохих» запросов переписыванием и приложить исходный SQL, новый SQL, план до / после и короткое объяснение эффекта
Результат:

умеешь читать план и находить лишнюю работу
знаешь, как ускорять запросы
можешь доказать улучшение по плану и метрикам в формате «до / после»
Урок №4. Проектирование модели данных

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

Теория:

нормализация vs денормализация: критерии выбора
сonstraints как бизнес-правила: PK/FK/UNIQUE/CHECK, дефолты, nullable/non-nullable
типы данных: деньги / время / uuid
когда нужны domain / enum
JSONB: когда оправдан, где границы
миграции: expand / contract, backward compatibility, опасные операции
Практика:

...
Домашнее задание:

переработать схему одного кейса: добавить constraints, исправить типы и описать миграционный план
Результат:

умеешь проектировать схему, которая ловит ошибки приложения
знаешь, как выбирать типы и ограничения под доменную модель
понимаешь, как делать миграции безопасно для продакшена
Урок №5. Индексы

Разбираем, почему «создал индекс — не помогло», как выбирать индексы под задачу, когда составной / частичный / покрывающий индекс реально спасет, а когда он только съедает место и замедляет вставки.

Теория:

B-tree: селективность, порядок колонок, range queries
Covering indexes (INCLUDE), expression indexes
Partial indexes для «горячих» подмножеств
GIN / BRIN и когда они реально нужны
Цена индексов: write amplification, обслуживание, bloat
Практика:

...
Домашнее задание:

для набора запросов предложить индексы + объяснить ожидаемое изменение плана. Приложить планы до / после после создания индексов
Результат:

умеешь выбирать индекс под конкретный кейс и план
понимаешь trade-off чтения и записи
можешь собрать минимальную индексную стратегию под задачу
Урок №6. Транзакции и конкурентный доступ

Разбираем, откуда берутся «рандомные» дедлоки и двойные списания, какой уровень изоляции реально нужен, и как проектировать конкурентные операции без гонок и зависаний — от очередей до резервирования.

Теория:

ACID и уровни изоляции в PG: что гарантируется и где ловушки
Locks: что именно блокируется и почему
Дедлоки: типовые причины, как воспроизвести и диагностировать
Паттерны: idempotency, upsert, SKIP LOCKED, оптимистичные / пессимистичные подходы
Advisory locks
Практика:

...
Домашнее задание:

2–3 задачи на конкурентный доступ (очередь / резерв / списание) с выбором изоляции и объяснением
доказать корректность сценария на уровне инвариантов
Результат:

умеешь проектировать конкурентные операции
знаешь, как предупредить, найти и устранить дедлоки
понимаешь, почему «длинные транзакции» убивают систему
Урок №7. Надёжность и масштабирование

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

Теория:

physical vs logical replication: когда что выбирать
backup / restore и идея PITR
failover и влияние на приложение: таймауты, лаг, read-after-write
connection pooling (pgbouncer): зачем, режимы, типовые грабли
партиционирование: критерии, ключ, жизненный цикл.
шардирование: когда внедрять и границы применения (обзорно)
Практика:

...
Домашнее задание:

настроить реплику
показать лаг
отработать сценарий чтения с реплики
сделать партиционирование events по времени + сравнение запросов
Результат:

понимаешь базовые стратегии отказоустойчивости для Postgres
понимаешь, когда партиционирование даёт эффект, а когда усложняет жизнь
Урок №8. Мониторинг и troubleshooting

Учимся собирать health check базы и искать источник инцидента.

Теория:

pg_stat_statements: как найти самые дорогие запросы
pg_stat_activity: что сейчас происходит, кто блокирует, кто ждёт
симптомы проблем vacuum / bloat на уровне разработчика
логи: slow queries, deadlocks, минимальные настройки
Практика:

...
Домашнее задание:

собрать «DB health report»: набор диагностических SQL + интерпретация результатов
предложить алерты / пороги и обосновать
Результат:

умеешь собрать быстрый health check PostgreSQL по набору запросов
можешь локализовать причину: запросы vs блокировки vs обслуживание
знаешь необходимый минимум набора метрик и алертов для команды разработки
Урок №9. Бонус. PostgreSQL в System Design

Разбираем, как обосновать выбор Postgres на System Design интервью, чем он отличается от других БД в боевых сценариях, и соберем финальный артефакт — дизайн схемы, индексов, мониторинга и HA под конкретную нагрузку.

Теория:

PG как компонент архитектуры: границы ответственности, where-to-cache, where-to- queue, где OLTP заканчивается
highload-паттерны вокруг PG: идемпотентность, outbox, read-model, батчи, лимиты соединений
Postgres vs MySQL / InnoDB vs SQL Server / Oracle — когда и что выбирать
вопросы с собеседований: планы, индексы, транзакции, блокировки, vacuum, replication
Практика:

мини-дизайн под один из кейсов: схема + запросы + индексы + мониторинг + HA
Домашнее задание:

сделать финальный документ по выбранному кейсу: схема, ключевые запросы, индексная стратегия, миграции, мониторинг, HA / backup
реализовать нагрузочный прогон, сделать выводы и составить план улучшений
Результат:

можешь обосновать решения по базе в system design: trade-offs, риски, эксплуатация
готов к большинству вопросов по БД на system design интервью
умеешь говорить и проектировать на уровне продукта / нагрузки / рисков


Преподаватель Олег Мифле

Team Lead разработки в Т-Банке
Т-Банк: руководит командой разработки, разрабатывает функционал внутри чата обслуживания
ВКонтакте: ex-Senior, разработка платформы для мини-приложений
SkyEng: ex-Senior, разработка back office продукта
Конференции: спикер Highload++, Стачка, PHP Russia, Podlodka Crew
15+ лет промышленного опыта разработки
7+ лет использует PgSQL в продакшене
12 терабайт максимальное кол-во данных в Postgres
10+ докладов по PgSQL на ведущих конференциях
Цену установит организатор




СКАЧАТЬ