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

Откуда: 127.0.0.1
Сообщений: 67508
Блог
PgSQLAnonymous
Ну так SAVEPOINT перед каждым запросом и всего делов.

1. Не очень понимаю, как savepoint спасёт от отката транзакции.

2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД "savepoint перед каждым запросом" обеспечивают автоматом.
6 май 15, 19:51    [17609579]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

softwarer
2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД
"savepoint перед каждым запросом" обеспечивают автоматом.

Ну так PG, видимо, не претендует...

Posted via ActualForum NNTP Server 1.5

6 май 15, 20:20    [17609663]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
PgSQLAnonymous
Dimitry Sibiryakov
Клиент должен принять решение. Решит откатывать - пусть откатывает. Решит закоммитить как
есть - пусть коммитит как есть. Решит использовать любую другую логику обработки конфликта
- ему и карты в руки. Потому что это его бизнес-логика, его мабиноги.

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

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

Зачем я в своих транзакциях должен использовать не SERIALIZABLE и предусматривать специальную обработку всех возможных ситуаций (в которой, IMHO, запросто могут ошибиться 99% программистов) вместо общего framework-а (при ошибке откатил-повторил)?
Мне одному кажется, что вы какой-то бред несете?
1) В редких приложениях встречается жесткая конкуренция за одни и те же строки. Обычно в многопользовательском режиме пользователи меняют разные данные. Отсюда и deadlocks встречаются редко. Наличие большого количеств deadlock говорит либо о кривости самого приложения, либо о кривости СУБД (слишком крупные блокировки)
2) Exception на то и exception, что мы заранее не знаем, какой он может произойти. Может быть deadlock, а может и место на сервере закончиться. На каждый случай условных веток не напасешься. Но всегда есть возможность написать обработчик others, который будет всегда откатывать транзакцию, показывать юзеру текст exception и предлагать повторить всю транзакцию с нуля. Какие к черту SAVEPOINT?
6 май 15, 20:23    [17609669]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67508
Блог
Alexander Ryndin
Мне одному кажется, что вы какой-то бред несете?

Да не то чтобы бред. Слова уважаемого коллеги напоминают мне поведение юного головастого студента с большим самомнением, который нахватался вершков теории и при нуле практики начал придумывать улучшения и прочие единственно правильные подходы.
6 май 15, 20:28    [17609681]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
softwarer
1. Не очень понимаю, как savepoint спасёт от отката транзакции.

Может откатиться до него.

softwarer
2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД "savepoint перед каждым запросом" обеспечивают автоматом.

О каких "обезьянках" речь? Если мне нужна будет "savepoint перед каждым запросом", я это легко реализую в клиентском (да и серверном) коде, а если не нужна --- не буду использовать. А в Ваших "нормальных СУБД" выбора нет, получается? И это Вы выдаёте за преимущество? ;)
6 май 15, 21:37    [17609897]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Dimitry Sibiryakov
softwarer
2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД
"savepoint перед каждым запросом" обеспечивают автоматом.

Ну так PG, видимо, не претендует...

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

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

PgSQLAnonymous
С чего это наличие или отсутствие произвольных ограничений вдруг
стало определять "нормальность" СУБД?

С тех пор как атомарность транзакции в целом и DML в частности стала стандартом.

Posted via ActualForum NNTP Server 1.5

6 май 15, 21:44    [17609921]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Alexander Ryndin
Мне одному кажется, что вы какой-то бред несете?

Откуда я знаю, сколько вас здесь, "считающих"? ;)

Alexander Ryndin
1) В редких приложениях встречается жесткая конкуренция за одни и те же строки. Обычно в многопользовательском режиме пользователи меняют разные данные. Отсюда и deadlocks встречаются редко.

А статистика, подтверждающая "в редких приложениях", у Вас есть? Или это информация агенства ОБС? ;) И как связаны "меняют разные данные" и DEADLOCK-и? Пускай 100500 клиентов конкурируют за одни и те же строки, но если они обрабатывают их в одном порядке, DEADLOCK-ов (без слишком крупных блокировок и т.п.) не будет вообще.

Alexander Ryndin
Наличие большого количеств deadlock говорит либо о кривости самого приложения, либо о кривости СУБД (слишком крупные блокировки)

Обычно да.

Alexander Ryndin
2) Exception на то и exception, что мы заранее не знаем, какой он может произойти. Может быть deadlock, а может и место на сервере закончиться.

Безусловно, какой будет exception, заранее неизвестно. Но вот deadlock-и и update conflict-ы --- это нормальные ситуации в работе СУБД, и любому Database Developer должно быть известно, как их полагается обрабатывать.

Alexander Ryndin
На каждый случай условных веток не напасешься.

Можно и напастись, т.к. обычно ошибки как-то разделяются на группы по severity и т.п.

Alexander Ryndin
Но всегда есть возможность написать обработчик others, который будет всегда откатывать транзакцию, показывать юзеру текст exception и предлагать повторить всю транзакцию с нуля.


Да Вы что? А если пользователя просто нет? Кому Вы будете это сообщение показывать?

Alexander Ryndin
Какие к черту SAVEPOINT?

Те самые, которые есть в стандарте и во всех "нормальных СУБД"? Вот они все дураки-то, правда? ;)
6 май 15, 21:53    [17609951]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67508
Блог
PgSQLAnonymous
softwarer
1. Не очень понимаю, как savepoint спасёт от отката транзакции.

Может откатиться до него

На предыдущем допросе (тм) Вы показали, что версионник должен отказывать транзакцию. Как откатиться до savepoint-а после отката транзакции и зачем?

PgSQLAnonymous
О каких "обезьянках" речь? Если мне нужна будет "savepoint перед каждым запросом", я это легко реализую в клиентском (да и серверном) коде,

Вот именно о таких обезьянках.

PgSQLAnonymous
А в Ваших "нормальных СУБД" выбора нет, получается? И это Вы выдаёте за преимущество? ;)

За преимущество я выдаю удобную и правильную работу. А мучающиеся с грязным чтением, мумпсом и прочим каменным веком имеют полное право гордиться тем, что у них зато есть выбор.
6 май 15, 21:56    [17609965]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Dimitry Sibiryakov
PgSQLAnonymous
С чего это наличие или отсутствие произвольных ограничений вдруг
стало определять "нормальность" СУБД?

С тех пор как атомарность транзакции в целом и DML в частности стала стандартом.

Извините, этого я не понял вообще. Стандарт ANSI SQL не требует implicit savepoints. О каком стандарте идёт речь и причём тут атомарность-то?
Как вообще наличие или отсутвие implicit savepoints влияет на атомарность?

Кстати, Вам не кажется, что Вы всё наоборот вывернули? Вот, например, если у меня есть "нормальная СУБД" и я выполняю:
BEGIN;
INSERT INTO history_table SELECT * FROM current_table;
TRUNCATE TABLE current_table;
COMMIT;

И у меня происходит ошибка в INSERT, то, как я понимаю, он откатывается и транзакция продолжается, и мне это поведение почему-то совсем не кажется "нормальным". Верни мои данные, проклятый сервер! ;)
6 май 15, 22:02    [17609985]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
softwarer
Alexander Ryndin
Мне одному кажется, что вы какой-то бред несете?

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

А мне Ваши, может, тоже чего-то напоминают. А аргументы-то есть у Вас?
6 май 15, 22:04    [17609990]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
softwarer
PgSQLAnonymous
пропущено...
Может откатиться до него

На предыдущем допросе (тм) Вы показали, что версионник должен отказывать транзакцию. Как откатиться до savepoint-а после отката транзакции и зачем?

Естественно, никак. Он может откатиться до savepoint-а вместо отката транзакции, если это нужно.

softwarer
PgSQLAnonymous
О каких "обезьянках" речь? Если мне нужна будет "savepoint перед каждым запросом", я это легко реализую в клиентском (да и серверном) коде,

Вот именно о таких обезьянках.

Нда. То есть возможность наличие выбора и возможность тривиально реализовать implict savepoint --- это недостаток, а отсутвие выбора --- это преимущество? Интересная у Вас логика.

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

Как здесь появились "грязное чтение, мумпсом и прочий каменным век"?
Ни с чем таким в PostgreSQL и MS SQL, например, где вышеописанный выбор есть, можно не мучаться (а с грязным чтением в PostgreSQL и не получится)...
6 май 15, 22:13    [17610004]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

PgSQLAnonymous
мне это поведение почему-то совсем не кажется "нормальным"

Выше я уже писал про неестественный интеллект и инициативу. Ты явно и недвусмысленно
приказал серверу закоммитить транзакцию не смотря ни на что. Он её закоммитил. Почему
точное выполнение сервером твоих приказов ты считаешь ненормальным?

Posted via ActualForum NNTP Server 1.5

6 май 15, 22:32    [17610047]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Dimitry Sibiryakov
PgSQLAnonymous
мне это поведение почему-то совсем не кажется "нормальным"

Выше я уже писал про неестественный интеллект и инициативу. Ты явно и недвусмысленно
приказал серверу закоммитить транзакцию не смотря ни на что. Он её закоммитил. Почему
точное выполнение сервером твоих приказов ты считаешь ненормальным?

Я говорю, что мне это поведение кажется ненормальным, потому что я привык к другому. ;) Если его учитывать, то ничего плохого тут нет, я приказал --- он закоммитил, формально косяк здесь только мой. Но без implicit savepoints я могу выполнить это всё одним запросом/пакетом и знать, что данные не потеряются, а здесь нет, и это мне кажется ненормальным. ;(
6 май 15, 22:57    [17610114]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
PgSQLAnonymous
Dimitry Sibiryakov
пропущено...

С тех пор как атомарность транзакции в целом и DML в частности стала стандартом.

Извините, этого я не понял вообще. Стандарт ANSI SQL не требует implicit savepoints. О каком стандарте идёт речь и причём тут атомарность-то?
Как вообще наличие или отсутвие implicit savepoints влияет на атомарность?

Кстати, Вам не кажется, что Вы всё наоборот вывернули? Вот, например, если у меня есть "нормальная СУБД" и я выполняю:
BEGIN;
INSERT INTO history_table SELECT * FROM current_table;
TRUNCATE TABLE current_table;
COMMIT;

И у меня происходит ошибка в INSERT, то, как я понимаю, он откатывается и транзакция продолжается, и мне это поведение почему-то совсем не кажется "нормальным". Верни мои данные, проклятый сервер! ;)


Я дико извиняюсь, что встреваю, но, в нормальной СУБД:

DELETE current_table OUTPUT deleted.* INTO history_table
6 май 15, 23:21    [17610168]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
pkarklin
PgSQLAnonymous
пропущено...

Извините, этого я не понял вообще. Стандарт ANSI SQL не требует implicit savepoints. О каком стандарте идёт речь и причём тут атомарность-то?
Как вообще наличие или отсутвие implicit savepoints влияет на атомарность?

Кстати, Вам не кажется, что Вы всё наоборот вывернули? Вот, например, если у меня есть "нормальная СУБД" и я выполняю:
BEGIN;
INSERT INTO history_table SELECT * FROM current_table;
TRUNCATE TABLE current_table;
COMMIT;

И у меня происходит ошибка в INSERT, то, как я понимаю, он откатывается и транзакция продолжается, и мне это поведение почему-то совсем не кажется "нормальным". Верни мои данные, проклятый сервер! ;)


Я дико извиняюсь, что встреваю, но, в нормальной СУБД:

DELETE current_table OUTPUT deleted.* INTO history_table


А в другой нормальной СУБД:
WITH deleted AS (
DELETE FROM current_table RETURNING *
)
INSERT INTO history_table SELECT * FROM deleted;

И что? ;)
6 май 15, 23:59    [17610233]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
PgSQLAnonymous
И что? ;)

Это был намек, что скрипт был приведен "под ситуацию".
7 май 15, 00:02    [17610242]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
ViPRos
Member

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

а воще то все эти output и returning убожество мысли и отсутствие фантазии с целю достичь атомарности в некоторых простых случаях

и говно тот субд который СВОЮ работу валит на плечи клиента, а дедлоки и конфликты именно работа субд, без оных нах субд и не нужна, кроме как читать она ни для чего не нужна
7 май 15, 00:42    [17610326]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
Alexander Ryndin
1) В редких приложениях встречается жесткая конкуренция за одни и те же строки. Обычно в многопользовательском режиме пользователи меняют разные данные.

это так кажется
7 май 15, 00:48    [17610335]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
const64
Member

Откуда:
Сообщений: 789
PgSQLAnonymous
А что хорошего в версионнике? Бесконечные откаты при высокой конкуренции
Звучит двусмысленно...
7 май 15, 14:22    [17613062]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
softwarer

Думаю, "неправильные" - очень неудачное слово.

Ну не очень неудачное. Как бы правило - читать в БД то, что в ней хранится в согласованном состоянии: т.е. результат завершенных транзакций. Несогласованные данные ("грязные") ну не правильные - таких не должно быть в БД. Согласованные типа как бы правильные. На момент запроса в БД именно такие данные. Хотя они в процессе изменения - как бы не совсем актуальные: раз меняют значит в там должны бы быть другие. Ну так это вопрос оперативности. Если это не правильно, то может быть, просто нужна типа система реального времени.
7 май 15, 18:36    [17614744]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67508
Блог
vadiminfo
softwarer
Думаю, "неправильные" - очень неудачное слово.

Ну не очень неудачное. Как бы правило - читать в БД то, что в ней хранится в согласованном состоянии

Именно. Насколько я понял Сергея, "неправильными" данными он назвал "те значения, которые вот-вот будут изменены, а мы их читаем".
7 май 15, 18:43    [17614782]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

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

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

Posted via ActualForum NNTP Server 1.5

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

Откуда: Обнинск
Сообщений: 4802
softwarer
vadiminfo
пропущено...

Ну не очень неудачное. Как бы правило - читать в БД то, что в ней хранится в согласованном состоянии

Именно. Насколько я понял Сергея, "неправильными" данными он назвал "те значения, которые вот-вот будут изменены, а мы их читаем".

Ну я тоже так понял. Но это как бы это все же особые требования к оперативности. Но если данные про то, чего не могло быть не до не после изменения, то они совсем неправильные.
Впрочем, я согласен, что термин "правильные" не подходит для строго описания. Выбран чисто для упрощения описания.
7 май 15, 19:13    [17614895]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67508
Блог
PgSQLAnonymous
Естественно, никак. Он может откатиться до savepoint-а вместо отката транзакции, если это нужно.

Замечательно. То есть предыдущее утверждение явно дезавуируем.

PgSQLAnonymous
Нда. То есть возможность наличие выбора

Выбор - не преимущество. Уместный выбор - преимущество. Неуместный выбор - недостаток.

Установка savepoint-а бесплатна и ничему не мешает. Поэтому выбор - неуместен, и необходимость в каких-то дополнительных телодвижениях для того, чтобы он был поставлен - недостаток.

PgSQLAnonymous
Как здесь появились "грязное чтение, мумпсом и прочий каменным век"?

Как пример "выборов", которые по Вашей логике, являются преимуществом.

PgSQLAnonymous
Ни с чем таким в PostgreSQL и MS SQL, например, где вышеописанный выбор есть, можно не мучаться (а с грязным чтением в PostgreSQL и не получится)...

Ну вот и очень плохо, что не получится Такие нехорошие, выбор отобрали
7 май 15, 19:17    [17614910]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить