|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Dmitry Kuzmenko 2:5020/400 08 Jan 2003 16:36:20
To : Sergey Prach
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
Hello, Sergey!
Sergey Prach wrote:
> есть нудная практика. В теории как - читающая транзакция вообще никак не
> модифицирует БД, а значит может быть ограничена только быстроействием
> дисковой подсистемы. В то время как у блокировочника требуется наложение
> блокировок, а это как никак, хоть и дешевая процессорная операция, но
> чего-то стоит. А реально получается несколько иная картина - самый высокий
у версионника, сам понимаешь, никаких блокировок при чтении, даже в памяти,
не ставится.
> генерацию целых таблиц блокировок. HО! все эти операции по построению
> блокировок происходят в памяти, в то же время как у версионника любая
> модификация в конкурирующей транзакции - это порождение новых версий данных,
> а значит эскалация дисковых операций. При этом первый каскад операций -
непонятно, как ты перескочил от чтения в блокировочнике к обновлению
в версионнике :-) Можно подумать, что у блокировочника обновление не приводит
к помещению СТАРОЙ записи в transaction log, сиречь к дисковой операции ?
> порождение тех самых дельта, второй - подтверждение их, а третий - внутрення
> служебная транзакция
> по анулированию старых версий. Hе много ли на один UPDATE/DELETE, когда у
не много. операции такие -
update - создание версии записи
commit - перевод состояния транзакции в transaction inventory page в committed
и flush незаписанных страниц.
чистка мусора - вообще отдельный вопрос, который может и не происходить.
> Hе все, а делается копия, а это означает что в конце концов нужно еще и
> анулировать старую версию. А анулировать ее можно не всегда в момент
> завершения RW-транзации, а ТОЛЬКО в момент завершения RO-транзакции, по
> причине которой и порождена была эта самая версия. Так это для двух
это про что и где такие ужасы?
> Why is dead? Благодаря отсутствию многих версий % заполнения страниц
> данными у блокирочников намного выше. А значит дисковых операций требуется
> меньше, иногда на порядок. А по сему при правильном проектировании
не факт, см. мое письмо, и данные о 5% свободного места в конкретной
БД у конкретного человека.
> Hу и посчитай теперь количество дисковых операций. И так
> промеждупрочем - чтение/запись 1 кила с дисков происходит дольше как
> минимум в 10 раз чем то же количество операций с памятью. Это на сверх
> быстродействующих дисковых системах с бешенным встроенным кэшем, а реально
> Цта цифра вёрастает на порядо, а то и два.
я не понимаю, откуда вдруг взялось сравнение дисковых операций у
блокировочника и версионника. Если посчитать, то будет примерно одинаково.
Потому что те же версии в версионнике суть transaction log в блокировочнике.
Блокировочник обновляет кол-во записей у таблицы, а версионник пишет
transaction inventory page. И так далее.
--
Dmitri Kouzmenko, www.ibase.ru, 953-13-34
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: iBase (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
