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

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

pkarklin
Казалось бы, причем здесь SERIALIZABLE TIL?!

При том, что, согласно ПГанонимусу, он сериализует транзакции, что делает невозможным
конфликты и дедлоки в принципе.

PgSQLAnonymous
Почему ты в этом уверен?

Потому что так работают все биржи. Баланс контролируется только по закрытию торгов.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 84
Dimitry Sibiryakov
pkarklin
Казалось бы, причем здесь SERIALIZABLE TIL?!

При том, что, согласно ПГанонимусу, он сериализует транзакции, что делает невозможным
конфликты и дедлоки в принципе.

Что ты несёшь?! Я никогда такого не говорил! Как раз конфликты и дедлоки при сериализации неизбежны в некоторых ситуациях.

Dimitry Sibiryakov
PgSQLAnonymous
Почему ты в этом уверен?

Потому что так работают все биржи. Баланс контролируется только по закрытию торгов.

А биржа тут причём? Речь идёт об обработке у брокера.
15 май 15, 14:14    [17645332]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
pkarklin
Member

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

автор
При том, что, согласно ПГанонимусу, он сериализует транзакции, что делает невозможным
конфликты и дедлоки в принципе.


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

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

PgSQLAnonymous
Что ты несёшь?! Я никогда такого не говорил!

А вот это тогда чьё?

PgSQLAnonymous
Если тебе так нравится этот журнал, я оттуда поцитирую
http://en.wikipedia.org/wiki/ACID :
The isolation property ensures that the concurrent execution of transactions results
in a system state that would be obtained if transactions were executed serially, i.e., one
after the other.


Какие могут быть дедлоки при выполнении транзакций "one after the other"?..

Posted via ActualForum NNTP Server 1.5

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

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov
PgSQLAnonymous
Что ты несёшь?! Я никогда такого не говорил!

А вот это тогда чьё?

PgSQLAnonymous
Если тебе так нравится этот журнал, я оттуда поцитирую
http://en.wikipedia.org/wiki/ACID :
пропущено...


Какие могут быть дедлоки при выполнении транзакций "one after the other"?..


А зачем сюда притаскивать за уши дедлоки, если здесь описан результат применения SERIALIZABLE - после выполнения двух транзакций хоть как последовательно, так и параллельно, система имеет одно и тоже конечное состояние?
15 май 15, 14:28    [17645453]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
MasterZiv
11 страниц для такого простого вопроса многовато...

да тут нам serializable впаривают как панацею.
15 май 15, 14:34    [17645493]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
Dimitry Sibiryakov
PgSQLAnonymous
Что ты несёшь?! Я никогда такого не говорил!

А вот это тогда чьё?

PgSQLAnonymous
Если тебе так нравится этот журнал, я оттуда поцитирую
http://en.wikipedia.org/wiki/ACID :
пропущено...


Какие могут быть дедлоки при выполнении транзакций "one after the other"?..

Да обычные, потому что не "выполнении транзакций one after the other", а would be obtained if transactions were executed serially. То есть идентичное состояние было бы получено, если бы транзакции выполнялись последовательно, одна за другой.
15 май 15, 14:40    [17645519]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
kdv
MasterZiv
11 страниц для такого простого вопроса многовато...

да тут нам serializable впаривают как панацею.

Потому что он ею и является, сюрприз. ;)
15 май 15, 14:41    [17645532]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

PgSQLAnonymous
Да обычные, потому что не "выполнении транзакций one after the
other", а would be obtained if transactions were executed serially. То есть идентичное
состояние было бы получено, если бы транзакции выполнялись последовательно, одна за
другой.

Ну так я повторяю вопрос: как можно получить состояние, идентичное дэдлоку при
последовательном выполнении транзакций?

Posted via ActualForum NNTP Server 1.5

15 май 15, 14:42    [17645543]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
зз топ
Guest
PgSQLAnonymous
Если тебе так нравится этот журнал, я оттуда поцитирую http://en.wikipedia.org/wiki/ACID :
The isolation property ensures that the concurrent execution of transactions results in a system state
that would be obtained if transactions were executed serially, i.e., one after the other.

Цитата приведена не полностью. Там дальше еще есть:
Depending on concurrency control method (i.e. if it uses strict - as opposed to relaxed - serializability), the effects of an incomplete transaction might not even be visible to another transaction.
15 май 15, 14:43    [17645549]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
PgSQLAnonymous,

тебе с порога было написано: вместо пересекающихся по конкурентам сущностей-- "агрегатов" Счет [Клиента|Брокера], должны быть индивидуальные Сущности "СчетКлиентаУБрокера". точка.

никаких агрегатных [по всем клиентам] сущностей. Пока можно агрегировать "счет брокера" в моменте. Как только уже нельзя -- долго агрегировать -- так начинаем чесать репу.

+ чесать репу
выход 1 -- организовать очередь на агрегирующем ресурсе, с инкрементальным навариванием "ресурса" [read commited only]. Ограниченно годен -- при большом числе конкурентов и большой длине "слайса очереди" (т.е. средней протяженности от захвата ресурса до коммита, отдающего очередь) встанет колом.

выход 2 -- не иметь уникального агрегирующего ресурса "СчетБрокера", а иметь "размазанный, периодически сворачиваемый" "многострочный" агрегат , нужно следить за видимостями при свёртках (можно сворачивать и в снепшоте (repeatable-read-е), как показывал сибиряков, можно сворачивать в commited-е -- по всякому, в pg -- в т.ч. через cte -- у которого единый снепшот [WITH del AS (DELETE ... RETURNING...) ]. а вот с сериалайзебл будет велик шанс облома сериализации. патамушто гладиолус).

и т.п.


простите отвлёкся работкой, забыл запостить
15 май 15, 15:00    [17645721]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
Dimitry Sibiryakov
PgSQLAnonymous
Да обычные, потому что не "выполнении транзакций one after the
other", а would be obtained if transactions were executed serially. То есть идентичное
состояние было бы получено, если бы транзакции выполнялись последовательно, одна за
другой.

Ну так я повторяю вопрос: как можно получить состояние, идентичное дэдлоку при
последовательном выполнении транзакций?

А нет никакого состояния базы, "идентичного дэдлоку". ;)
База переходит из одного консистентного состояния в другое только по COMMIT-ам транзакций.
У меня ощущение, что пересказываю базовые вещи.
15 май 15, 15:41    [17646085]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

PgSQLAnonymous
А нет никакого состояния базы, "идентичного дэдлоку". ;)

Отсюда следует, что транзакции, впадающие в дэдлок - не serializable.

Posted via ActualForum NNTP Server 1.5

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

нет, просто понятие "состояние базы" в контексте про сериализацию -- это некая обсракция [~~~#состояние данных#], отличная от физического понятия "состояние базы и её СУБД", которым пытаетесь оперировать вы

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

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

этта
оперируйте пожалуйста обсракциями здорового человека

Да нет проблем: две параллельные транзакции, впавшие в дэдлок, не могут быть закоммичены.
Следовательно, они не могут привести БД в состояние, в которое они привели бы её, если бы
выполнялись последовательно. Следовательно, такие транзакции - не serializable.

Posted via ActualForum NNTP Server 1.5

15 май 15, 15:58    [17646215]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
Dimitry Sibiryakov
этта
оперируйте пожалуйста обсракциями здорового человека

Да нет проблем: две параллельные транзакции, впавшие в дэдлок, не могут быть закоммичены.
Следовательно, они не могут привести БД в состояние, в которое они привели бы её, если бы
выполнялись последовательно. Следовательно, такие транзакции - не serializable.
не-а
вы оперируете не обсракцией здорового человек "транзакция"
а обсракцией курильщика "транзакция в конкретном конкурентном окружении"

они (как, объекты вне окружения, self) таки приводятся в чувство процедурой снятия одной из 2-х и выстраиванием её в хвост к закоммиченной. т.е. serializable.
15 май 15, 16:17    [17646340]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

этта
они (как, объекты вне окружения, self) таки приводятся в чувство процедурой
снятия одной из 2-х и выстраиванием её в хвост к закоммиченной. т.е. serializable.

А снимать её, такую всю без окружения, а потом ещё и повторять полностью от начала - кто
будет?..

Posted via ActualForum NNTP Server 1.5

15 май 15, 16:20    [17646355]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
Dimitry Sibiryakov
этта
они (как, объекты вне окружения, self) таки приводятся в чувство процедурой
снятия одной из 2-х и выстраиванием её в хвост к закоммиченной. т.е. serializable.

А снимать её, такую всю без окружения, а потом ещё и повторять полностью от начала - кто
будет?..


https://www.sql.ru/forum/memberinfo.aspx?mid=222507 же
ему оно упало -- вот пусть и колупается
15 май 15, 16:22    [17646368]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
ps а снимет-то -- пж
снимет легко
у него это в serializable не заржавеет

ононимусу только повторять придется.

и так --100499 раз в 100500/2 в среднем транзакциях
15 май 15, 16:25    [17646384]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
этта
PgSQLAnonymous,
у вас ус отклеился

у вас там таблички N непришейкобылехвост. [стюдент рука--лицо ]

и да -- в пж при сериалайзебл будет откат второй
+
ОШИБКА:  не удалось сериализовать доступ из-за зависимостей чтения/записи между транзакциями
DETAIL: Reason code: Canceled on identification as a pivot, during write.
HINT: Транзакция может завершиться успешно при следующей попытке.

а при repeatable read -- количество во второй будет соответствовать снепшоту при старте, а не нормальному, при read commited текущему состоянию.

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

кто умеет -- пишут инкрементальную, а не агрегатную логику на сервере, и требуют именно readcommited-а, а не маргинальных снапшотов и т.п.

все маргинальные уровни изоляции требуются только для развесистых агрегатов типа отчетов по плохо связанным наборам. -- чтобы синхронизировать снапшоты отдельных расчётов

клиентов много, пишущие их разной квалификации и т.д.
создание и управление "золотой записи" (как в МДМ) святой долг СУБД, но для этого СУБД должна себе представлять, что такое "золотая запись" и какие правила ее формирования
имеющегося набора всяких чахлых констрейнтов и т.д. инструментария не хватает для интерпретации данных со стороны СУБД
15 май 15, 16:47    [17646520]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
sanyock2
Member

Откуда:
Сообщений: 3882
PgSQLAnonymous
И, кстати, знай добавляй RAM и "будет расти iops-ы". ;)

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

Откуда:
Сообщений: 84
этта
Dimitry Sibiryakov
пропущено...

А снимать её, такую всю без окружения, а потом ещё и повторять полностью от начала - кто
будет?..


https://www.sql.ru/forum/memberinfo.aspx?mid=222507 же
ему оно упало -- вот пусть и колупается

Ну а кто же ещё будет повторять-то? ;) Естественно, клиент.
Более того, каждый клиент в норме обязан быть готов это сделать.
15 май 15, 17:26    [17646732]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

PgSQLAnonymous
Естественно, клиент.
Более того, каждый клиент в норме обязан быть готов это сделать.

Ага, это мне напомнило времена, когда тут ещё появлялись Фокспрошники: "нашей СУБД не
нужны транзакции, мы легко эмулируем их с помощью временных таблиц".

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 3882
Dimitry Sibiryakov
Infernal V. Raven
Ну так обоснуйте.

Обосновываю: существует всего два вероятных исхода: "блондинка встретит динозавра" и
"блондинка не встретит динозавра". Согласно теории вероятности, вероятность каждого
отдельного исхода равна единице, делённой на число возможных исходов. Следовательно, у
блондинки есть вероятность 50% на встречу с динозавром. Сможете опровергнуть?


так это ведь только в самом общем случае при отсутствии информации о популяции блондинок и динозавров
15 май 15, 17:51    [17646859]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
sanyock2
Dimitry Sibiryakov
пропущено...

Обосновываю: существует всего два вероятных исхода: "блондинка встретит динозавра" и
"блондинка не встретит динозавра". Согласно теории вероятности, вероятность каждого
отдельного исхода равна единице, делённой на число возможных исходов.
Следовательно, у
блондинки есть вероятность 50% на встречу с динозавром. Сможете опровергнуть?


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


зачем вы спорите с бредом.

+
оступление 1:
есть примитивный способ отъёма денех -- бросается 3 кубика, исходы -- от 3 до 18 побиты на 3 неравные части. банкующий сидит на короткой средней стороне (где мало исходов), игроку предлагает любую другую (из 3-х), но в среднем выигрывает сам.

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



теория вероятности не устанавливает вероятности какого либо исхода. они полагаются априорно известными. (например в комбинаторных задачах -- по числу комбинаций примитивных событий приводящих к исходу. от общего числа комбинаций). или считается известной (или хотя бы определённой) плотность вероятности (равномерная по комбинациям [но не исходам] -- в случае комбинаторных задач). ну и т.п.
15 май 15, 18:07    [17646946]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 [12] 13 14 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить