Voland_de_mortСтала задача миграции c postgress на один из 2 вариантов
MS SQL или IBM DB2

Если проблемы при переходе с PG на MS могу оценить, то с оценкой перехода на IBM тяжеловато.
Прошу помощи и подсказки в оценки сложности/не совеместимости диалектов, типов данных..
db2 при такой постановки сильно проигрывает, там нет версионного механизма вообще. на мсскл и его snapshot isolation level портировать PG будет гораздо проще. диалекты и типы фигня, под db2 вам полностью концепцию менять придется.
а чем Pg не устроил, что мигрировать задумали ? почему такие странные кандидаты на миграцию ?

Voland_de_mortа в чем концепт менять прийдется? Где подводные камни будут?
в том что нельзя портировать в лоб. почитайте что такое версионный механизм, чем отличается от блокировочного. вкратце у Pg версионный механизм, там select читает согласованные данные на момент старта запроса не накладывая блокировок, db2 дефолтный режим читает несогласованную кашу накладывая блокиовки. т.е. если вы начнете портировать с Pg в лоб получите кашу вместо результата и тьму дедлоков. а если у вас еще длинные читающие запросы есть (репорты например) так и вовсе без перепроектирвания таблиц не обойтись.

Mark BarinsteinВ db2 9.7 вы не получите локов и дедлоков больше, чем у вас их уже есть.

глупости. в 9.7 просто введено чуть больше разновидностей "грязного" чтения (формально удолетворяет ansi RC, но по сути грязное). меньше локов -> больше сюрпризов, не известно что еще лучше.

Mark BarinsteinRead consistency важна только для тех алгоритмов, где это действительно нужно, для алгоритмов, которые написаны именно с учётом такого поведения сервера.
А это, мягко говоря, не для каждого алгоритма нужно.
Вот скажите, Yo!, вы что, телепат, чтобы говорить такие вещи про систему, о которой вы вообще ничего не знаете?
система спроектирована под версионник и ТС никогда не сталкивался с блокировочными механизмами. тут не нужно быть телепатом, что бы гарантировать, что на блокировочнике версионная концепция огребет по полной. Read consistency просто один из моментов. а еще есть блокировки при чтении, эскалация и многое другое.
если в его системе длинный отчет читает данные во время OLTP нагрузки так и вовсе пол системы придется перепроектировать заново.

Mark Barinstein"грязное" чтение есть возможность увидеть незакомиченные чтения других приложений.
Если у вас есть своё понятие "грязного" чтения, не смешивайте его с ansi уровнями.

раз у вас такое трепетное отношение к терминам ansi я буду называть его "грязное+", годиться ?

Mark BarinsteinПо какой же такой вашей сути оно "грязное"?
у CS без last committed феномен lost update приключался иногда, CS c last committed (дефолтный с 9.7) феномен lost update просто гарантирует. поэтому я позиционирую этот IL как "грязное+", он слабей обычного CS.

Mark BarinsteinВсе эти проблемы с эскалацией рашаются увеличением locklist.
По-умолчанию запросы работают на уровне CS, в том числе и "длинные отчёты".
Т.е. блокируется только текущая строка, на которой курсор стоит.
Читетели и писатели не блокируют друг друга.
Что надо перепроектировать?

если не устраивает каша которую выдает CS, а на длинном отчете практически наверняка каша не устроит, придется повышать уровень изолированности, который упрется в блокировки. без перепроектирования проблема не решается. примитивный пример чуть ниже.

Ggg_oldYo любит потроллить на эту тему, только правда вся в том что при исполнении OLTP-операций все системы ведут себя как блокировочник.
А снэпшот вещь конечно-же полезная, но для отчетов а не операций.
ну давай разберемся где правда. примитивный пример есть таблица accounts с полями id, acc_number, balance, вторая движение payments (id, acc_id, amount). т.е. ели с одного счета на другой перебрасывается сумма 20, то в одной транзакции с одного счета -20, на другой счет +20 и обновление балансов обоих счетов. покажи на блокировочнике как получить сумму средств на всех счетах не прерывая поток пишущих транзакций ?

SergSuperGgg_old же написал - да, для отчетов полезно
ну где еще сумма всех счетов нужна?
оно полезно везде где читатели сталкиваются с писателями и каша выдаваемая на уровне RC не канает. где нужна - смотри TPC-E

Alexander RyndinНе спора ради, а для общего развития - как в отсутствии read consistency можно сделать, например, экспорт таблички?
наложив шаред лок, стопорнув всех писателей ...

2Ggg_old

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

Ggg_old,

это прекрасно что вам не лень настукивать банальности, но среди этих много букафф я так и не понял, вы по прежнему уверены что "при исполнении OLTP-операций все системы ведут себя как блокировочник" ? мой пример не заставил задуматься о том, что версионник может строить oltp транзакции без всяких "банковских дней" ?

interesting,

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

по примеру кредитной линии - ну да, конкретно в этом случае подход оптимистический подход не применить. тут пессимистический подход версионника мало чем будет отличаться от блокировочника. да, наверно еще много можно придумать задач где подходы будут схожи, но это не отменяет тьму OLTP задач где блокировочник не сможет эффективно эмулировать подход версионника.