Читать надо... включая свои мозги...
Вот
пример отрывок из статьи Козленко.... Весьма начитанная дама, но... думать умеет только в ограниченном коридоре... собственных догм
Блокирование или многоверсионность
Использование многоверсионности для обеспечения изолированности транзакций дает существенное преимущество: операции чтения и записи объектов данных никогда не конфликтуют. Но и цена отсутствия этих конфликтов достаточно высока. Накладные расходы складываются из следующих составляющих:
- хранение версий объектов данных;
- очистка устаревших версий объектов данных;
- затраты по актуализации запрашиваемых данных на чтение;
- принудительный откат транзакций в случае неактуальности считанных данных.
Кроме того, вводится ограничение на операции записи данных: для каждого объекта данных в каждый момент времени может существовать только одна нефиксированная версия. Порождение конкурирующей транзакцией второй нефиксированной версии запрещено. Это связано с тем, что разрешение порождать две нефиксированные версии объекта данных с последующей фиксацией соответствующих транзакций влечет проявление феномена LOST UPDATE. Разрешение порождения двух нефиксированных версий одного объекта данных влечет откат одной из конкурирующих транзакций, а именно той, которая подает операцию СOMMIT второй. Допускать фиксацию обеих транзакций нельзя, поскольку это привело бы систему к рассогласованию данных.
Если при использовании техники блокирования основным регулятором взаимодействия транзакций является синхронизационный захват объектов данных и запрет/разрешение доступа к данным, то при использовании техники многоверсионности основным регулятором является предоставление копии объекта данных и хранение копии объекта данных до тех пор, пока она может быть востребована хотя бы одной транзакцией.
Сравнивая цену, её надо реально сравнивать, а не выдавать желаемое за действительное...
1. Хранение версий устаревших данных есть и в блокировочных и в версионных СУБД. В блокировочных СУБД устаревшие данные хранятся в журнале.
2. Очистка устаревших версий, соответственно тоже необходима при обоих типах изолированности, при этом в версионном варианте неактуальные данные могут просто перезаписываться новыми записями, наравне с записями помеченными, как удалённые. То есть, никаких дополнительных расходов на очистку от устаревших версий версионность не требует.
3. Затраты на актуализацию при чтении у версионных серверов меньше, чем у блокировочных. Реально такая проверка сводится к тому, что сравниваются метки транзаций: метка у записи с меткой текущей транзакции. Блокировочный сервер должен при чтении проверить не заблокирована ли данная запись на изменение. Если не заблокирована, то установить для неё свою блокировку на чтение. Казалось бы это совсем немного работы... Но! Блокирующий механизм это один синхронизирующий поток/процесс для всех транзакций (и читающих, и пишущих). Распараллелить работу механизма блокировок очень непросто, а это означает, что
каждая транзакция для каждой обрабатываемой записи встаёт в очередь к процессу/потоку, который отвечает за блокировки. При этом для каждой записи данные о блокировках: 1. Читаются, 2. Устанавливаются, 3. Снимаются. Так что же проще... сравнить две метки или отработать блокировки?..
4. Принудительный откат транзакций существует независимо от того, блокировочный или версионный механизм используются. Неактуальность данных может быть и в том и другом случае. Но откат на блокировщике требует восстановления всех изменённых записей из журнала, в то время, как версионный вариант обходится тем, что делает метку данной транзакции неактуальной, соответственно, все изменённые данные тоже утрачивают свою актуальность и могут быть перезаписаны и проигнорированы при backup.
Ещё более странной выглядит привязка к LOST UPDATE - эта проблема существует только для блокировочных СУБД. В версионных СУБД "потерянных обновлений" не может быть в принципе, поскольку под каждое обновление создаётся своя версия и никто "чужих" не зафиксированных обновлений не может "затереть". Да, промышленные СУБД не позволяют сегодня создавать более одной версии, но это никак не связано с проблемой LOST UPDATE.
Вот такие перлы от Козленко... не впервые... не любит она версионные СУБД
может потому что СУБД ЛИНТЕР, разработчиком которой она является... блокировочная СУБД... отставшая от реалий.
