Вт, 19.03.2024, 10:26
Приветствую Вас Гость | RSS
Главная | Каталог статей | Регистрация | Вход
Форма входа
Логин:
Пароль:
Поиск

Меню сайта

Категории раздела
От AKost [29]
От других авторов [6]

Наш опрос
О регистрации на сайте с помощью соцсетей.
Всего ответов: 24

Метки
EGL ODM бизнес правила программирование SOA arcati блоги журналы Каталог мейнфреймы журнал z/os Freeware VM bigdata nosql zOS MVS OS SLES zLinux мейнфрейм Хабрахабр 50лет документы хранилище Java EE liberty WebSphere z/VM Share history GitHub OS/VS S/379 сообщение Форум DFSORT Hercules VSAM отчётность Linux Analytics Accelerator Netezza IMS IBM IDC продажа CHKPT GSam XRST гипервизор KVM Shutdown #hollywar mainframe Вакансии Санкт-Петербург видео Выступления Dis нагрузка пример Assembler VM/ESA НИЦЭВТ Docker Sie Kubernetes OpenShift Environment RedBook RedHat рынок LHI vs XR instruction to clear GPR z Seies CPU performance семинар впечатление доступность ЦБ цены аутсорсинг BMC CMS ZVM санкции Rockwell история z13 мобильность DB2 Java Coupling Facility Parallel Sysplex WebSphere AS MVT ОС ЕС ссср Tape VTL Вакансия БЛОГ Линукс Новое статьи Люксофт Польша Работа Москва

Статистика

Главная » Статьи » Мысли по поводу » От других авторов


Сравнение IMS DB и DB2

Вот натолкнулся на просторах интернета

http://www.slideshare.net/geery/db2-vs-db1part1shortlink-34863741

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

В дополнение - еще одна статья про высоконагруженную конфигурацию на основе IMS.

Категория: От других авторов | Добавил: ggv (19.05.2014)
Просмотров: 5249 | Комментарии: 34


Всего комментариев: 341 2 »
1 Gregory  
Судя по названию, должна быть вторая (третья...) часть, так что IMHO имеет смысл прочитать текст полностью.
Если же рассматривать только эту часть, то у меня она вызвала, мягко говоря, неоднозначную реакцию - при рассмотрении под таким углом прямой транзакционный VSAM будет выглядеть гораздо привлекательнее и DB2, и IMS, а BDAM так и вообще будет вне конкуренции)

2 ggv  
в принципе, верно, потому во второй части будет про языки доступа к данным. Можно, кстати, и VSAM добавить, и посмотреть, зачем вообще нужна СУБД, может и без неё можно. Что такого даёт СУБД удобного, чего нету при использовании VSAM.

3 akost  
это ты насчет VSAM и использования СУБД может и перегибаешь палку. те, кто знают, что такое VSAM, и так знают, чем он хорош и чем плох. а те, кто не знают, все равно не поймут - для них СУБД это одно, а метод доступа - вообще другое, почти разные Вселенные.
однако пиши, я отслеживаю.

4 ggv  
Ну для начала надо таки уточнить, что Gregory писал про transactional VSAM, и это делает некоторую разницу.
Но вот в чём ты прав - разницу делает для тех, кто понимает.
А теперь по поводу твоего опасения.
Поскольку я не вы, и не родился в мейнфрейме, а прошёл долгий путь, начиная от freebsd 2.2.1, и много чего пользовал,
то имею дурацкую привычку сравнивать.
Вот и для VSAM у меня есть сравнение.
И речь небыло за "хорош" или "плох".
Так нельзя.
В одном случае он будет очень хорош, а в другом очень плох - это влияют нефункциональные требования больше всего.
И расстановка приоритетов в требованиях.
Я просто хотел сказать, что индустрия не удовлетворилась VSAM-ом единым, а почему-то появились IMS, ADABAS, IDMC, и так далее, вплоть до DB2 (прости оссссспади smile )
А значит, раз сделали эту надстройку - СУБД - то наверное, был смысл. Что-то это даёт полезного.
И вот про это можно поговорить.
В первой части статьи автор явно пытался сравнивать у обоих СУБД примерно одинаковые по функицоналу, по назначению, вещи.
При использовании transactional VSAM, отдельно ли (что вряд ли), или с монитором транзакций (что вероятнее, и скорее всего CICS), многих этих вещей не будет out of box, придётся делать их самим. Этим и отличаются СУБД от того, что было до-СУБД.
Ещё раз - это не хорошо, и не плохо, это имеет свои особенности и области применения, и всё.
Вопрос правильный, важный, и почему бы кратенько не рассмотреть связочку "монитор транзакций плюс transactional VSAM"
Не вижу препятствий.
Ну, важный вопрос кому... Тому, кому интересно smile
Мы же just for fun smile
А не из под палки smile
Я правильно поясняю?

5 Gregory  
IMHO при сравнении имело бы смысл начать с обсуждения представления данных предметной области в рассматриваемых моделях управления данными, а затем уже рассматривать возможности управления данными каждой модели...

6 akost  
Ща мы потихоньку раскатаем Гришу Власова на полноценную монографию)))

7 ggv  
Не, мне эта тема не нравится
Предметная область заявлена там.
Смоделировать данные можно по-разному.
И для
- VSAM
- IMS
- DB2
модели будут разные
Какая модель подходит лучше?
А по каким параметрам будем сравнивать?
А какие критерии оценки параметров будем применять?
Так что это направление ушло в отдельный документ

Методика выбора программно-аппаратной
платформы для финансово-учётных систем


Аннотация
Данный материал посвящен обсуждению проблемы выбора
программно-аппаратной платформы для транзакционных систем,
обеспечивающих перевод денежных средств между пользователя-
ми. К ним относятся финансово-учётные системы предприятия,
платежные системы международных и национальных масштабов,
биллинговые системы. Рассмотрены основные критерии выбора и
подход к их оценке: эффективность, сопровождаемость, достовер-
ность и своевременность возвращаемой информации. В статье да-
ется объяснение технологических причин, по которым платформы,
которые частно относят к разряду унаследованных, продолжают
эксплуатироваться по сей день.

Вот там и будет немного про модели данных.
А вот вам заключение ИПИ РАН - для платёжных систем применение реляционных баз не только не нужно, но и вредно.
Это я по памяти своими словами.

8 ggv  
И вообще, я бы не рассматривал модели данных отдельно, сами по себе.
Бесполезно это.
Вне отрыва от конкретных задач - бесполезно.
Есть конкретная система, биллинг, приём массы поступающих событий, расчёт, и списывание денег со счета ну или выдачи ответа в аппаратуру о параметрах допустимой сессии.
Или - платёжная система, перевод средств между участниками.
Предполагаемый срок эксплуатации - лет 30. Лучше больше smile

И не важно, какая модель.
Важны качества получаемой системы.
Какие качества?
Вот и предлагается взять
- Достоверность и своевременность финансовой информации
- Сопровождаемость и эффективность самой системы.

Будут пожелания по рассматриваемым параметрам (качествам) - хорошо.

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

10 ggv  
OLTP и данные за несколько недель?
Честное слово - первый раз такое встречаю.
Вопрос объёма данных - не проблема для ОЛТП системы.
Даже если эти данные определить как ненужные - они не мешают работе системы.
Если она не на реляционке smile
Если мы предполагаем хранение года данных для тысячи участников платежей, то это и будет ключевыми параметрами для физического дизайна системы - по одной "записи" (в терминах IMS) на каждый опер день на участника. Обращение к одной любой записи константно по времени. Не вижу препятствий. Так же время константно будет для обработки массива "записей" за месяц, квартал, полугодие, год - количество "записей" за каждый промежуток времени константно, как и время обращения к ним.
Ну и, собственно, сама OLAP возникла немножко так по-позже электронных платёжных систем, на сколько, на два десятилетия? Или на полтора?
В принципе, для анализа данных не нужен OLAP, но OLAP может сократить время анализа.
Прямой зависимости типа "платёжная система не может существовать без аналитики" нету.
Это и вы подтверждаете фразой
Цитата
Любые выявленные факты такого рода могут оказать на платежную систему самое существенное влияние.
Могут оказать, а могут и не оказать.
Можно иметь аналитику, а можно и не иметь.
Да, без ОЛАП анализ данных потребует уже отдела статистики из ряда сотрудников, пожалуй.
Но платёжной системе немного фиолетово - она сможет продолжить свою работу и выполнять свои функции безотносительно аналитики.
А если это монопольная, навязанная платёжная система.... То вообще по-барабану smile

11 Gregory  
Пы. Сы. Хотелосбь бы заметить, что между "историческими данными" и данными для OLAP есть большая разница. Исторические данные сырые, и попытки их переваривать вызовут несварение как у средств обработки данных, так и у потребителя)

12 ggv  
Ок, тогда платёжная система Банка России - похожа на деревенский базар smile
Несколько недель - это мало.
Тысяча участников платежей - это пример, подставляйте другую переменную.
Роли особой не играет.
Наличие или отсутсвие прибыли не имеет прямой связи с внедрением OLAP.
Кроме того, что финансовая организация не благотворительная, но учредители платёжной системы могут не стмавить целью извлечение прибыли, а стоимость услуг всего лишь для покрытия затрат, справедливо как для Банка России, так и для Европеского ЦБ.
Что не отменяет факта наличия коммерческих платёжных систем.
Доказывает отсутсвие прямой  и жёсткой связи между наличием платёжной системы и наличием OLAP.
Ну нету такой связи

13 ggv  
Пусть будет пример 100000 участников на один год (365 операционных дней).
Могу грубо подсчитать количество дисковых данных.
Не так уж и много будет, поверьте.

14 Gregory  
почему Вы отталкиваетесь от числа участников, а не от количества платежных документов? участник участнику рознь, участником может быть и бабушка, раз в месяц снимающая пенсию с карточки, и промышленное или торговое предприятие.

Цитата
Наличие или отсутсвие прибыли не имеет прямой связи с внедрением OLAP.  ... Доказывает отсутсвие прямой  и жёсткой связи между наличием платёжной системы и наличием OLAP. Ну нету такой связи
а наличие OLTP системы и степень ее навороченности имеет "прямую и жесткую связь" с наличием или отсутствием прибыли? biggrin

15 ggv  
Не я отталкиваюсь.
Просто платёжные системы очень разные, под разные условия и разного назначения - межбанковские, или розничные.
Я просто хочу донести простую мысль - нет никакой жёсткой необходимости иметь ОЛАП для функционирования платёжной системы.

Цитата
а наличие OLTP системы и степень ее навороченности имеет "прямую и жесткую связь" с наличием или отсутствием прибыли?
Нет, связь скорее косвенная, чем прямая, и очень сильно будет зависеть от того, что именно за платёжная система.
Но степень навороченности безусловно будет иметь жёсткую связь с нефункциональными требованиями, с качественными характеристиками платёжной системы.
Навороченность OLTP может способствовать получению прибыли от платёжной системы.
За счёт снижения издержек разного рода - на лицензионные отчисления, на сопровождение системы,
за счёт предоставления более качественного (нефункциональные характеристики) сервиса, что сделает систему более конкурентно-способной и подтолкнёт пользователя её выбрать (если выбор вообще возможен).
Вполне возможно, что начиная проект Union Pay китайское правительство во главу угла ставило вовсе не прибыль. А например, независимость, диверсификацию, и лучшие условия для переговоров с Visa и MasterCard.
А европейские банки создавая платёжную систему ЕЦБ и вовсе ориентировались не на прибыль.
Перейдём к России?
Нам что более актуально, срубить бабла по-быстрому получить прибыль, или получить безопасность, независимость, устойчивость финансовой системы и хорошие условия для переговоров с международными системами?
В этом вопросе может быть множество аспектов.
Но всё это не имеет отношение к ОЛАП.
Есть экономисты.
Есть дисциплина АХД (Анализ Хозяйственной Деятельности).
Есть перечень входных документов для АХД.
Для этого вовсе не обязательно иметь ОЛАП.
Полезно - да.
Обязательно - сомневаюсь.

16 drblez  
про "онолитегу".

Тут с какой стороны подходить.

По количеству гемора -- 90% от сложности системы.

По количеству персонала -- базовый состав (только аналитика) + оперативный состав (процентов 20-25% заданий можно отнести к сфере аналитики). всего 38% персонала занимаются поддержкой разного рода "не основных" данных.

Под "основными" подразумеваю то, что относится непосредственно к ОЛТП части.

Все делается на инструментарии, который предоставляет СУБД + часть данных выгружается в 1С и часть обработки происходит там.

По размеру данных -- практически 100% от всех хранящихся данных

Может если есть какие-то конкретные вопросы -- могу ответить ))

1-15 16-25
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]

Яндекс.Метрика