Подходит ли платформа для начинающих без опыта работы?

Да, курсы разбиты по уровням: Junior, Middle, Senior. Начинающие могут стартовать с базовых тем Python, Docker и алгоритмов и постепенно двигаться к более сложным темам.

Как быстро можно подготовиться к собеседованию на позицию Junior разработчика?

При занятиях 1–2 часа в день — от 2 до 4 недель на основные темы. Платформа анализирует слабые места по результатам квизов и строит персональный план подготовки.

Какие технологии охватывает платформа?

Python, FastAPI, Django, Docker, алгоритмы и структуры данных, Agile/Scrum, SQL, CI/CD, системный дизайн, код-ревью и более 50 других тем для разработчиков.

Платформа бесплатная?

Большинство учебных материалов и квизов доступны бесплатно после регистрации. Регистрация занимает менее минуты.

Как платформа помогает найти работу программистом?

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

monitoring_debugging

Мониторинг, отладка, антипаттерны

Диагностика проблем, неиспользуемые индексы, типичные ошибки и best practices.

Мониторинг, отладка, антипаттерны

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

1. Диагностика неиспользуемых индексов

1.1. Поиск неиспользуемых индексов

SELECT 
    schemaname,
    relname as table_name,
    indexrelname as index_name,
    idx_scan as index_scans,
    idx_tup_read as tuples_read,
    idx_tup_fetch as tuples_fetched,
    pg_size_pretty(pg_relation_size(indexrelid)) as size
FROM pg_stat_user_indexes
WHERE schemaname = 'public'
  AND idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC;

Интерпретация:

idx_scan = 0 — индекс ни разу не использовался
size — сколько места занимает зря

1.2. Индексы с низкой эффективностью

SELECT 
    indexrelname,
    idx_scan,
    idx_tup_read,
    idx_tup_fetch,
    CASE 
        WHEN idx_scan > 0 THEN idx_tup_read / idx_scan 
        ELSE 0 
    END as avg_tuples_per_scan
FROM pg_stat_user_indexes
WHERE schemaname = 'public'
ORDER BY idx_scan ASC;

Интерпретация:

Мало сканирований, но много чтений — возможно, индекс используется для редких, но важных запросов
Много сканирований, мало чтений — индекс эффективен

1.3. Удаление неиспользуемых индексов

-- Удаление без блокировок (production)
DROP INDEX CONCURRENTLY IF EXISTS idx_unused;

-- Удаление нескольких индексов
DO $$
DECLARE
    r record;
BEGIN
    FOR r IN (
        SELECT indexrelname
        FROM pg_stat_user_indexes
        WHERE schemaname = 'public'
          AND idx_scan = 0
          AND indexrelname NOT LIKE '%_pkey'  -- Не трогать PRIMARY KEY
    ) LOOP
        EXECUTE 'DROP INDEX CONCURRENTLY IF EXISTS ' || r.indexrelname;
        RAISE NOTICE 'Dropped index: %', r.indexrelname;
    END LOOP;
END$$;

2. Диагностика раздувания индексов (Bloat)

2.1. Простая оценка bloat

SELECT 
    indexrelname,
    pg_size_pretty(pg_relation_size(indexrelid)) as size,
    idx_scan,
    pg_relation_size(indexrelid) / NULLIF(idx_scan, 0) as bytes_per_scan
FROM pg_stat_user_indexes
WHERE schemaname = 'public'
ORDER BY pg_relation_size(indexrelid) DESC;

2.2. Точная оценка через pgstattuple

-- Установка расширения (требует суперпользователя)
CREATE EXTENSION IF NOT EXISTS pgstattuple;

-- Анализ индекса
SELECT * FROM pgstatindex('idx_users_email');

Результат:

Столбец	Описание
`leaf_fragmentation`	Процент фрагментации листовых узлов
`avg_leaf_density`	Средняя плотность заполнения (должна быть ~90%)
`leaf_count`	Количество листовых страниц

2.3. Запрос для оценки bloat всех индексов

WITH bloat_info AS (
    SELECT 
        indexrelname,
        pg_relation_size(indexrelid) as index_size,
        (pgstatindex(indexrelname::text)).leaf_fragmentation as frag,
        (pgstatindex(indexrelname::text)).avg_leaf_density as density
    FROM pg_stat_user_indexes
    WHERE schemaname = 'public'
)
SELECT 
    indexrelname,
    pg_size_pretty(index_size) as size,
    round(frag::numeric, 2) as fragmentation_percent,
    round(density::numeric, 2) as avg_density_percent,
    CASE 
        WHEN frag > 50 THEN 'CRITICAL'
        WHEN frag > 20 THEN 'WARNING'
        ELSE 'OK'
    END as status
FROM bloat_info
ORDER BY frag DESC;

2.4. Лечение bloat

-- Перестроение индекса (блокирует таблицу)
REINDEX INDEX idx_users_email;

-- Перестроение без блокировок (PostgreSQL 12+)
REINDEX INDEX CONCURRENTLY idx_users_email;

-- Альтернатива: pg_repack (требует расширения)
-- pg_repack --index=idx_users_email --dbname=mydb

3. Анализ планов выполнения

3.1. EXPLAIN с метриками

-- Базовый анализ
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT * FROM orders 
WHERE user_id = 123 AND status = 'pending';

Ключевые метрики:

Actual Time — реальное время выполнения
Rows — фактическое количество строк
Buffers — чтения из буфера (hit = память, read = диск)
Planning Time — время на планирование запроса
Execution Time — время выполнения

3.2. Поиск медленных запросов

-- Требуется расширение pg_stat_statements
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- Топ-10 медленных запросов
SELECT 
    query,
    calls,
    round(total_exec_time::numeric / 1000, 2) as total_time_sec,
    round(mean_exec_time::numeric, 2) as avg_time_ms,
    rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

-- Топ-10 самых частых запросов
SELECT 
    query,
    calls,
    round(mean_exec_time::numeric, 2) as avg_time_ms
FROM pg_stat_statements
ORDER BY calls DESC
LIMIT 10;

3.3. Визуализация планов

-- EXPLAIN в формате JSON для визуализаторов
EXPLAIN (FORMAT JSON, ANALYZE)
SELECT * FROM orders WHERE user_id = 123;

-- Используйте https://explain.dalibo.com/ или https://explain.depesz.com/

4. Типичные антипаттерны

4.1. Индексы на всём подряд

-- ❌ Плохо: индексы на каждой колонке
CREATE INDEX idx_users_name ON users(name);
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_users_phone ON users(phone);
CREATE INDEX idx_users_created ON users(created_at);
-- ... ещё 10 индексов

-- ✅ Хорошо: индексы для частых запросов
CREATE INDEX idx_users_email ON users(email);  -- Частый поиск по email
CREATE INDEX idx_users_created ON users(created_at DESC);  -- Сортировка

4.2. Избыточные индексы

-- ❌ Плохо: дублирование функциональности
CREATE INDEX idx_user_id ON orders(user_id);
CREATE INDEX idx_user_status ON orders(user_id, status);
-- Первый индекс избыточен!

-- ✅ Хорошо: только составной
CREATE INDEX idx_user_status ON orders(user_id, status);
-- Покрывает и запросы только по user_id

4.3. Функции в WHERE без индекса

-- ❌ Плохо: индекс не используется
SELECT * FROM users WHERE LOWER(email) = 'test@example.com';

-- ✅ Хорошо: индекс по выражению
CREATE INDEX idx_lower_email ON users(LOWER(email));

4.4. Неправильный порядок колонок

-- ❌ Плохо: низкая селективность первой
CREATE INDEX idx_status_user ON orders(status, user_id);
-- status имеет 4 значения, user_id — миллионы

-- ✅ Хорошо: высокая селективность первой
CREATE INDEX idx_user_status ON orders(user_id, status);

4.5. Игнорирование NULL

-- ❌ Плохо: NULL не индексируются в некоторых типах индексов
SELECT * FROM users WHERE deleted_at IS NULL;

-- ✅ Хорошо: частичный индекс для NULL
CREATE INDEX idx_not_deleted ON users(created_at) 
WHERE deleted_at IS NULL;

4.6. Отсутствие LIMIT для больших результатов

-- ❌ Плохо: выборка всех строк
SELECT * FROM logs ORDER BY created_at DESC;

-- ✅ Хорошо: ограничение результата
SELECT * FROM logs ORDER BY created_at DESC LIMIT 100;

4.7. N+1 запросы

# ❌ Плохо: N+1 запросов
users = db.query("SELECT * FROM users")
for user in users:
    orders = db.query("SELECT * FROM orders WHERE user_id = ?", user.id)

# ✅ Хорошо: один запрос с JOIN
results = db.query("""
    SELECT u.*, o.* 
    FROM users u
    LEFT JOIN orders o ON o.user_id = u.id
""")

5. Мониторинг производительности индексов

5.1. Эффективность индексов

SELECT 
    indexrelname,
    idx_scan as scans,
    idx_tup_read as read,
    idx_tup_fetch as fetched,
    CASE 
        WHEN idx_scan > 0 THEN round(
            (idx_tup_fetch::numeric / idx_tup_read) * 100, 2
        )
        ELSE 0 
    END as hit_ratio_percent
FROM pg_stat_user_indexes
WHERE schemaname = 'public'
ORDER BY idx_scan DESC;

Интерпретация:

hit_ratio близок к 100% — индекс эффективен
hit_ratio низкий — много «холостых» чтений

5.2. Размер индексов vs выгода

SELECT 
    indexrelname,
    pg_size_pretty(pg_relation_size(indexrelid)) as size,
    idx_scan,
    idx_tup_fetch,
    CASE 
        WHEN idx_scan = 0 THEN 'UNUSED'
        WHEN idx_scan < 100 THEN 'LOW'
        WHEN idx_scan < 1000 THEN 'MEDIUM'
        ELSE 'HIGH'
    END as usage_level
FROM pg_stat_user_indexes
WHERE schemaname = 'public'
ORDER BY pg_relation_size(indexrelid) DESC;

5.3. Автовакуум и индексы

-- Проверка последнего VACUUM/ANALYZE
SELECT 
    relname,
    last_vacuum,
    last_autovacuum,
    last_analyze,
    last_autoanalyze,
    n_dead_tup,
    n_live_tup,
    round((n_dead_tup::numeric / NULLIF(n_live_tup, 0)) * 100, 2) as dead_ratio_percent
FROM pg_stat_user_tables
WHERE schemaname = 'public'
ORDER BY n_dead_tup DESC;

Рекомендация: dead_ratio > 20% — требуется VACUUM.

6. Автоматизация мониторинга

6.1. Представление для мониторинга

CREATE OR REPLACE VIEW index_health AS
SELECT 
    schemaname,
    relname as table_name,
    indexrelname as index_name,
    pg_size_pretty(pg_relation_size(indexrelid)) as size,
    idx_scan,
    idx_tup_read,
    idx_tup_fetch,
    CASE 
        WHEN idx_scan = 0 THEN 'UNUSED'
        WHEN idx_scan < 100 THEN 'LOW_USAGE'
        ELSE 'OK'
    END as status,
    indexdef
FROM pg_stat_user_indexes psu
JOIN pg_indexes pi USING (indexrelname)
WHERE schemaname = 'public';

6.2. Alert для неиспользуемых индексов

-- Проверка для alert-системы
SELECT 
    indexrelname,
    pg_size_pretty(pg_relation_size(indexrelid)) as wasted_size
FROM pg_stat_user_indexes
WHERE schemaname = 'public'
  AND idx_scan = 0
  AND pg_relation_size(indexrelid) > 10 * 1024 * 1024;  -- > 10 MB

