Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 IBM DB2 vs MS SQL  [new]
Voland_de_mort
Member

Откуда:
Сообщений: 125
Стала задача миграции c postgress на один из 2 вариантов
MS SQL или IBM DB2

Если проблемы при переходе с PG на MS могу оценить, то с оценкой перехода на IBM тяжеловато.
Прошу помощи и подсказки в оценки сложности/не совеместимости диалектов, типов данных..
22 фев 11, 12:41    [10272951]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Dimitry Sibiryakov
Member

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

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

Поскольку попил бабла - нетехническая задача, то оптимальный выбор обычно делается с
помощью ГСЧ (ака "монетка").

Posted via ActualForum NNTP Server 1.4

22 фев 11, 13:16    [10273255]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Росгоснанораспилтрест
Member [заблокирован]

Откуда: Главпилорама
Сообщений: 2421
А за что больше отката дают?
22 фев 11, 13:18    [10273265]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Yo.!
Guest
Voland_de_mort
Стала задача миграции c postgress на один из 2 вариантов
MS SQL или IBM DB2

Если проблемы при переходе с PG на MS могу оценить, то с оценкой перехода на IBM тяжеловато.
Прошу помощи и подсказки в оценки сложности/не совеместимости диалектов, типов данных..

db2 при такой постановки сильно проигрывает, там нет версионного механизма вообще. на мсскл и его snapshot isolation level портировать PG будет гораздо проще. диалекты и типы фигня, под db2 вам полностью концепцию менять придется.
а чем Pg не устроил, что мигрировать задумали ? почему такие странные кандидаты на миграцию ?
22 фев 11, 13:48    [10273536]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Voland_de_mort
Member

Откуда:
Сообщений: 125
кандидаты связаны с тем, какие сервера стоят на стороне заказчика. Новое ПО ставить не будут.
22 фев 11, 13:51    [10273558]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Voland_de_mort
Member

Откуда:
Сообщений: 125
Yo.!
db2 при такой постановки сильно проигрывает, там нет версионного механизма вообще. на мсскл и его snapshot isolation level портировать PG будет гораздо проще. диалекты и типы фигня, под db2 вам полностью концепцию менять придется.


а в чем концепт менять прийдется? Где подводные камни будут?

Сообщение было отредактировано: 22 фев 11, 14:24
22 фев 11, 13:52    [10273570]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Dimitry Sibiryakov
Member

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

Voland_de_mort
кандидаты связаны с тем, какие сервера стоят на стороне заказчика. Новое ПО ставить не будут.

Что, у заказчика вот так одновременно стоят два недешёвых SQL сервера?..

Posted via ActualForum NNTP Server 1.4

22 фев 11, 13:57    [10273634]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Yo.!
Guest
Voland_de_mort
а в чем концепт менять прийдется? Где подводные камни будут?

в том что нельзя портировать в лоб. почитайте что такое версионный механизм, чем отличается от блокировочного. вкратце у Pg версионный механизм, там select читает согласованные данные на момент старта запроса не накладывая блокировок, db2 дефолтный режим читает несогласованную кашу накладывая блокиовки. т.е. если вы начнете портировать с Pg в лоб получите кашу вместо результата и тьму дедлоков. а если у вас еще длинные читающие запросы есть (репорты например) так и вовсе без перепроектирвания таблиц не обойтись.
22 фев 11, 14:18    [10273864]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Voland_de_mort
Member

Откуда:
Сообщений: 125
Yo.!
Voland_de_mort
а в чем концепт менять прийдется? Где подводные камни будут?

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


ок, я понял. Надеялся, что не все так печально с ISOLATION LEVEL в DB2
по мимо блокировок и связанных с ними проблем, что еще может доставить неприятности?
22 фев 11, 14:57    [10274204]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Voland_de_mort
Member

Откуда:
Сообщений: 125
Росгоснанораспилтрест
А за что больше отката дают?

отката не дают) и деньгу не делим..
22 фев 11, 14:58    [10274211]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5030
Yo.!
Voland_de_mort
а в чем концепт менять прийдется? Где подводные камни будут?

в том что нельзя портировать в лоб. почитайте что такое версионный механизм, чем отличается от блокировочного. вкратце у Pg версионный механизм, там select читает согласованные данные на момент старта запроса не накладывая блокировок, db2 дефолтный режим читает несогласованную кашу накладывая блокиовки. т.е. если вы начнете портировать с Pg в лоб получите кашу вместо результата и тьму дедлоков. а если у вас еще длинные читающие запросы есть (репорты например) так и вовсе без перепроектирвания таблиц не обойтись.
В db2 9.7 вы не получите локов и дедлоков больше, чем у вас их уже есть.
Read consistency важна только для тех алгоритмов, где это действительно нужно, для алгоритмов, которые написаны именно с учётом такого поведения сервера.
А это, мягко говоря, не для каждого алгоритма нужно.
Вот скажите, Yo!, вы что, телепат, чтобы говорить такие вещи про систему, о которой вы вообще ничего не знаете?
22 фев 11, 15:29    [10274434]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
Mark Barinstein
Read consistency важна только для тех алгоритмов, где это действительно нужно, для алгоритмов, которые написаны именно с учётом такого поведения сервера.
Read consistency важна для большинства операций в приложении занимающемся финансовым/бухгалтерским (насчет остальных врать не буду) учетом. Это не является проблемой для блокировочника, так как разработчики уже соответствующим образом ориентированы и привыкли это предусматривать.
Разработчики, использующие версионники, обычно вообще не задумываются над согласованным чтением, так как версионник автоматически обеспечивает такое поведение. То есть там все операции уже "написаны именно с учётом такого поведения сервера". При переходе на блокировочник, в котором по умолчанию read consistency отсутствует, такая система гарантиировано огребет кучу проблем - потребуется либо внимательнейшим образом анализировать все операции на предмет возможности отказа от согласованного чтения, либо тупо повысить уровень изоляции, увеличив соответствующим образом и количество блокировок.
22 фев 11, 15:49    [10274590]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Yo.!
Guest
Mark Barinstein
В db2 9.7 вы не получите локов и дедлоков больше, чем у вас их уже есть.

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

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

система спроектирована под версионник и ТС никогда не сталкивался с блокировочными механизмами. тут не нужно быть телепатом, что бы гарантировать, что на блокировочнике версионная концепция огребет по полной. Read consistency просто один из моментов. а еще есть блокировки при чтении, эскалация и многое другое.
если в его системе длинный отчет читает данные во время OLTP нагрузки так и вовсе пол системы придется перепроектировать заново.
22 фев 11, 18:02    [10275505]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5030
Yo.!
Mark Barinstein
В db2 9.7 вы не получите локов и дедлоков больше, чем у вас их уже есть.

глупости. в 9.7 просто введено чуть больше разновидностей "грязного" чтения (формально удолетворяет ansi RC, но по сути грязное). меньше локов -> больше сюрпризов, не известно что еще лучше.
Где именно в моём утверждении вы нашли глупость?
"грязное" чтение есть возможность увидеть незакомиченные чтения других приложений.
Если у вас есть своё понятие "грязного" чтения, не смешивайте его с ansi уровнями.
По какой же такой вашей сути оно "грязное"?
Yo.!
система спроектирована под версионник и ТС никогда не сталкивался с блокировочными механизмами. тут не нужно быть телепатом, что бы гарантировать, что на блокировочнике версионная концепция огребет по полной. Read consistency просто один из моментов. а еще есть блокировки при чтении, эскалация и многое другое.
если в его системе длинный отчет читает данные во время OLTP нагрузки так и вовсе пол системы придется перепроектировать заново.
Все эти проблемы с эскалацией рашаются увеличением locklist.
По-умолчанию запросы работают на уровне CS, в том числе и "длинные отчёты".
Т.е. блокируется только текущая строка, на которой курсор стоит.
Читетели и писатели не блокируют друг друга.
Что надо перепроектировать?

2 ТС:
При переносе системы надо проанализировать все алгоритмы в приложении, которые могут начать неправильно работать из-за отсутствия read consistency, если такие алгоритмы вообще есть.
Отсальные возможные проблемы не так значительны.

2 Yo.!:
Большая просьба - не пишите, пожалуйста, о том, чего не знаете.
А именно о том, как там в DB2 всё работает.
Просто вы либо намеренно, либо нет, но постоянно вводите людей в заблуждение...
22 фев 11, 18:42    [10275723]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Yo любит потроллить на эту тему, только правда вся в том что при исполнении OLTP-операций все системы ведут себя как блокировочник.
А снэпшот вещь конечно-же полезная, но для отчетов а не операций.
22 фев 11, 19:44    [10275941]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Yo.!
Guest
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_old
Yo любит потроллить на эту тему, только правда вся в том что при исполнении OLTP-операций все системы ведут себя как блокировочник.
А снэпшот вещь конечно-же полезная, но для отчетов а не операций.

ну давай разберемся где правда. примитивный пример есть таблица accounts с полями id, acc_number, balance, вторая движение payments (id, acc_id, amount). т.е. ели с одного счета на другой перебрасывается сумма 20, то в одной транзакции с одного счета -20, на другой счет +20 и обновление балансов обоих счетов. покажи на блокировочнике как получить сумму средств на всех счетах не прерывая поток пишущих транзакций ?
23 фев 11, 02:22    [10277121]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Yo.!
ну давай разберемся где правда. примитивный пример есть таблица accounts с полями id, acc_number, balance, вторая движение payments (id, acc_id, amount). т.е. ели с одного счета на другой перебрасывается сумма 20, то в одной транзакции с одного счета -20, на другой счет +20 и обновление балансов обоих счетов. покажи на блокировочнике как получить сумму средств на всех счетах не прерывая поток пишущих транзакций ?
Ggg_old же написал - да, для отчетов полезно
ну где еще сумма всех счетов нужна?
23 фев 11, 02:29    [10277130]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Yo.!
Guest
SergSuper
Ggg_old же написал - да, для отчетов полезно
ну где еще сумма всех счетов нужна?

