Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
возвращаясь к теме, на чём в мире делают процессинговые системы.
в основном на двух платформах,
HP Nonstop
IBM Z
и что интересно, в обоих случаях не всегда (если не сказать всегда не) на реляционках.
в случае IBM это z/TPF и/или IMS, в случае HP это Enscribe.
В основном потому, что контракт на обслуживание скурпулёзно определяет очень много параметров всяких, не только время отклика, допустимые отклонения от этого времени в обе стороны, процент случаев с такими отклонениями, и ты ды и ты пы, и устанавливаются меры ответственности за несоблюдения контракта.
31 мар 13, 10:02    [14118039]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
geereye
в основном на двух платформах,
"В основном" это сколько? 5%, 20%, 90% ? Может быть источниками поделитесь?
31 мар 13, 10:16    [14118049]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
не, не поделюсь, да и вообще спорить не собираюсь :)
это надо конкретно по каждой системе смотреть, не все они афишируют, на чём сделано, исключение Visa Inc
но в принципе найти можно, но чтобы вот так вот готовый анализ - что-то и не припомню.
можете сделать вывод, что я ляпнул фигню и вообще не в теме, мне пофиг :)
31 мар 13, 10:56    [14118104]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
geereye,

Ну зачем же сразу обижаться. Просто любое обобщающее утверждение требует обладания некоторой статистикой. Если у вас ее нет (хотя бы из личных наблюдений), то обобщающими утверждениями раскидываться не стоит. Я статистики по процессинговым системам не имею. Сам сталкивался с тремя системами для карточного процессинга (Way4, Compass, Rusoft) и все они Oracle использовали.
31 мар 13, 19:46    [14119024]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
да какие обиды, что вы :)
просто я форум sql.ru хорошо знаю :)
убедить кого-либо в чём либо я себе задачу не ставлю - это невозможно, базовики самые упёртые в мире люди :)
если человек технарь, с инженерной жилкой - то ему идею только дать, и дальше он сам нароет, и выводы сделает.
не все йогурты процессинги одинаковы.
русскоязычная тусовка оперирует одними понятиями.
а, к примеру, японская тусовка очень закрыта.
очень.
а там какой-нить японский банчик по всем финансовым показателям кроет все финансы гордой страны Россия как бык овцу. и вы им никогда не докажете, что ява, оракл, дельфи, что угодно - это круто, это по передовому, это по-настоящему.
или другой пример, более 800 европейских банков аутсорсят услуги платёжной системы в одной германской конторке, в облаке, так сказать. количество финасовых транзакций просто запредельно, как и количество счетов, и всего прочего. а обслуживают всё это хозяйство 12 человек. если вы захотите им пояснить суть извечных споров sql.ru, то они понять не смогут, о чём тут спорить то :)
и вообще - заказчики, клиенты, да и технари - все заинтересованы, чтобы было как можно больше конкурирующих технологий.
а то буржуи зажрутся.
так что кому интересно - и про нон-стоп, и про IMC или z/TPF можно почитать, и прикинуть, как же это добро можно использовать с пользой для дела, в чём плюсы, в чём минусы, где пределы применимости, и всё такое прочее. и вообще, как там говорили про изучение иностранных языков - помогает глубже понять свой родной. также и с изучением конкурирующих технологий - помогает лучше понять свои :)
31 мар 13, 21:22    [14119209]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
2geereye
А можно поподробнее про "800 банков аутсорсят ИТ-услуги".
Крайне интересная инфа, я то думал, что ихние банки так-же как и наши сидят на своих серверах как наседка на яйцах :).
1 апр 13, 12:01    [14120770]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Гирай
Guest
так я и говорю - у нас своя тусовка, у них своя, перетекание информации крайне затруднено, в определённых областях.
про то, как пивной ларёк автоматизировали, каждый может узнать. Ну, там, сбербанк, к примеру.
а выцепить подробности про Credit Susse, допустим, или Банк Америки, уже куда как тяжелее. А там умудряются опер день в милисекунды закрывать. И спрашивают русских - а вы на чём транзакции проводите? И смеются, услышав ответ, отвечают you are kidding us!
Не верят, буржуи, что мы сплошь на продвинутом софте, что мы их на века обогнали в этом плане :) Как же они бедные без споров то про версионность :)

