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

Откуда:
Сообщений: 37
Привет всем! Собственно вопрос в сабже. Действительно ли при работе такого же DB2, при скажем 100 активных пользователей сильно проседает время отклика по сравнению с такой же структурой базы и запросами того же Postgre, Oracle или даже Firebird?
5 май 15, 20:25    [17604171]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
DPH3
Member

Откуда:
Сообщений: 456
db2exc
Привет всем! Собственно вопрос в сабже. Действительно ли при работе такого же DB2, при скажем 100 активных пользователей сильно проседает время отклика по сравнению с такой же структурой базы и запросами того же Postgre, Oracle или даже Firebird?


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

Вообще, не помню, что бы мне под DB2 хотелось бы версионности.

Кстати, по моему опыту, большая часть backend-разработчиков о такой вещи, как версионники не знает и думает, что читатели писателей блокируют. Что приводит к интересным результатам, особенно в биллингах )
5 май 15, 20:44    [17604247]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
db2exc
Привет всем! Собственно вопрос в сабже. Действительно ли при работе такого же DB2, при скажем 100 активных пользователей сильно проседает время отклика по сравнению с такой же структурой базы и запросами того же Postgre, Oracle или даже Firebird?

Ну, возможно, что отличие не в чистой производительности, а в производительности "чистого" чтения. Т.е. в теории пишущий до коммита, к примеру, записал в блок грязные данные, которые отражают только часть операций транзакции. К пример, умножил зарплату в двое, но еще не добавил 100000. Т.е. там данные неправильные. Тогда читающий прочитает неправильные данные и примет не правильное решение. Чтобы избежать этого блокировочник имеет возможность заблокировать блок. Т.е. его читать до завершения транзакции нельзя: падение производительности. Но может иметь возможность позволить читать грязные данные, тогда производительность не страдает. Версионник создает копии меняемых блоков: несколько версий блока. Читающий видит копии правильных данных на момент запроса.
5 май 15, 21:02    [17604280]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
vadiminfo
db2exc
Привет всем! Собственно вопрос в сабже. Действительно ли при работе такого же DB2, при скажем 100 активных пользователей сильно проседает время отклика по сравнению с такой же структурой базы и запросами того же Postgre, Oracle или даже Firebird?

Ну, возможно, что отличие не в чистой производительности, а в производительности "чистого" чтения. Т.е. в теории пишущий до коммита, к примеру, записал в блок грязные данные, которые отражают только часть операций транзакции. К пример, умножил зарплату в двое, но еще не добавил 100000. Т.е. там данные неправильные. Тогда читающий прочитает неправильные данные и примет не правильное решение. Чтобы избежать этого блокировочник имеет возможность заблокировать блок. Т.е. его читать до завершения транзакции нельзя: падение производительности. Но может иметь возможность позволить читать грязные данные, тогда производительность не страдает. Версионник создает копии меняемых блоков: несколько версий блока. Читающий видит копии правильных данных на момент запроса.
вообще-то неудачный пример - в обоих случаях читаются неправильные данные
5 май 15, 23:05    [17604703]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30273
db2exc,

обычно, приложения пишутся под конкретную СУБД, и поэтому (если разработчик хорошо знаком с архитектурой СУБД) проблем не возникает.
Проблемы начинаются тогда, когда приложения, ориентированные на версионник пытаются перенести на блокировочник, и наоборот.
По идее, проблем в направлении переноса версионник->блокировочник куда больше, чем в обратную сторону.
Версионник, скажем так, "развращает" разработчика в том смысле, что блокировок в нем как таковых нет. Блокировочник наоборот, вызывает ожидание на блокировке ресурсов там, где его могло бы не быть при использовании версионника.
6 май 15, 00:57    [17605016]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30273
vadiminfo
Тогда читающий прочитает неправильные данные

среди старых и нынешних архитекторов Firebird есть мнение, что режим Dirty Read как таковой противопоказан любой СУБД, поэтому даже возможность (существующая) реализации Dirty Read в версионнике не обсуждается.
К примеру, в Firebird (и InterBase) уже много-много лет есть режим read_committed no_rec_version, который выдает ошибку при попытке чтения non-committed версии. Казалось бы, легко реализовать возможность ее "показа", однако...
6 май 15, 01:01    [17605025]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
db2exc
Привет всем! Собственно вопрос в сабже. Действительно ли при работе такого же DB2, при скажем 100 активных пользователей сильно проседает время отклика по сравнению с такой же структурой базы и запросами того же Postgre, Oracle или даже Firebird?

Вопрос несколько бессмысленный, поскольку "такой же" практически не используется. Скажу так: для достижения хорошего быстродействия в блокировочниках, как правило, приходится запрещать длинные транзакции и использовать худшие (в смысле качества данных) уровни изоляции.

SergSuper
вообще-то неудачный пример - в обоих случаях читаются неправильные данные

Думаю, "неправильные" - очень неудачное слово.
6 май 15, 01:04    [17605031]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30273
softwarer
для достижения хорошего быстродействия в блокировочниках, как правило, приходится запрещать длинные транзакции и использовать худшие (в смысле качества данных) уровни изоляции.

в InterBase 1984-85 года выпуска был один уровень изолированности - snapshot, но тем не менее, для достижения хорошего быстродействия в версионнике и с read_committed длинные транзакции тоже не рекомендуются. Я не берусь оценивать эффекты быстродействия от длинных транзакций в обоих архитектурах, но если в блокировочнике длинные транзакции приводят к блокированию конкурирующих транзакций, то в версионнике длинные транзакции приводят к падению производительности из-за накопления версий и последующей сборки "мусора".

Впрочем, полезность версионной архитектуры явно продемонстрирована ее поддержкой в MS SQL 2005, это кроме поддержки в Oracle, PostgreSQL и MySQL, не говоря про ее родоначальника InterBase и наследника Firebird.
Однако, существуют задачи, где версионник только вреден - например, классическая "прокачка" данных через СУБД. Тут блокировочники рулят (как и аналоги dbf, впрочем). Хорошо, что такая задача составляет мизерный процент от остальных.
6 май 15, 01:32    [17605082]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
kdv
в InterBase 1984-85 года выпуска был один уровень изолированности - snapshot, но тем не менее

Я как раз об этом. Для блокировочника snapshot - это "крайне дорогое удовольствие".

kdv
для достижения хорошего быстродействия в версионнике и с read_committed длинные транзакции тоже не рекомендуются.

Для версионника уровень изоляции мало влияет на производительность, поскольку указывает в основном какую из версий выбрать. Для блокировочника же он очень сильно влияет на производительность, поскольку указывает, как долго удерживать блокировку на широко востребованном ресурсе. Поэтому для него и вводят всякие dirty read, with nolock etc.

kdv
Я не берусь оценивать эффекты быстродействия от длинных транзакций в обоих архитектурах,

Насколько я понимаю, они несравнимы. Суть в том, что в версионнике до достаточно большого порога замедление идёт линейно и в целом малокритично, в блокировочнике же нарастает снежный ком (заблокированная транзакция в свою очередь дольше держит блокировки и блокирует следующие транзакции итд).
6 май 15, 01:55    [17605097]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7677
db2exc,

А что хорошего в блокировочнике? В том, что люди приходят на форум чуть-ли не каждый день спрашивать "как залить в таблицу мильен-другой записей не блокируя таблицу на долго"?
6 май 15, 02:19    [17605101]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
kdv
Версионник, скажем так, "развращает" разработчика в том смысле, что блокировок в нем как таковых нет.
предлагаю выдать коллеге нобелевскую премию. Это явно фундаментальное открытие
6 май 15, 11:22    [17606188]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

kdv
среди старых и нынешних архитекторов Firebird есть мнение, что режим Dirty Read
как таковой противопоказан любой СУБД, поэтому даже возможность (существующая) реализации
Dirty Read в версионнике не обсуждается.

А некоторые даже и на Read Committed смотрят косо. Ибо проблем с его поддержанием много, а
полезного выхлопа - мало.

Posted via ActualForum NNTP Server 1.5

6 май 15, 13:20    [17606905]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Relic Hunter
db2exc,
А что хорошего в блокировочнике? В том, что люди приходят на форум чуть-ли не каждый день спрашивать "как залить в таблицу мильен-другой записей не блокируя таблицу на долго"?


А что хорошего в версионнике? Бесконечные откаты при высокой конкуренции (даже тогда, когда они вовсе не нужны)? Особенно с учётом того, что чистый (полноценный) версионник (из известных RDBMS) только один (PostgreSQL)? ;)

Вообще, я за гибридный подход.
6 май 15, 15:39    [17608012]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

PgSQLAnonymous
Бесконечные откаты при высокой конкуренции (даже тогда, когда они
вовсе не нужны)? Особенно с учётом того, что чистый (полноценный) версионник (из известных
RDBMS) только один (PostgreSQL)? ;)

Если PG что-то постоянно при конкуренции откатывает, то это его, PG, личные проблемы.

Posted via ActualForum NNTP Server 1.5

6 май 15, 15:55    [17608129]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
Dimitry Sibiryakov,

эттот псевдо пж--ононимус к пг относится так же ,как я к балету

-- оно любитель мастдайскуэля.
и вероятно только , опять таки, как клиентопейсатель.

в пг форуме имеет вопросы только относительно сериалайзебл режима (адепт исключительного сериалайзебла всегда и во всём [блокировочный моск, уле])

а то, что любая субд будет, будучи в сериалайзебле, то и дело что-то откатывать -- ну это какбе оксиома.
6 май 15, 16:08    [17608229]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Dimitry Sibiryakov
PgSQLAnonymous
Бесконечные откаты при высокой конкуренции (даже тогда, когда они
вовсе не нужны)? Особенно с учётом того, что чистый (полноценный) версионник (из известных
RDBMS) только один (PostgreSQL)? ;)

Если PG что-то постоянно при конкуренции откатывает, то это его, PG, личные проблемы.

Ничего подобного. Как версионник может не откатывать? Это (традиционно) часть данного подхода к изоляции транзакций.

И вообще, если транзакции конкурируют за какой-то ресурс, можно:
  • Заблокировать одну из транзакций (подождать) --- подход блокировочника.
  • Откатить одну из транзакций --- подход версионника.
    А какие ещё варианты-то? Или же вы имеете в виду использование блокировок в версионнике (что его частично превращает в блокировочник)?
  • 6 май 15, 16:13    [17608256]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Guest
    этта
    эттот псевдо пж--ононимус к пг относится так же ,как я к балету

    Что, зацепило тебя в прошлый раз, балерина, аж кушать не можешь? ;)

    этта
    -- оно любитель мастдайскуэля.

    Не угадал.
    этта
    и вероятно только , опять таки, как клиентопейсатель.

    А ты у нас из PostgreSQL core team, значит? ;)

    этта
    в пг форуме имеет вопросы только относительно сериалайзебл режима (адепт исключительного сериалайзебла всегда и во всём [блокировочный моск, уле])

    Да, я адепт консистентности (и SERIALIZABLE, который её гарантирует) и считаю, что смысла от быстрого перемалывания мусора никакого нет. А причём тут блокировки, я не понимаю.

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

    Любая СУБД иногда будет что-то откатывать (DEADLOCK-и, например).
    6 май 15, 16:23    [17608344]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    Dimitry Sibiryakov
    Member

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

    PgSQLAnonymous
    Как версионник может не откатывать? Это (традиционно) часть данного
    подхода к изоляции транзакций.

    Да в общем-то легко. И опять же если кто-то что-то традиционно откатывает, это его личные
    половые проблемы. Приведи конкретный пример когда откат транзакции необходим.

    Posted via ActualForum NNTP Server 1.5

    6 май 15, 16:34    [17608454]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Guest
    Dimitry Sibiryakov
    Да в общем-то легко.

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

    Dimitry Sibiryakov
    И опять же если кто-то что-то традиционно откатывает, это его личные
    половые проблемы. Приведи конкретный пример когда откат транзакции необходим.



    Да классический DEADLOCK:
    1. t1: UPDATE t SET b=2 WHERE a=1
    2. t2: UPDATE t SET b=3 WHERE a=2
    3. t1: UPDATE t SET b=2 WHERE a=2
    4. t2: UPDATE t SET b=3 WHERE a=1
    

    Как тут кого-то не откатить?
    6 май 15, 17:00    [17608669]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    Dimitry Sibiryakov
    Member

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

    PgSQLAnonymous
    Да классический DEADLOCK:
    Как тут кого-то не откатить?

    Во-первых, это не deadlock, а update conflict.
    Во-вторых, откатывать таки надо архитектора, который такую дурную логику в БД заложил.

    Posted via ActualForum NNTP Server 1.5

    6 май 15, 17:28    [17608866]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Guest
    Dimitry Sibiryakov
    Во-первых, это не deadlock, а update conflict.

    Или так, зависит от реализации. Но откатывать-то нужно!

    Dimitry Sibiryakov
    Во-вторых, откатывать таки надо архитектора, который такую дурную логику в БД заложил.

    А это уже не дело СУБД. ;) И вообще, это могут быть разные "архитекторы".

    Так, пример "когда откат транзакции необходим" я привёл. ;)
    И какой же общий способ не откатывать?
    6 май 15, 17:39    [17608927]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    Dimitry Sibiryakov
    Member

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

    PgSQLAnonymous
    Так, пример "когда откат транзакции необходим" я привёл. ;)
    И какой же общий способ не откатывать?

    Выбросить ошибку и пусть с ней приложение разбирается. Не дело СУБД проявлять
    неестественный интеллект и инициативу.

    Posted via ActualForum NNTP Server 1.5

    6 май 15, 18:07    [17609125]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Guest
    Dimitry Sibiryakov
    Выбросить ошибку и пусть с ней приложение разбирается.


    То есть в какой-то момент СУБД выбросит ошибку и клиент должен вручную откатить все или часть изменений?

    Dimitry Sibiryakov
    Не дело СУБД проявлять неестественный интеллект и инициативу.


    Не вижу тут никакого "интеллекта" и "инициативы". Всё по стандарту, не хотите полного отката --- используйте SAVEPOINT, что тут не так-то?
    6 май 15, 18:56    [17609379]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    Dimitry Sibiryakov
    Member

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

    PgSQLAnonymous
    То есть в какой-то момент СУБД выбросит ошибку и клиент должен
    вручную откатить все или часть изменений?

    Клиент должен принять решение. Решит откатывать - пусть откатывает. Решит закоммитить как
    есть - пусть коммитит как есть. Решит использовать любую другую логику обработки конфликта
    - ему и карты в руки. Потому что это его бизнес-логика, его мабиноги.

    Posted via ActualForum NNTP Server 1.5

    6 май 15, 19:04    [17609407]     Ответить | Цитировать Сообщить модератору
     Re: Чем плох блокировочник по сравнению с версионником?  [new]
    PgSQLAnonymous
    Guest
    Dimitry Sibiryakov
    Клиент должен принять решение. Решит откатывать - пусть откатывает. Решит закоммитить как
    есть - пусть коммитит как есть. Решит использовать любую другую логику обработки конфликта
    - ему и карты в руки. Потому что это его бизнес-логика, его мабиноги.

    Ну так SAVEPOINT перед каждым запросом и всего делов.

    Я вот только не могу понять, как бизнес-логика связана с конфликтами и зачем ей вообще что-то о них знать?

    Зачем я в своих транзакциях должен использовать не SERIALIZABLE и предусматривать специальную обработку всех возможных ситуаций (в которой, IMHO, запросто могут ошибиться 99% программистов) вместо общего framework-а (при ошибке откатил-повторил)?
    6 май 15, 19:43    [17609554]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 15   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить