Снимок данных: числа и правила видимости

Частое заблуждение: «снимок - это фотография таблицы на момент старта транзакции». Если бы это было так, каждая транзакция копировала бы базу целиком - на больших данных немыслимо дорого.

На деле снимок - это компактный набор чисел. По ним и по версионным полям каждой строки (xmin/xmax, см. tuple-header) транзакция вычисляет на лету, видеть ей конкретную версию или нет. Ничего не копируется: видимость не хранится, а считается. Полный разбор - в snapshot.

Посмотрим на снимок своими глазами:

SELECT pg_current_snapshot();

-- 787:787:

Формат - xmin:xmax:список. Три части:

• xmin снимка - граница, ниже которой все транзакции уже решены (зафиксированы или откатились);
• xmax снимка - граница, начиная с которой транзакций ещё не было на момент снимка;
• список - идентификаторы транзакций между xmin и xmax, которые шли прямо в момент снимка.

В примере оба числа равны и список пуст - рядом никого. Под нагрузкой это выглядело бы как 100:105:101,103: три активных границы и две транзакции в работе.

Снимок делит все транзакции на три зоны относительно момента, когда он взят:

Всё ниже xmin - прошлое: результат известен. Всё в списке - настоящее: транзакция идёт сейчас, её результат ещё не виден. Всё выше или равно xmax - будущее: на момент снимка не начиналось, поэтому невидимо. Снимок - это и есть набор границ, разделяющий эти три зоны.

Теперь соберём снимок и поля строки вместе. Версия видна, если её xmin:

• меньше xmin снимка - точно в прошлом, и если та транзакция закоммитилась, версия годится; либо
• между xmin и xmax снимка, не в списке активных, и зафиксирован по clog.

И при этом xmax версии не должен быть «уже зафиксированным в прошлом» - иначе версия удалена с точки зрения снимка. Полные правила для пары полей - в xmin-xmax. Главное: одни и те же версии на диске разные транзакции видят по-разному, потому что у каждой свой снимок, а правило одно на всех.

Раз снимок - это просто числа, его можно отдать другой сессии, чтобы обе видели данные в одинаковом срезе времени.

-- сессия 1, внутри открытой транзакции

SELECT pg_export_snapshot();

-- 00000006-00000002-1

-- сессия 2

BEGIN ISOLATION LEVEL REPEATABLE READ;

SET TRANSACTION SNAPSHOT '00000006-00000002-1';

-- теперь сессия 2 видит данные так же, как сессия 1

Так работает параллельный pg_dump: ведущий процесс экспортирует снимок, рабочие подхватывают его и выгружают разные таблицы из одного среза времени, получая согласованную копию. Детали и условия - в snapshot-export.

Момент взятия снимка зависит от уровня изоляции. На уровне по умолчанию (Read Committed) новый снимок берётся на каждый оператор - поэтому соседний SELECT в той же транзакции может увидеть свежие чужие коммиты. На Repeatable Read и Serializable снимок берётся один раз на транзакцию и держится до конца: сколько ни перечитывай, картина та же.

Это прямое продолжение опыта из прошлой главы и тема следующей - isolation-levels. Запомни связь: уровень изоляции - это, по сути, политика «когда обновлять снимок».

Снимок дёшев по памяти - это несколько чисел. Но построить его не бесплатно: чтобы узнать список активных транзакций, сервер обходит структуру со всеми работающими процессами. Чем больше открытых соединений, тем дороже взять снимок, а берётся он часто - как минимум на каждую транзакцию, а на Read Committed на каждый оператор.

Отсюда неочевидное следствие: тысячи почти простаивающих соединений вредят, даже когда «ничего не делают». Каждое из них утяжеляет снимок всем остальным. Это ещё один довод за умеренный пул соединений, который мы упоминали в части про процессы. Связь прямая: много соединений - дорогие снимки - медленнее вся система.