к сожалению, есть только от счастливого вендора:)
но по ноябрям в германии собираются европейские тусовки, прошлый год мой друг организовывал, так там очень много можно (и нужно) послушать от компаний-пользователей, а не от вендора. Хотя бы что за претензии они предъявляют вендору, что требуют у вендора, что заботит заказчиков :)
И можно с чистой совестью сказать - нам бы ваши заботы :)

думаю, если погуглить, ещё будет документиков за разные годы.


Прошу прощения за юморно-насмешливый стиль, никого не хотел задеть или обидеть, больше технологий хороших и разных!
1 апр 13, 14:24    [14121599]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Гирай
Guest
как всегда в таких вещах, вендорам особо доверять не стоит.
факт имеет место быть, да, а вот подробности реализации вендор может безбожно приврать, ибо сам нафиг не понимает, как они там всё это понаделали:)
поэтому тусовки - незаменимая вещь, когда сами архитекторы компаний выкладывают подробности.
Меня, например, глубоко поразила презентация архитектора сталелитейнйой компании.
На рожу - бандюк бандюком, из наших 90-х, с толстенной голдой на шее :)
Но такие вещи творят! они Технари с большой буквы!
на малупусеньком сервачке из примерно 3 ЦПУ умудряются творить всю логистику крупнейшей компании, при сбое в 30 минут системы городок встанет напрочь, в пробках.

Люди, приезжая к нам, и видя неработающий АТМ, не понимают, как это может быть, если это регулируется законодательно?! Ведь его ограничивают в доступе к его собственным средствам?!? И это люди, которые реализовывали закрытие опер дня банка америки, поэтому в деталях понимающие, как оно может быть, и должно быть :)
1 апр 13, 14:31    [14121634]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
гирай, это офигенно!
мля, как теперь жить то дальше после такого в нашем колхозе, где даже не то что не видел, а даже не представляют теоретически что такое взрослое ИТ и почему оно, а не всякие ораклы таки решают.
1 апр 13, 14:54    [14121776]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Гирай
Guest
на всякий случай, уточняю, я тут ни при чём, я в авантюре с гансами не замешан, не состоял, не привлекался.
просто кручу головой периодически по сторонам, пытаясь понять почему мы в жопе у нас трудности
а так, я целиком и полностью За, и колеблюсь с линией партии, и верю, что реляционки победили (на всякий случай) всех и везде.
1 апр 13, 15:01    [14121836]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Гирай
Guest
с другой стороны, "аполитично рассуждаешь" - это что же, двадцать человек хватит закрыть потребности всей банковской сферы России???
А куда же сотни бездельников сотрудников Сбера и других девать?
Эдак коммунизм капитализм не построить!
1 апр 13, 15:03    [14121854]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
я помню в детстве мне сказали что атомный ледокол за год использует топлива размером в спичечный коробок
я верил
потом оказалось что урана там грузят десятками тонн

теперь я взрослый и не поверю что 20 человек могут покрыть потребности приличного банка
беру гугл и попадается такая новость:

UBS планирует уволить тысячи сотрудников IT
оказывается что в швейцарском банке USB работает 48200 сотрудников, из них в ИТ - 8200
к примеру в сбере работает народу раза в два больше, а в ИТ раза в три меньше

т.е. возможно есть какие-то узкие направления, которые обслуживают много банков и где мало сотрудников - но вот остальным 8180 работникам тоже есть (некоторым правда уже было) чем заняться
1 апр 13, 17:41    [14123002]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
ну, возможно эти 20 человек заняты исключительно обслуживанием инфраструктуры мэйнфрейма.
А сколько там из банковского народа имеет логический доступ ко всяким разделам - неизвестно.
В любом случае, озвученные цифры нагрузок очень серьезные, а значит бигайрон живее всех живых.
1 апр 13, 18:58    [14123399]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
не, ну если я не расставил смайликов в посте про бездельников сотрудников Сбера, то уж...
я прям не знаю :)
ясно же, что аутсорсят в эту Fiducia что-то (платёжная система), в другую компанию ещё что-то, что-то имеют у себя, и сотрудников тоже имеют. Понятно, что на этом штат сотрудников ИТ банка не завершается, кто-то должен и бумагу в принтеры заправлять, и винду администрить, с активной директорией, куда ж без этого :)
Беда в том, что у нас на нашем пространстве даже законодательство не позволяет схемы аутсорсинга такого уровня, с этого надо начинать. А технологии дело третье.
А эти 20 человек заняты:
- 8 администрят инфраструктуру IMS - TM + DB2
- 8 администрят DB2 z/OS
- 4 администрят MQ z/OS
в продакшн стоит два сисплекса - типичная схема, два разнесённых дата-цента, в каждом по две машины в сисплексе, между датацентрами GDPS - Geographicaly dispersed сисплекс
и один для теста и разработки.
А вот новость об увольнениях показательная - аутсорсинг набирает обороты, и финансово гораздо выгоднее оказывается платить, чем содержать свой штат.
Ну и ещё момент - Швейцария, несмотря на то, что они почти немцы, таки не немцы, и они идут своим путём. Эта Fiducia по-моему вообще не аутсорсит швейцарцев, тому свои причины. Так каждый за себя. Был. Меняется, конечно.

А по нагрузкам это достойно, но не рекорд.
Вот, к примеру, Виза Инк закупает у ИБМ софт для фрейма с исходниками (было время, ИБМ продавал железо, а софт в исходниках давал задаром :) ).
Чего-то там допиливает, имея нехилый штат и переманивая ИБМеров :)
Ну часть наработок возвращают в ИБМ, который включает их в продукт.
Это к примеру про IMS.
Так так такие рекорды!
1 апр 13, 20:39    [14123682]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
geereye
и финансово гораздо выгоднее оказывается платить, чем содержать свой штат.


А расчеты можно показать?
1 апр 13, 23:54    [14124096]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
geereye
а там какой-нить японский банчик по всем финансовым показателям кроет все финансы гордой страны Россия как бык овцу. и вы им никогда не докажете, что ява, оракл, дельфи, что угодно - это круто, это по передовому, это по-настоящему.
или другой пример, более 800 европейских банков аутсорсят услуги платёжной системы в одной германской конторке, в облаке, так сказать. количество финасовых транзакций просто запредельно, как и количество счетов, и всего прочего. а обслуживают всё это хозяйство 12 человек. если вы захотите им пояснить суть извечных споров sql.ru, то они понять не смогут, о чём тут спорить то :)
и вообще - заказчики, клиенты, да и технари - все заинтересованы, чтобы было как можно больше конкурирующих технологий.
а то буржуи зажрутся.
так что кому интересно - и про нон-стоп, и про IMC или z/TPF можно почитать, и прикинуть, как же это добро можно использовать с пользой для дела, в чём плюсы, в чём минусы, где пределы применимости, и всё такое прочее. и вообще, как там говорили про изучение иностранных языков - помогает глубже понять свой родной. также и с изучением конкурирующих технологий - помогает лучше понять свои :)
Жуть какая. Аж 800 европейских банков.

Ну вот далеко ходить не надо - ЗАО «Компания объединенных кредитных карточек» http://www.ucs.su/about/
Не 800, но 157 российских и иностранных банков (что вполне сравнимо), обслуживают 75.000 терминалов. И прекрасно справляются без всяких мейнфреймов.
А админят систему так вообще, наверное, человека 3-4.

