Сравнение: чем отличается снимок данных, создаваемый для каждого оператора, от снимка, закреплённого за всей транзакцией?
При снимке на уровне оператора каждый оператор видит состояние данных на момент собственного начала, поэтому два чтения в одной транзакции могут получить разные результаты. При снимке на уровне транзакции все чтения используют одно логическое состояние данных, сформированное в начале транзакции, поэтому повторное чтение обычно видит тот же набор зафиксированных версий.
Это различие определяет компромисс между более свежими данными и стабильностью чтения. Точная реализация зависит от СУБД: снимки часто реализуются через MVCC, но некоторые уровни изоляции могут использовать блокировки или их сочетание.
В многопользовательских системах возникла необходимость одновременно обслуживать короткие OLTP-запросы и длительные чтения, например отчёты. Если каждый читатель блокирует изменяемые строки, отчёты снижают пропускную способность; если блокировки почти не применяются, один отчёт может собрать данные из разных состояний.
Разделение снимков по времени позволило явно выбирать поведение. Снимок оператора уменьшает устаревание данных и обычно даёт больше конкурентности, а снимок транзакции обеспечивает стабильную картину для последовательности связанных чтений.
Представим отчёт, который сначала получает список заказов, а затем отдельными операторами читает платежи и статусы этих заказов. Между операторами другая транзакция может зафиксировать изменения.
При снимках на уровне операторов отчёт способен увидеть старый список заказов, но уже новые платежи или статусы. Каждый оператор по отдельности может быть согласованным, однако весь отчёт окажется собранным из разных временных срезов.
Снимок на уровне транзакции устраняет эту проблему для обычных чтений, но может увеличить время жизни версий данных, конфликтность записи или вероятность ошибки сериализации. Поэтому более сильная стабильность не является бесплатной.
При операторном снимке момент видимости определяется началом конкретного оператора. Зафиксированные до этого момента изменения видимы, а зафиксированные позже обычно не видимы этому оператору. Следующий оператор получает новый момент видимости и потому может увидеть дополнительные фиксации.
При транзакционном снимке момент видимости выбирается один раз для транзакции. Все последующие чтения используют его, за исключением собственных изменений транзакции, которые обычно должны быть видимы самой транзакции. Изменения, зафиксированные после создания снимка, не становятся видимыми обычным чтениям до завершения транзакции.
В терминах распространённой модели MVCC читатель выбирает подходящую версию строки, а не обязательно ждёт освобождения блокировки записи. Это не означает отсутствия конфликтов: запись может быть отклонена, ожидать блокировку или потребовать повторения транзакции — конкретное поведение определяется СУБД и уровнем изоляции.
Операторный снимок подходит для независимых запросов, которым важна актуальность каждого результата. Транзакционный снимок предпочтителен для многошагового расчёта, где результаты должны относиться к одной логической картине. Для строгой сериализуемости одного фиксированного снимка может быть недостаточно: параллельные транзакции способны нарушить ограничение через взаимосвязанные записи, если механизм не проверяет сериализуемость.
Сервис формирует финансовый отчёт несколькими запросами: отдельно читает счета, затем операции, затем вычисляет итоговые остатки. При операторных снимках новый платёж, зафиксированный между запросами, может попасть в расчёт, хотя соответствующая версия списка счетов была прочитана раньше.
Можно добавить блокировки чтения. Это даст более сильную координацию, но будет задерживать платежи и ухудшать пропускную способность. Можно объединить расчёт в один оператор, однако такой вариант не всегда реалистичен из-за сложности запроса.
Выбран транзакционный снимок, поскольку отчёт должен быть внутренне согласованным, а блокировка рабочих записей недопустима. Компромисс — контролировать длительность отчёта и нагрузку на хранение версий; для операций, меняющих данные, дополнительно обрабатывать конфликты и повторять транзакцию, если это требует выбранная СУБД.
Нет. Его цель — стабильность, а не максимальная актуальность. После создания снимка другие транзакции могут зафиксировать изменения, но обычные чтения текущей транзакции их не увидят. Это предсказуемая цена повторяемости чтения.
Да. Каждый оператор может видеть согласованное состояние на свой момент начала, но эти моменты различаются. Поэтому набор результатов разных операторов не обязан соответствовать одному состоянию базы. Для связанных чтений нужен общий снимок, один атомарный оператор либо явная координация.
Нет, не всегда. Если две транзакции читают один и тот же снимок, независимо принимают решение и изменяют разные строки, фиксированный снимок может сохранить обе записи, хотя их совокупность нарушит правило. Для такого случая нужны блокировки подходящего диапазона или строк, явная проверка конфликта, ограничение базы данных либо режим SERIALIZABLE, способный обнаружить несовместимое выполнение.