Практическое использование уровня изоляции Seralization?

Question

В каких сценариях мы используем SERIALIZABLE Isolation level? Я видел несколько ответов на веб-сайте, где говорится, что если вы хотите полностью изолировать транзакцию, мы обычно идем на это.

То, что я хотел бы знать по собственному опыту, заключается в том, что, когда вы использовали это в своих проектах/или вы видели, что это используется в других проектах, и каково конкретное требование, которое не выполнялось другими уровнями изоляции?

Answer 1

SERIALIZABLE полезен при создании сложных отчетов, требующих нескольких запросов.

В READ COMMITTED или REPEATABLE READ в запросах можно увидеть изменения, произошедшие между начатой ​​транзакцией и моментом их запуска.

pg_dump, утилита PostgreSQL свалки, начинает его работу с выдачей SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, чтобы гарантировать, что состояние базы данных выбрасывали бы, что на данный момент утилита была запущена, и последующие изменения в базу данных не могут вмешиваться в свалка.

Answer 2

Сериализуемые транзакции полезны, если вы хотите простое доказательство правильности при одновременных нагрузках. Поскольку определение уровня изоляции сериализуемых транзакций в стандарте SQL (начиная с SQL-92) заключается в том, что поведение любого параллельного набора сериализуемых транзакций должно быть согласовано с каким-то порядковым (последовательным) порядком исполнения, любым транзакция, которая может быть показана, чтобы делать правильные вещи, когда она выполняется сама по себе, будет делать правильную вещь как часть любого сочетание сериализуемых транзакций.

Для этой защиты существует стоимость - транзакции должны блокироваться или откатываться для повторной попытки время от времени, чтобы обеспечить сериализуемую изоляцию транзакции, а информацию необходимо отслеживать, чтобы определить, когда необходимо предпринять такие действия. В некоторых средах разработки с небольшим количеством типов транзакций и небольшим числом разработчиков часто более экономично использовать менее строгий уровень изоляции и явно управлять условиями гонки в коде приложения. После того, как у вас есть десятки программистов, работающих против схемы с сотнями таблиц и десятками тысяч типов транзакций, стоимость определения того, где существуют условия гонки, может стать ошеломляющей при менее строгих уровнях изоляции, и обычно становится более экономичным использовать сериализуемые транзакции ,

В настоящее время наиболее часто реализуемым методом предоставления сериализуемых транзакций является строгая двухфазная блокировка (S2PL), которая опирается на блокирующие блокировки, удерживаемые до конца каждой транзакции, и обнаружение блокировки с откатами для разблокировки взаимоблокировок. В нагрузках с очень небольшим количеством конфликтов записи может использоваться оптимизированный контроль параллелизма (OCC). Он отслеживает «прочитанный набор» во время транзакции и откатывается, если любая другая транзакция изменяет набор чтения. Некоторые продукты баз данных относятся к изоляции моментальных снимков как сериализуемые, хотя на самом деле не обеспечивают гарантий, требуемых стандартом SQL. Новый метод, называемый Serializable Snapshot Isolation (SerializableSI или SSI), был впервые описан в учебном документе, представленном в 2008 ACM SIGMOD, и используется в PostgreSQL версии 9.1 и более поздних версиях. Он использует изоляцию моментальных снимков и отслеживание шаблонов зависимостей чтения и записи, чтобы определить, когда транзакция должна быть отменена. Существуют другие методы, которые встречаются реже в производстве. Каждый из них имеет свой собственный набор преимуществ и недостатков, предоставляя другую точку безубыточности для такого вопроса.