Трек баз данных: тест на припоминание
Промпты на свободное припоминание поперёк трека баз данных — схема, индексы, планы, MVCC, пулинг, миграции, шардинг. Сначала ответь по памяти, затем раскрой и сравни.
Припоминание бьёт перечитывание. На каждый промпт восстанови полный ответ по памяти, прежде чем открыть образец — они идут поперёк всего трека, поэтому именно усилие связать понятия закрепляет их. К концу ты точно увидишь, что из трека у тебя уже сидит, а что ты до сих пор угадываешь.
Восстанови хребет трека, не подглядывая: когда гнуть нормализацию, как cost-модель индекса выбирает скан, почему ошибки оценки строк каскадируются, что snapshot-изоляция защищает и не защищает, математика размера пула и как ключ шардирования ко-локирует или рассыпает работу.
- 01Когда правильно гнуть реляционные правила — денормализовать, хранить JSONB или даже отключать foreign keys?
- 02Как планировщик выбирает между index scan и sequential scan и почему ведущая колонка composite-индекса так важна?
- 03Почему ошибки оценки строк каскадируются в катастрофически плохие планы и как стабилизировать план под нагрузкой?
- 04От чего защищает snapshot-изоляция MVCC в PostgreSQL, от чего нет и как долгая транзакция вызывает bloat таблицы?
- 05Дай рассуждение о размере пула PgBouncer перед Postgres: почему backend тяжёлый, какого размера серверный пул и в чём ловушка prepared statement в transaction mode?
- 06Как выбрать ключ шардирования, почему низкокардинальный ключ создаёт hot shard и каков безопасный порядок действий до шардинга вообще?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет трека от начала до конца: нормализуй по умолчанию и гни лишь ради названного, чьего-то компромисса; пусть ведущая колонка индекса совпадает с паттерном доступа; считай оценки строк несущим входом планировщика; держи транзакции короткими, чтобы MVCC мог освобождать; мультиплексируй тяжёлые backends через небольшой измеренный пул; выстраивай ломающие изменения как expand-contract; и шардь последним, на высококардинальном ко-локирующем ключе, лишь когда исчерпан каждый рычаг одного узла. Теперь, когда увидишь медленный запрос, раздувшуюся таблицу или storm соединений, ты знаешь, за какой слой хвататься первым — и какие данные собрать, прежде чем объявлять фикс.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.