|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
в контексте данной темы интересно, как в тяжелых тиражируемых системах удается сделать поддержку СУБД с разной реализацией уровней изоляции, особенно блокировочников и версионников одновременно (т.е. какой-то один на выбор приобретателя системы) там пишется разный код бизнес логики приложения для разных СУБД? Подразумевается, что в СУБД логики по минимуму (без хранимых процедур, если так бывает, или хранимые процедуры только для тяжелых отчетов), почти вся логика в бизнес слое приложения ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:01 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
sanyock2в контексте данной темы интересно, как в тяжелых тиражируемых системах удается сделать поддержку СУБД с разной реализацией уровней изоляции, особенно блокировочников и версионников одновременно (т.е. какой-то один на выбор приобретателя системы) там пишется разный код бизнес логики приложения для разных СУБД? Подразумевается, что в СУБД логики по минимуму (без хранимых процедур, если так бывает, или хранимые процедуры только для тяжелых отчетов), почти вся логика в бизнес слое приложения Как-как... обычно хреново, т.е. используется минимальное общее подмножество возможностей, а потом разработчики под эту систему долбаются с результатом. :( ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:10 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
эттаPgSQLAnonymous, тебе с порога было написано: вместо пересекающихся по конкурентам сущностей-- "агрегатов" Счет [Клиента|Брокера], должны быть индивидуальные Сущности "СчетКлиентаУБрокера". точка. никаких агрегатных [по всем клиентам] сущностей. Пока можно агрегировать "счет брокера" в моменте. Как только уже нельзя -- долго агрегировать -- так начинаем чесать репу. чесать репувыход 1 -- организовать очередь на агрегирующем ресурсе, с инкрементальным навариванием "ресурса" [read commited only]. Ограниченно годен -- при большом числе конкурентов и большой длине "слайса очереди" (т.е. средней протяженности от захвата ресурса до коммита, отдающего очередь) встанет колом. выход 2 -- не иметь уникального агрегирующего ресурса "СчетБрокера", а иметь "размазанный, периодически сворачиваемый" "многострочный" агрегат , нужно следить за видимостями при свёртках (можно сворачивать и в снепшоте (repeatable-read-е), как показывал сибиряков, можно сворачивать в commited-е -- по всякому, в pg -- в т.ч. через cte -- у которого единый снепшот [WITH del AS (DELETE ... RETURNING...) ]. а вот с сериалайзебл будет велик шанс облома сериализации. патамушто гладиолус). и т.п. Ну это всё как-то слишком общо... Не видно, как достигается цель: не допустить ухода в минус счёта брокера. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:14 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
sanyock2PgSQLAnonymousИ, кстати, знай добавляй RAM и "будет расти iops-ы". ;) это как? можно поподробнее? Вы бы контекста-то побольше оставляли: ;) PgSQLAnonymousGgg_oldЛично я всегда предпочитал блокировочники, но у версионников как показало время есть преимущество в части масштабируемости информационных систем, которые не параллелятся по типу shared nothing. Например все тяжелые учетные системы, банковские системы. Дисковые стойки масштабируются очень хорошо и линейно, знай добавляй дисков и будет расти iops-ы, версионники хрянт инфу о блокировка на диске, а значит гораздо меньше зависят в отличие от блокировочников, хранящих блокировки в RAM. Т.е. производительность версионников привязана к гораздо более легко масштабируемому ресурсу, чем производительность блокировочников. Вообще-то кеширование в основном скрывает эти различия, и как блокировки (которые тоже могут храниться на диске), так и версии (которые тоже можно хранить в RAM) обычно находятся именно в RAM. И, кстати, знай добавляй RAM и "будет расти iops-ы". ;) Если не хватает RAM для блокировок, они обычно эскалируются (например, блокировки записей превращаются в блокировки страниц или таблиц), поэтому производительность может страдать. Добавление RAM может предотвратить это, только и всего (основное влияние на производительность происходит за счёт кэширования, конечно). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:31 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
и еще интересно, как думаете, теоретически возможно в DB2 появление включаемой версионности аналогично MSSQL? или IBMвцы принципиально не хотят версионник или это слишком сложно конкретно в случае DB2 или или ... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:32 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
sanyock2в контексте данной темы интересно, как в тяжелых тиражируемых системах удается сделать поддержку СУБД с разной реализацией уровней изоляции, особенно блокировочников и версионников одновременно (т.е. какой-то один на выбор приобретателя системы) там пишется разный код бизнес логики приложения для разных СУБД? Подразумевается, что в СУБД логики по минимуму (без хранимых процедур, если так бывает, или хранимые процедуры только для тяжелых отчетов), почти вся логика в бизнес слое приложения все эти системы монопольно используют СУБД, все конфликты разрешается через промежуточный слой к СУБД но как только какая та другая система в обход этого промежуточного слоя идет в БД, так сразу все гавкается и все это потому что у СУБД нет мозгов ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:33 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovPgSQLAnonymousЕстественно, клиент. Более того, каждый клиент в норме обязан быть готов это сделать. Ага, это мне напомнило времена, когда тут ещё появлялись Фокспрошники: "нашей СУБД не нужны транзакции, мы легко эмулируем их с помощью временных таблиц". А какая-то СУБД гарантирует , что для любой транзакции не будет ни DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам? Реальный мир не напоминает? ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:33 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymousDimitry Sibiryakovпропущено... Ага, это мне напомнило времена, когда тут ещё появлялись Фокспрошники: "нашей СУБД не нужны транзакции, мы легко эмулируем их с помощью временных таблиц". А какая-то СУБД гарантирует , что для любой транзакции не будет ни DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам? Реальный мир не напоминает? ;) любая СУБД это может делать, если он знает свои обязанности и права ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:36 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
и при этом набор прав и обязанностей должен быть полной для разрешения любого типа конфликта ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:37 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
а то блин орловский мент одни правила применяет, а московский другие - вот жисть то блин ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:38 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymoussanyock2пропущено... это как? можно поподробнее? Вы бы контекста-то побольше оставляли: ;) в смысле это было образно про то, что с помощью оперативки получится смасштабировать любое количество сессий большого динозавра? и под "iops" подразумевалось TPS вместо iops? чето я запутался, вообще конечно тяжелая ветка в целом для моего понимания, может быть из-за отсутствия опыта программирования высоконагруженных БД ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:43 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
ViPRosвсе конфликты разрешается через промежуточный слой к СУБД т.е. они по разному разрешаются в зависимости от используемой СУБД, для каждой свой конфликт манагер создается? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:49 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymousА какая-то СУБД гарантирует, что для любой транзакции не будет ни DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам? Да любая, у которой есть "настоящий serializable". Ты же сам говорил, что знаешь одну такую. PS: Джим Старки пару лет назад говорил, что в одном из своих свежих поделий (то ли в Nexus, то ли в Nuo) решил проблему конкуренции полной сериализацией транзакций. Типа, это упростило и ускорило движок до невозможности, так что TPS взлетели до небес. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:53 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
sanyock2ViPRosвсе конфликты разрешается через промежуточный слой к СУБД т.е. они по разному разрешаются в зависимости от используемой СУБД, для каждой свой конфликт манагер создается? они по разному разрешается в каждой системе написанной для этой СУБД, что и приводит к бардаку все эти аппсерверы пытаются закрыть дыры СУБД по части разрешения конфликтов а поставщики СУБД не занимаются этим вопросом по причине гонки за "производительностью", а то бы давно был стандартный менеджер разрешения любых!!! конфликтов за счет утяжеления описания данных, семантичнеский анализ поступающих запросов и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:55 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovPgSQLAnonymousА какая-то СУБД гарантирует, что для любой транзакции не будет ни DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам? Да любая, у которой есть "настоящий serializable". Ты же сам говорил, что знаешь одну такую. PS: Джим Старки пару лет назад говорил, что в одном из своих свежих поделий (то ли в Nexus, то ли в Nuo) решил проблему конкуренции полной сериализацией транзакций. Типа, это упростило и ускорило движок до невозможности, так что TPS взлетели до небес. пиздит ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:55 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
ViPRosпиздит С чего бы? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 19:59 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovViPRosпиздит С чего бы? ускорения невозможно добиться ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 20:00 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
хотя если у него до этого было совсем говно, то почему бы и нет ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 20:00 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovPgSQLAnonymousА какая-то СУБД гарантирует, что для любой транзакции не будет ни DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам? Да любая, у которой есть "настоящий serializable". Ты же сам говорил, что знаешь одну такую. Нда. И с чего ты взял, что "настоящий serializable" --- это отсутствие вышеперечисленного? Тем более, после того , как тебе здесь неоднократно указали, что это не так? PgSQLAnonymousPS: Джим Старки пару лет назад говорил, что в одном из своих свежих поделий (то ли в Nexus, то ли в Nuo) решил проблему конкуренции полной сериализацией транзакций. Типа, это упростило и ускорило движок до невозможности, так что TPS взлетели до небес. Поживём-увидим. ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 20:04 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
ViPRosускорения невозможно добиться Ага, ещё добавь "у меня же не получилось". Рецепт-то простой: NoSQL, in-memory, autocommit. Всё, телемаркет: миллиард транзакций в секунду выдаётся на гора легко. Фигня, что эти "транзакции" - увеличение числа на единицу, кому-нибудь и такое требуется. Например, гуглю посещения считать. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 20:06 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
ViPRosони по разному разрешается в каждой системе написанной для этой СУБД, что и приводит к бардаку все эти аппсерверы пытаются закрыть дыры СУБД по части разрешения конфликтов а поставщики СУБД не занимаются этим вопросом по причине гонки за "производительностью", а то бы давно был стандартный менеджер разрешения любых!!! конфликтов за счет утяжеления описания данных, семантичнеский анализ поступающих запросов и т.д. А алгоритмы-то есть какие-нибудь на эту тему? А то мечтать-то можно... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 20:11 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymousИ с чего ты взял, что "настоящий serializable" --- это отсутствие вышеперечисленного? По определению: нет параллельных транзакций - порядок записи не важен, нет не то что взаимоблокировок на записях, вообще никаких других блокировок нет, уже изменённую запись никто не пытается изменять заново. PgSQLAnonymousТем более, после того, как тебе здесь неоднократно указали, что это не так? Здесь неоднократно показали, что та хрень, которая гордо называется "serializable" в PG и Оракуле - никакого отношения к serializable не имеет. Ничего более. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 20:19 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
sanyock2в смысле это было образно про то, что с помощью оперативки получится смасштабировать любое количество сессий большого динозавра? Да, где-то как-то так. ;) sanyock2и под "iops" подразумевалось TPS вместо iops? чето я запутался, вообще конечно тяжелая ветка в целом для моего понимания, может быть из-за отсутствия опыта программирования высоконагруженных БД Если для выполнения запроса клиента СУБД нужно прочитать 100000 страниц, и в одном случае на это уходит 2 сек, а в другом 1, то похоже на то, что во втором случае IOPS вдвое больше (что может быть просто эффектом кэширования). ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 20:20 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovПо определению: нет параллельных транзакций - порядок записи не важен, нет не то что взаимоблокировок на записях, вообще никаких других блокировок нет, уже изменённую запись никто не пытается изменять заново. Нет, ты замучал уже. Советую перечитывать эту тему, стандарт SQL, документацию настоящих СУБД (мурзилку, наконец) пока до тебя не дойдёт, что такое ACID, ISOLATION, serializability и SERIALIZABLE. Dimitry SibiryakovЗдесь неоднократно показали, что та хрень, которая гордо называется "serializable" в PG и Оракуле Не надо Oracle и PostgreSQL мешать в одну кучу в этом вопросе. Dimitry Sibiryakov - никакого отношения к serializable не имеет. Ничего более. Да, да, чёрное — это белое. Война — это мир. Свобода — это рабство. Незнание — сила. Ложь — это правда. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 20:31 |
|
Чем плох блокировочник по сравнению с версионником?
|
|||
---|---|---|---|
#18+
PgSQLAnonymousСоветую перечитывать эту тему, стандарт SQL, документацию настоящих СУБД (мурзилку, наконец) пока до тебя не дойдёт, что такое ACID, ISOLATION, serializability и SERIALIZABLE. А какое слово из "если бы транзакции выполнялись последовательно, одна за другой" не понимаешь ты? Если транзакции на самом деле выполняются строго последовательно, одна за другой - это и есть истинный TIL serializable. Потому что (сурпрайз!) транзакции при нём действительно сериализованы. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2015, 20:47 |
|
|
start [/forum/topic.php?fid=35&msg=38960267&tid=1552327]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
40ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 166ms |
0 / 0 |