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

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

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

в лобовую, select for update на кассах, и система будет вести себя так же ка и блокировочник.
Нет не будет, читайте мое сообщение выше про установку SCN
в слотах транзакций и поведении open в курсоре на update.
Это плата за консистенность "на начало", которую мы обсуждали.
Зато они класно формируют репорты.
Ну не так все печально обстоит :)
Вы можете, конечно, заставить сервер работать так, как Вы привыкли на блокировочниках. Но это булет не самый верный подход.
В oracle, к примеру, выгоднее пользоваться тем, что он делает особенно хорошо - консистентными отчетами.
То есть кассы регистрируют покупки (это insert) и ни о чем более не заботятся.
Рабочие остатки в любой момент можно получить одним sql-запросом, сопоставив остатки от прошлой фиксации и товары, проведенные по кассе.
В любой момент так же консистентно можно зафиксировать рабочие остатки и опираться уже на них.
При этом вообще не требуется блокировка записей остатков при работе касс, а блокировка остатков очень кратковременна (на момент фиксации).
Вот и расскажите теперь про преимущества блокировочника в супермаркете ;)
onstat-
То есть если какаято конкрентаня запись сейчас заблокирована,
на следующий фетч она не пойдет а пойдет свободная, а через 5 фетчей ее уже закомитят.
А каким образом он запоминает пропущенные записи и как потом к ним обращается?
Допустим, есть табличка в 10 млн. строчек, под условия отбора попадает ~1млн, равномерно рассеянный по таблице 90% которых в текущий момент заблокированы. Запускаем запрос.
28 сен 06, 15:01    [3197119]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

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

ASCRUS

Но однако проблемы это не снимает - кто сказал, что на момент
фиксации остатков даже на месяц назад в этот момент у меня никто в БД не
будет добавлять записи месячной давности ?

Большой Босс. Если у вас данные за месяц не устаканиваются это всего
лишь означает что надо отодвинуть дату фиксации еще дальше. До тех пор
пока вероятность существования конкурентных транзакций не упадет до
приемлемого уровня. Цель-то - избавиться от одновременных апдейтов.

Posted via ActualForum NNTP Server 1.3

28 сен 06, 15:05    [3197156]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Толком не пойму задачу, и мне что то лень втыкать :).

ps.
у нас остатки текущие.
28 сен 06, 15:14    [3197232]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19923
Dimitry Sibiryakov

ASCRUS

Но однако проблемы это не снимает - кто сказал, что на момент
фиксации остатков даже на месяц назад в этот момент у меня никто в БД не
будет добавлять записи месячной давности ?
Если у вас данные за месяц не устаканиваются это всего
лишь означает что надо отодвинуть дату фиксации еще дальше.

Да не надо тут никакой вероятностной мути.
Просто процедура, вливающая проводки в базу должна удалить все фиксации, помеченные более поздними датами, чем самая ранняя вливаемая проводка.
После влива проводок можно опять сделать нужные фиксации, но это проблемы не предавляет.
28 сен 06, 15:26    [3197336]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
andrey_anonymous
Да не надо тут никакой вероятностной мути.
Просто процедура, вливающая проводки в базу должна удалить все фиксации, помеченные более поздними датами, чем самая ранняя вливаемая проводка.
После влива проводок можно опять сделать нужные фиксации, но это проблемы не предавляет.

Ага, заодно баланс откатить к примеру. Для таких случаев существуют проверки и перерасчеты задними числами - то что зафиксено никем просто так на автомате не откатывается, что в налоговой декларации, что в балансе, что по остаткам на складе.
28 сен 06, 16:03    [3197692]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 ASCRUS
Не понимаю, чего тут такую кашу развели с несчастным READ COMMITED - ведь написанно же, читаем закомиченные данные. Хотим второй раз те же данные считать, ставим REPEATABLEREAD, боимсе при повторном чтении новые записи схлопотать - ставим SERIALIZABLE. Все как написано в стандарте, работать в любом сервере должно одинаково по смыслу.

Поправочка - работать должно в любом сервере одинаково по смыслу, но только если этот сервер нужный уровень изоляции есть :)
А так да, если уровень изоляции есть - то (принципиальной) разницы быть не должно. Хотя как топик начался с того, что Гаря начал сравнивать разные сервера при разных уровнях изоляции, так оно и идет :).
Разруха - она не в сортирах.

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

Да нету в версионниках сериалайзбла. Последний раз когда тема фантомов поднималась, кто-то из лагеря ораклоидов (помоему это был товарисч Глюк Казанский) начал плакать, а дескать как мы это реализуем без просадок производительности и прочие сопли. Ну, хозяин барин. Если не хотят работать медленно, то всегда остается альтернатива - работать неправильно :))
Вот и Йо начал песни петь про перфоманс и про бизнес-логику в супермаркетах :)

Хотя, конечно, при наличии желания можно для каждого конкретного случая соорудить подобие сериалайзбла. Типа из огурца, петрушки и зеленого лука сделать себе маленького, но вполне съедобного Ктулху.

-----------------------------------

2 Yo!!
блин еще один, непойму где вы (и остальные) увидели "чтения незакомиченных данных"

Здесь
При обсуждении ситуации "128 сессий каждая в своей транзакции проапдейтила, но еще не закоммитила", ты высказал, что блокировочник "будет видеть чужие изменения, читать заблокированые" - типо в противопоставление оракловому Read Commited.
Возьми топор и попробуй вырубить :)

------------------------------------

2 Gluk (Kazan)
Gluk (Kazan)
транзакция рушится на коммите.

Специально для УМНЫХ аксессников - ТРАНЗАКЦИЯ не рушиться. Конкретный DML ловит Exception, вполне штатная ситуация (транзакции от этого не жарко и не холодно).

Гыыыы... Товарисч Глюк, Вы тупой, или прикидываетесь?
Четвертый раз повторяю - Гаря описал случай, когда ошибка ловится в момент коммита. Претензии по абалденному частичному откату - конкретно для этого случая. Если не веришь, что транзакция может пасть именно на коммите, а не только на последнем стейтменте, то поинтересуйся у старших товарисчей. Или в библиотеку сходи.

Если ты рассматриваешь какой-то другой случай - то и рассматривай его себе в тряпочку, ко мне то какие вопросы?


У тебя есть документация по аксесу?

Ага, есть. Вместе с аксессом

Ну раз у тебя есть - ты и ищи. У меня, например, нету. Ни документации, ни аксеса :))
А раз оно у тебя оно есть вместе с аксесом, то можешь еще и эксперименты провести, если уж тебе так сильно "Хочется какта приобщиться".

--------------------------

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

Точно так же можно сказать, что "блокировочник - это не значит без версий".
Ну и о чем будем говорить? С одной стороны - гибрид, с другой стороны - гибрид. Не нужно обладать телепатическими способностями, чтобы понять, что под сравнением блокировочников с версионниками скорее всего подразумевается "чисто блокировочный" и "чисто версионный" подходы. Сравнивать гибриды разной степени гибридности никому не интересно :)
28 сен 06, 16:08    [3197728]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
AI
Member

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

...

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

...


Разумеется. Это будет самое обычное ожидание освобождения блокировки. Затем будет получено текущее состояние записи (current read) и чтение или продолжится (при read commited), или даст ошибку (при serializable).

Я писал, что dml получает данные последней доступной версии. Что тут противоречащего логике или теории?
28 сен 06, 16:35    [3197953]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
автор
Претензии по абалденному частичному откату - конкретно для этого случая.

тогда о каком вообще "частичном откате" при ошибке по commit речь??? Сами себе выдумываете какие-то странные "постановки задачи".
28 сен 06, 16:36    [3197959]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 kdv
автор
Претензии по абалденному частичному откату - конкретно для этого случая.

тогда о каком вообще "частичном откате" при ошибке по commit речь???

Вот и я не понимаю - какой такой частичный откат??? Кто его выдумал, зачем он его выдумал, и почему ораклоиды начали приплетать сюда какие-то бредни типа "написать приладу", "последний стейтмент", "неявный сейв-поинт", и прочий цирк.

Сами себе выдумываете какие-то странные "постановки задачи".

Я выдумываю??? Это Гаря выдумал. Гарин пост сами найдете, или пальцем показать?
28 сен 06, 16:46    [3198035]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
ЛП

Здесь
При обсуждении ситуации "128 сессий каждая в своей транзакции проапдейтила, но еще не закоммитила", ты высказал, что блокировочник "будет видеть чужие изменения, читать заблокированые" - типо в противопоставление оракловому Read Commited.
Возьми топор и попробуй вырубить :)

зачем ? ИМХО это надо поставить в рамку и каждый раз тыкать лохов в нее :)
попробую еще раз так чтоб даже последнему лоху было понятно: моя фраза делалась на 2 части "будет видеть чужие изменения" - думаю тут понятно что read commited у блокировочника (и в стандарте) не обещает не увидеть чужие, закомиченые изменения во время исполнения стейтмента (оракл же консистентное чтение обещает). и вторая часть "читать заблокированые" - это фича mssql где транзакция может прочитать запись, залоченую эксклюзивной блокировкой, чужой транзакции.

ЛП

Поправочка - работать должно в любом сервере одинаково по смыслу, но только если этот сервер нужный уровень изоляции есть :)
А так да, если уровень изоляции есть - то (принципиальной) разницы быть не должно.


мда ... 5 страниц разжевывали, разжевывали что не будет одинаково работать, хоть и имеют одинаковые названия уровней, но походу в пустую :(
28 сен 06, 16:49    [3198046]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
DimaR
Member

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

Четвертый раз повторяю - Гаря описал случай, когда ошибка ловится в момент коммита. Претензии по абалденному частичному откату - конкретно для этого случая. Если не веришь, что транзакция может пасть именно на коммите, а не только на последнем стейтменте, то поинтересуйся у старших товарисчей. Или в библиотеку сходи.


Я не являюсь большим специалистом в этом вопросе, и может "старшие" товарищи поправят, я знаю только один вариант когда транзакция вылетет на коммите, это если будет нарушен deferred constraint, тогда вроде откатится вся транзакция, но это вроде немного из другой оперы (наверное есть еще ньюансы в распределенных транзакциях)
28 сен 06, 17:04    [3198186]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ЛП
Да нету в версионниках сериалайзбла. Последний раз когда тема фантомов поднималась, кто-то из лагеря ораклоидов (помоему это был товарисч Глюк Казанский) начал плакать, а дескать как мы это реализуем без просадок производительности и прочие сопли.


Не песди, или сцылку дай. Не помню я такого

ЛП

Гыыыы... Товарисч Глюк, Вы тупой, или прикидываетесь?
Четвертый раз повторяю - Гаря описал случай, когда ошибка ловится в момент коммита.


Апять, же друк, пример нарисавать для Oracle руки не отсохнут ?
ато складывается впечатление, что вы пи...бол

ЛП

А раз оно у тебя оно есть вместе с аксесом, то можешь еще и эксперименты провести, если уж тебе так сильно "Хочется какта приобщиться".


Пальцем в доку ткнуть ламает ? Или по крайней мере сказать с какой ВЕРСИИ сие чудо появилось.

Я все больше убеждаюсь в том, что кроме бла бла бла вы ничего не могете
28 сен 06, 17:07    [3198217]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ЛП
какие-то бредни типа "написать приладу",


Эти бредни фтваей галаве, трук. Где говорилось "написать" приладу ???
Прилада ЕСТЬ всегда (даже если это SQL+)
28 сен 06, 17:12    [3198266]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 Yo.!!
моя фраза делалась на 2 части "будет видеть чужие изменения" - думаю тут понятно что read commited у блокировочника (и в стандарте) не обещает не увидеть чужие, закомиченые изменения

Гыыы... с рассмотрения ста двадцати восьми незакоммиченных транзакций - плавный переход на чужие закомиченные изменения :). Ну да, оно конечно понятно, что так оно и подразумевалось с самого начала :))
Не отмазывайся, Йо.

----------------

2 Gluk (Kazan)
Не песди, или сцылку дай. Не помню я такого

Гыыы... Оракл плохо на память влияет?
"...Вы правы, если подобные аномалии недопустимы в Вашей задаче, следует совершать "дополнительные телодвижения". Теперь расскажите, как построить версионник без подобных аномалий и без отвратительных просадок по производительности при блокировании диапазонов ключей с соотвественно увеличивающеся вероятностью deadlock-ов ???"
Тут

Пальцем в доку ткнуть ламает ?

Ломает, конечно.
Кстати, сколько раз надо повторить, что у меня нет ни аксеса, ни доки к нему, прежде чем этот факт дойдет до пораженного ораклом мозга? :)

Или по крайней мере сказать с какой ВЕРСИИ сие чудо появилось.

Думаю, что с первой :)
По крайней мере в Access 2.0 оно уже было.

Эти бредни фтваей галаве, трук. Где говорилось "написать" приладу ???

Легко написать прикладу
28 сен 06, 17:27    [3198372]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19923
ЛП
2 Gluk (Kazan)
Не песди, или сцылку дай. Не помню я такого

Гыыы... Оракл плохо на память влияет?
"...Вы правы, если подобные аномалии недопустимы в Вашей задаче, следует совершать "дополнительные телодвижения". Теперь расскажите, как построить версионник без подобных аномалий и без отвратительных просадок по производительности при блокировании диапазонов ключей с соотвественно увеличивающеся вероятностью deadlock-ов ???"
Тут


ЛП, Вы производите впечатление разумного человека.
Я хотел бы услышать от Вас, какие именно выводы Вы сделали из данного высказывания Gluk (Kazan) в частности и из той дискуссии вообще.
28 сен 06, 17:32    [3198416]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19923
ЛП
Легко написать прикладу

По данной ссылке написано нечто, понятное только автору. Вы основываете на этом какие-либо выводы? Может, лучше уточнить у автора что именно он имел ввиду?
28 сен 06, 17:34    [3198435]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19923
ASCRUS
andrey_anonymous
Да не надо тут никакой вероятностной мути. Просто процедура, вливающая проводки в базу должна удалить все фиксации, помеченные более поздними датами, чем самая ранняя вливаемая проводка.
После влива проводок можно опять сделать нужные фиксации, но это проблемы не предавляет.
Ага, заодно баланс откатить к примеру. Для таких случаев существуют проверки и перерасчеты задними числами - то что зафиксено никем просто так на автомате не откатывается, что в налоговой декларации, что в балансе, что по остаткам на складе.

Вы знаете хоть один способ не модифицировать баланс в случае появления начислений "задним числом"? Наверное, "блокировочник" волшебным образом сделает это за вас :)
Нет? Тогда к чему это замечание?
28 сен 06, 17:36    [3198459]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
ChA
Вы, простите, о чем ? Мое комментарий относился только к утверждению Yo.!!,

OK, понял. Я почему-то решил, что если ответ идет на цитату из моего письма, то он мне. Прошу прощения.

ChA
то Merle, в принципе, уже провел весьма убедительный эксперимент

Спасибо, разобрался. К сожалению, текст оформлен чуть неудобно для восприятия человеком, у которого нет под рукой MSSQL, так что я пропустил его при ознакомлении.

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

ChA
Аналогичность способа подразумевается как использование версионности, при котором не происходит чтения измененных данных, а не точное копия механизма.

Признаться, сходу не нашел в первой названной ссылке описания названного Вами механизма (исключая возможность включить READ_COMMITTED_SHAPSHOT). Видимо, надо читать повнимательнее, так что ознакомлюсь позже.
28 сен 06, 17:40    [3198483]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

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

...

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

...


Разумеется. Это будет самое обычное ожидание освобождения блокировки. Затем будет получено текущее состояние записи (current read) и чтение или продолжится (при read commited), или даст ошибку (при serializable).

Я писал, что dml получает данные последней доступной версии. Что тут противоречащего логике или теории?


Абсолютно Ничем, кроме дополнительных накладных расходов
и эскалации блокировок на таблице остатков.

Чтобы получить консистентность данных на уровне транзакции
(а не dml), как писал Андрей, в первом сообщенни на данной странице,
нужно все делать в serializable.


Или все, что он написал делается одним dml?
типа

