ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Чем плох блокировочник по сравнению с версионником?
25 сообщений из 370, страница 1 из 15
  1  все
Чем плох блокировочник по сравнению с версионником?
    #38952142
db2exc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2exc
Гость
Привет всем! Собственно вопрос в сабже. Действительно ли при работе такого же DB2, при скажем 100 активных пользователей сильно проседает время отклика по сравнению с такой же структурой базы и запросами того же Postgre, Oracle или даже Firebird?
...
Рейтинг: 0 / 0
05.05.2015, 20:25
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952154
DPH3
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DPH3
Участник
db2excПривет всем! Собственно вопрос в сабже. Действительно ли при работе такого же DB2, при скажем 100 активных пользователей сильно проседает время отклика по сравнению с такой же структурой базы и запросами того же Postgre, Oracle или даже Firebird?

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

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

Кстати, по моему опыту, большая часть backend-разработчиков о такой вещи, как версионники не знает и думает, что читатели писателей блокируют. Что приводит к интересным результатам, особенно в биллингах )
...
Рейтинг: 0 / 0
05.05.2015, 20:44
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952158
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
db2excПривет всем! Собственно вопрос в сабже. Действительно ли при работе такого же DB2, при скажем 100 активных пользователей сильно проседает время отклика по сравнению с такой же структурой базы и запросами того же Postgre, Oracle или даже Firebird?
Ну, возможно, что отличие не в чистой производительности, а в производительности "чистого" чтения. Т.е. в теории пишущий до коммита, к примеру, записал в блок грязные данные, которые отражают только часть операций транзакции. К пример, умножил зарплату в двое, но еще не добавил 100000. Т.е. там данные неправильные. Тогда читающий прочитает неправильные данные и примет не правильное решение. Чтобы избежать этого блокировочник имеет возможность заблокировать блок. Т.е. его читать до завершения транзакции нельзя: падение производительности. Но может иметь возможность позволить читать грязные данные, тогда производительность не страдает. Версионник создает копии меняемых блоков: несколько версий блока. Читающий видит копии правильных данных на момент запроса.
...
Рейтинг: 0 / 0
05.05.2015, 21:02
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952225
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
vadiminfodb2excПривет всем! Собственно вопрос в сабже. Действительно ли при работе такого же DB2, при скажем 100 активных пользователей сильно проседает время отклика по сравнению с такой же структурой базы и запросами того же Postgre, Oracle или даже Firebird?
Ну, возможно, что отличие не в чистой производительности, а в производительности "чистого" чтения. Т.е. в теории пишущий до коммита, к примеру, записал в блок грязные данные, которые отражают только часть операций транзакции. К пример, умножил зарплату в двое, но еще не добавил 100000. Т.е. там данные неправильные. Тогда читающий прочитает неправильные данные и примет не правильное решение. Чтобы избежать этого блокировочник имеет возможность заблокировать блок. Т.е. его читать до завершения транзакции нельзя: падение производительности. Но может иметь возможность позволить читать грязные данные, тогда производительность не страдает. Версионник создает копии меняемых блоков: несколько версий блока. Читающий видит копии правильных данных на момент запроса.вообще-то неудачный пример - в обоих случаях читаются неправильные данные
...
Рейтинг: 0 / 0
05.05.2015, 23:05
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952258
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
db2exc,

обычно, приложения пишутся под конкретную СУБД, и поэтому (если разработчик хорошо знаком с архитектурой СУБД) проблем не возникает.
Проблемы начинаются тогда, когда приложения, ориентированные на версионник пытаются перенести на блокировочник, и наоборот.
По идее, проблем в направлении переноса версионник->блокировочник куда больше, чем в обратную сторону.
Версионник, скажем так, "развращает" разработчика в том смысле, что блокировок в нем как таковых нет. Блокировочник наоборот, вызывает ожидание на блокировке ресурсов там, где его могло бы не быть при использовании версионника.
...
Рейтинг: 0 / 0
06.05.2015, 00:57
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952261
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
vadiminfoТогда читающий прочитает неправильные данные
среди старых и нынешних архитекторов Firebird есть мнение, что режим Dirty Read как таковой противопоказан любой СУБД, поэтому даже возможность (существующая) реализации Dirty Read в версионнике не обсуждается.
К примеру, в Firebird (и InterBase) уже много-много лет есть режим read_committed no_rec_version, который выдает ошибку при попытке чтения non-committed версии. Казалось бы, легко реализовать возможность ее "показа", однако...
...
Рейтинг: 0 / 0
06.05.2015, 01:01
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952263
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
db2excПривет всем! Собственно вопрос в сабже. Действительно ли при работе такого же DB2, при скажем 100 активных пользователей сильно проседает время отклика по сравнению с такой же структурой базы и запросами того же Postgre, Oracle или даже Firebird?
Вопрос несколько бессмысленный, поскольку "такой же" практически не используется. Скажу так: для достижения хорошего быстродействия в блокировочниках, как правило, приходится запрещать длинные транзакции и использовать худшие (в смысле качества данных) уровни изоляции.

SergSuperвообще-то неудачный пример - в обоих случаях читаются неправильные данные
Думаю, "неправильные" - очень неудачное слово.
...
Рейтинг: 0 / 0
06.05.2015, 01:04
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952268
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
softwarerдля достижения хорошего быстродействия в блокировочниках, как правило, приходится запрещать длинные транзакции и использовать худшие (в смысле качества данных) уровни изоляции.
в InterBase 1984-85 года выпуска был один уровень изолированности - snapshot, но тем не менее, для достижения хорошего быстродействия в версионнике и с read_committed длинные транзакции тоже не рекомендуются. Я не берусь оценивать эффекты быстродействия от длинных транзакций в обоих архитектурах, но если в блокировочнике длинные транзакции приводят к блокированию конкурирующих транзакций, то в версионнике длинные транзакции приводят к падению производительности из-за накопления версий и последующей сборки "мусора".

Впрочем, полезность версионной архитектуры явно продемонстрирована ее поддержкой в MS SQL 2005, это кроме поддержки в Oracle, PostgreSQL и MySQL, не говоря про ее родоначальника InterBase и наследника Firebird.
Однако, существуют задачи, где версионник только вреден - например, классическая "прокачка" данных через СУБД. Тут блокировочники рулят (как и аналоги dbf, впрочем). Хорошо, что такая задача составляет мизерный процент от остальных.
...
Рейтинг: 0 / 0
06.05.2015, 01:32
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952273
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
kdvв InterBase 1984-85 года выпуска был один уровень изолированности - snapshot, но тем не менее
Я как раз об этом. Для блокировочника snapshot - это "крайне дорогое удовольствие".

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

kdvЯ не берусь оценивать эффекты быстродействия от длинных транзакций в обоих архитектурах,
Насколько я понимаю, они несравнимы. Суть в том, что в версионнике до достаточно большого порога замедление идёт линейно и в целом малокритично, в блокировочнике же нарастает снежный ком (заблокированная транзакция в свою очередь дольше держит блокировки и блокирует следующие транзакции итд).
...
Рейтинг: 0 / 0
06.05.2015, 01:55
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952275
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Relic Hunter
Участник
db2exc,

А что хорошего в блокировочнике? В том, что люди приходят на форум чуть-ли не каждый день спрашивать "как залить в таблицу мильен-другой записей не блокируя таблицу на долго"?
...
Рейтинг: 0 / 0
06.05.2015, 02:19
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952450
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexander Ryndin
Участник
kdvВерсионник, скажем так, "развращает" разработчика в том смысле, что блокировок в нем как таковых нет.предлагаю выдать коллеге нобелевскую премию. Это явно фундаментальное открытие
...
Рейтинг: 0 / 0
06.05.2015, 11:22
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952587
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
kdvсреди старых и нынешних архитекторов Firebird есть мнение, что режим Dirty Read
как таковой противопоказан любой СУБД, поэтому даже возможность (существующая) реализации
Dirty Read в версионнике не обсуждается.
А некоторые даже и на Read Committed смотрят косо. Ибо проблем с его поддержанием много, а
полезного выхлопа - мало.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
06.05.2015, 13:20
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952748
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLAnonymous
Гость
Relic Hunterdb2exc,
А что хорошего в блокировочнике? В том, что люди приходят на форум чуть-ли не каждый день спрашивать "как залить в таблицу мильен-другой записей не блокируя таблицу на долго"?

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

Вообще, я за гибридный подход.
...
Рейтинг: 0 / 0
06.05.2015, 15:39
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952774
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
PgSQLAnonymousБесконечные откаты при высокой конкуренции (даже тогда, когда они
вовсе не нужны)? Особенно с учётом того, что чистый (полноценный) версионник (из известных
RDBMS) только один (PostgreSQL)? ;)
Если PG что-то постоянно при конкуренции откатывает, то это его, PG, личные проблемы.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
06.05.2015, 15:55
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952788
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
этта
Гость
Dimitry Sibiryakov,

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

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

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

а то, что любая субд будет, будучи в сериалайзебле, то и дело что-то откатывать -- ну это какбе оксиома.
...
Рейтинг: 0 / 0
06.05.2015, 16:08
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952794
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLAnonymous
Гость
Dimitry SibiryakovPgSQLAnonymousБесконечные откаты при высокой конкуренции (даже тогда, когда они
вовсе не нужны)? Особенно с учётом того, что чистый (полноценный) версионник (из известных
RDBMS) только один (PostgreSQL)? ;)
Если PG что-то постоянно при конкуренции откатывает, то это его, PG, личные проблемы.

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

И вообще, если транзакции конкурируют за какой-то ресурс, можно:
Заблокировать одну из транзакций (подождать) --- подход блокировочника.

Откатить одну из транзакций --- подход версионника.
А какие ещё варианты-то? Или же вы имеете в виду использование блокировок в версионнике (что его частично превращает в блокировочник)?
...
Рейтинг: 0 / 0
06.05.2015, 16:13
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952803
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLAnonymous
Гость
эттаэттот псевдо пж--ононимус к пг относится так же ,как я к балету

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

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

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

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

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

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

эттаа то, что любая субд будет, будучи в сериалайзебле, то и дело что-то откатывать -- ну это какбе оксиома.
Любая СУБД иногда будет что-то откатывать (DEADLOCK-и, например).
...
Рейтинг: 0 / 0
06.05.2015, 16:23
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952820
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
PgSQLAnonymousКак версионник может не откатывать? Это (традиционно) часть данного
подхода к изоляции транзакций.
Да в общем-то легко. И опять же если кто-то что-то традиционно откатывает, это его личные
половые проблемы. Приведи конкретный пример когда откат транзакции необходим.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
06.05.2015, 16:34
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952862
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLAnonymous
Гость
Dimitry SibiryakovДа в общем-то легко.

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

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



Да классический DEADLOCK:
Код: sql
1.
2.
3.
4.
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


Как тут кого-то не откатить?
...
Рейтинг: 0 / 0
06.05.2015, 17:00
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952896
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
PgSQLAnonymousДа классический DEADLOCK:
Как тут кого-то не откатить?
Во-первых, это не deadlock, а update conflict.
Во-вторых, откатывать таки надо архитектора, который такую дурную логику в БД заложил.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
06.05.2015, 17:28
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952911
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLAnonymous
Гость
Dimitry SibiryakovВо-первых, это не deadlock, а update conflict.

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

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

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

Так, пример "когда откат транзакции необходим" я привёл. ;)
И какой же общий способ не откатывать?
...
Рейтинг: 0 / 0
06.05.2015, 17:39
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952944
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
PgSQLAnonymousТак, пример "когда откат транзакции необходим" я привёл. ;)
И какой же общий способ не откатывать?
Выбросить ошибку и пусть с ней приложение разбирается. Не дело СУБД проявлять
неестественный интеллект и инициативу.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
06.05.2015, 18:07
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952977
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLAnonymous
Гость
Dimitry SibiryakovВыбросить ошибку и пусть с ней приложение разбирается.


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

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


Не вижу тут никакого "интеллекта" и "инициативы". Всё по стандарту, не хотите полного отката --- используйте SAVEPOINT, что тут не так-то?
...
Рейтинг: 0 / 0
06.05.2015, 18:56
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38952984
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
PgSQLAnonymousТо есть в какой-то момент СУБД выбросит ошибку и клиент должен
вручную откатить все или часть изменений?
Клиент должен принять решение. Решит откатывать - пусть откатывает. Решит закоммитить как
есть - пусть коммитит как есть. Решит использовать любую другую логику обработки конфликта
- ему и карты в руки. Потому что это его бизнес-логика, его мабиноги.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
06.05.2015, 19:04
| Ответить | Цитировать | Написать  
Чем плох блокировочник по сравнению с версионником?
    #38953016
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLAnonymous
Гость
Dimitry SibiryakovКлиент должен принять решение. Решит откатывать - пусть откатывает. Решит закоммитить как
есть - пусть коммитит как есть. Решит использовать любую другую логику обработки конфликта
- ему и карты в руки. Потому что это его бизнес-логика, его мабиноги.

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

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

Зачем я в своих транзакциях должен использовать не SERIALIZABLE и предусматривать специальную обработку всех возможных ситуаций (в которой, IMHO, запросто могут ошибиться 99% программистов) вместо общего framework-а (при ошибке откатил-повторил)?
...
Рейтинг: 0 / 0
06.05.2015, 19:43
| Ответить | Цитировать | Написать  
25 сообщений из 370, страница 1 из 15
  1  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Чем плох блокировочник по сравнению с версионником?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&msg=38952273&tid=1552327]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 39ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 67ms
get tp. blocked users:
 2ms
others: 13ms
total:  160ms
созд. / загр.: 160ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]