Или Qiwi (https://www.qiwi.ru/ru/company/qiwi.action) со 170.000 терманалами. Тоже вроде без мейнфреймов живут, насколько я знаю.

Мейнфреймы умирают. Не знаю, плохо это или хорошо. Большие железки продаются все хуже - поищите статистику: продажи IBM Mainframe снижаются. IBM чтобы скомпенсировать это делает "маленькие" mainframe. И все равно продажи не растут. Многие компании мигрируют с IBM Mainframов на что-то более дешевое и практичное - те же Power или Exadata. Недаром ведь за границей так популярна Tuxedo.

Вот например миграция BBVA (это 35-ый по размеру банк в мире со 100.000 сотрудников) с IBM Mainframe на стандартные системы.
Даже Microsoft клиентов растаскивает с Mainframe.
NASA отказалась от последнего mainframe.
Есть целые фирмы, занимающиеся миграцией с Mainframe.

Так что в России Mainframe - это бесперспективно, потому как мало кому хочется внедрять то, с чего все бегут. Хотя в мире mainframe еще долго будут жить, потому как "работает - не трожь"
2 апр 13, 01:22    [14124204]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
P.S. Кстати, HP Nonstop довольно интересная система. Только в России я ее видел всего в 2-3 местах.
2 апр 13, 01:41    [14124221]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
brrrrrrrrr
Guest
Alexander Ryndin
P.S. Кстати, HP Nonstop довольно интересная система.
Так оно-ж на Итаниумах и я полагаю на Венде :-/
2 апр 13, 01:49    [14124228]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
brrrrrrrrr
Alexander Ryndin
P.S. Кстати, HP Nonstop довольно интересная система.
Так оно-ж на Итаниумах и я полагаю на Венде :-/
Там своя операционка.
2 апр 13, 02:17    [14124236]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
расчёты - не ко мне, я не бизнесмен.

по поводу умирания фреймов - фейк полный!
И интересно, что эта фигня почти исключительно в России имеет место хождения.
Наверное, потому, что российское отделение ИБМ сам вообще не знает, что такое мэйнфрейм, и позиционируют его "просто как большой сервер" - в таком качестве это нафиг никому не надо действительно. В таком качестве оно должно умереть.
А вот в таком качестве как там, у них, у той же Фидучи - у нас нет альтернативы просто напросто. Вот к тому зе примеру по Киви и по объеденённым предитным карточкам - это не может никак идти в сравнение - просто по условиям контракта и по мерам ответственности.
Поэтому и нас и действуют на коленке сгавняканные изделия, потому как никто никакой ответственности не несёт.
Зачем вкладываться?
А первый враг мэйнфрейма у нас на территории - это российский ИБМ.
2 апр 13, 13:39    [14126320]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
По поводу миграции на что-то практичное - ещё один фейк, наоборот, последние несколько лет количество мигрирующих НА фрейм в процессе консолидации или централизации превышает количество уходящих с фрейма катастрофически.
В нынешних условиях, когда каналы в регионах становятся доступнее, а специалистов всё меньше, всё больше будет идти процесс централизации - когда не несколько АБС на банк, а одна, в добавок ко всему только это позволит конкурировать по качеству и гибкости с зарубежными банками. А централизация просто вынудит смотреть в сторону фреймов. Или сидеть в жопе как и ныне, выдумывая всё, что угодно, что оправдывает убогое состояние, к примеру, банковской системы.
Если пойти по сайтам вендоров - то тоже кучу всяких агиток найдём, но голову то включать надо.
Кстати, таксидо не может быть популярным, ибо редкостный отстой :)
Уж лучше TXSeries начиная с шестых версий, чем это убожество :)
Уж лучше тогда NonStop, там не просто операционка своя, там всё, что надо для OLTP - во-первых, нормальный менеджер очередей с низкими накладными расходами (да, это главное, а не база), во вторых, нормальный монитор транзакций, в третьих, две базы, для аналитики реляционка и для OLTP Enscribe - конечно, не так, как IMS, но всё-таки очень и очень неплохо. Это вот единственная нормальная альтернатива фрейму, там и аппаратное решение интресное, во многом использующее идеологию фрейма, и программная платформа интересная, идеологически повторяет IMS Dependent Regions.
А так, трындеть - "умерли, уходят" - и при этом нифига не знать в технологиях - это не вопрос знаний, это вопрос веры, посему базовики есть самые упёртые религиозные фанатики, учится не хотят, но баталии устраивать горазды :)
Ладно, извините, если что не так :)
Я не со зля, я знаю, что всем пофиг, и никого ни в чём не преубедить :)
Пока сам, своими глазами, руками, не увидит человек... Да и то вряд ли :)
2 апр 13, 13:50    [14126402]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
Кстати, не Киви, другая платёжная система, я тут волею случая поучавствовал, мы тут выполнили обследование ей, составили ТЗ, ну и завершаем системку, так что я бы системы этого рода приводить в пример как высоконагруженные - не стал.
Пики - есть, да, пиковость явно выраженная, но это количество терминалов ни о чём не говорит - поскольку транзакций по ним проходит в среднем очень мало.
Там трудность и засада в другом месте есть, особенность такая, какой, например, в других платёжных (банковских) и клиринговых, например, системах - нету.
Так что пример с Киви - это по незнанию :)
Можно ещё пример амазона привести - тоже без мэйнфреймов :)
Оно когда незнаешь - то примеры быстро приводятся:)
2 апр 13, 13:57    [14126452]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
Да, а чтобы не гадать - ближе к концу весны, наверное, можно будет решение платёжной системы показать, во всех подробностях, с исходными кодами, структурами, и прочим. И с живой нагрузкой.
Я понимаю, что это то это никого ни в чём не убедит :)
Да и вообще - такие платёжные системы в силу практически никакой законодательной ответственности (если сравнивать, как ТАМ), ну и в силу нагрузки, и других моментов - могут действительно обойтись без фрейма.
Но фишка тут в том, и это вот действительно можно будет подкрепить расчётами - что с фреймом получается дешевле.
Во какой парадокс - из-за софтового лицензирования по ядрам решение на фрейме, если делалось не рукожопыми, будет дешевле.
2 апр 13, 14:02    [14126507]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
londinium
Member

