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

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

эттаPgSQLAnonymous,

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

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



Ну это всё как-то слишком общо... Не видно, как достигается цель: не допустить ухода в минус счёта брокера.

sanyock2PgSQLAnonymousИ, кстати, знай добавляй RAM и "будет расти iops-ы". ;)
это как? можно поподробнее?
Вы бы контекста-то побольше оставляли: ;)

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

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

Если не хватает RAM для блокировок, они обычно эскалируются (например, блокировки записей превращаются в блокировки страниц или таблиц), поэтому производительность может страдать. Добавление RAM может предотвратить это, только и всего (основное влияние на производительность происходит за счёт кэширования, конечно).

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

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

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

Dimitry SibiryakovPgSQLAnonymousА какая-то СУБД гарантирует, что для любой транзакции не будет ни
DEADLOCK-ов, ни UPDATE CONFLICT-ов, ни откатов по каким-то другим причинам?
Да любая, у которой есть "настоящий serializable". Ты же сам говорил, что знаешь одну такую.

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

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

Поживём-увидим. ;)

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

sanyock2в смысле это было образно про то, что с помощью оперативки получится смасштабировать любое количество сессий большого динозавра?
Да, где-то как-то так. ;)

sanyock2и под "iops" подразумевалось TPS вместо iops? чето я запутался, вообще конечно тяжелая ветка в целом для моего понимания, может быть из-за отсутствия опыта программирования высоконагруженных БД
Если для выполнения запроса клиента СУБД нужно прочитать 100000 страниц,
и в одном случае на это уходит 2 сек, а в другом 1, то похоже на то,
что во втором случае IOPS вдвое больше (что может быть просто эффектом кэширования). ;)

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

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

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

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

Да, да, чёрное — это белое. Война — это мир. Свобода — это рабство. Незнание — сила. Ложь — это правда.