> Что такое MVCC в PostgreSQL (Go)

Короткий ответ

MVCC (Multi-Version Concurrency Control) - механизм в PostgreSQL, который позволяет нескольким транзакциям одновременно читать и изменять данные без блокировок на чтение. Каждая транзакция видит согласованный снимок базы данных на момент её начала. При изменении строки создаётся новая версия, а старая остаётся доступной для транзакций, начавшихся раньше. Это обеспечивает изоляцию и высокую конкурентность.

Подробное объяснение

MVCC в PostgreSQL реализован через хранение нескольких версий строк. Каждая строка имеет скрытые системные колонки:

• xmin - идентификатор транзакции, создавшей версию
• xmax - идентификатор транзакции, удалившей или изменившей версию

Когда транзакция выполняет UPDATE, PostgreSQL создаёт новую версию строки с xmin текущей транзакции, а у старой версии проставляет xmax. При DELETE просто проставляется xmax.

Версия строки видима транзакции, если:

• xmin - это завершённая (committed) транзакция, и она началась раньше текущей
• xmax пуст или это незавершённая транзакция, либо транзакция, начавшаяся позже текущей

Для проверки видимости используется структура snapshot - снимок состояния системы на момент начала транзакции. Снимок содержит список активных транзакций.

Устаревшие версии строк периодически удаляются процессом VACUUM, который запускается автоматически или вручную. Это предотвращает бесконечный рост таблиц.

На практике

В Go с драйвером pgx или database/sql MVCC работает прозрачно - вы просто выполняете SQL-запросы. Но важно понимать поведение при конкурентных операциях:

• Две транзакции могут читать одни и те же строки без блокировок
• При попытке двух транзакций обновить одну строку одна из них получит ошибку serialization_failure (при уровне изоляции SERIALIZABLE) или будет ждать блокировку (при READ COMMITTED)
• Долгие транзакции препятствуют очистке старых версий - таблица может "раздуться"

На практике для Go-приложений важно:

• Использовать короткие транзакции
• Настраивать autovacuum для активных таблиц
• При высоком конкурентном обновлении одной строки использовать оптимистичную блокировку с проверкой версии

Пример кода

GO
// Оптимистичная блокировка с использованием MVCC
// Предположим, таблица users имеет колонку version

type User struct {
    ID      int
    Name    string
    Version int
}

func UpdateUserName(ctx context.Context, db *sql.DB, userID int, newName string) error {
    // Начинаем транзакцию
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    defer tx.Rollback()

    // Читаем текущую версию строки
    var currentVersion int
    err = tx.QueryRowContext(ctx,
        "SELECT version FROM users WHERE id = $1 FOR UPDATE", userID,
    ).Scan(&currentVersion)
    if err != nil {
        return err
    }

    // Обновляем строку, проверяя версию
    result, err := tx.ExecContext(ctx,
        "UPDATE users SET name = $1, version = version + 1 WHERE id = $2 AND version = $3",
        newName, userID, currentVersion,
    )
    if err != nil {
        return err
    }

    rowsAffected, _ := result.RowsAffected()
    if rowsAffected == 0 {
        return fmt.Errorf("конфликт версий: строка была изменена другой транзакцией")
    }

    return tx.Commit()
}

Как отвечать на собеседовании

Начните с простого определения: MVCC позволяет читать данные без блокировок за счёт хранения нескольких версий строк. Затем объясните механизм через xmin/xmax и снимки транзакций. Упомяните, что это даёт высокую конкурентность чтения и записи. Если спросят про недостатки - скажите про разрастание таблиц и необходимость VACUUM. Для уровня junior достаточно понимания базовой идеи и видимости версий.

Что проверяет интервьюер

Интервьюер проверяет:

• Понимаете ли вы, зачем нужен MVCC (конкурентность без блокировок чтения)
• Знаете ли вы базовые механизмы (xmin, xmax, snapshot)
• Понимаете ли разницу между уровнями изоляции в контексте MVCC
• Знаете ли про VACUUM и проблему "раздувания" таблиц
• Умеете ли объяснить простыми словами, что видит транзакция

Типичные ошибки

• Путаница между MVCC и блокировками - MVCC не отменяет блокировки полностью, он убирает блокировки на чтение
• Утверждение, что MVCC хранит полные копии строк - на самом деле хранятся только изменённые версии
• Непонимание, почему долгие транзакции вредны - они блокируют очистку старых версий
• Смешивание MVCC с механизмом SELECT ... FOR UPDATE - это разные вещи, FOR UPDATE использует блокировки поверх MVCC
• Забывают упомянуть VACUUM как обязательную часть работы MVCC