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

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

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

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

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

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

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

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

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

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

concurrent_index

Индексы без блокировок (CONCURRENTLY)

Создание и удаление индексов в production без простоя.

Индексы без блокировок (CONCURRENTLY)

В production нельзя останавливать базу на часы. CONCURRENTLY позволяет создавать и удалять индексы без блокировки записи.

1. Проблема: блокировки при создании индекса

1.1. Обычное создание индекса

CREATE INDEX idx_users_email ON users(email);

Что происходит:

PostgreSQL получает ShareLock на таблицу
Все INSERT/UPDATE/DELETE блокируются до завершения
Только SELECT работают нормально

1.2. Последствия для production

Время создания индекса для 100 млн записей: 30 минут

В это время:
✅ SELECT — работают
❌ INSERT — ждут 30 минут
❌ UPDATE — ждут 30 минут
❌ DELETE — ждут 30 минут

Результат: простой приложения, таймауты, недовольные пользователи.

2. Решение: CONCURRENTLY

2.1. Синтаксис

CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

2.2. Что происходит

PostgreSQL не блокирует запись
Индекс строится в фоновом режиме
Новые данные добавляются и в таблицу, и в строящийся индекс
После завершения индекс становится видимым для запросов

2.3. Сравнение блокировок

Операция	CREATE INDEX	CREATE INDEX CONCURRENTLY
SELECT	✅ Работает	✅ Работает
INSERT	❌ Блокируется	✅ Работает
UPDATE	❌ Блокируется	✅ Работает
DELETE	❌ Блокируется	✅ Работает

3. Как работает CONCURRENTLY

3.1. Два прохода сканирования

┌─────────────────────────────────────────────────┐
│  PASS 1: Сканирование таблицы                   │
│  - Строится основная структура индекса          │
│  - Запись не блокируется                        │
│  - Новые данные отслеживаются                   │
└─────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────┐
│  PASS 2: Обработка новых данных                 │
│  - Короткая блокировка ShareUpdateExclusiveLock │
│  - Применяются изменения с Pass 1               │
│  - Индекс становится видимым                    │
└─────────────────────────────────────────────────┘

3.2. Уровни блокировок

CREATE INDEX:

ShareLock — блокирует запись на всё время

CREATE INDEX CONCURRENTLY:

ShareUpdateExclusiveLock — короткая блокировка только в конце каждого прохода

4. Создание индекса CONCURRENTLY

4.1. Базовый синтаксис

CREATE INDEX CONCURRENTLY index_name ON table_name (column);

4.2. Пример

-- Таблица с 50 млн записей
CREATE TABLE orders (
    id BIGSERIAL,
    user_id BIGINT,
    status VARCHAR(20),
    created_at TIMESTAMP
);

-- Создание индекса без блокировок
CREATE INDEX CONCURRENTLY idx_orders_user_id ON orders(user_id);

4.3. С другими опциями

-- Уникальный индекс
CREATE UNIQUE INDEX CONCURRENTLY idx_users_email ON users(email);

-- Частичный индекс
CREATE INDEX CONCURRENTLY idx_pending_orders ON orders(user_id) 
WHERE status = 'pending';

-- Составной индекс
CREATE INDEX CONCURRENTLY idx_orders_user_status ON orders(user_id, status);

-- Покрывающий индекс
CREATE INDEX CONCURRENTLY idx_orders_covering ON orders(user_id) 
INCLUDE (status, created_at);

5. Удаление индекса CONCURRENTLY

5.1. Обычное удаление

DROP INDEX idx_users_email;

Блокировка: ShareLock — блокирует запись.

5.2. Удаление без блокировок

DROP INDEX CONCURRENTLY idx_users_email;

Блокировка: ShareUpdateExclusiveLock — не блокирует запись.

5.3. Пример

-- Неиспользуемый индекс
DROP INDEX CONCURRENTLY idx_unused_column;

6. Ограничения CONCURRENTLY

6.1. Нельзя в транзакции

-- ❌ Ошибка
BEGIN;
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);
COMMIT;
-- ERROR: CREATE INDEX CONCURRENTLY cannot run inside a transaction block

Почему: CONCURRENTLY требует нескольких проходов и ожидания завершения транзакций.

6.2. Требует завершения всех транзакций

-- Транзакция 1 (долгая)
BEGIN;
SELECT * FROM users WHERE id = 1;
-- ... держит транзакцию 10 минут ...
COMMIT;

-- Транзакция 2 (создание индекса)
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);
-- Ждёт завершения Транзакции 1 перед Pass 2

6.3. Дольше обычного создания

CREATE INDEX: 30 минут
CREATE INDEX CONCURRENTLY: 45 минут

Почему: два прохода + ожидание транзакций + накладные расходы.

7. Мониторинг создания индекса

7.1. Прогресс создания

-- PostgreSQL 12+
SELECT 
    pid,
    query,
    state,
    now() - query_start as duration
FROM pg_stat_activity
WHERE query LIKE 'CREATE INDEX CONCURRENTLY%';

7.2. Блокировки

SELECT 
    blocked_locks.pid AS blocked_pid,
    blocked_activity.usename AS blocked_user,
    blocking_locks.pid AS blocking_pid,
    blocking_activity.usename AS blocking_user,
    blocked_activity.query AS blocked_query
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;

7.3. Статус индекса

-- Проверка валидности индекса
SELECT 
    indexname,
    pg_get_indexdef(indexrelid) as definition,
    pg_relation_size(indexrelid) as size
FROM pg_indexes
WHERE tablename = 'users';

-- Индекс в процессе создания будет невалидным
SELECT 
    indexrelid::regclass as index_name,
    indisvalid as is_valid,
    indisready as is_ready
FROM pg_index
WHERE indexrelid = 'idx_users_email'::regclass;

8. Обработка ошибок

8.1. Отмена создания

-- Отмена через Ctrl+C в psql или pg_cancel_backend()
SELECT pg_cancel_backend(pid) 
FROM pg_stat_activity 
WHERE query LIKE 'CREATE INDEX CONCURRENTLY%';

Что происходит:

Индекс остаётся в состоянии invalid
Нужно удалить: DROP INDEX CONCURRENTLY idx_name;

8.2. Повтор после ошибки

-- 1. Удалить невалидный индекс
DROP INDEX CONCURRENTLY IF EXISTS idx_users_email;

-- 2. Создать заново
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

8.3. Ошибка: дубликат имени

-- ❌ Ошибка
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);
-- ERROR: relation "idx_users_email" already exists

-- ✅ Решение
DROP INDEX CONCURRENTLY IF EXISTS idx_users_email;
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

9. Best practices для production

9.1. Всегда используйте CONCURRENTLY

-- ✅ Хорошо для production
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

-- ❌ Плохо для production (блокирует запись)
CREATE INDEX idx_users_email ON users(email);

9.2. Создавайте индексы в непиковое время

# Cron job на 3 AM
0 3 * * * psql -c "CREATE INDEX CONCURRENTLY ..."

9.3. Установите таймаут

-- Отмена после 1 часа
SET statement_timeout = '1h';
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);
RESET statement_timeout;

9.4. Мониторьте прогресс

-- Проверка длительных операций
SELECT 
    pid,
    now() - query_start as duration,
    query
FROM pg_stat_activity
WHERE state = 'active'
  AND query LIKE '%INDEX%'
ORDER BY duration DESC;

9.5. Используйте transaction_id для ожидания

-- Дождитесь завершения старых транзакций
SELECT pg_current_xact_id();

-- Создавайте индекс после завершения
CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

10. Автоматизация

10.1. Скрипт для создания индекса

#!/bin/bash
# create_index_concurrently.sh

DB_NAME="mydb"
INDEX_NAME="idx_users_email"
TABLE_NAME="users"
COLUMN_NAME="email"

# Проверка существования индекса
if psql -d $DB_NAME -c "\di $INDEX_NAME" | grep -q $INDEX_NAME; then
    echo "Index already exists"
    exit 1
fi

# Создание индекса
echo "Creating index concurrently..."
psql -d $DB_NAME -c "CREATE INDEX CONCURRENTLY $INDEX_NAME ON $TABLE_NAME ($COLUMN_NAME);"

if [ $? -eq 0 ]; then
    echo "Index created successfully"
else
    echo "Index creation failed"
    exit 1
fi

10.2. Миграция с Alembic (Python)

from alembic import op

def upgrade():
    # Создание индекса CONCURRENTLY
    op.create_index(
        'idx_users_email',
        'users',
        ['email'],
        postgresql_concurrently=True
    )

def downgrade():
    # Удаление индекса CONCURRENTLY
    op.drop_index(
        'idx_users_email',
        table_name='users',
        postgresql_concurrently=True
    )

10.3. Миграция с Django

from django.db import migrations, models

class Migration(migrations.Migration):
    
    dependencies = [
        ('myapp', '0001_initial'),
    ]

    operations = [
        migrations.AddIndex(
            model_name='user',
            index=models.Index(
                fields=['email'],
                name='idx_users_email',
            ),
        ),
    ]

Django автоматически использует CONCURRENTLY для PostgreSQL.

11. Практические примеры

11.1. Добавление индекса в working hours

-- 9 AM, база под нагрузкой
-- ❌ Не делайте так
CREATE INDEX idx_orders_created_at ON orders(created_at);
-- Блокировка на 30 минут, простой приложения

-- ✅ Делайте так
CREATE INDEX CONCURRENTLY idx_orders_created_at ON orders(created_at);
-- Работает 45 минут, но без простоя

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

-- Найти неиспользуемые индексы
SELECT 
    indexrelname,
    idx_scan,
    pg_size_pretty(pg_relation_size(indexrelid)) as size
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC;

-- Удалить без блокировок
DROP INDEX CONCURRENTLY idx_unused_1;
DROP INDEX CONCURRENTLY idx_unused_2;

11.3. Перестроение индекса

-- Обычное перестроение (блокирует)
REINDEX INDEX idx_users_email;

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

12. Сравнение операций CONCURRENTLY

Операция	CONCURRENTLY	Без CONCURRENTLY
CREATE INDEX	✅ Не блокирует запись	❌ Блокирует запись
DROP INDEX	✅ Не блокирует запись	❌ Блокирует запись
REINDEX INDEX	✅ Не блокирует запись (12+)	❌ Блокирует запись
CREATE INDEX UNIQUE	✅ Не блокирует запись	❌ Блокирует запись
ALTER INDEX	⚠️ Зависит от операции	⚠️ Зависит от операции

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

Как оптимизатор выбирает индексы — внутренняя логика
Мониторинг и отладка — диагностика проблем
BRIN — для очень больших таблиц

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

CONCURRENTLY не блокирует запись — безопасно для production
Дольше обычного создания — два прохода + ожидание транзакций
Нельзя в транзакции — требует автономного выполнения
Всегда используйте в production — DROP INDEX CONCURRENTLY тоже
Мониторьте прогресс — через pg_stat_activity и pg_index

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

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

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

Время создания индекса для 100 млн записей: 30 минут В это время: ✅ SELECT — работают ❌ INSERT — ждут 30 минут ❌ UPDATE — ждут 30 минут ❌ DELETE — ждут 30 минут

Операция

CREATE INDEX

CREATE INDEX CONCURRENTLY

SELECT

✅ Работает

INSERT

❌ Блокируется

✅ Работает

UPDATE

❌ Блокируется

✅ Работает

DELETE

❌ Блокируется

✅ Работает

┌─────────────────────────────────────────────────┐ │ PASS 1: Сканирование таблицы │ │ - Строится основная структура индекса │ │ - Запись не блокируется │ │ - Новые данные отслеживаются │ └─────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────┐ │ PASS 2: Обработка новых данных │ │ - Короткая блокировка ShareUpdateExclusiveLock │ │ - Применяются изменения с Pass 1 │ │ - Индекс становится видимым │ └─────────────────────────────────────────────────┘

Операция

CONCURRENTLY

Без CONCURRENTLY

CREATE INDEX

✅ Не блокирует запись

❌ Блокирует запись

DROP INDEX

✅ Не блокирует запись

❌ Блокирует запись

REINDEX INDEX

✅ Не блокирует запись (12+)

❌ Блокирует запись

CREATE INDEX UNIQUE

✅ Не блокирует запись

❌ Блокирует запись

ALTER INDEX

⚠️ Зависит от операции