оно полезно везде где читатели сталкиваются с писателями и каша выдаваемая на уровне RC не канает. где нужна - смотри TPC-E
23 фев 11, 02:52    [10277142]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Не спора ради, а для общего развития - как в отсутствии read consistency можно сделать, например, экспорт таблички?
23 фев 11, 04:37    [10277174]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Yo, там не каша, если голову приложить.
У меня будет табличка проводок с указанием времени проводки. И когда я захочу получить состояние системы на момент времени N какой угодно с момента старта системы, то логическая структура должна мне это позволить. Соответсвенно при старте отчета фиксируется время его запуска, потом селектятся все операции до этого момента времени. Т.К. эти записи операций не изменны (должны быть неизменны если все сделано правильно) и они не будут конкурировать с OLTP транзакциями то оно пройдет без прямой конкурнеции с горячими транзакциями, которые сам уже будут драться между собой. Я не хочу вдаваться в глуби, но так работала банковская система на моей предыдущей работе.
Но иметь снэпшот или ласткомиттед очень конечно полезно, но не критично.
По крайней мере многие биг системы в мире написаны и работают еще на мэйнфреймах в 70х и 80х годах и обслуживают абонентов по всему миру. А там не то что снэпшота, а и просто реляционка то не везде стоит.
23 фев 11, 08:45    [10277256]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Но многие системы так не написаны и приходится видать спасаться снэпшотом. Эт да, не поспоришь.
23 фев 11, 08:48    [10277259]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Yo.!
Guest
Alexander Ryndin
Не спора ради, а для общего развития - как в отсутствии read consistency можно сделать, например, экспорт таблички?

наложив шаред лок, стопорнув всех писателей ...

2Ggg_old

как выкручиваются у блокировочников я прекрасно знаю. я дал простой пример патерна достаточно часто встречающегося в версионниках. давай, покажи на это примере как ты без тотального редизайна ты собрался перенести на блокировочник. каждый раз вычислять баланс прочесывая таблицу payments уже на первом миллионе система захлебнется.
23 фев 11, 11:10    [10277611]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Yo.!
Alexander Ryndin
Не спора ради, а для общего развития - как в отсутствии read consistency можно сделать, например, экспорт таблички?

наложив шаред лок, стопорнув всех писателей ...
Хотелось бы услышать не от вас Yo.!
23 фев 11, 11:27    [10277669]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Voland_de_mort
Member

Откуда:
Сообщений: 125
DB2 поддерживает какие-то дополнительные расширения?
Такие как С# в MS SQL, pl/perl, pl/java в Postgree?
23 фев 11, 11:32    [10277689]     Ответить | Цитировать Сообщить модератору
 Re: IBM DB2 vs MS SQL  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
Yo, то не выкручивание ради блокировочника, а требование к системе иметь возможность получить ее состояние на любой момент времени, хоть на год назад. Когда так делается система, то и архитекура получается такой что дает возможность нормально работать и на блокировочнике и еще лучше если есть ласткоммитед/снэпшот. И согласителсь, что снэпшот к решению это задачи не имеет отношения, это вопрос архитектуры хранения данных.
Я просто не работал в бизнесе, а только в банках, и у нас есть понятие банковского дня, на конец которого все подсчитывается и закрывается и больше проводок туда задним числом не делается (это в идеале конечно). Посему подсчет текущего остатка на счете происходит как взять остаток на начало дня и накатить пяток другой операций за текущий день до момента начала операции. Посему и отчеты, которым не критично получить горячий остаток на счете в такой схеме в такой схеме работают нормально, во всяком случае фактор того что отчет грузит ввод-вывод и вымывает кэш уже становятся важными, ну и ресурсы на шаред локи тоже расходуются.
А если отчеты строятся по горячим записям и конкуренция как по локам так и по вводу/выводу становится такой, что система впадает в ступор, то как по мне правильно сделать второй отчетный сервер, по своместительсву резервный и пусть он колбасит отчеты.
Но я с вами конечно соглашаюсь, что наличие дополнительной возможности как снэпшот может решить задачу расчистки авгиевых конюшен в каждом конкретном случае без перепроектирования, покупки доп.серверов и другого гемора.
23 фев 11, 12:29    [10277941]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить