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

Откуда: Москва
Сообщений: 19925
Мимопроходящий

Боюсь, моих телепатических способностей недостаточно для беседы с Вами.
Вернемся к этой теме когда научитесь мычать более членораздельно.
С пожеланиями скорейшего выздоровления,
Андрей.
28 сен 06, 11:26    [3195183]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19925
Funny_Falcon
На версионнике биллинг получается лучше (я и не спорю), но без блокировок по-любому не обойтись (моё мнение).

Я так до сих пор и не смог осознать связи "версионник значит без блокировок" :(
Ну откуда оно растет, кто-нибудь знает?!
28 сен 06, 11:28    [3195205]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

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

А говорите понятно :)
Тут все просто. Запрос должен вернуть согласованный набор данный на некоторый момент времени.
Для "блокировочников" это момент окончания запроса, для "версионников" - момент начала. Просто ввиду особенностей технологии.


Я выше приводил конкрентый пример, и мне хотелось бы разобраться
в механизме работы oracle для этого примера и разных уровней изоляции.
Может я, читая сыылку, пропустил фразу о том что это набор
должен быть согласован на конкреный момент времени и СУБД это гарантирует.
Не могли бы Вы процитировать, если несложно.

Ихмо сам факт наличия рестарта противоречит
либо согласованности набора на конкретный момент времени,
либо логической целостности этого набора с точки зрения изоляции.

Можно вопрос поставить по другому.
На каких уровнях изоляции будет рестарт в ситуации описанной в моем примере?
28 сен 06, 11:37    [3195291]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Funny_Falcon
Member

Откуда:
Сообщений: 447
2andrey_anonymous
andrey_anonymous
Я так до сих пор и не смог осознать связи "версионник значит без блокировок" :(
Ну откуда оно растет, кто-нибудь знает?!

мир, дружба, жевачка?!! :-)
28 сен 06, 11:40    [3195324]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

Откуда:
Сообщений: 6941
andrey_anonymous
onstat-
Если брать к примеру oracle

Простите, но тут Вы пытаетесь навязать свойства какой-то очень неудачной реализации серверу БД.

Какой курсор "не готов"? Почему он "не готов"?

Рассказываю:
При открытии курсора select for update
oracle не вернет управление из open до тех пор пока
для всех записей курсора в слоты транзакций в соответствующих
блоках не будет проставлен SCN.
Для того что бы проставить SCN предидущая транзакция
изменяющая эту запись должна быть уже закомичена или
откатана.

andrey_anonymous

Если Вам интересны конкретные технические решения, которые могли бы работать в Вашей задаче - могу проконсультировать, но это уже оффтоп поэтому предпочтительно все-таки в личной переписке.
Могу даже спроектировать и сделать пилот, но уже за деньги :)


Это гипотетическая задача разрешения конкурентного доступа к данным.
28 сен 06, 11:51    [3195431]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19925
onstat-
Я выше приводил конкрентый пример, и мне хотелось бы разобраться
в механизме работы oracle для этого примера и разных уровней изоляции.

Вы про этот пример?
В oracle: в зависимости от уровня изолированности и характера изменений, произведенных t1 t2 может либо взять закоммиченные, либо рестартовать, либо выбросить "Can't serialize access". UNDO взять не может.
onstat-
Может я, читая сыылку, пропустил фразу о том что это набор
должен быть согласован на конкреный момент времени и СУБД это гарантирует.
Ищите по словосочетанию "Read Consistency" и обрящете.
onstat-
Ихмо сам факт наличия рестарта противоречит
либо согласованности набора на конкретный момент времени,
либо логической целостности этого набора с точки зрения изоляции.
Почему? В read commited рестарт для приложения выглядит как будто
этот dml-statement начал выполняться позже.
Т.е. переносится точка начала выполнения.
В serializable рестарта не будет - будет exception.
В readonly dml запрещен.
onstat-

Можно вопрос поставить по другому.
На каких уровнях изоляции будет рестарт в ситуации описанной в моем примере?

Read Commited, при наличии конфликта по изменяемым данным.
28 сен 06, 11:54    [3195455]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19925
onstat-
andrey_anonymous
onstat-
Если брать к примеру oracle
Какой курсор "не готов"? Почему он "не готов"?

Рассказываю:
При открытии курсора select for update

Простите, а зачем пытаться заблокировать сразу все да еще и надолго в условиях высокой конкуренции?
Кстати, раз случай гипотетический, давайте для примера Вы расскажете как эту задачу решить на "блокировочнике" - чтобы понятнее было, что конкретно сравниваем. Я попробую предложить аналогичный функционал на oracle.
Похожие задачи решать приходилось, но не до конца ясен предложенный дизайн и суть затруднений.
28 сен 06, 12:01    [3195548]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo.!!
вы это у юзеров спросите, вы то может и не наблюдаете проблем, их юзера наблюдают. выстривать все транзакции в очередь и разгребать их одним джобом это "функционал сервера, позволяющий решать проблему" :)

Все ответы Yo.!! сводятся к 2 простым вещам:
1. Фигня, везде есть выделенка
2. Блокировочник это такая страшная штука с деадлоками, от которой все страдают. Сам я не пробовал, но читал рекламный проспект Ларри, где все это подробно описано (с картинками).

Ну ну
28 сен 06, 12:47    [3195953]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
ASCRUS

2. Блокировочник это такая страшная штука с деадлоками, от которой все страдают. Сам я не пробовал, но читал рекламный проспект Ларри, где все это подробно описано (с картинками).

зачем же Ларри, про ужасы блокировок могу с MSDN, могу с ibm.com к стате интересно было бы почитать чем мотивирует Sybase введением MVCC ;)

ASCRUS, так что реальной задачи вы так и не смогли придумать ? поставте наместо злобных ораклойдов, дайте задачу которую на MVCC нельзя решить прямо. Ораклойды вам такую задачу дали, вы не справились, может стоит достойно ответить, а не лить тонны булшита на обстрактные темы ?
28 сен 06, 13:05    [3196124]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

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

Ищите по словосочетанию "Read Consistency" и обрящете.

onstat-

Ихмо сам факт наличия рестарта противоречит
либо согласованности набора на конкретный момент времени,
либо логической целостности этого набора с точки зрения изоляции.



Почему? В read commited рестарт для приложения выглядит как будто
этот dml-statement начал выполняться позже.
Т.е. переносится точка начала выполнения.
В serializable рестарта не будет - будет exception.
В readonly dml запрещен.

[/quot]


Исходя из таблицы консистентный набор по времени для транзакции
можно получить только в Serializable.





Operation Read Committed Serializable
--------------------------------------------------------------------------------
Dirty write Not Possible Not Possible

Dirty read Not Possible Not Possible

Non-repeatable read Possible Not Possible

Phantoms Possible Not Possible

Compliant with ANSI/ISO SQL 92 Yes Yes

Read snapshot time Statement Transaction

Transaction set consistency Statement level Transaction level

Row-level locking Yes Yes

Readers block writers No No

Writers block readers No No

Different-row writers block writers No No

Same-row writers block writers Yes Yes

Waits for blocking transaction Yes Yes

Subject to "can't serialize access" error No Yes

Error after blocking transaction aborts No No

Error after blocking transaction commits No Yes


Есть сомнения в правдивости таблицы для выденный параметров если 2
конкурентные транзакции находятся в Serializable
Я не могу поянть механизма, чем это достигается.

Если смотреть в комплексе, то достоинств по сравнению с блокировочниками, совсем не много.
28 сен 06, 13:12    [3196203]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Yo.!!

ASCRUS, так что реальной задачи вы так и не смогли придумать ? поставте наместо злобных ораклойдов, дайте задачу которую на MVCC нельзя решить прямо. Ораклойды вам такую задачу дали, вы не справились, может стоит достойно ответить, а не лить тонны булшита на обстрактные темы ?

Если уж на такой примитивной человек признаётся, что на Оракл не может выполнить поставленных условий - то чего уж говорить про серьёзные :)

Это примерно как будущее предсказывать - на пару дней вперёд не могу, а вот лет на 100 - пожалуйста!
28 сен 06, 13:14    [3196222]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
SergSuper

Если уж на такой примитивной человек признаётся, что на Оракл не может выполнить поставленных условий - то чего уж говорить про серьёзные :)

вот можно эту задачу сформулировать в терминах бизнес логики, а то в таком виде я не пойму чо куда а главное зачем.
28 сен 06, 13:23    [3196312]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo.!!
ASCRUS

2. Блокировочник это такая страшная штука с деадлоками, от которой все страдают. Сам я не пробовал, но читал рекламный проспект Ларри, где все это подробно описано (с картинками).

зачем же Ларри, про ужасы блокировок могу с MSDN, могу с ibm.com к стате интересно было бы почитать чем мотивирует Sybase введением MVCC ;)

ASCRUS, так что реальной задачи вы так и не смогли придумать ? поставте наместо злобных ораклойдов, дайте задачу которую на MVCC нельзя решить прямо. Ораклойды вам такую задачу дали, вы не справились, может стоит достойно ответить, а не лить тонны булшита на обстрактные темы ?

Гм, если фантомы это абстрактные темы, а реальные задачи только на отчеты ориентированы, то я умолкаю.
28 сен 06, 13:24    [3196325]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

Откуда:
Сообщений: 6941
andrey_anonymous
onstat-
andrey_anonymous
onstat-
Если брать к примеру oracle
Какой курсор "не готов"? Почему он "не готов"?

Рассказываю:
При открытии курсора select for update

Простите, а зачем пытаться заблокировать сразу все да еще и надолго в условиях высокой конкуренции?
Кстати, раз случай гипотетический, давайте для примера Вы расскажете как эту задачу решить на "блокировочнике" - чтобы понятнее было, что конкретно сравниваем. Я попробую предложить аналогичный функционал на oracle.
Похожие задачи решать приходилось, но не до конца ясен предложенный дизайн и суть затруднений.


Систематезируем условия абстрактной задачи.
Есть наборы товаров с количеством в таблице, они уже закомичены.
Нужно проводить по остаткам и по кассе эти наборы за одну транзакцию каждый, в паралельных сессиях, при том, что один одни товар
встречается в 90% наборов.
Такая постановка Вас устроит?
28 сен 06, 13:32    [3196382]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19925
onstat-
andrey_anonymous

Ищите по словосочетанию "Read Consistency" и обрящете.
Исходя из таблицы консистентный набор по времени для транзакции
можно получить только в Serializable.
Для транзакции - да, только в serializable или readonly. Не думаю, что это специфично для oracle.
Транзакция подразумевает некий набор операций.
Read commited в oracle предполагает согласованность данных на уровне statement.
onstat-



Operation Read Committed Serializable
--------------------------------------------------------------------------------
Transaction set consistency Statement level Transaction level


Readers block writers No No

Writers block readers No No


Есть сомнения в правдивости таблицы для выденный параметров если 2
конкурентные транзакции находятся в Serializable Я не могу поянть механизма, чем это достигается.
Oracle concepts - документ достаточно толстый, но Вам нужна только глава "Data Concurrency and Consistency", там написано.
Сомнения напрасны.
onstat-
Если смотреть в комплексе, то достоинств по сравнению с блокировочниками, совсем не много.

Вот чего-чего, а комплексного рассмотрения я что-то в этом топике не видел :)
Одни говорят про соответствие стандартам, другие - про блокировки, третьи - про версионность...
Применимость тех или иных СУБД для решения тех или иных задач (не придуманных задачек с искусственными ограничениями, а именно задач) не рассматривается :)
Лично мне кажется, что любую задачу в конце концов можно решить на большинстве существующих СУБД.
Вопрос надо ставить о стоимости оборудования, доступности персонала требуемой квалификации, сроках разработки и бюджете проекта.
Могу, конечно, и ошибаться - вдруг на блокировочниках чего-то в принципе сделать нельзя или по стандарту не положено :)
28 сен 06, 13:42    [3196455]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
DimaR
Member

Откуда:
Сообщений: 1570
onstat-

Систематезируем условия абстрактной задачи.
Есть наборы товаров с количеством в таблице, они уже закомичены.
Нужно проводить по остаткам и по кассе эти наборы за одну транзакцию каждый, в паралельных сессиях, при том, что один одни товар
встречается в 90% наборов.
Такая постановка Вас устроит?


в лобовую, select for update на кассах, и система будет вести себя так же ка и блокировочник.
за исключением того, что другие пользователи, смотрящие текущие остатки и делающие отчеты будут видеть согласованный набор данных, и не будут блокироваться этими писателями.

(хотя для бизнес логики, когда кассы сами снимают остатки напрямую не очень красиво (к задаче это не имеет никакого отношения))
28 сен 06, 13:45    [3196485]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19925
onstat-
Систематезируем условия абстрактной задачи.
Есть наборы товаров с количеством в таблице, они уже закомичены.
Нужно проводить по остаткам и по кассе эти наборы за одну транзакцию каждый, в паралельных сессиях, при том, что один одни товар
встречается в 90% наборов.
Такая постановка Вас устроит?

Я их всех проведу за одну транзакцию (выборка наборов с агрегацией по товарам и merge в остатки - можно даже одним statement заколбасить :), в чем проблема-то? По масштабам супермаркета писюку работы секунд на несколько в сутки :)
При этом ничто не будет мешать в процессе регистрировать новые наборы.
Супермаркет - такая штука, где перерасход невозможен (покупатель с физически существующим товаром покидает магазин), что очень сильно облегчает задачу ;)
28 сен 06, 13:51    [3196554]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
DimaR
в лобовую, select for update на кассах, и система будет вести себя так же ка и блокировочник.

То есть мы выбрали набор данных через select for update по некоему условию и мне будет гарантироваться, что другие сессии не смогут вставить новые записи по этому условию, пока я не отпущу транзакцию ?
28 сен 06, 13:58    [3196614]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
DimaR
Member

Откуда:
Сообщений: 1570
ASCRUS
То есть мы выбрали набор данных через select for update по некоему условию и мне будет гарантироваться, что другие сессии не смогут вставить новые записи по этому условию, пока я не отпущу транзакцию ?

При чем тут вставить? Я может неправильно понял условие.
Как я понял, узкое место при update в таблице остатков по товарам???
28 сен 06, 14:03    [3196670]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
DimaR
ASCRUS
То есть мы выбрали набор данных через select for update по некоему условию и мне будет гарантироваться, что другие сессии не смогут вставить новые записи по этому условию, пока я не отпущу транзакцию ?

При чем тут вставить? Я может неправильно понял условие.
Как я понял, узкое место при update в таблице остатков по товарам???

Ну остатки по идее то считать по товарам надо как бы с других таблиц. Значит до апдейта остатка нужно еще и гарантировать, что в этот момент никто не приведет эти таблицы к состоянию, где их данные не будут соответствовать записанному значению остатка, то есть в том числе и не вставятся новые.
28 сен 06, 14:08    [3196710]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

Откуда:
Сообщений: 6941
DimaR
onstat-

Систематезируем условия абстрактной задачи.
Есть наборы товаров с количеством в таблице, они уже закомичены.
Нужно проводить по остаткам и по кассе эти наборы за одну транзакцию каждый, в паралельных сессиях, при том, что один одни товар
встречается в 90% наборов.
Такая постановка Вас устроит?


в лобовую, select for update на кассах, и система будет вести себя так же ка и блокировочник.


Нет не будет, читайте мое сообщение выше про установку SCN
в слотах транзакций и поведении open в курсоре на update.

Это плата за консистенность "на начало", которую мы обсуждали.
Зато они класно формируют репорты.


Блокировочники не пытаются создать консистентный набор на начало
и отадют первый fetch, при возможности добраться к первой же записи из набора, при этом остальных может еще не быть даже в кеше буферов
а обработка записей набора уже идет, и поиск остальных а также контроль уже установленных другими сессиями блокировок может
производится в фоновом режиме.
То есть если какаято конкрентаня запись сейчас заблокирована,
на следующий фетч она не пойдет а пойдет свободная, а через 5 фетчей ее уже закомитят.
Это поведение может элементарно убить order by, но это уже детали реализации приложения и использования возможностей СУБД.


Всязи с отсутствием ограничения по консистентности на начало,
с которым я лично мирюсь,
у разработчиков блокировочников
выше возможности по оптимизации обработки.

з.ы. Простите работать надо. Я еще вернусь.
28 сен 06, 14:15    [3196761]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

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

ASCRUS

Ну остатки по идее то считать по товарам надо как бы с других таблиц.
Значит до апдейта остатка нужно еще и гарантировать, что в этот момент
никто не приведет эти таблицы к состоянию, где их данные не будут
соответствовать записанному значению остатка

Вот поэтому-то и твердят все кому не лень, что хранимые (актуальные)
остатки - зло. Если хранить остатки, скажем, месячной давности, то такая
гарантия создается административно - запретом работать задним числом (и
подкрепляется соответствующими триггерами).

Posted via ActualForum NNTP Server 1.3

28 сен 06, 14:17    [3196779]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Dimitry Sibiryakov

ASCRUS

Ну остатки по идее то считать по товарам надо как бы с других таблиц.
Значит до апдейта остатка нужно еще и гарантировать, что в этот момент
никто не приведет эти таблицы к состоянию, где их данные не будут
соответствовать записанному значению остатка

Вот поэтому-то и твердят все кому не лень, что хранимые (актуальные)
остатки - зло. Если хранить остатки, скажем, месячной давности, то такая
гарантия создается административно - запретом работать задним числом (и
подкрепляется соответствующими триггерами).
Posted via ActualForum NNTP Server 1.3


Ну вот, отошли от субд и пришли к административным ограничениям.
Не коструктивно как то получается.
28 сен 06, 14:24    [3196826]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
softwarer
ChA
Судя по комментарию, Вы не совсем поняли смысл той дискуссии.

Почему-то я уверен, что если я попрошу Вас логически строго обосновать свое утверждение, мы придем к выводу, что Вы брякнули абы что.
Вы, простите, о чем ? Мое комментарий относился только к утверждению Yo.!!, когда он в качестве доказательства оного обратился явно не ту дискуссию. Или Вы там обнаружили доказательство его правоты ? Тогда, будьте любезны, ткните носом...
softwarer
То есть, если я правильно понял, Вы не производили экспериментов, не задавали вопросов и другими способами не выясняли, какой же все-таки результат запроса вернет Вам сервер.
Совершенно верно, если внимательно посмотреть на ранее упомянутую дискуссию, то Merle, в принципе, уже провел весьма убедительный эксперимент, хотя мое предположение касалось более сложной ситуации, причем оно было не первым. Мне его аргументы показались достаточно убедительными, чтобы перепроверять их.
softwarer
Тогда вопрос: каким образом Вы добиваетесь того, что приложение ведет себя предсказуемым образом? Пихаете в каждый нетривиальный запрос хинт holdlock? Используете только простые запросы? Что-то другое? Оставляете на самотек, "авось не случится", наконец?
По разному, в некоторых случаях вместо хинта Holdlock проще сразу поставить уровень изоляции RR, иногда фиксируется план запроса таким образом, чтобы повторного чтения "опасных" мест не происходило, иногда же, действительно, можно пренебречь, так как подобная несогласованность либо элиминируется на последующих шагах, либо не важна, что в моей практике не редкость, так как она не касается ни ядерных реакторов, ни космических аппаратов.
softwarer
Нельзя ли ссылку?
Запросто. Одна из них уже приводилась. Можно здесь глянуть.
*Аналогичность способа подразумевается как использование версионности, при котором не происходит чтения измененных данных, а не точное копия механизма.
28 сен 06, 14:34    [3196888]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Dimitry Sibiryakov
Вот поэтому-то и твердят все кому не лень, что хранимые (актуальные)
остатки - зло. Если хранить остатки, скажем, месячной давности, то такая
гарантия создается административно - запретом работать задним числом (и
подкрепляется соответствующими триггерами).
Posted via ActualForum NNTP Server 1.3

А где я сказал про хранение актуальных остатков ? У меня по жизни фиксированные хранятся, а актуальные получаются как сумма последних зафиксированных остатков плюс все по таблицам движения (без разницы чего). Но однако проблемы это не снимает - кто сказал, что на момент фиксации остатков даже на месяц назад в этот момент у меня никто в БД не будет добавлять записи месячной давности ? Да запросто - начиная от самих пользователей и заканчивая вливом данных репликацией или импортом с другой системы. И на момент фиксации этих остатков с одной стороны все пользователи должны продолжать счастливо работать, с другой стороны остатки должны быть зафиксированны правильными, то есть не нарушена согласованная целостность данных.
28 сен 06, 14:37    [3196919]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить