Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 15   вперед  Ctrl
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Yo.!
Guest
DPH3
1) 95% разработчиков систем вообще не знают о разнице между блокировочниками и версионниками и думают, что у Oracle уровень serializable работает так же, как и у DB2.
В результате у нескольких платежных систем (реально работающих на рынке) при массовых операциях с одним счетом могут пропадать деньги и нарушаться пользовательские лимиты по счетам.

ну это проблема просто ничто, на фоне того, что творят программисты db2. по скольку serializable на db2 по сути не работоспособен, обсолютно все используют RC, не подозревая какую кашу выдает этот уровень у db2. на RC db2 не способен гарантировать, что запрос не прочитает одну и ту же запись несколько раз из-за того, что кто-то ее проапдейтил и она невместившись переместилось в другое место.
8 май 15, 11:52    [17617182]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
PgSQLAnonymous
А если вот в версионнике 100500 транзакций пересекаются и конкурируют за один и тот же ресурс, то "пусть весь мир отойдёт". ;)


Это что у вас за система такая? Торговля резервными валютами или фьючерсами по нефти, что у вас 100500 ПИШУЩИХ транзакций пересекаются по ИЗМЕНЯЕМЫМ данных? Или вы прибыль предприятия решили материализовать и обновлять в каждой транзакции?
8 май 15, 11:54    [17617204]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Nitro_Junkie
PgSQLAnonymous
А если вот в версионнике 100500 транзакций пересекаются и конкурируют за один и тот же ресурс, то "пусть весь мир отойдёт". ;)


Это что у вас за система такая? Торговля резервными валютами или фьючерсами по нефти, что у вас 100500 ПИШУЩИХ транзакций пересекаются по ИЗМЕНЯЕМЫМ данных? Или вы прибыль предприятия решили материализовать и обновлять в каждой транзакции?

Ну а если такая система? Версионник-то для этой задачи как-то очень не... ;)
Мне бы хотелось, чтобы в одной СУБД можно было делать что-то вроде:
SET TRANSACTION ISOLATION LEVEL [SNAPSHOT] SERIALIZABLE [READ ONLY] ...прочие опции...

То есть выбирать механизм.
8 май 15, 12:01    [17617256]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Yo.!
Guest
Nitro_Junkie

Это что у вас за система такая? Торговля резервными валютами или фьючерсами по нефти, что у вас 100500 ПИШУЩИХ транзакций пересекаются по ИЗМЕНЯЕМЫМ данных? Или вы прибыль предприятия решили материализовать и обновлять в каждой транзакции?

а в чем проблема ? смотрите TPC-C, те самые 100500 пишущих примитивных транзакций, версионный оракл там всех делает в одни ворота и именно на идентичной технике
8 май 15, 12:07    [17617300]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

Yo.!
смотрите TPC-C

Хранимых агрегатов нет, конкуренции по складам - 1% максимум. Да, да, отличный пример...

Posted via ActualForum NNTP Server 1.5

8 май 15, 12:25    [17617396]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Yo.!
Nitro_Junkie
Это что у вас за система такая? Торговля резервными валютами или фьючерсами по нефти, что у вас 100500 ПИШУЩИХ транзакций пересекаются по ИЗМЕНЯЕМЫМ данных? Или вы прибыль предприятия решили материализовать и обновлять в каждой транзакции?

а в чем проблема ? смотрите TPC-C, те самые 100500 пишущих примитивных транзакций, версионный оракл там всех делает в одни ворота и именно на идентичной технике

Как конкретно он там всех делает, т.е. какие запросы используются (хотя бы cсылкой не поделитесь)?

Меня в основном интересует вот что:
  • Там только SERIALIZABLE и никаких SELECT FOR UPDATE?
  • Там именно 100500 конкурирующих за те же записи "пишущих примитивных транзакций"?

    И вообще, если я правильно помню, в TPC-C измеряется производительность транзакции, которая вставляет новые заказы, разве там высокая конкуренция за один ресурс?
  • 8 май 15, 12:36    [17617485]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    Yo.!
    Guest
    PgSQLAnonymous
    Как конкретно он там всех делает, т.е. какие запросы используются (хотя бы cсылкой не поделитесь)?

    Меня в основном интересует вот что:
  • Там только SERIALIZABLE и никаких SELECT FOR UPDATE?
  • Там именно 100500 конкурирующих за те же записи "пишущих примитивных транзакций"?

    И вообще, если я правильно помню, в TPC-C измеряется производительность транзакции, которая вставляет новые заказы, разве там высокая конкуренция за один ресурс?

  • все ответы вы найдете на сайте tpc.org или в моих постах в этом разделе лет этак 10 назад.
    как делает смотрите тут:
    http://oraclemind.blogspot.com/2005/10/tpc-c-oracle-vs-ibm.html
    http://oraclemind.blogspot.com/2006/11/tpc-c-oracle-10-vs-mssql2k5.html
    http://oraclemind.blogspot.com/2007/07/tpc-c.html
    8 май 15, 13:34    [17617825]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Member

    Откуда:
    Сообщений: 84
    Yo.!
    все ответы вы найдете на сайте tpc.org или в моих постах в этом разделе лет этак 10 назад.
    как делает смотрите тут:
    http://oraclemind.blogspot.com/2005/10/tpc-c-oracle-vs-ibm.html
    http://oraclemind.blogspot.com/2006/11/tpc-c-oracle-10-vs-mssql2k5.html
    http://oraclemind.blogspot.com/2007/07/tpc-c.html


    Не нашёл по ссылкам ответов на свои вопросы (или где именно на tpc.org посмотреть, как реализовано в Oracle):
    PgSQLAnonymous
    Меня в основном интересует вот что:
  • Там только SERIALIZABLE и никаких SELECT FOR UPDATE?
  • Там именно 100500 конкурирующих за те же записи "пишущих примитивных транзакций"?

    И вообще, если я правильно помню, в TPC-C измеряется производительность транзакции, которая вставляет новые заказы, разве там высокая конкуренция за один ресурс?


  • Ваших релевантных постов тоже что-то не находится. :(
    8 май 15, 13:48    [17617901]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    Yo.!
    Guest
    PgSQLAnonymous
    Не нашёл по ссылкам ответов на свои вопросы (или где именно на tpc.org посмотреть, как реализовано в Oracle):

    может вам балетом заняться ? откройте любой Full Disclosure Report, там листинг все сторед процедур прилагается. общее описание тут
    http://www.tpc.org/TPC_Documents_Current_Versions/pdf/TPC-C_V5-11.pdf
    8 май 15, 13:56    [17617951]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Member

    Откуда:
    Сообщений: 84
    Yo.!
    может вам балетом заняться? откройте любой Full Disclosure Report, там листинг все сторед процедур прилагается. общее описание тут
    http://www.tpc.org/TPC_Documents_Current_Versions/pdf/TPC-C_V5-11.pdf

    А может, Вам? Так трудно ответить (если знаете), а не в Full Disclosure Report посылать (а то мне прямо делать больше нечего, кроме как искать это в исходниках в 300-страничном отчёте)?

    alter session set isolation_level = serializable
    /*
     * Initialize the environment, err-handle, attach, open session,
     *  alter session to serializable.  Common for all 5 TX.
     */
    


    И я повторю вопрос: если я правильно помню, в TPC-C измеряется производительность транзакции, которая вставляет новые заказы, разве там высокая конкуренция за один ресурс? Не знаете / не хотите --- не отвечайте.
    8 май 15, 15:00    [17618381]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    Yo.!
    Guest
    PgSQLAnonymous
    А может, Вам? Так трудно ответить (если знаете), а не в Full Disclosure Report посылать (а то мне прямо делать больше нечего, кроме как искать это в исходниках в 300-страничном отчёте)?

    конечно, ведь это так сложно найти PROCEDURE neworder в документе и посмотреть, что там за что конкурирует.
    8 май 15, 15:17    [17618529]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Member

    Откуда:
    Сообщений: 84
    Yo.!
    PgSQLAnonymous
    А может, Вам? Так трудно ответить (если знаете), а не в Full Disclosure Report посылать (а то мне прямо делать больше нечего, кроме как искать это в исходниках в 300-страничном отчёте)?

    конечно, ведь это так сложно найти PROCEDURE neworder в документе и посмотреть, что там за что конкурирует.

    Знаете что, это Вы утверждали, что TPC-C является хорошей иллюстрацией к обсуждаемому вопросу (100500 транзакций конкурируют за один ресурс), вот Вы и приводите конкретные доказательства. А то я нашёл, посмотрел и теперь думаю --- причём тут это?!
    8 май 15, 16:01    [17618797]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    Yo.!
    Guest
    PgSQLAnonymous,

    человек который не мог найти процедуру в паре строк кода смотрит и думает, да ладно шутить, чем он там думает !
    8 май 15, 16:26    [17619014]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    SergSuper
    Member

    Откуда: SPb
    Сообщений: 5488
    Nitro_Junkie
    DPH3
    Хм, интересно, а почему на OLTP системе запускаются отчеты, которые работают 3 дня и что бы сделать с архитектором за такие фокусы :)


    Это вы объясните людям, которые хотят на одной форме рядом с количеством для ввода видеть количество реализации за период. Вы конечно можете им пораcсказывать про OLTP и OLAP, про неправильную архитектуру их бизнеса. Но я надеюсь вы сами понимаете, куда вас пошлет заказчик.

    А у версионника про это даже думать не надо.
    тут то как раз грязное чтение можно использовать
    8 май 15, 16:57    [17619227]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Member

    Откуда:
    Сообщений: 84
    Yo.!
    PgSQLAnonymous,
    человек который не мог найти процедуру в паре строк кода смотрит и думает, да ладно шутить, чем он там думает !

    А что, существо, которое привело не относящийся к делу пример и ещё требует, чтоб я что-то в нём искал, по теме сказать нечего?
    8 май 15, 17:04    [17619252]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    DPH3
    Member

    Откуда:
    Сообщений: 456
    Alexander Ryndin
    DPH3
    3) Версионники, почему-то, сложнее администрировать. По крайней мере, DBA для DB2 и MS SQL стоят дешевле, чем для Oracle/Postgre и часов на типовую задачу у них уходит меньше.
    Не знаю, проблемы с архитектурой или чем-то еще )
    Это по причине того, что вы сравниваете среднюю температуру по больнице. В вашу статистику попадают как DBA, сопровождающие банковские системы, так и DBA с 1С на MSSQL.
    Если вы начнете сравнивать яблоки с яблоками, то увидите, что классный MSSQL спец получает не меньше чем классный спец по Oracle. Просто крутых систем на MSSQL построено раз два и обчелся, а на Oracle куда не плюнь бизнес-критические системы. Ну те же банки возьмите - они в России сидят на Oracle в 90% случаев.


    Ну, я вообще ищу DBA под конкретные задачи: настройка log shipping между ДЦ (Data Guard, HADR - не важно), обновление версии без останова, обновление таблиц без блокировок, оптимизация запросов.
    Тут c Oracle совсем все плохо, DB2 заметно дешевле, Postrge где-то посередине, c MS SQL давно не связывался. А больше сравнивать-то и не с кем )
    Хотя да, это совсем "личный" опыт, статистики нет.
    8 май 15, 17:29    [17619363]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    DPH3
    Member

    Откуда:
    Сообщений: 456
    irbis_al
    А пропадают деньги у кого у оракла или дб2?...

    У Оракла, у Оракла )

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

    Да кто-бы спорил, что это их косяк. Но увы, очень мало разработчиков реально разбираются в БД. Хотя при этом считают, что все хорошо знают и даже не думаю о консультациях или проверке по документации.
    8 май 15, 17:33    [17619384]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    DPH3
    Member

    Откуда:
    Сообщений: 456
    Nitro_Junkie
    Это вы объясните людям, которые хотят на одной форме рядом с количеством для ввода видеть количество реализации за период. Вы конечно можете им пораcсказывать про OLTP и OLAP, про неправильную архитектуру их бизнеса. Но я надеюсь вы сами понимаете, куда вас пошлет заказчик.
    А у версионника про это даже думать не надо.


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

    А вот если у нас жесткий лимит на количество реализации за период и нельзя за него выходить - то и на версионнике сразу вылезет select for update со всеми радостями )
    Особенно весело, если таких лимитов несколько десятков нужно проверять на каждую транзакцию )

    У меня, кстати, обычно именно такие задачи )
    8 май 15, 17:38    [17619409]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    DPH3
    Member

    Откуда:
    Сообщений: 456
    Nitro_Junkie
    Это что у вас за система такая? Торговля резервными валютами или фьючерсами по нефти, что у вас 100500 ПИШУЩИХ транзакций пересекаются по ИЗМЕНЯЕМЫМ данных? Или вы прибыль предприятия решили материализовать и обновлять в каждой транзакции?


    Ну, например, перевод комиссии с забалансового счета на счет популярного мерчанта. Или перевод выигрышей с забалансового счета на счет кастомера. Во всех случаях - жесткие требования к овердрафту (кроме всего прочего).
    8 май 15, 17:43    [17619422]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    Dimitry Sibiryakov
    Member

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

    DPH3
    Вообще, такие данные надо прямо из кэша на applayer забирать. Или получать
    dirtyread, благо точность не важна. Или с реплики (в CQRS-style системах).

    А вот если у нас жесткий лимит на количество реализации за период и нельзя за него
    выходить - то и на версионнике сразу вылезет select for update со всеми радостями )

    Как данные забирать - так с кэша на апплаере, а как лимит контролировать, так позарез в
    БД. Ню-ню...

    Posted via ActualForum NNTP Server 1.5

    8 май 15, 17:47    [17619443]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Member

    Откуда:
    Сообщений: 84
    DPH3
    А вот если у нас жесткий лимит на количество реализации за период и нельзя за него выходить - то и на версионнике сразу вылезет select for update со всеми радостями )

    Ничего такого там не вылезает. Я ещё раз повторюсь, из популярных СУБД полноценный версионник только один, и никаких "select for update" там не нужно. Просто используете SERIALIZABLE для всех модифицирующих транзакций.
    8 май 15, 17:48    [17619444]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Member

    Откуда:
    Сообщений: 84
    Dimitry Sibiryakov
    DPH3
    Вообще, такие данные надо прямо из кэша на applayer забирать. Или получать
    dirtyread, благо точность не важна. Или с реплики (в CQRS-style системах).

    А вот если у нас жесткий лимит на количество реализации за период и нельзя за него
    выходить - то и на версионнике сразу вылезет select for update со всеми радостями )

    Как данные забирать - так с кэша на апплаере, а как лимит контролировать, так позарез в
    БД. Ню-ню...

    (удивлённо оглядывась на других участников) А что, с блокировочниками кто-то не грешен dirty read на таких задачах (точность-то не важна)?

    А если серьёзно, то кэш на application layer тут вполне подойдёт. А кто хочет, может и в базу сходить...
    8 май 15, 17:55    [17619467]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    Dimitry Sibiryakov
    Member

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

    PgSQLAnonymous
    Просто используете SERIALIZABLE для всех модифицирующих транзакций.

    Угу, просто загоните его в однопользовательский режим и забудьте слово "масштабирование".

    Posted via ActualForum NNTP Server 1.5

    8 май 15, 18:14    [17619565]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    ViPRos
    Member

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

    а других способов и нет :)
    8 май 15, 18:53    [17619716]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Member

    Откуда:
    Сообщений: 84
    Dimitry Sibiryakov
    PgSQLAnonymous
    Просто используете SERIALIZABLE для всех модифицирующих транзакций.

    Угу, просто загоните его в однопользовательский режим и забудьте слово "масштабирование".

    С чего бы это (я вот никогда не использовал БД, в которой только один разделяемый ресурс)?

    Это у Вас иррациональный страх / одержимость "производительностью" или реальная статистика использования? ;) Люди-то используют и не знают. ;)

    Кстати, результаты упоминавшегося тут TPC-C, который выполняется на этом самом SERIALIZABLE и показывает нормальные TPS-ы, Вам ни о чём не говорят? ;)
    8 май 15, 19:04    [17619734]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 15   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить