Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 10 11 [12] 13 14   вперед  Ctrl
Между сообщениями интервал более 1 года.
 Re: Версионники и блокировочники  [new]
V&B
Guest
Garya

Тема весьма неоднозначная. По моему убеждению "чистых" версионников сейчас практически не существует (не уверен, поскольку не со всеми СУБД знаком достаточно близко). В той или иной степени любай СУБД является гибридом версионника и блокировочника. На тех СУБД, которые принято считать версионниками, указанная в примере проблема разрешается с помощью блокировок, выполняемых принудительно или "на автомате". Или с помощью микрооткатов, выполняемых при обнаружении факта модификации ранее считанных данных и повторного выполнения транзакции (это может отрицательно сказаться на быстродействии, поскольку происходит лишняя загрузка сервера напрасно выполняемыми операциями). Многие "версионники" (точнее, полагаемые таковыми) могут попадать в дедлок, который возможен только по причине блокировок. То есть, "версионники" сближаются с "блокировочниками". "Блокировочники" в свою очередь делают шаги навстречу версионникам. В частности, в MS SQL Server 2005 реализована возможность выполнения транзакций аналогично версионнику. То есть, грани постепенно стираются. Это, собственно, моя точка зрения.

Опоненты считают (если я их правильно понял), что любой "версионник" в любом случае лучше блокировочника, и описанную мною в примере проблему может обойти методами именно "версионника", не превращаясь при этом в "немножко блокировочник". Прошу высказать свои мнения по этому вопросу.
А где почитать FAQ или wiki, в чем вообще принципиальная разница между версионниками и блокировочниками? Access, Oracle, Firebird, Foxpro кто из них версионник, а кто блокировочник?
4 апр 08, 14:32    [5504561]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54803

V&B

А где почитать FAQ или wiki, в чем вообще принципиальная разница между
версионниками и блокировочниками?

Википедии не хватит?
V&B
Access, Oracle, Firebird, Foxpro кто из них версионник, а
кто блокировочник?

Два из четырех вообще не являются клиент-серверными СУБД - вопрос не
имеет смысла.

Posted via ActualForum NNTP Server 1.4

4 апр 08, 14:38    [5504600]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
V&B
Guest
Dimitry Sibiryakov

V&B

А где почитать FAQ или wiki, в чем вообще принципиальная разница между
версионниками и блокировочниками?

Википедии не хватит?

http://ru.wikipedia.org/wiki/%D0%92%D0%B5%D1%80%D1%81%D0%B8%D0%BE%D0%BD%D0%BD%D0%B8%D0%BA Пустая страница. Где читать?

V&B
Access, Oracle, Firebird, Foxpro кто из них версионник, а
кто блокировочник?

Два из четырех вообще не являются клиент-серверными СУБД - вопрос не
имеет смысла.
Access между прочим клиент-серверный, читайте www.microsoft.com, если сомневаетесь. Не знаю насчет Foxpro.
4 апр 08, 15:11    [5504863]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
V&B
Access между прочим клиент-серверный, читайте www.microsoft.com, если сомневаетесь.


Спасибо, поржал... Как средство разработки клиента к клиент\серверной СУБД access может быть использован. Но как СУБД он является файл\серверной (как и фокс), а не клиент серверной.
4 апр 08, 15:22    [5504961]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
cherrex_Den
Member

Откуда:
Сообщений: 729
У нас в компании существует в основном 2 СУБД. Это оракл и сайбейс асе! так как я больше занимаюсь асе всетаки предерживаюсь лагеря с "блокировкой"! Полемики по поводу что лучше а что хуже видуться уже давно! И сколько копий было поломанно,УЖАС! По этому вопрос: Что же все таки может "версионник" чего не может "блокеровочник" или на оборот? Что должно такое произойти, чтоб можно было одназначно и без сомнений сказать: "Да, токое может тока блокировочник или версионник!"? Я заранее извенюсь за то что не до конца прочитал весь этот форум(вернее это ветку)!!! Может на какойто странице уже и был ответ на это вопрос! Мое мнение, что оба типа притендуют на жизнь, но каждый выбирает что он лучше знает и что лучше умеет! Заранее спасибо!!!
20 июл 08, 20:52    [5960947]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
cherrex_Den
У нас в компании существует в основном 2 СУБД...

Ты школу закончил?
20 июл 08, 22:25    [5961076]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
cherrex_Den
По этому вопрос: Что же все таки может "версионник" чего не может "блокеровочник" или на оборот?

Версионник может сочетать конкурентный доступ и согласованное чтение, блокировочнику это не дано. Обратно в столь же общей формулировке не выскажусь.. у Oracle, например, есть пара проблем с "неистинным serializable", но это следствие как раз того, что он "недоверсионник".
20 июл 08, 22:33    [5961081]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
V&B
Access, Oracle, Firebird, Foxpro кто из них версионник, а
кто блокировочник?


Oracle, Firebird, - версионники.
Access, Foxpro - блокировочники, но они оба не поддерживают ACID -транзакции
(т.е. как бы "ниже рангом" и несравнимы с двумя первыми).

Два из четырех вообще не являются клиент-серверными СУБД - вопрос не
имеет смысла.

Как это не имеет смысла ? Как протокол взаимодействия клиента и сервера
связан со способом изоляции транзакций ? (ответ - никак).

Вполне себе есть достаточно много не клиен-сервер СУБД, с полной поддержкой ACID.
21 июл 08, 10:55    [5961979]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Naju
Member

Откуда:
Сообщений: 5
Со строны клиента - клиентское приложение говорит серверу, какой ему нужен уровень изоляции транзакций для своих запросов.

Уровни изоляции:

Read Commited - текущая запись и все записи которые обновлены внутри транзакции не меняются для этой транзакции.

Repetable Read - все записи, которые внутри транзакции прочитаны и/или изменены - не меняются для этой транзакции.
Если внутри транзакции есть два select'a с одинаковым условием, то во втором может быть больше записей (которые появляются из-за параллельных транзакций, так называемые фантомы)

Что бы избежать фантомов, есть еще один уровень.

Serializable - если есть select, insert, update, delete -- с условием, то все записи попадающие под это условие не изменяются для транзакции.

Самый простой пример, нам нужно вычислить минимум и сумму по столбцу.
select MAX(v) from mytable;
select SUM(v) from mytable;

Serializable - гарантирует, что оба оператора, отработают по одному и тому же набору данных, внутри транзакции.

Транзакции конкурируют, чтобы обеспечить Consistency (непротиворечивость или целосность),
"блокировочники" применяют блокировки: Read Lock, Write Lock
При Read Lock другая транзакция ждет, если ей нужен Write Lock,
при Write Lock другая транзакция ждет если ей нужен Read Lock или Write Lock.

Поскольку возникает ситуация, что мы можем ждать чтения, то появились
"версионники" :)
При MVCC (Multiversion concurrency control) - создаються версии и c каждой версией пишется
write timestamp и read timestamp. Тратятся ресурсы но больше нет ожидания при чтении,
а роль флажков блокировки играют write timestamp и read timestamp.


Еще пример, когда нужен Serializable:

Пусть есть две таблицы:
create table T1 ( id int, itog decimal(10,2) );
create table T2 ( id int, decimal(10,2), rashod decimal(10,2) );

T1 - содержит итоги для каждого id, а T2 - движение - приход и расход.

При уровне изоляции Serializable, транзакция c такими операторами:
...
select sum(prihod - rashod) into @itog from T2 where id=10;
update T1 set itog=@itog where id=10;
...
Гарантирует, что в T1 попадет то что надо, и никто не добавит лишних записей в T2 c id=10.
22 июл 08, 00:50    [5966302]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Naju
Member

Откуда:
Сообщений: 5
Пример: В базе данных в разных таблицах находятся значения A и B, которые исходя из их согласованности никогда не должны быть равны (что проверяется триггером). В исходном состоянии A=1; B=2.
На версионнике одновременно запускаются две транзакции. Одна пытается присвоить A:=5, другая пытается присвоить B:=5. В каждой из этих транзакций считываются значения A и B ДО их запуска. Срабатывает триггер в транзакции №1 и проверяет (А=5) != (B=2) - значит изменение A разрешено. Срабатывает триггер в транзакции №2 и проверяет (A=1) != (B=5) - значит изменение B тоже разрешено. Обе транзакции сохраняют новые значения A и B и закомичивают свои транзакции, новые версии A=5 и B=5 сохраняются в базе данных, нарушив согласованность данных. Такая ситуация не может произойти на блокировочнике.


Откуда не согласованность ? И что значит "считываются значения A и B ДО их запуска." ?
В тригер параметры не передаються, так что при
update t1 set A=5,
в тригере t1 будет
select B from t2;
и наоборот.

При Repeatable Read,
на "блокировочнике", первая транзакция, которая пишет А=5 повесит Read Lock при чтении в тригере значения B. Поэтому вторая транзакция не сможет B записать.

