Oberon space
General Category => Общий раздел => Тема начата: Valery Solovey от Апрель 13, 2012, 03:44:38 pm
-
Вердикт такой:
СУБД либо ведет журнал транзакций, либо не отвечает требованиям ACID.
Что вы подразумеваете под журналом? Обычно, журнал - это Log. Журналал транзакций не обязателен, чтобы выполнять условия ACID. Или какое из условий по-вашему перестаёт удовлетвораться?
-
Журналал транзакций не обязателен, чтобы выполнять условия ACID
Это как? Возможно я заблуждаюсь конечно, но я таких СУБД не знаю.
Кузнецов - Основы современных баз данных:
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с
особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на
разных физических дисках), в которую поступают записи обо всех изменениях основной
части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда
запись в журнале соответствует некоторой логической операции изменения БД (например,
операции удаления строки из таблицы реляционной БД), иногда - минимальной
внутренней операции модификации страницы внешней памяти; в некоторых системах
одновременно используются оба подхода.
Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так
называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается
в том, что запись об изменении любого объекта БД должна попасть во внешнюю память
журнала раньше, чем измененный объект попадет во внешнюю память основной части БД.
Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью
журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго
говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для
каждой транзакции поддерживать локальный журнал операций модификации БД,
выполненных в этой транзакции, и производить откат транзакции путем выполнения
обратных операций, следуя от конца локального журнала. В некоторых СУБД так и
делают, но в большинстве систем локальные журналы не поддерживают, а
индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все
записи от одной транзакции связывают обратным списком (от конца к началу).
-
Или какое из условий по-вашему перестаёт удовлетвораться?
Целостность
-
Вообще-то, то, что у Кузнецова названо локальным журналом по сути является стеком. Для отката транзакций. Это не журнал, и журнал для этого не нужен. После завершения транзакции этот стек можно просто почистить. А при запуске после аварийного завершения откатить всё по стеку.
Про другие аварии в СУБД не знаю, поэтому не могу сказать, нужен ли там журнал.
-
Все проще. :)
Да. Журнал - это стек и есть.
Исторически просто выбран неудачный термин. Возможно за бугром слово Log несколько другую смысловую нагрузку несет нежели у нас. Не знаю. Но в литературе по теории баз данных механизм обеспечивающий откат транзакций называется логированием (или протоколированием).
см. Гарсиа Молина - Системы баз данных.
В общем случае для поддержки отката записи в журнале можно удалять после фиксации транзакции. Тут конечно все сложнее, т.к. транзакции еще и вложенными могут быть например... Но в простейшем случае это так.
В версионниках роль журнала выполняют версии, и после фиксации транзакции происходит сборка мусора, т.е. старые записи помечаются и впоследствии затераются другими данными.
Кроме того журнал, помимо обеспечения отката нагружают и другими функциями (касающиеся надежности обычно).
Все это вносит некоторую путаницу.
Кузнецов использует слово "журнал", т.к. это уже общепринятый термин. Хоть и неудачный.
Мы просто привыкли что лог - это что-то сбоку, т.е. какие-то дополнительные сведения не связанные с алгоритмом (или просто сообщения о выполняемых действиях).
Но в случае транзакций журнал (версии) - это алгоритм и есть.
Нет журнала - нет отката и следовательно нет транзакции.
-
Вот выдержка из книги "Системы баз данных"
-
Упс. Не рассчитал :(
valexey, можно исправить?
-
Вот тут очень интересные сведения о журнале:
Семейство алгоритмов ARIES (http://citforum.ru/database/articles/aries/)
-
Вот еще серия статей:
http://www.sql.ru/forum/actualthread.aspx?bid=10&tid=71657&pg=12#944864 (http://www.sql.ru/forum/actualthread.aspx?bid=10&tid=71657&pg=12#944864)
-
Вот от пионеров на ангельском (глава 6):
http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx (http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx)
-
Читать надо... включая свои мозги...
Вот пример отрывок из статьи Козленко... (http://www.osp.ru/os/2003/02/182649/). Весьма начитанная дама, но... думать умеет только в ограниченном коридоре... собственных догм
Блокирование или многоверсионность
Использование многоверсионности для обеспечения изолированности транзакций дает существенное преимущество: операции чтения и записи объектов данных никогда не конфликтуют. Но и цена отсутствия этих конфликтов достаточно высока. Накладные расходы складываются из следующих составляющих:
- хранение версий объектов данных;
- очистка устаревших версий объектов данных;
- затраты по актуализации запрашиваемых данных на чтение;
- принудительный откат транзакций в случае неактуальности считанных данных.
Кроме того, вводится ограничение на операции записи данных: для каждого объекта данных в каждый момент времени может существовать только одна нефиксированная версия. Порождение конкурирующей транзакцией второй нефиксированной версии запрещено. Это связано с тем, что разрешение порождать две нефиксированные версии объекта данных с последующей фиксацией соответствующих транзакций влечет проявление феномена LOST UPDATE. Разрешение порождения двух нефиксированных версий одного объекта данных влечет откат одной из конкурирующих транзакций, а именно той, которая подает операцию СOMMIT второй. Допускать фиксацию обеих транзакций нельзя, поскольку это привело бы систему к рассогласованию данных.
Если при использовании техники блокирования основным регулятором взаимодействия транзакций является синхронизационный захват объектов данных и запрет/разрешение доступа к данным, то при использовании техники многоверсионности основным регулятором является предоставление копии объекта данных и хранение копии объекта данных до тех пор, пока она может быть востребована хотя бы одной транзакцией.
Сравнивая цену, её надо реально сравнивать, а не выдавать желаемое за действительное...
1. Хранение версий устаревших данных есть и в блокировочных и в версионных СУБД. В блокировочных СУБД устаревшие данные хранятся в журнале.
2. Очистка устаревших версий, соответственно тоже необходима при обоих типах изолированности, при этом в версионном варианте неактуальные данные могут просто перезаписываться новыми записями, наравне с записями помеченными, как удалённые. То есть, никаких дополнительных расходов на очистку от устаревших версий версионность не требует.
3. Затраты на актуализацию при чтении у версионных серверов меньше, чем у блокировочных. Реально такая проверка сводится к тому, что сравниваются метки транзаций: метка у записи с меткой текущей транзакции. Блокировочный сервер должен при чтении проверить не заблокирована ли данная запись на изменение. Если не заблокирована, то установить для неё свою блокировку на чтение. Казалось бы это совсем немного работы... Но! Блокирующий механизм это один синхронизирующий поток/процесс для всех транзакций (и читающих, и пишущих). Распараллелить работу механизма блокировок очень непросто, а это означает, что каждая транзакция для каждой обрабатываемой записи встаёт в очередь к процессу/потоку, который отвечает за блокировки. При этом для каждой записи данные о блокировках: 1. Читаются, 2. Устанавливаются, 3. Снимаются. Так что же проще... сравнить две метки или отработать блокировки?..
4. Принудительный откат транзакций существует независимо от того, блокировочный или версионный механизм используются. Неактуальность данных может быть и в том и другом случае. Но откат на блокировщике требует восстановления всех изменённых записей из журнала, в то время, как версионный вариант обходится тем, что делает метку данной транзакции неактуальной, соответственно, все изменённые данные тоже утрачивают свою актуальность и могут быть перезаписаны и проигнорированы при backup.
Ещё более странной выглядит привязка к LOST UPDATE - эта проблема существует только для блокировочных СУБД. В версионных СУБД "потерянных обновлений" не может быть в принципе, поскольку под каждое обновление создаётся своя версия и никто "чужих" не зафиксированных обновлений не может "затереть". Да, промышленные СУБД не позволяют сегодня создавать более одной версии, но это никак не связано с проблемой LOST UPDATE.
Вот такие перлы от Козленко... не впервые... не любит она версионные СУБД :) может потому что СУБД ЛИНТЕР, разработчиком которой она является... блокировочная СУБД... отставшая от реалий.
-
4. Принудительный откат транзакций существует независимо от того, блокировочный или версионный механизм используются. Неактуальность данных может быть и в том и другом случае. Но откат на блокировщике требует восстановления всех изменённых записей из журнала, в то время, как версионный вариант обходится тем, что делает метку данной транзакции неактуальной, соответственно, все изменённые данные тоже утрачивают свою актуальность и могут быть перезаписаны и проигнорированы при backup.
Хм... вроде она другое имела ввиду.
-
Если две транзакции решат изменить один и тот же объект, то возникнет конфликт версий. Побеждает та транзакция, которая успела первой, а опоздавшую, как правило, приходится откатывать. С точки зрения производительности откат довольно-таки дорогая операция, к тому же приходится в обязательном порядке предусматривать обработку подобного конфликта. Если в чистом блокировочнике откат транзакции явное следствие ошибки, то в версионнике откат может произойти во вполне невинной ситуации.
http://www.rsdn.ru/article/db/yukonvers.xml (http://www.rsdn.ru/article/db/yukonvers.xml)
-
4. Принудительный откат транзакций существует независимо от того, блокировочный или версионный механизм используются. Неактуальность данных может быть и в том и другом случае. Но откат на блокировщике требует восстановления всех изменённых записей из журнала, в то время, как версионный вариант обходится тем, что делает метку данной транзакции неактуальной, соответственно, все изменённые данные тоже утрачивают свою актуальность и могут быть перезаписаны и проигнорированы при backup.
Хм... вроде она другое имела ввиду.
То, что она имела ввиду приведено в цитате, повторю:
принудительный откат транзакций в случае неактуальности считанных данных
-
Если две транзакции решат изменить один и тот же объект, то возникнет конфликт версий. Побеждает та транзакция, которая успела первой, а опоздавшую, как правило, приходится откатывать. С точки зрения производительности откат довольно-таки дорогая операция, к тому же приходится в обязательном порядке предусматривать обработку подобного конфликта. Если в чистом блокировочнике откат транзакции явное следствие ошибки, то в версионнике откат может произойти во вполне невинной ситуации.
http://www.rsdn.ru/article/db/yukonvers.xml (http://www.rsdn.ru/article/db/yukonvers.xml)
Если две транзакции решат изменить один и тот же объект, то в блокировочном сервере происходит "отлуп" с откатом второй транзакции, иначе и быть не может. Все последующие рассуждения автора - полная чушь. Какую "невинную ситуацию" имел ввиду автор... осталось загадкой.
-
в блокировочном сервере происходит "отлуп" с откатом второй транзакции
Вторая транзакция даже не начнется в блокировочнике
-
в блокировочном сервере происходит "отлуп" с откатом второй транзакции
Вторая транзакция даже не начнется в блокировочнике
Ну, а теперь, наверное, надо включить мозги...
-
Щелкнул тумблером
-
Щелкнул тумблером
Ну, так теперь скажите, как "не начавшаяся транзакция" узнает о том, что нужный ей для изменения объект кем-то уже изменён?.. :)
-
Ну так по блокировке.... Не? ???
-
Ну так по блокировке.... Не? ???
А кто ж не стартовавшей транзакции даст смотреть блокировки?.. Туда посторонних не пускают, там только один процесс работает... Постучишься к нему...
- Можно мне такую-то запись прочитать?..
- Не-а, встань в очередь...
Через какое-то время...
- Эй ты... ожидающий, откатывайся...
или
- На читай... но по-быстрому...
Но чтоб постучаться, стартовать транзакцию всё же придётся...
-
Так откатывать то нечего, если она фактически с данными ничего не делала. А версионник будет реально данные колбасить, а потом откатывать.
-
Так откатывать то нечего, если она фактически с данными ничего не делала. А версионник будет реально данные колбасить, а потом откатывать.
Так, тумблер щёлкнул, но мозги пока не включились... прогреваются видимо.
-
Не... у нас видимо рассинхронизация... так как вы щелкнуть забыли. ;)
-
1. А если транзакцию не запускать, а просто выполнить чтение, то какие данные будут прочтены? Блокировка не произойдёт? Или транзакция автоматом запустится?
2. Зачем откатывать транзакцию, если она была блокирована на входе и никаких неправильных данных прочесть не смогла? Может, просто после снятьия блокировки ей сказали "на, читай", и всё?
-
1. А если транзакцию не запускать, а просто выполнить чтение, то какие данные будут прочтены? Блокировка не произойдёт? Или транзакция автоматом запустится?
Простите, что вопросом... на вопрос... А как выполнить чтение, если транзакция не стартована. Любое действие (чтение, вставка, обновление, удаление) выполняются запросами, запросы выполняются внутри транзакций (иногда транзакция стартует неявно для разработчика (с параметрами по умолчанию), но вне транзакции... жизни нет).
2. Зачем откатывать транзакцию, если она была блокирована на входе и никаких неправильных данных прочесть не смогла? Может, просто после снятьия блокировки ей сказали "на, читай", и всё?
Транзакцию надо завершать. Если транзакция ничего не делала, то её можно зафиксировать или откатить... Но надо учитывать и мнение других транзакций... которые могут иметь разные уровни изолированности, разные режимы ожидания... То есть, наша транзакция что-то успела прочитать, больше ничего не делала, и через какое-то время... завершилась (commit | rollback). Но пока она ничего не делала, другая транзакция попыталась какие-то из считанных данных изменить, а ей не дали, поскольку висит блокировка по чтению. И эта вторая/не наша транзакция откатилась. Другими словами, то что наша транзакция "ничего не делает" не означает, что она никому не мешает.
Ещё хуже ситуация, когда наша транзакция что-то поменяла и теперь хочет что-то прочитать. А это "что-то" блокировано другой пишущей транзакцией, которая жаждет прочитать то, что поменяла наша транзакция. Возникает deadlock.
-
Так, тумблер щёлкнул, но мозги пока не включились... прогреваются видимо.
Ну так что?
-
Так, тумблер щёлкнул, но мозги пока не включились... прогреваются видимо.
Ну так что?
Жду... когда поясните, что там версионник "колбасить будет"...
-
Вот это наглость :o
Ты в очередной раз поимел наглость принизить мои умственные способности. И в очередной раз ошибся.
И еще ждешь от меня объяснений?
Сам погуглишь.
-
Вот это наглость :o
Н-да, пожалуй я поспешил...
Ты в очередной раз поимел наглость принизить мои умственные способности. И в очередной раз ошибся.
И еще ждешь от меня объяснений?
Нет, уже не жду. Собственно, всё было понятно из фразы:
Вторая транзакция даже не начнется в блокировочнике
Принизить Ваши умственные способности невозможно, в связи... с полным их отсутствием... :(
Я действительно поспешил, простите.
-
Ты смешон
-
Да, кстати... Когда достигнешь просветления, можешь даже извиниться.
-
Ты смешон
Охх ты, я что то упустил -не припомню когда вы с AlexUsом- успели выпить "на брудершафт" ?
-
Да. Вы пропустили ;)
Если есть, что возразить, то... возрази, а кидаться словами... ума не надо.
-
А... хотите испытать острые ощущения от ходьбы по "граням цензуры".... дело доброе.. тема интересная (у нас есть уголок для любителей выпустить пар -как говорится -Welcome).. кстати.. что - то давно мы ее не затрагивали.. :)
-
Вот ее адресок http://oberspace.dyndns.org/index.php/topic,19.0.html (http://oberspace.dyndns.org/index.php/topic,19.0.html) - :) все как в лучших домах Европы и Парижа
-
Можно и потереть :)
Диалог вещь тонкая ;)