6.3. Cron job для еженедельного отчёта

#!/bin/bash
# weekly_index_report.sh

psql -d mydb -c "
SELECT 
    indexrelname,
    pg_size_pretty(pg_relation_size(indexrelid)) as size,
    idx_scan,
    CASE WHEN idx_scan = 0 THEN '⚠️ UNUSED' ELSE '✅' END as status
FROM pg_stat_user_indexes
WHERE schemaname = 'public'
ORDER BY idx_scan ASC, pg_relation_size(indexrelid) DESC;
" | mail -s "Weekly Index Report" admin@example.com

7. Best practices для production

✅ Делайте

Регулярно проверяйте pg_stat_user_indexes — ищите неиспользуемые индексы
Мониторьте bloat — через pgstattuple или простые эвристики
Используйте EXPLAIN (ANALYZE, BUFFERS) — для всех медленных запросов
Настройте autovacuum — для актуальной статистики и очистки
Удаляйте избыточные индексы — экономия места и ускорение записи
Используйте CONCURRENTLY — для создания/удаления в production
Мониторьте pg_stat_statements — для поиска медленных запросов

❌ Не делайте

Не создавайте индексы «на всякий случай» — только для реальных запросов
Не игнорируйте bloat > 50% — перестраивайте индексы
Не используйте enable_seqscan = off — в production
Не создавайте индексы во время пиковой нагрузки — без CONCURRENTLY
Не забывайте про VACUUM — особенно после массовых обновлений
Не храните индексы > 100 GB — рассмотрите партиционирование

8. Чеклист аудита индексов

Еженедельно

Проверить неиспользуемые индексы (idx_scan = 0)
Проверить top-10 медленных запросов (pg_stat_statements)
Проверить dead tuples ratio (> 20% — тревога)

Ежемесячно

Оценить bloat индексов (pgstattuple)
Удалить неиспользуемые индексы
Перестроить индексы с bloat > 50%
Проверить статистику (last_analyze)

Ежеквартально

Аудит всех индексов на соответствие запросам
Удаление избыточных индексов
Анализ эффективности составных индексов
Планирование ёмкости (рост индексов)

9. Полезные расширения

Расширение	Описание
`pg_stat_statements`	Статистика выполнения запросов
`pgstattuple`	Точная оценка bloat и фрагментации
`pg_trgm`	Trigram-индексы для нечёткого поиска
`pg_repack`	Перестроение без блокировок (альтернатива REINDEX)
`hypopg`	Гипотетические индексы для тестирования

Пример: гипотетические индексы

-- Установка
CREATE EXTENSION IF NOT EXISTS hypopg;

-- Создание гипотетического индекса
SELECT hypopg_create_index('CREATE INDEX idx_test ON users(email)');

-- Проверка плана с гипотетическим индексом
EXPLAIN SELECT * FROM users WHERE email = 'test@example.com';

-- Удаление
SELECT hypopg_drop_index(indexrelid) FROM hypopg_index;

10. Что дальше?

Курс завершён! Вы изучили:

Основы — что такое индексы и как работают
B-дерево — внутреннее устройство
Все типы индексов — Hash, GIN, GiST, SP-GiST, BRIN
Продвинутые техники — составные, частичные, покрывающие
Оптимизатор — как выбирается план выполнения
Мониторинг — диагностика и best practices

Ключевые выводы

Мониторьте регулярно — pg_stat_user_indexes, pg_stat_statements
Bloat > 50% — перестраивайте — REINDEX CONCURRENTLY
Неиспользуемые индексы — удаляйте — экономия места и ускорение записи
EXPLAIN (ANALYZE, BUFFERS) — ваш друг — всегда проверяйте планы
Автоматизируйте — cron jobs, alert-ы, представления

Проверьте свои знания

Вопросы ещё не добавлены

Вопросы для этой подтемы ещё не добавлены.