Смотрю видео после прочтения документации и других видео. Оно помогло мне уложить эти знания в голове правильным образом. Спасибо докладчику. Мне понравилось
Смотрю курс и параллельно заглядываю в книгу Рогова - так намного яснее. Проработка каждого видео занимает от 2х часов. Материал обзорный, собран в курсе отлично. Спасибо большое!
Изоляции транзакций стоит уделять особое внимание при написании приложений: конкурентное обновление данных часто приводит к несогласованности итогового результата. И нужно поднимать уровень изоляции до REPEATABLE READ, либо прибегать к append only стратегии, либо сжимать чтение и обновление до одного запроса (тут возможны подводные камни).
Во втором случае в Т1 мы не увидим, что строка была удалена в Т2. Потому что уровень Repeatable Read создает снимок базы на момент выполнения ПЕРВОГО оператора в транзакции, то есть первого SELECT, когда запись еще не удалили в Т2. И этот снимок останется для Т1 на все время выполнения Т1. Она да, может уже работать с устаревшими данными, но благодаря этому устраняется проблема Phantom Read, когда Т1 сначала прочитала, что строка есть. А потом во второй раз в этой же транзакции прочитала, а строки уже нет.
2:20 Если оператор UPDATE состоит из двух операторов: DELETE и INSERT, то почему тогда при операции UPDATE у нас запись, имеющая колонки по умолчанию (например, дата), не обновляется?
UPDATE - это _как бы_ DELETE + INSERT. Так удобно себе представлять, что происходит с версиями строк. Но на самом деле это, конечно, отдельный оператор, он не выполняет буквально DELETE и INSERT.
В голове после лекции остался туман. Я понимаю, человек старался, но приходится нереально сильно напрягаться и часто додумывать за лектора... Пойду почитаю документацию, чтобы восполнить.
слабовато объяснение, посмотрите для пример объяснения Федора Самородова из УЦ Специалист для Read Committed Snapshot Isolation для будущих версий обучающих курсов. Все же версионность - важнейшая фича современных реляционных баз данных.
@@afedot9557 Это на курсах УЦ Специалист. Они денег стоят, но возможно уже выложили на торрентах. Когда то был популярен nnmclub, давно туда не заходил.
Вероятно в первый раз рассказывает и сразу "под запись". Многие бы занервничали (я в первый раз нервничал еще сильнее кажется). Человек попривыкнет, расслабится, наберется опыта и станет слушать его приятнее. Будьте снисходительны к докладчику, пожалуйста. Ну и вопросы и прочее можно потом в личку отправить. Прошу прощения, возможно это только мое мнение, но обычно так происходит.
Эта лекция очень сильно сбивает с толку. В 4:30 вы разбираете пример со строкой 2 и говорите, что снимок был сделан на момент, когда актуальной версией была версия №2 (вторая точка на прямой). Потом появляется версия №3 (третья точка на прямой). Вы говорите, что мы не берем ее во внимание, т.к. снимок мы сделали на момент, когда была версия №2. Далее в 12:37 мы вроде как разбираем на практике такой же пример, что и на 4:30, но тут изменения из транзакции 2 МЕНЯЮТ снимок транзакции 1. И вот тут просто происходит когнитивный диссонанс. Почему изменения второй транзакции поменяли снимок 1? Вроде же только что (4:30) говорили, что снимок 1 не должен зависеть от других изменений. Я считаю, что в лекции следовало объяснить, что снимок создается не ОДИН РАЗ на транзакцию, а при каждом вызове SELECT *, xmin, xmax FROM t. Тогда всё встает на свои места. И еще один момент, который неочевиден. На схеме, которая приведена на 4:30 непонятно как интерпретировать пунктирную линию которая перпендикулярно пересекает две прямые строка 1 и строка 2. Все время кажется, что все эти три примера (строка 1, строка 2, строка 3) надо вместе рассматривать. На самом деле это абсолютно независимые примеры. Я бы подчеркнул, что они рассматриваются ОТДЕЛЬНО. Можно их как-то по очереди выводить анимацией или на отдельных слайдах. Спасибо за видео!
Смотрю видео после прочтения документации и других видео. Оно помогло мне уложить эти знания в голове правильным образом. Спасибо докладчику. Мне понравилось
Смотрю курс и параллельно заглядываю в книгу Рогова - так намного яснее. Проработка каждого видео занимает от 2х часов. Материал обзорный, собран в курсе отлично. Спасибо большое!
какая именно книга?
Изоляции транзакций стоит уделять особое внимание при написании приложений: конкурентное обновление данных часто приводит к несогласованности итогового результата. И нужно поднимать уровень изоляции до REPEATABLE READ, либо прибегать к append only стратегии, либо сжимать чтение и обновление до одного запроса (тут возможны подводные камни).
Или использовать дополнительные блокировки. Все так.
версия лекции с другим лектором th-cam.com/video/Xe5DEANmad8/w-d-xo.html
Cпасибо
Во втором случае в Т1 мы не увидим, что строка была удалена в Т2. Потому что уровень Repeatable Read создает снимок базы на момент выполнения ПЕРВОГО оператора в транзакции, то есть первого SELECT, когда запись еще не удалили в Т2. И этот снимок останется для Т1 на все время выполнения Т1. Она да, может уже работать с устаревшими данными, но благодаря этому устраняется проблема Phantom Read, когда Т1 сначала прочитала, что строка есть. А потом во второй раз в этой же транзакции прочитала, а строки уже нет.
2:20
Если оператор UPDATE состоит из двух операторов: DELETE и INSERT, то почему тогда при операции UPDATE у нас запись, имеющая колонки по умолчанию (например, дата), не обновляется?
UPDATE - это _как бы_ DELETE + INSERT. Так удобно себе представлять, что происходит с версиями строк. Но на самом деле это, конечно, отдельный оператор, он не выполняет буквально DELETE и INSERT.
В голове после лекции остался туман. Я понимаю, человек старался, но приходится нереально сильно напрягаться и часто додумывать за лектора... Пойду почитаю документацию, чтобы восполнить.
слабовато объяснение, посмотрите для пример объяснения Федора Самородова из УЦ Специалист для Read Committed Snapshot Isolation для будущих версий обучающих курсов. Все же версионность - важнейшая фича современных реляционных баз данных.
а ссылочку не можете пошарить а то что-то не нагуглил
@@afedot9557 Это на курсах УЦ Специалист. Они денег стоят, но возможно уже выложили на торрентах. Когда то был популярен nnmclub, давно туда не заходил.
Докладчик нервничает, из-за этого не совсем приятно слушать. И самое главное, что непонятно было рассказано про снимки.
Вероятно в первый раз рассказывает и сразу "под запись". Многие бы занервничали (я в первый раз нервничал еще сильнее кажется). Человек попривыкнет, расслабится, наберется опыта и станет слушать его приятнее. Будьте снисходительны к докладчику, пожалуйста. Ну и вопросы и прочее можно потом в личку отправить. Прошу прощения, возможно это только мое мнение, но обычно так происходит.
Эта лекция очень сильно сбивает с толку. В 4:30 вы разбираете пример со строкой 2 и говорите, что снимок был сделан на момент, когда актуальной версией была версия №2 (вторая точка на прямой). Потом появляется версия №3 (третья точка на прямой). Вы говорите, что мы не берем ее во внимание, т.к. снимок мы сделали на момент, когда была версия №2.
Далее в 12:37 мы вроде как разбираем на практике такой же пример, что и на 4:30, но тут изменения из транзакции 2 МЕНЯЮТ снимок транзакции 1. И вот тут просто происходит когнитивный диссонанс. Почему изменения второй транзакции поменяли снимок 1? Вроде же только что (4:30) говорили, что снимок 1 не должен зависеть от других изменений.
Я считаю, что в лекции следовало объяснить, что снимок создается не ОДИН РАЗ на транзакцию, а при каждом вызове SELECT *, xmin, xmax FROM t. Тогда всё встает на свои места.
И еще один момент, который неочевиден. На схеме, которая приведена на 4:30 непонятно как интерпретировать пунктирную линию которая перпендикулярно пересекает две прямые строка 1 и строка 2. Все время кажется, что все эти три примера (строка 1, строка 2, строка 3) надо вместе рассматривать. На самом деле это абсолютно независимые примеры. Я бы подчеркнул, что они рассматриваются ОТДЕЛЬНО. Можно их как-то по очереди выводить анимацией или на отдельных слайдах.
Спасибо за видео!
Паша с Егором пошли в кафе, а этому пришлось отдуваться за лекцию))
учебные материалы: edu.postgrespro.ru/dev1-12/dev1_03_arch_mvcc_overview.html