553 вопроса по PostgreSQL с технических собеседований
553 вопроса1634 компании353 технологии
Что проверяют на интервью
Как устроена подборка
На странице собраны вопросы по PostgreSQL — от проверки базовых принципов до практического применения и архитектурных решений. В подборке чаще встречаются темы: database, sql, postgresql.
Сравните модели доставки секретов, а не объявляйте Injector плохим. ESO синхронизирует секреты в Kubernetes, Injector доставляет их через Vault Agent; выбор зависит от приложения и требований безопасности.
Назовите реально использованные базы и их задачи. Для Redis уточните, что кешировалось, как задавались TTL и инвалидирование и что происходило при недоступности кеша.
Индекс — дополнительная структура для ускорения поиска и некоторых других операций над таблицей. Он занимает место и требует обновления при изменении данных.
Создайте пул PostgreSQL на время жизни приложения и выполняйте SQL в /menu через полученное из пула соединение. Не открывайте неограниченное число соединений и не блокируйте async-обработчик синхронным драйвером.
FOR UPDATE конфликтует со всеми четырьмя режимами. NO KEY UPDATE допускает KEY SHARE; SHARE допускает SHARE и KEY SHARE; KEY SHARE блокирует UPDATE, но совместим с остальными названными режимами.
Опишите уровень владения SQL на реальных задачах: join, агрегации, транзакции, планы и индексы. Уточните, где использовали ORM, а где осознанно переходили к чистому SQL.
B-Tree индексирует значения с точным поиском по упорядоченной структуре, а BRIN хранит сводки по диапазонам страниц. BRIN особенно полезен на огромных таблицах с корреляцией значения и физического порядка данных.
WAL позволяет восстанавливать изменения после сбоя, не записывая каждую изменённую страницу данных на диск при каждом commit. Сначала сохраняется журнал, а страницы можно записать позже.
Начните с измерения: какие запросы и ресурсы ограничивают систему. Затем оптимизируйте запросы, индексы, объём данных и транзакции; реплики, разделение нагрузки и шардирование рассматривайте после простых мер.
PostgreSQL должен вовремя замораживать старые версии строк, чтобы циклические 32-битные XID не нарушили определение видимости. Anti-wraparound VACUUM — часть защиты от этой проблемы, а не просто уборка мусора.
Оптимистическая и пессимистическая блокировки — стратегии согласования, а row/table locks — механизмы БД. Оптимистический UPDATE с проверкой версии тоже использует физические блокировки при записи.
Более зрелый вариант — атомарное условное списание в PostgreSQL с проверкой результата. Оно защищает общий баланс между процессами и экземплярами приложения, а не только внутри одного event loop.