Тоже самое на "версионнике", время чтения B в первом тригере меньше, чем время записи во втором, поэтому во втором запись B не пройдет. Роль read/write timestampov -- часто играет счетчик транзакций, потому что компы быстрые и у счетчика разрешение какое надо, но смысл тот же.
22 июл 08, 01:40    [5966352]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Naju
Member

Откуда:
Сообщений: 5
Пример: В базе данных в разных таблицах находятся значения A и B, которые исходя из их согласованности никогда не должны быть равны (что проверяется триггером). В исходном состоянии A=1; B=2.
На версионнике одновременно запускаются две транзакции. Одна пытается присвоить A:=5, другая пытается присвоить B:=5. В каждой из этих транзакций считываются значения A и B ДО их запуска. Срабатывает триггер в транзакции №1 и проверяет (А=5) != (B=2) - значит изменение A разрешено. Срабатывает триггер в транзакции №2 и проверяет (A=1) != (B=5) - значит изменение B тоже разрешено. Обе транзакции сохраняют новые значения A и B и закомичивают свои транзакции, новые версии A=5 и B=5 сохраняются в базе данных, нарушив согласованность данных. Такая ситуация не может произойти на блокировочнике.


Итак:

1я транзакция update t1 set A=5;
2я транзакция update t2 set B=5;

Обе дергают по тригеру, в котором 1й читает B, а второй А. Потом обе комитятся.

Хронология такая:
W1(a) W2(b) R1(b) R2(a) C1 C2
где W - write timestamp, R - read timestamp, C - commit.

Согласно http://en.wikipedia.org/wiki/Timestamp-based_concurrency_control
1-я транзакция хочет commit, имея R1(b) при том что был W2(b) без commita (чтение B, при том что была запись B в другой транзакции без commit).
Поэтому 1я транзакция сбрасывается, а 2я выполняется или возможно тоже сбрасывается.
Так что "версионник" справляется нормально, согласованность не ломается.

На блокировщике при Repeatable Read получаем dead lock и сброс второй транзакции после:
W1a W2b R1b R2a

R1b - нельзя поставить Read Lock на B, после W2b (Write locka на B), 1я транзакция ждет 2ю.
R2a - тоже нельзя поставить Read Lock на A, после W1a (Write locka на А), 2я начинает ждать 1ю
короче dead lock.
22 июл 08, 03:34    [5966414]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
этого места.
цитата
Пример: В базе данных в разных таблицах находятся значения A и B, которые исходя из их согласованности никогда не должны быть равны (что проверяется триггером). В исходном состоянии A=1; B=2.
На версионнике одновременно запускаются две транзакции. Одна пытается присвоить A:=5, другая пытается присвоить B:=5. В каждой из этих транзакций считываются значения A и B ДО их запуска. Срабатывает триггер в транзакции №1 и проверяет (А=5) != (B=2) - значит изменение A разрешено. Срабатывает триггер в транзакции №2 и проверяет (A=1) != (B=5) - значит изменение B тоже разрешено. Обе транзакции сохраняют новые значения A и B и закомичивают свои транзакции, новые версии A=5 и B=5 сохраняются в базе данных, нарушив согласованность данных. Такая ситуация не может произойти на блокировочнике.


Кто это такие бредовые примеры приводит ? На любой СУБД (версионник или блокировочник)
обеспечивается т.н. изоляция -0 (repeatable write) или согласованная запись. Грубо говоря, записываемые (изменяемые) записи транзакции блокируются эксклюзивно. Это должно приводить в вышеприведённой ситуации к откату одной из транзакций по таймауту, т.е. к дедлоку. Либо на чтении записи для последующего изменнения одна из транзакций зависнет и будет ждать окончания опонирущей. Эффект, описываемый в примере, вообще невозможен на ACID - серверах.
22 июл 08, 07:57    [5966561]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Чего-то я не то процитировал, но не важно. Бредовость примера от этого не изменяется.
22 июл 08, 08:00    [5966564]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54803

Naju

Repetable Read - все записи, которые внутри транзакции прочитаны и/или
изменены - не меняются для этой транзакции.
Если внутри транзакции есть два select'a с одинаковым условием, то во
втором может быть больше записей (которые появляются из-за параллельных
транзакций, так называемые фантомы)

Какой же это RR? Это как раз RC - раз второй select сумел
прочитать записи, закоммиченные другой транзакцией!

Posted via ActualForum NNTP Server 1.4

22 июл 08, 11:01    [5967468]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Naju
Member

Откуда:
Сообщений: 5
MasterZiv
Чего-то я не то процитировал, но не важно. Бредовость примера от этого не изменяется.


Вполне реально что значение поля А в одной таблице, может определят допустимость значения поля Б в другой таблице. Так что пример, как пример. Бред в том что утверждаеться что Multi Version Consistency Control, не обеспечивает Consistency Control.

