Комментарии 12
И тут, блин, изоляция! ппц
Помимо преподавания, как вы могли заметить, я занимаюсь написанием авторского материала для блога OTUS на хабре и сегодняшнюю статью хочу приурочить к запуску курса «PostgreSQL», на который прямо сейчас открыт набор.
Интересно, как соотносится изложенный в статье обзор методов изоляции транзакций на основе блокировок, используемых в традиционной архитектуре реляционных DBMS (таких как MS SQL Server) и материал курса по PostgreSQL, который, насколько мне известно, использует другой метод изоляции — на основе создания версий записей базы данных.
И если никак — то зачем вообще тогда упомянут курс по PostgreSQL?
MS SQL не обязательно использует уровни на блокировках — см. snapshot isolation.
В общем, вы слишком грубо подходите к вопросу.
В статье ценно то, что упомянута неполнота схемы уровней ISO, хотя тут… мне кажется, спецы и так это знают, а неспецам надо детальнее разжевать.
За PostgreSQL не скажу — не знаю, но я вот лет примерно 20 назад довольно много работал с другой СУБД с многоверсионной схемой хранения — Interbase, и там были весьма заметные отличия от классической схемы (и кстати, snapshot isolation в MS SQL, реализованном по этой схеме, тогда ещё не было, и это было одной из причин выбора Interbase).
В частности, блокировки записей в таблице практически отсутствовали, даже когда были нужны (была однажды у нас такая задача, что блокировка потребовалась). Единственный способ добиться блокировки между разными транзакициями, который я тогда нашел — это изменение в разных транзакциях одной и той же специально выделенной для этого записи: пока первая изменившая запись транзакция активна, изменение записи во второй висит на блокировке в ожидании завершения (и тогда происходит ошибка) или отката (тогда операция успешно завершается) первой транзакции.
В статье ценно то, что упомянута неполнота схемы уровней ISOСогласен, всех возможных ограничений на содержимое БД схема уровней ISO не поддерживает. В частности, последний упомянутый в статье случай лежит за пределами этой схемы — в ней просто не предусмотрены ограничения на все записи таблицы по произвольному условию, а подерживаются только некоторые варианты таких ограничений: UNIQUE/PRIMARY KEY/FOREIGN KEY. Собственно, по этой причине нам тогда и понадобилась блокировка — для поддержки выходящих за рамки схемы ISO ограничений, порожденых бизнес-логикой.
*не преследую цель подушнить искренне этого не хочу, преследую цель обсудить*
В статье ценно то, что упомянута неполнота схемы уровней ISO, хотя тут… мне кажется, спецы и так это знают, а неспецам надо детальнее разжевать.
Возможно эту часть стоит вынести в начало статьи, тоже стал задаваться вопросом ценности статьи, в той же "Postgres изнутри" об уровнях изоляции написано, и когда разбираешься в вопросе, там или ISO догоняет реалии, или ISO не достаточно или при составлении ISO не увидели какие ситуацию еще могут быть. Не знаю у как других, но меня в процессе обучения сильно успокаивало, когда видел, что дурак не только я. Простое знание "при составление ISO не подумали" — успокаивает. Вот даже когда пишу коммент, лишний раз задумываюсь о том, дурак я или нет — жесть, одним словом.
неспецам надо детальнее разжевать.
Тут мне кажется еще сложнее, допустим, тут использовали диаграмму Ганта, чтобы передать то как происходит чтение данных, показывают таблицы и SQL запросы и как все это связано со временем, в целом — понятно, но не понятно тогда кто такой "НЕспециалист".
Потому что читающий в виде меня:
Насмотрен на диаграммы Ганта
Знает синтаксис SQL
Знает, что базы данных внутри могут поддерживать(или не поддерживать) уровни изоляции, да и в целом, базы данных в целом могут не поддерживать SQL и документо-ориентированные бд тоже нуждаются в изоляции(забавно) UPD: Была отличная статья которая рассказывала о том как MongoDB применяла "аналог ACID" в маркетинговых целях
В моей практике при работе со студентами и начинающими специалистами к каким только хитростям не нужно приходить, чтобы стало понятно, собственно, пока вижу что побеждают хорошо продуманные визуальные образы или анимации, они более емкие
Я, в целом, сильно за, чтобы был какой-то набор правил или софт, чтобы можно было гибче выбирать уровень детализации который в моменте нужен, потому что каждый раз писать, чтобы всем было понятно — труд сложнее любой работы.
По-поводу курса, захожу на сайт.
Что требуют перед изучением курса:
Опыт работы с Linux на уровне пользователя и базовое представление об SQL
Окей, у Postgres и Clickhouse — восхитительное комьюнити которые многие другие могут позавидовать, ребята огромные молодцы
Есть серия книг, опять таки, аналогичных этой, там даже показывают примеры на банковских операциях.
Что смущает, вы пишите целый курс, и делаете вводную статью, на диаграмму ниже потратил 5 минут(просто потому что, все инструменты под рукой)
Выводы сделать трудно, хочется рубить с плеча, только из-за того что, вводная к курсу, в моем понимании курс это работа методистов, психологов, дизайнеров, профессионалов и многократная проверка материала, поэтому, просто надеюсь, что этот комментарий был хоть кому-то полезен
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, как гласит надпись в рисунке.
Желаю успехов и новых содержательных публикаций.
К чему может привести ослабление уровня изоляции транзакций в базах данных