Один из самых простых и популярных способов «устроить highload на ровном месте» — это написать пару необдуманных строк, изменяющих схему БД, и выложить это в «прод» без обстоятельного тестирования.

В докладе мы подробно разберём ряд типичных ошибок разработчиков, архитекторов и администраторов баз данных, регулярно совершаемых при активной разработке приложений, когда необходимо изменить схему БД — от добавления новых объектов БД, столбцов до рефакторинга и оптимизации существующей схемы. Обсудим подводные камни, связанные с управлением транзакциями, блокировками, различными настройками Постгреса.

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

И наконец, основываясь на многолетнем опыте работы с быстрорастущими командами, обсудим организационные вопросы — как выстроить процессы разработки так, чтобы риски простоя и деградации производительности были сведены к минимуму, а команды разработчиков развивались и постоянно наращивали экспертизу работы с БД.

Вы пришли в компанию, где используется PostgreSQL, разные БД, некоторые из них по нескольку терабайт, и некая ORM (подставьте любую, которая вам ближе). Старые таблицы подросли настолько, что в некоторых уже миллиард строк. И вы обнаруживаете, что у старых таблиц столбцы id — типа int4, при этом значение подбирается к максимуму (2^31-1).

Понятно, что надо мигрировать на int8. Простой оценивается в $100500/мин и грозит увольнением, времени на разработку осталось — месяц-два.

1. Что будем делать?
2. Зависят ли ваши действия от версии Postgres? Если да, то как?
3. Какие вообще возможны варианты и какие у них плюсы-минусы?
4. А как можно наломать дров, какие варианты?