|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Prach 2:5020/400 27 Dec 2002 03:16:00
To : Pavel V. Pasechnik
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
Hi!
"Pavel V. Pasechnik" <Pavel.V.Pasechnik@f17.n5025.z2.fidonet.org>
сообщил/сообщила в новостях следующее: news:4070299137@mail.relex.ru...
> > Hу тогда приведи пример реализации уровня SNAPSHOT, который не
> будет
> > зависеть от размера БД.
>
> Причём здесь размер БД???
> Работа со snapshot'ами должна быть эффективней, чем использование
> serializable. Т.к. при snapshot обычно не подразумевается внесение
> изменений - тогода это RO. Это не уровень изоляции, а режим работы
> транзакций. Hе будем путать. И реализовываться этот режим должен
> специальными методами, и просто обязан быть эффективней. В противном
> случае, нафига он тогда нужен???
Правильно ты пишешь - должна быть эффективной? Hо есть голая теория, а
есть нудная практика. В теории как - читающая транзакция вообще никак не
модифицирует БД, а значит может быть ограничена только быстроействием
дисковой подсистемы. В то время как у блокировочника требуется наложение
блокировок, а это как никак, хоть и дешевая процессорная операция, но
чего-то стоит. А реально получается несколько иная картина - самый высокий
уровень не всегда самый дорогостоящий по времени выполнения для
блокировочника, так как блокировка накладываеся либо целиком на таблицу,
либо на узел индекса (оптимизатор сам выбирает что дешевле). А дальше идет
только чистое чтение. В то же время даже на уровне RR при чтении с условием
требуется либо построчная блокировка, либо постраничная. Что порождает
генерацию целых таблиц блокировок. HО! все эти операции по построению
блокировок происходят в памяти, в то же время как у версионника любая
модификация в конкурирующей транзакции - это порождение новых версий данных,
а значит эскалация дисковых операций. При этом первый каскад операций -
порождение тех самых дельта, второй - подтверждение их, а третий - внутрення
служебная транзакция
по анулированию старых версий. Hе много ли на один UPDATE/DELETE, когда у
блокировчника только
1. чтение PK/ROW_ID по условию и построение таблицы блокировок
3. непосредственно сама запись.
> А пример, пожалуйста.
> Работающая транзакция проверяет - есть ли RO транзакции. Если есть, то
> перед модификацией страницы делается её копия для RO транзакции. Всё :-)
Hе все, а делается копия, а это означает что в конце концов нужно еще и
анулировать старую версию. А анулировать ее можно не всегда в момент
завершения RW-транзации, а ТОЛЬКО в момент завершения RO-транзакции, по
причине которой и порождена была эта самая версия. Так это для двух
транзакций, а есть такие вещи как сальдо счетов и некоторые из них пытаются
модифицировать постоянно сразу несколько транзакций (несколько>>2) на
предприятии средней
руки. Там этих версий на каждую транзакцию ого-го и не успевает одна
завершится как
тут же стартует новая.
> Если же это дело блокировка решать, то один фиг. Что serializable, что
> snapshot. Всё одно - смерть.
Why is dead? Благодаря отсутствию многих версий % заполнения страниц
данными у блокирочников намного выше. А значит дисковых операций требуется
меньше, иногда на порядок. А по сему при правильном проектировании
большинство транзакций не успевают выйти за пределы нескольких секунд (а
реально долей секунд) и не образуют за собой длинную очередь простаивающих
транзакций.
> > 1. Так дельта есть или нет?
>
> Да откуда я знаю???
Лучший ответ на этой неделе! А лучший потому, что честный. Тут я на
полном серьезе.
>
> > 2. С каких это пор операции выделения новых страниц (а это
> прачктически
> > всегда дисковые операции), стали "проще и быстрее"?
>
> Да с тех, что эту пресловутую дельту, как ты и говоришь, где-то нужно
> хранить.
> А хранится она будет в той же самой странице...
> А что эта дельта не будет равна странице никто тоже не гарантирует...
> А что... ну и т.д. и т.п.
Hу и посчитай теперь количество дисковых операций. И так
промеждупрочем - чтение/запись 1 кила с дисков происходит дольше как
минимум в 10 раз чем то же количество операций с памятью. Это на сверх
быстродействующих дисковых системах с бешенным встроенным кэшем, а реально
Цта цифра вёрастает на порядо, а то и два.
>
> > 3. Какая разница где она хранится? - да вообще-то никакой. Если
> она
>
> Hу в общем то любые данные где-то хранятся. Альтернативы пока не
> придумали ;-)
Hу хоть кто-то хоть косвенно начал понимать чего я вопрошаю.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: LtawaSoft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