Откуда: Киев
Сообщений: 1202
автор
ближе к концу весны, наверное, можно будет решение платёжной системы показать, во всех подробностях, с исходными кодами, структурами, и прочим.

Думаю, многие (я точно) будут рады увидеть
2 апр 13, 14:10    [14126546]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL как СУБД для процессинговых центров  [new]
geereye
Guest
хм. ну в Киев тоже можно.
Ок, надо будет только как-то связаться.
И, хотелось бы, чтобы хотя бы два человека, а не один, выразили желание :)
Ну, так сказать, на троих сообразить :)
Оно то можно и удалённо смотреть, но, я боюсь, что если даже всё подробно описать, устные пояснения понадобятся, решение ведь не совсем стандартное, болезненный разрыв шаблона во многих местах гарантирован :)
Я по себе помню, как больно было :)
Сейчас надо соорудить скрипты нагрузки (на TPNS), которые будут эмулировать терминалы, посылающие запросы.
по расчётам, максимальная нагрузка один платёж с терминала в пять минут, но стрессовое тестирование тоже надо, когда терминалы посылают платежи с той скорость, с какой успевают их генерировать, ясно, что это без участия человека.
Так на достигнутую нагрузку можно точно знать, сколько ядер, что ИБМ за это просит, ну и каков размер бедствия в плане кодирования всего этого. Ну, там, закрытие опер дня, подготовка и печать выписок, и прочее.
Можно, конечно, всё записать, в виде повести "о настоящей системе", но блин ведь большая часть тупо не поверит, скажет - фейковые цифры, никто ничего не тестировал, засада!
А сложность и дороговизна фрейма сильно преувеличина. Понятно, не в каждый пивной ларёк. А только в те, где есть понятие "SLA", и когда есть потребность его достигать и соблюдать - ну, то ли конкурентная борьба, то ли законодательство заставляет, так тоже зачастую бывает, почти везде, кроме как здесь :)
Здесь никто ничего не гарантирует :)
И если что где упадёт (что мы знаем никогда не может быть) то вся Москва пол рабочего дня без банкоматов Сбербанка раз в квартал примерно, но это, как нам пояснили, не системная ошибка, это просто случайность, а так все булочки свежие сервера надёжные, ПО отличное!
И никого, что интересно, не расстреляли уволили :)
А так - да, Кивии и Сбербанк это офигенно, это просто образцы качества работы и полноты предоставляемого сервиса, а Россия - родина слонов (или Украина? :) ), а мэйнфреймы умерли, правда, это я слышу уже с 91 года, пожалуй, а они всё умирают и умирают... кол осиновый поискать, что ли....
2 апр 13, 14:36    [14126706]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить