Pull to refresh

Comments 11

да что вы сразу. Просто прикольно ассоциируется же. Злободневно. Здоровья всем=)

Очень жаль, что вы принципиально не разбираете, в чем физический смысл и почему уровней изоляции и аномалий в данных именно такое количество. Наверное, не знаете, почему?
Вы про способы реализации различных уровней и различных overhead'ов с ними связанных? Или я вас неправильно понял? Я думаю, что все были бы рады, если бы вы поделились своими знаниями)
Помимо преподавания, как вы могли заметить, я занимаюсь написанием авторского материала для блога OTUS на хабре и сегодняшнюю статью хочу приурочить к запуску курса «PostgreSQL», на который прямо сейчас открыт набор.

Интересно, как соотносится изложенный в статье обзор методов изоляции транзакций на основе блокировок, используемых в традиционной архитектуре реляционных DBMS (таких как MS SQL Server) и материал курса по PostgreSQL, который, насколько мне известно, использует другой метод изоляции — на основе создания версий записей базы данных.
И если никак — то зачем вообще тогда упомянут курс по PostgreSQL?
PostgresQL, да, имеет специфику хранения, но в результате у него только исключается read uncommitted — старые версии не выдаются. Остальные уровни у него формально по ISO.
MS SQL не обязательно использует уровни на блокировках — см. snapshot isolation.
В общем, вы слишком грубо подходите к вопросу.

В статье ценно то, что упомянута неполнота схемы уровней ISO, хотя тут… мне кажется, спецы и так это знают, а неспецам надо детальнее разжевать.
Благодарю за ответ.
За PostgreSQL не скажу — не знаю, но я вот лет примерно 20 назад довольно много работал с другой СУБД с многоверсионной схемой хранения — Interbase, и там были весьма заметные отличия от классической схемы (и кстати, snapshot isolation в MS SQL, реализованном по этой схеме, тогда ещё не было, и это было одной из причин выбора Interbase).
В частности, блокировки записей в таблице практически отсутствовали, даже когда были нужны (была однажды у нас такая задача, что блокировка потребовалась). Единственный способ добиться блокировки между разными транзакициями, который я тогда нашел — это изменение в разных транзакциях одной и той же специально выделенной для этого записи: пока первая изменившая запись транзакция активна, изменение записи во второй висит на блокировке в ожидании завершения (и тогда происходит ошибка) или отката (тогда операция успешно завершается) первой транзакции.

В статье ценно то, что упомянута неполнота схемы уровней ISO
Согласен, всех возможных ограничений на содержимое БД схема уровней ISO не поддерживает. В частности, последний упомянутый в статье случай лежит за пределами этой схемы — в ней просто не предусмотрены ограничения на все записи таблицы по произвольному условию, а подерживаются только некоторые варианты таких ограничений: UNIQUE/PRIMARY KEY/FOREIGN KEY. Собственно, по этой причине нам тогда и понадобилась блокировка — для поддержки выходящих за рамки схемы ISO ограничений, порожденых бизнес-логикой.
Половина аномалий это не проблема базы данных. Выбрал самый дешёвый товар, через секунду добавили дешевле. В чем разница происходила выборка одновременно со вставкой или через секунду? Это реалии, а не аномалии.
Примеры с Алисой и Бобом — это «в огороде бузина, а в Киеве — дядька». Хотите, чтобы дядька был когерентен бузине — держите XLOCK на бузину, пока обрабатываете дядьку, либо включайте условие бузины прямо в стейтмент обработки дядьки. В случае докторов — если нам нужно, чтобы в смену 111 дежурило не меньше 1 доктора, то в условие апдейта кроме ID смены нужно добавить "… and exists(select 1 from doctors where shiftID = 111 and doctorid <> <наш_доктор>)" — апдейт автоматически наложит XLOCK на весь контекст, который нужен для того, чтобы гарантированно проверить предикат — и если update вернет 0 записей — значит, нас перехватили.

SQL-транзакция не гарантирует бизнес-когерентности. И даже не гарантирует бизнес-целостности. Она лишь гарантирует, что все действия, которые были в ней сделаны с данными, либо будут применены, либо будут откатаны — то есть техническую когерентность и целостность данных
Спасибо за статью.
Из пожеланий хотелось бы увидеть, как описанные аномалии решаются в PostgreSQL, если вы приурочили статью к запуску этого курса. В частности, как PostgreSQL поддерживает Serializable Snapshot Isolation (SSI) и Snapshot Isolation через уровни изоляции SERIALIZABLE и REPEATABLE READ.
Тема транзакций хорошо разобрана в книге Martin Kleppmann «Designing Data-Intensive Applications». Судя по всему часть примеров взята из неё.

Пара мелких штрихов:
Phantom read. Все-таки reads в английской терминалогии.
Там же. Insert where(?), понятно что вы хотели сказать, но синтаксис есть синтаксис.
Read skew. Изначально, исходя из таблицы, updated_by равно Alice, а не T0, как гласит надпись в рисунке.
Желаю успехов и новых содержательных публикаций.

Sign up to leave a comment.