update remains r
set (cnt ......)=(select sum(fn)...... from tab1 t1.... group by.....)
where
<сумашедшая связка r и таблиц входящих в репорт)

Хороший запросец для OLTP , не правда ли?

Ихмо, чем дольше отягивается контроль логической целостности,
тем больше необходимо ресурсов чтобы ее достичь.
Ведь все сессии в ней нуждаются.
А ресурсы сейчас дешевые :)

Разруха она в головах, как правильно, кто то уже говорил здесь.


2 andrey_anonymous

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

По поводу пропуска записей решений может быть много,
для каждого сервера свое, я пока не разработчик СУБД, когда им буду
расскажу.



зы Снова ушел работать.
28 сен 06, 17:45    [3198518]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 andrey_anonymous
Я хотел бы услышать от Вас, какие именно выводы Вы сделали из данного высказывания Gluk (Kazan) в частности и из той дискуссии вообще.

А какие выводы я должен был сделать из того высказывания и той дискуссии?
В том дискуссии было высказано мнение, что в оракле нету уровня изоляции Serializable патамушта есть фантомы. Все с этим согласились. Какие выводы из этого я должен сделать?
Теперь вот товарисч Глюк пытается открестится от авторства слов про всякие там слова про "просады производительности". Из этого я тоже должен какие-то выводы делать?

По данной ссылке написано нечто, понятное только автору. Вы основываете на этом какие-либо выводы?

Я делаю вывод что это - бредни. Но товарисч Глюк опять таки пытался авторство этих бредней приписать мне. С этим я согласиться не могу, потому что автор бредней совсем не я, но какие еще выводы я из этого должен сделать - обратно не понимаю
28 сен 06, 17:46    [3198523]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11378
softwarer
Хм. Ядерные реакторы ядерными реакторами... не знаю, может это вопрос привычки, но после такого известия у меня было бы желание включить повсеместное использование repeatable read. Неконсистентный результат запроса - очень неуютная концепция, имхо.
Согласен, для меня это тоже было неприятным фактом, пусть даже он и не противоречил формальному определению RC. К счастью, в большинстве случаев, достаточно его знать, чтобы понимать последствия такого поведения в конкретной ситуации и, соответственно, реагировать на него должным образом. Или не реагировать :)

P.S. IMHO. Максимум производительности, в целом, лучше всего достигается тонкой настройкой, в том числе и хинтами. А "автоматика", а она и есть автоматика, она будет прекрасно работать в 90%(глядя на потолок) наиболее массовых и, как правило, более простых случаях, но в критичных ее лучше отключать и брать, что называется, дело в свои руки :)
28 сен 06, 18:14    [3198686]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19923
onstat-
AI
onstat-
При открытии курсора select for update
Разумеется. Это будет самое обычное ожидание освобождения блокировки. Затем будет получено текущее состояние записи (current read) и чтение или продолжится (при read commited), или даст ошибку (при serializable).
Я писал, что dml получает данные последней доступной версии. Что тут противоречащего логике или теории?
Абсолютно Ничем, кроме дополнительных накладных расходов и эскалации блокировок на таблице остатков.
Что Вы имеете ввиду под эскалацией блокировок на таблице остатков?
onstat-
Чтобы получить консистентность данных на уровне транзакции (а не dml), как писал Андрей, в первом сообщенни на данной странице, нужно все делать в serializable.
Думаю, это слишком сильное утверждение.
Консистентность данных штука хорошая, но является лишь инструментом для достижения некоторых целей.
Если задача "внести расход и обновить при этом таблицу остатков" не поддается переформулировке (и такое бывает), то оперируем:
1) консистентным набором проводок, подлежащих внесению. Мы их вставили, но не зафиксировали - никто кроме нас их еще не видит.
2) актуальным значением остатков на момент внесения - согласованность на уровне dml statement.
3) не так страшен черт (рестарт), как его малюют. Его еще надо суметь спровоцировать :) Но если нагрузочные тесты и в самом деле выявили данную проблему при обновлении группы записей, то можно снизить накладные расходы посредством пользовательской блокировки. Та же сериализация доступа. Т.е. создать паритетную по отношению к "блокировочнику" ситуацию достаточно просто. Следующий вопрос - как оптимизировать процесс, чтобы хлебушек не застопорил торговлю.
Можно предложить несколько путей, но они будут одинаково эффективны (или одинаково неэффективны) что для блокировочника, что для версионника - посему оффтопик :)
Причем организовать обновление "редких" групп товаров и отложить обновление востребованных можно и в oracle, причем не так уж и сложно, но "руками".
С учетом Вашего дальнейшего замечания мне начинает казаться, что в "блокировочнике" дела обстоят не сильно лучше ;)
onstat-
Ихмо, чем дольше отягивается контроль логической целостности, тем больше необходимо ресурсов чтобы ее достичь.
Ведь все сессии в ней нуждаются.
Тут согласен.
Но еще разумнее, на мой взгляд, нерперывно обеспечивать целостность, чтобы не приходилось ее достигать "потом".
И тут очень часто помогает переформулировка задач.
onstat-
2 andrey_anonymous
Задача была о "хлебе насущном", а не о супермаркете.
Перевените ее наоборот в задачу выписки накладных по выдаче со склада
и приеме товара на хранение суть от этого не изменится.

Изменится. Контроль остатка - задачка интересная, поскольку провоцирует "горячие" точки в системе и в приведенном сценарии еще и тяжело поддается масштабированию (а если касс - 1000 штук? 10000?).
Подходы есть, но они, как уже говорилось, будут схожи для любой СУБД.
onstat-
По поводу пропуска записей решений может быть много,
для каждого сервера свое, я пока не разработчик СУБД, когда им буду
расскажу.

То есть Вы это придумали?!
Или все-таки есть надежные источники информации?
Может, кто-нибудь из аудитории владеет вопросом?
28 сен 06, 18:21    [3198740]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19923
ЛП
2 andrey_anonymous
Я хотел бы услышать от Вас, какие именно выводы Вы сделали из данного высказывания Gluk (Kazan) в частности и из той дискуссии вообще.

А какие выводы я должен был сделать из того высказывания и той дискуссии?
В том дискуссии было высказано мнение, что в оракле нету уровня изоляции Serializable патамушта есть фантомы. Все с этим согласились. Какие выводы из этого я должен сделать?

То есть Вы никаких выводов делать не стали.
К чему тогда была эта ссылка? Просто показать, что Вы читали один из многочисленных топиков этого сайта?
28 сен 06, 18:24    [3198758]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
ЛП
Вот и я не понимаю - какой такой частичный откат??? Кто его выдумал, зачем он его выдумал, и почему ораклоиды начали приплетать сюда какие-то бредни типа "написать приладу", "последний стейтмент", "неявный сейв-поинт", и прочий цирк.


а кто вообще выдумал какие-то действия при commit? Если НЕТ deferred constraints, то какая нафиг "ошибка при коммите", которая вообще не может возникнуть по определению?
про "стейтменты" имеется в виду вот что:

StartTransaction
insert - ok
insert - ok
insert - облом
Commit.
Все. во время последнего insert оператор не выполнился. никаких роллбэков. Все что сделал этот insert, отменилось автоматической отменой savepoint. Изменения сделанные первыми двумя insert УЖЕ сохранены в БД.
Commit лишь подтверждает вступление этих изменений в силу, а не "применяет их".

softwarer
но после такого известия у меня было бы желание включить повсеместное использование repeatable read. Неконсистентный результат запроса - очень неуютная концепция, имхо.

фигня это, если речь идет о read-committed. сам уровень изолированности неконсистентный в отношении чужих commit-изменений. Почему оператор внутри такого уровня должен быть консистентным, и какую "уверенность" это даст, и в чем? Например, если некий select выполнен сейчас, секунду назад, или секундой позже?

рекомендую почитать тут:
https://www.sql.ru/forum/actualthread.aspx?tid=173455&pg=2
28 сен 06, 18:28    [3198786]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 andrey_anonymous
То есть Вы никаких выводов делать не стали.
К чему тогда была эта ссылка?

Абъисняйю
Это сцылко к таму шта таварисч Глюк Козанскей папрасил сцылку.
Глюк Козансей
Не песди, или сцылку дай

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

------------

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