Распространённые ошибки изменения схемы базы данных PostgreSQL / Николай Самохвалов (Postgres.ai)
HTML-код
- Опубликовано: 3 окт 2021
- Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
HighLoad++ Весна 2021
Крупнейшая профессиональная конференция для разработчиков высоконагруженных систем
17 и 18 мая 2021. Москва, Крокус-Экспо
Тезисы и презентация:
www.highload.ru/spring/2021/a...
Один из самых простых и популярных способов «устроить highload на ровном месте» - это написать пару необдуманных строк, изменяющих схему БД, и выложить это в «прод» без обстоятельного тестирования.
В докладе мы подробно разберём ряд типичных ошибок разработчиков, архитекторов и администраторов баз данных, регулярно совершаемых при активной разработке приложений, когда необходимо изменить схему БД - от добавления новых объектов БД, столбцов до рефакторинга и оптимизации существующей схемы.
...
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
Отличный и актуальный доклад!
Хороший доклад. Мне нравится их канал rupostgres. Самохвалов и Космодемьянский светилы в области postgres'а для меня)
Не согласен с 1. IF [NOT] EXISTS может быть полезен. Простой пример. Миграция создает несколько индексов CONCURRENTLY, что нельзя сделать внутри транзакции. Вы должны быть готовы к тому, что миграция по какой-то причине упадет и ее придется перекатывать. Значит миграция должна быть идемпотентна. На помощь приходит CREATE INDEX CONCURRENTLY IF NOT EXISTS. Уверен, что пример не единственный.
За знания спасибо, были кейсы, о которых я не знал. Но в примерах SQL запросы написаны маленькими буквами. Созерцал с интересом и отвращением. За снобизм извени.