Базы данных
Трек баз данных: тест на припоминание
Припоминание бьёт перечитывание. На каждый промпт восстанови полный ответ по памяти, прежде чем открыть образец — они идут поперёк всего трека, поэтому именно усилие связать понятия закрепляет их.
Восстанови хребет трека, не подглядывая: когда гнуть нормализацию, как 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; и шардь последним, на высококардинальном ко-локирующем ключе, лишь когда исчерпан каждый рычаг одного узла.