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

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

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

Там написано, зачем они нужны, стюдент. ;)

этта
и да -- в пж при сериалайзебл будет откат второй

И это правильно.

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

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

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


А я говорю, что всё это болтовня, и аргументы я уже приводил в других ветках. Реальные контраргументы будут?
15 май 15, 11:49    [17644106]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
PgSQLAnonymous,

так, как хочется стюденту, "должно быть" при read commited
а при serializable д.б. ошибка изоляции, как оно и происходит в пж


рука--лицо, сюдент, рука--лицо

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

Откуда:
Сообщений: 84
этта
PgSQLAnonymous,
так, как хочется стюденту, "должно быть" при read commited
а при serializable д.б. ошибка изоляции, как оно и происходит в пж

С чего ты взял, что мне так хочется?! Ты вообще читать умеешь, стюдент?!
Так я повторю так, чтоб ты увидел:

PgSQLAnonymous

И это правильно.



этта
а птичка тут продемонстрировала банальный repeatable read

Таки да. ;)
15 май 15, 11:58    [17644178]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
PgSQLAnonymous
<>
А я говорю, что всё это болтовня, и аргументы я уже приводил в других ветках. Реальные контраргументы будут?
откат 100500 конкурентов выше по ветке

обусловленный 2--мя ошибками "архитектора" -- кривым дизайном (с пересекающимся в конкурентной работе с аггрегирующими сущностями) и неверным уровнем изоляции (который с таким дизайном вообще не ползает, не то, чтобы трепыхаться). я этот дизайн ещё могу оживить. Будет ползать с очередями. Хотя он и левый. Вы -- никогда.

и это всё е-болтовня, что ты якобы что-то где-то как-то приводил. ибо не по сеньке шапка, стюдент.
15 май 15, 12:01    [17644194]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
hvlad
Member

Откуда:
Сообщений: 11564
PgSQLAnonymous
Получиться-то должно было так:
Читаем что такое снапшот. 3 раза каждый день на ночь.
15 май 15, 12:01    [17644197]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
hvlad
PgSQLAnonymous
Получиться-то должно было так:
Читаем что такое снапшот. 3 раза каждый день на ночь.


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

Откуда:
Сообщений: 84
[quot этта]
PgSQLAnonymous
<>
обусловленный 2--мя ошибками "архитектора" -- кривым дизайном (с пересекающимся в конкурентной работе с аггрегирующими сущностями) и неверным уровнем изоляции (который с таким дизайном вообще не ползает, не то, чтобы трепыхаться). я этот дизайн ещё могу оживить. Будет ползать с очередями. Хотя он и левый. Вы -- никогда.

А покажи-ка "правый" дизайн для этой задачи, умник. Болтать --- не мешки таскать.


этта
и это всё е-болтовня, что ты якобы что-то где-то как-то приводил. ибо не по сеньке шапка, стюдент.

А это ты попросту соврал. Кому надо --- найдёт, почитает.
15 май 15, 12:22    [17644363]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

этта
откат 100500 конкурентов выше по ветке

Считаем на пальцах: пусть транзакция у анонимуса идёт 10 минут (иначе 100500 конкурентов
ну никак не накопятся), пусть он заставил из сериализоваться. Тогда последний конкурент
дождётся своей очереди на получение денег аккурат так через 10050000 минут. Умрёт от
старости он, пожалуй, гораздо раньше.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 11564
pkarklin
hvlad
Ну, тогда - да, нет в FB такого уровня изоляции. А где есть ?


MS SQL.
Т.е. там не будет дедлока при "перекрёстных" writes ? Позвольте не поверить :)
Или мы снова говорим о разном.
15 май 15, 12:29    [17644422]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
hvlad
Member

Откуда:
Сообщений: 11564
PgSQLAnonymous
Обожемой, ты же даже не понял.
Ты таки не видишь в своём собственном примере тупой ошибки с расстановкой коммитов ? Обожемой (ц)
15 май 15, 12:31    [17644445]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
hvlad
PgSQLAnonymous
Обожемой, ты же даже не понял.
Ты таки не видишь в своём собственном примере тупой ошибки с расстановкой коммитов ? Обожемой (ц)

Никакой ошибки там нет. Это провоцирующий тест на сериализацию, который InterBase провалил.
Что будет в настоящей ACID-СУБД, тебе уже показали на примере PostgreSQL. Я бы посоветовал перечитывать, пока не дойдёт.
15 май 15, 12:38    [17644502]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
hvlad
pkarklin
пропущено...
MS SQL.
Т.е. там не будет дедлока при "перекрёстных" writes ? Позвольте не поверить :)
Или мы снова говорим о разном.

Да (кажется), там будет DEADLOCK, и это, опять-таки, правильно.
А InterBase просто тихо покоцал данные, и это то, чего не должно быть.
15 май 15, 12:41    [17644533]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7005
PgSQLAnonymous
в настоящей ACID-СУБД

оставьте этот пафос, ей богу. Поддержка SERIALIZABLE и ACID вещи ортогональные. Или может вспомним, что ваша "настоящая" СУБД до 2011 года была "ненастоящей" и вовсю баловалась "подменой терминов"?
15 май 15, 12:47    [17644584]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
hvlad
Member

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

последняя попытка тебе образумиться:
- в момент старта каждой тр-ции в таблицах A и B было по 1-ой записи
- соотвественно инсерты видели по одной записи и позже вставили единицы, ибо это снапшот - он не может видеть
чужих изменений по-определению
- т.к. ты коммитишь первый инсерт до того, как выполнить второй инсерт, то конкуренции в твоём тесте нет вообще, ноль
- если сделать insert (1), insert (2), commit(1), commit (2), то insert (2) будет ждать commit(1) и, есс-но, вставит всё равно 1,
ибо в момент старта тр-ции (2) в таблице была 1 запись

PS То, что ты выдаёшь за единственно правильное, в IB\FB достигается с READ COMMITTED + RESERVING, но это я тут жевать не намерен.
15 май 15, 12:52    [17644635]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
dimitr
PgSQLAnonymous
в настоящей ACID-СУБД

оставьте этот пафос, ей богу. Поддержка SERIALIZABLE и ACID вещи ортогональные.

Ничего подобного. Поддержка SERIALIZABLE --- это обязательный компонент ACID, потому что он обеспечивает свойство ISOLATION.

dimitr
Или может вспомним, что ваша "настоящая" СУБД до 2011 года была "ненастоящей" и вовсю баловалась "подменой терминов"?

Да была, да, баловалась. Я так подозреваю, что это было тупо содрано с некоторой СУБД, на которую PostgreSQL пытался быть похожим.
И что из того? Некоторые-то до сих пор "ненастоящие" и балуются.
15 май 15, 12:59    [17644695]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

PgSQLAnonymous
Поддержка SERIALIZABLE --- это _обязательный_ компонент ACID, потому
что он обеспечивает свойство ISOLATION.

А вот нефиг читать комиксы в сокращённом варианте. Читай полную статью:
http://en.wikipedia.org/wiki/Isolation_(database_systems)

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 84
hvlad
PgSQLAnonymous,

последняя попытка тебе образумиться:
- в момент старта каждой тр-ции в таблицах A и B было по 1-ой записи
- соотвественно инсерты видели по одной записи и позже вставили единицы, ибо это снапшот - он не может видеть
чужих изменений по-определению
- т.к. ты коммитишь первый инсерт до того, как выполнить второй инсерт, то конкуренции в твоём тесте нет вообще, ноль
- если сделать insert (1), insert (2), commit(1), commit (2), то insert (2) будет ждать commit(1) и, есс-но, вставит всё равно 1,
ибо в момент старта тр-ции (2) в таблице была 1 запись

PS То, что ты выдаёшь за единственно правильное, в IB\FB достигается с READ COMMITTED + RESERVING, но это я тут жевать не намерен.

Последняя попытка тебе образумиться: ты утверждал, что этот "SNAPSHOT TABLE STABILITY" --- это SERIALIZABLE.
В SERIALIZABLE должен был получиться один из двух указанных результатов. Тест показал, что это не так. Следовательно, "SNAPSHOT TABLE STABILITY" --- это не SERIALIZABLE, и все твои объяснения к делу не относятся.
15 май 15, 13:06    [17644728]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

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

Считаем на пальцах: пусть транзакция у анонимуса идёт 10 минут (иначе 100500 конкурентов
ну никак не накопятся), пусть он заставил из сериализоваться. Тогда последний конкурент
дождётся своей очереди на получение денег аккурат так через 10050000 минут. Умрёт от
старости он, пожалуй, гораздо раньше.

То есть ссылки на статистику NASDAQ и объяснения ты просто проигнорировал (потому что в твою картину мира они не укладываются)?
15 май 15, 13:09    [17644751]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

PgSQLAnonymous
То есть ссылки на статистику NASDAQ и объяснения ты просто
проигнорировал (потому что в твою картину мира они не укладываются)?

Я их проигнорировал, поскольку во-первых, ты их не привёл, а во-вторых, там транзакции не
длятся по 10 минут.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 84
Dimitry Sibiryakov
PgSQLAnonymous
Поддержка SERIALIZABLE --- это _обязательный_ компонент ACID, потому
что он обеспечивает свойство ISOLATION.

А вот нефиг читать комиксы в сокращённом варианте. Читай полную статью:
http://en.wikipedia.org/wiki/Isolation_(database_systems)

О, вот и ссылки на мурзилку появились. ;) Кстати, где ты там это вычитал?
Если тебе так нравится этот журнал, я оттуда поцитирую 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.
15 май 15, 13:14    [17644795]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Что-то вы тут разошлись, 11 страниц для такого простого вопроса многовато...
15 май 15, 13:19    [17644841]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
Dimitry Sibiryakov
Я их проигнорировал, поскольку во-первых, ты их не привёл, а во-вторых, там транзакции не длятся по 10 минут.


Во-первых:
PgSQLAnonymous
Короче говоря, в некоторых условиях у достаточно крупного брокера тысячи транзакций могут пересечься.
Или все проблемы с конкурентным доступом нужно решать их отрицанием? ;)

Кстати, вот можно оценить объёмы транзакций на бирже: http://www.nasdaqtrader.com/Trader.aspx?id=DailyMarketSummary

И это только сделки, заявок (которые используются в моём примере) за день делается гораздо больше.

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

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

PgSQLAnonymous
Во-вторых, в этом примере ни одна транзакция не длится по 10
минут.

А теперь берём цифры по ссылке, делим количество сделок на количество брокеров, а потом на
длину рабочего для и получаем 38 сделок в минуту на брокера. Где там 100500 откатов?

Кстати, строгого контроля овердрафта там тоже нет, так что счёт брокера вообще не является
конкурентным ресурсом.

Posted via ActualForum NNTP Server 1.5

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

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
MS SQL.
Т.е. там не будет дедлока при "перекрёстных" writes ? Позвольте не поверить :)
Или мы снова говорим о разном.[/quot]

Казалось бы, причем здесь SERIALIZABLE TIL?!
15 май 15, 13:41    [17645042]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
Dimitry Sibiryakov
PgSQLAnonymous
Во-вторых, в этом примере ни одна транзакция не длится по 10
минут.

А теперь берём цифры по ссылке, делим количество сделок на количество брокеров, а потом на
длину рабочего для и получаем 38 сделок в минуту на брокера. Где там 100500 откатов?

Попробую в третий раз:
PgSQLAnonymous
И это только сделки, заявок (которые используются в моём примере) за день делается гораздо больше.


Dimitry Sibiryakov
Кстати, строгого контроля овердрафта там тоже нет, так что счёт брокера вообще не является
конкурентным ресурсом.

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