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

Откуда:
Сообщений: 3882
в контексте данной темы интересно, как в тяжелых тиражируемых системах удается сделать поддержку СУБД с разной реализацией уровней изоляции, особенно блокировочников и версионников одновременно (т.е. какой-то один на выбор приобретателя системы)

там пишется разный код бизнес логики приложения для разных СУБД?
Подразумевается, что в СУБД логики по минимуму (без хранимых процедур, если так бывает, или хранимые процедуры только для тяжелых отчетов), почти вся логика в бизнес слое приложения
15 май 15, 19:01    [17647211]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
sanyock2
в контексте данной темы интересно, как в тяжелых тиражируемых системах удается сделать поддержку СУБД с разной реализацией уровней изоляции, особенно блокировочников и версионников одновременно (т.е. какой-то один на выбор приобретателя системы)

там пишется разный код бизнес логики приложения для разных СУБД?
Подразумевается, что в СУБД логики по минимуму (без хранимых процедур, если так бывает, или хранимые процедуры только для тяжелых отчетов), почти вся логика в бизнес слое приложения

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

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

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

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

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

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

и т.п.


Ну это всё как-то слишком общо... Не видно, как достигается цель: не допустить ухода в минус счёта брокера.
15 май 15, 19:14    [17647242]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

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

это как? можно поподробнее?

Вы бы контекста-то побольше оставляли: ;)

PgSQLAnonymous
Ggg_old
Лично я всегда предпочитал блокировочники, но у версионников как показало время есть преимущество в части масштабируемости информационных систем, которые не параллелятся по типу shared nothing. Например все тяжелые учетные системы, банковские системы. Дисковые стойки масштабируются очень хорошо и линейно, знай добавляй дисков и будет расти iops-ы, версионники хрянт инфу о блокировка на диске, а значит гораздо меньше зависят в отличие от блокировочников, хранящих блокировки в RAM. Т.е. производительность версионников привязана к гораздо более легко масштабируемому ресурсу, чем производительность блокировочников.

Вообще-то кеширование в основном скрывает эти различия, и как блокировки (которые тоже могут храниться на диске), так и версии (которые тоже можно хранить в RAM) обычно находятся именно в RAM. И, кстати, знай добавляй RAM и "будет расти iops-ы". ;)

Если не хватает RAM для блокировок, они обычно эскалируются (например, блокировки записей превращаются в блокировки страниц или таблиц), поэтому производительность может страдать. Добавление RAM может предотвратить это, только и всего (основное влияние на производительность происходит за счёт кэширования, конечно).
15 май 15, 19:31    [17647291]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
sanyock2
Member

Откуда:
Сообщений: 3882
и еще интересно, как думаете, теоретически возможно в DB2 появление включаемой версионности аналогично MSSQL?
или IBMвцы принципиально не хотят версионник
или это слишком сложно конкретно в случае DB2
или или ...
15 май 15, 19:32    [17647294]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
sanyock2
в контексте данной темы интересно, как в тяжелых тиражируемых системах удается сделать поддержку СУБД с разной реализацией уровней изоляции, особенно блокировочников и версионников одновременно (т.е. какой-то один на выбор приобретателя системы)

там пишется разный код бизнес логики приложения для разных СУБД?
Подразумевается, что в СУБД логики по минимуму (без хранимых процедур, если так бывает, или хранимые процедуры только для тяжелых отчетов), почти вся логика в бизнес слое приложения

все эти системы монопольно используют СУБД, все конфликты разрешается через промежуточный слой к СУБД
но как только какая та другая система в обход этого промежуточного слоя идет в БД, так сразу все гавкается
и все это потому что у СУБД нет мозгов
15 май 15, 19:33    [17647300]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
Dimitry Sibiryakov
PgSQLAnonymous
Естественно, клиент.
Более того, каждый клиент в норме обязан быть готов это сделать.

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

А какая-то СУБД гарантирует, что для любой транзакции не будет ни DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам?
Реальный мир не напоминает? ;)
15 май 15, 19:33    [17647301]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
ViPRos
Member

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

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

А какая-то СУБД гарантирует, что для любой транзакции не будет ни DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам?
Реальный мир не напоминает? ;)

любая СУБД это может делать, если он знает свои обязанности и права
15 май 15, 19:36    [17647310]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
и при этом набор прав и обязанностей должен быть полной для разрешения любого типа конфликта
15 май 15, 19:37    [17647312]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
а то блин орловский мент одни правила применяет, а московский другие - вот жисть то блин
15 май 15, 19:38    [17647317]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
sanyock2
Member

Откуда:
Сообщений: 3882
PgSQLAnonymous
sanyock2
пропущено...
это как? можно поподробнее?

Вы бы контекста-то побольше оставляли: ;)


в смысле это было образно про то, что с помощью оперативки получится смасштабировать любое количество сессий большого динозавра? и под "iops" подразумевалось TPS вместо iops? чето я запутался, вообще конечно тяжелая ветка в целом для моего понимания, может быть из-за отсутствия опыта программирования высоконагруженных БД
15 май 15, 19:43    [17647329]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
sanyock2
Member

Откуда:
Сообщений: 3882
ViPRos
все конфликты разрешается через промежуточный слой к СУБД

т.е. они по разному разрешаются в зависимости от используемой СУБД, для каждой свой конфликт манагер создается?
15 май 15, 19:49    [17647340]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

PgSQLAnonymous
А какая-то СУБД гарантирует, что для любой транзакции не будет ни
DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам?

Да любая, у которой есть "настоящий serializable". Ты же сам говорил, что знаешь одну такую.

PS: Джим Старки пару лет назад говорил, что в одном из своих свежих поделий (то ли в
Nexus, то ли в Nuo) решил проблему конкуренции полной сериализацией транзакций. Типа, это
упростило и ускорило движок до невозможности, так что TPS взлетели до небес.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 9967
sanyock2
ViPRos
все конфликты разрешается через промежуточный слой к СУБД

т.е. они по разному разрешаются в зависимости от используемой СУБД, для каждой свой конфликт манагер создается?

они по разному разрешается в каждой системе написанной для этой СУБД, что и приводит к бардаку
все эти аппсерверы пытаются закрыть дыры СУБД по части разрешения конфликтов
а поставщики СУБД не занимаются этим вопросом по причине гонки за "производительностью", а то бы давно был стандартный менеджер разрешения любых!!! конфликтов за счет утяжеления описания данных, семантичнеский анализ поступающих запросов и т.д.
15 май 15, 19:55    [17647357]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
Dimitry Sibiryakov
PgSQLAnonymous
А какая-то СУБД гарантирует, что для любой транзакции не будет ни
DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам?

Да любая, у которой есть "настоящий serializable". Ты же сам говорил, что знаешь одну такую.

PS: Джим Старки пару лет назад говорил, что в одном из своих свежих поделий (то ли в
Nexus, то ли в Nuo) решил проблему конкуренции полной сериализацией транзакций. Типа, это
упростило и ускорило движок до невозможности, так что TPS взлетели до небес.

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

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

ViPRos
пиздит

С чего бы?

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 9967
Dimitry Sibiryakov
ViPRos
пиздит

С чего бы?

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

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

Откуда:
Сообщений: 84
Dimitry Sibiryakov
PgSQLAnonymous
А какая-то СУБД гарантирует, что для любой транзакции не будет ни
DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам?

Да любая, у которой есть "настоящий serializable". Ты же сам говорил, что знаешь одну такую.

Нда. И с чего ты взял, что "настоящий serializable" --- это отсутствие вышеперечисленного?
Тем более, после того, как тебе здесь неоднократно указали, что это не так?

PgSQLAnonymous
PS: Джим Старки пару лет назад говорил, что в одном из своих свежих поделий (то ли в
Nexus, то ли в Nuo) решил проблему конкуренции полной сериализацией транзакций. Типа, это упростило и ускорило движок до невозможности, так что TPS взлетели до небес.

Поживём-увидим. ;)
15 май 15, 20:04    [17647384]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

ViPRos
ускорения невозможно добиться

Ага, ещё добавь "у меня же не получилось".

Рецепт-то простой: NoSQL, in-memory, autocommit. Всё, телемаркет: миллиард транзакций в
секунду выдаётся на гора легко. Фигня, что эти "транзакции" - увеличение числа на единицу,
кому-нибудь и такое требуется. Например, гуглю посещения считать.

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 84
ViPRos
они по разному разрешается в каждой системе написанной для этой СУБД, что и приводит к бардаку
все эти аппсерверы пытаются закрыть дыры СУБД по части разрешения конфликтов
а поставщики СУБД не занимаются этим вопросом по причине гонки за "производительностью", а то бы давно был стандартный менеджер разрешения любых!!! конфликтов за счет утяжеления описания данных, семантичнеский анализ поступающих запросов и т.д.

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

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

PgSQLAnonymous
И с чего ты взял, что "настоящий serializable" --- это отсутствие
вышеперечисленного?

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

PgSQLAnonymous
Тем более, после того, как тебе здесь неоднократно указали, что это
не так?

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

Posted via ActualForum NNTP Server 1.5

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

Откуда:
Сообщений: 84
sanyock2
в смысле это было образно про то, что с помощью оперативки получится смасштабировать любое количество сессий большого динозавра?

Да, где-то как-то так. ;)

sanyock2
и под "iops" подразумевалось TPS вместо iops? чето я запутался, вообще конечно тяжелая ветка в целом для моего понимания, может быть из-за отсутствия опыта программирования высоконагруженных БД

Если для выполнения запроса клиента СУБД нужно прочитать 100000 страниц,
и в одном случае на это уходит 2 сек, а в другом 1, то похоже на то,
что во втором случае IOPS вдвое больше (что может быть просто эффектом кэширования). ;)
15 май 15, 20:20    [17647419]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

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

Нет, ты замучал уже. Советую перечитывать эту тему, стандарт SQL,
документацию настоящих СУБД (мурзилку, наконец) пока до тебя не дойдёт,
что такое ACID, ISOLATION, serializability и SERIALIZABLE.

Dimitry Sibiryakov
Здесь неоднократно показали, что та хрень, которая гордо называется "serializable" в PG и
Оракуле

Не надо Oracle и PostgreSQL мешать в одну кучу в этом вопросе.

Dimitry Sibiryakov
- никакого отношения к serializable не имеет. Ничего более.

Да, да, чёрное — это белое. Война — это мир. Свобода — это рабство. Незнание — сила. Ложь — это правда.
15 май 15, 20:31    [17647446]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

PgSQLAnonymous
Советую перечитывать эту тему, стандарт SQL, документацию настоящих
СУБД (мурзилку, наконец) пока до тебя не дойдёт, что такое ACID, ISOLATION,
serializability и SERIALIZABLE.

А какое слово из "если бы транзакции выполнялись последовательно, одна за другой" не
понимаешь ты? Если транзакции на самом деле выполняются строго последовательно,
одна за другой - это и есть истинный TIL serializable. Потому что (сурпрайз!) транзакции
при нём действительно сериализованы.

Posted via ActualForum NNTP Server 1.5

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