CODERIKK

🔹 Когда и зачем применять materialized view? 🔸 materialized view хранит заранее вычисленные результаты (precompute) в отдельном storage, чтобы чтение шло из готовой структуры — это даёт заметное улучшение query speed за счёт избегания повторных тяжёлых вычислений. 🔸 Решает повторяющиеся дорогостоящие JOIN и агрегации, аналитические дашборды и latency‑чувствительные API (интерфейс прикладного программирования): вместо ре‑вычисления — чтение из materialized view. 🔸 Применять, когда данные меняются...

🔹 Когда лучше threading, а когда asyncio? 🔸 Без конкурентности (concurrency) приложение простаивает при I/O: клиенты ждут, throughput падает. threading и asyncio дают параллельность (parallelism) разными способами, чтобы не блокировать процесс. 🔸 threading — это OS‑потоки. Простая модель: запустил функцию в Thread. Хорошо для блокирующего I/O и когда есть C‑расширения, которые освобождают GIL (Global Interpreter Lock). 🔸 GIL (Global Interpreter Lock) мешает реальной параллельности Python‑байткода:...

🔹 Зачем мерять метрики качества данных? 🔸 Accuracy — показывает, насколько значения в таблице соответствуют реальности или эталону; без неё отчёты и модели дают смещённые выводы, поэтому отслеживают разницу с reference-данными и ставят пороги для отклонений. 🔸 Completeness — измеряет долю отсутствующих значений; пропуски ломают агрегации и ML; простая метрика — процент non-null. SELECT SUM(CASE WHEN col IS NULL THEN 1 ELSE 0 END) AS nulls, COUNT(*) AS total, SUM(CASE WHEN col IS NULL THEN 1...

🔹 Что повторяли и зачем это полезно? 🔸 list comprehension существует чтобы заменять громоздкие циклы при трансформации коллекций: короче читать, меньше ошибок, удобно для быстрых промежуточных списков при обработке данных. 🔸 SQL подзапрос помогает выделить шаг агрегации или фильтрации отдельно от основной выборки: полезно когда нужно отфильтровать строки по результатам агрегата без лишних JOIN'ов. 🔸 joins решают проблему объединения связанных таблиц: используйте INNER для общих записей,...

🔹 Как понять, что 99.9% — это много или мало для сервиса? 🔸 SLA нужен, чтобы согласовать ожидания и ответственность между командами и клиентами. Без него product, infra и data будут спорить о приоритетах и сроках реакции. 🔸 SLA (Service Level Agreement — соглашение об уровне сервиса) — контракт: какие метрики меряем, какой уровень сервиса, окна обслуживания и последствия за провал. Уровень сервиса прописывают явно. 🔸 Uptime — доля времени, когда сервис физически "в сети". Availability — практическая доступность для пользователей (учитывает деградации и таймауты)...