ACID (Atomicity, Consistency, Isolation, Durability).
Топику два года, и в обсуждении Consistency + Isolation -- свели к Isolation.
При том что эти понятия больше логические, а движок БД использует либо блокировки, либо MVCC или еще другие механизмы, чтобы транзакции были ACID.

при MVCC - нет блокировок и нет дедлоков, транзакции которые только читают не тормозятся никогда.
Транзакциями которые пишут, управляет "шедулер", который их не блокирует а пытается по возможности отложить их выполнение в случае конфликтов перестраивая очередь. Как транзакции конкурируют в очереди это и есть ноухау каждой MVCC базы.
22 июл 08, 12:04    [5967926]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
hvlad
Member

Откуда:
Сообщений: 11555
Naju
Транзакциями которые пишут, управляет "шедулер", который их не блокирует а пытается по возможности отложить их выполнение в случае конфликтов перестраивая очередь. Как транзакции конкурируют в очереди это и есть ноухау каждой MVCC базы.
Можно пример из жизни ?
22 июл 08, 15:38    [5969677]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
Dimitry Sibiryakov
Какой же это RR? Это как раз RC - раз второй select

Дим, ты же у нас ибейсовец? Вот как раз потому и удивляешься. "Блокировочный" RR - это почти то же самое, что "версионный" RC. Уровни изоляции, как и прочие составляющие ANSI стандарта, есть следствие кучи дурных компромиссов в стиле "главное, чтобы вписать существующие реализации хоть чучелом, хоть тушкой".

Различия можно показать на следующем примере. Допустим, я делаю запрос наподобие:

select a.*, (select count(*) from b) cnt
from a

Допустим, оптимизатор плохо соображает (ну или мы ему помогли) и вычисляет b-подзапрос отдельно для каждой строки из a.

Так вот: например, в Oracle, если я использую read committed, cnt будет заведомо одинаковым для всех строк результата. В других версионниках, полагаю, аналогично. А вот в блокировочнике, если кто-то параллельно делает insert into b / commit / insert into b / commit / .... - даже в repeatable read получатся разные значения в разных строках. И для того, чтобы гарантировать одинаковое значение, надо делать serializable, который приведет к блокировке b на все время выполнения запроса.
22 июл 08, 16:15    [5970002]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ппм
Guest
Repeatable Read по версии IBM не даст сделать insert в параллельной транзакции, пока есть незавершённая транзакция уровня RR
22 июл 08, 16:33    [5970109]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
Спасибо за информацию. А чем он тогда отличается от serializable? Что он позволит такого, чего не даст сделать последний?
22 июл 08, 16:37    [5970135]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
ппм
Repeatable Read по версии IBM не даст сделать insert в параллельной транзакции, пока есть незавершённая транзакция уровня RR


неужели всё так плохо?
22 июл 08, 16:38    [5970141]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
softwarer
который приведет к блокировке b на все время выполнения запроса.

Виноват, неправильно сказал - не на время выполнения запроса, а до конца транзакции.
22 июл 08, 16:40    [5970153]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ппм
Guest
vadiminfo - http://publib.boulder.ibm.com/infocenter/db2luw/v9r5//topic/com.ibm.db2.luw.admin.perf.doc/doc/c0007870.html

нет такого - serializable - у IBM

FreemanZAV - почему плохо? Согласно определения RR, сколько бы раз запрос не повторялся в текущей транзакции, набор записей должен возвращатся неизменным, стало быть, если insert может изменить этот набор данных, то такой insert не будет выполнен.
Если такой уровень изоляции не нужен - есть RC. И можно делать insert.
22 июл 08, 16:41    [5970163]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ппм
Guest
oope, ответ для softwarer, а не для vadiminfo, извините.

IBM уже давно обещалась сделать доступ к last commited значению, должно быть в слудующем году imho
22 июл 08, 16:43    [5970175]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ппм
Согласно определения RR, сколько бы раз запрос не повторялся в текущей транзакции, набор записей должен возвращатся неизменным, стало быть, если insert может изменить этот набор данных, то такой insert не будет выполнен.


Гм... Это определение serializable. При RR по определению фантомы допустимы. Это по стандарту. Вы о каком определении говорите?
22 июл 08, 16:50    [5970226]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ппм
Guest
опять ошибся - не RC, а RS (Read Stability)
Итого IBM имеет
Repeatable Read
Read Stability
Cursor Stability
Uncommited Read
22 июл 08, 16:50    [5970228]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 10 11 [12] 13 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить