17 июня, четверг 11:28
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

100 000 и более документов в день

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Partner
    Участник создал тему 100 000 и более документов в день

    100 000 и более документов в день

    Стоим перед выбором сторонней АБС, возможен вариант разработки собственной. Нужно уяснить: сможет ли технология от БГ (NT+SQL) обеспечить функциональность АБС при 100 000 и более документов в день?

  • ANM_SPb
    Участник ответил
    Добрый день.

    А Progress не расматривается? А почему?
    К сожалению вопрос так и остался без ответа.


    100 000 - это не только большой объем... но и высокая интенсивность. На такой уровень надо смотреть как на непрерывное производство.
    Прогресс - это умеет. Объем для него - рабочий. И я поговорил, бы с Бисквитом

    Думаю, что стоит поговорить с ГУТА-банком, работающем на БИСквите. В первую очередь конечно же с их головным офисом, один такой их клиент, как МТС чего стоит... У ребят есть опыт сопряжения с "Интернет-Банками" от разных производителей.


    Александр Н. Моносов www.intourbank.spb.ru

    Прокомментировать:


  • Ovchinnikoff
    Участник ответил
    Добрый день. Был в отъезде на неделю, поэтому не мог ответить сразу.
    2 Sun_Lin Судя по Вашим примерам - экзотические "навороты" с планосм счетов (а-ля СБ РФ) и полное незнанение того, без чего банк в принципе не может начать экслуатацию любой системы (контроль внешних платежей) - ваша система для коммерческого банка в принципе не подойдет. Как вы сами в этом признались.
    С уважением.

    Прокомментировать:


  • Аватар гостей
    Гость ответил
    2 Vladimir Kuzovlev :
    Да, Вы совершенно правы, речь идет действительно о "Гамбите" и "АйТи", действительно, закрыла проект, но проект, как это ни странно, еще жив, т.к. нам передали все исходники и мы его в меру своих сил развиваем. А то, что "АйТи" так и не смогла продать систему ни в один банк ... ... да уж ...

    а продавать систему теперь уже никто и не собирается , поэтому ...

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

    Прокомментировать:


  • Vladimir Kuzovlev
    Участник ответил
    2 Sun_Lin
    Смотрю я на свойства Вашей системы и диву даюсь. Где-же она? Почему еще не удавила всех и вся на рынке АБС? Давайте поищем. Если Вы называете ее "АйТи-банк", то неясно причем сдесть фирма "АйТи". Они подразделение АБС закрыли больше года назад. Может быть название другое - "Гамбит", тогда это практически локальная установка да еще и не в коммерческом банке. К чему это? Да к тому, что человек, открывший тему ищет АБС, причем поддерживаемую и сопровождаемую. Мне приятно, что Вам нравится система на которой работаете (нечасто это бывает), но вы собираетесь ее продавать на сторону, а затем поддерживать у других?
    Если же это просто полемика на тему "Сколько тянет MS SQL, тогда другое дело.
    С уважением,
    Владимир Кузовлев.

    Прокомментировать:


  • Аватар гостей
    Гость ответил
    2 Ovchinnikoff :
    "И вы всерьез считаете, что ваша система выдержит объем 100 000 документов в день ... ?"
    1. УЖЕ выдерживает порядка 30 000, причем с фантастическим запасом прочности 100 000, я (как и все мои коллеги) уверен, что не проблема
    2. Время проведения одного документа составляет, как я уже говорил, 0.1 сек.

    "... зачем при вводе ... проверять остаток на синтетическом счете ... ???"
    1. Очень просто : вот к примеру, синт. счет кассы "20202.01" ... он какой должен быть ? правильно, активный ! а если под ним завести некую пассивную аналитику, то куда мы можем залезть в 20202.01 (в принципе!) ? правильно, в пассив ! Ну, может быть, я неудачный пример привел насчет кассы но я хотел показать, почему надо проверять остаток на синтетике.
    2. Если НЕ проверять, то, боюсь, время проведения док-та станет <<0.1 сек.

    "... и уж тем более на разделе баланса ???"
    1. В системе есть возможность завести любое количество "деревьев", причем даже для своих внутренних учетных нужд
    2. Элементарный пример : как Вы смотрите на возможность вот такой проводки : Дт(40702810...) - Кт(90902810...) ? А вот если мы будем по-честному поднимать все до самого верха, то поймем, что главы "А" и "В" разбалансируются (кстати, у любого счета есть понятие статуса и есть в нем отдельная позиция "Сохраняется баланс по остаткам") ==> такая проводка не пройдет

    "... по требованиям KONVA"
    расскажите, пожалуйста, что Вы под этими требованиями понимаете.

    Прокомментировать:


  • Ovchinnikoff
    Участник ответил
    2 Sun_Lin
    И вы всерьез считаете, что ваша система выдержит объем 100 000 документов в день сохранив при этом адекватные свойства?
    И не понятно, зачем при вводе (проводе) документа проверять остаток на синтетическом счете и уж тем более на разделе баланса???
    А проверки внешних платежей ваша программа делает (по требованиям KONVA)?

    Прокомментировать:


  • Аватар гостей
    Гость ответил
    Хотя нет, я кажется понял, о чем Ваш вопрос !
    Если Вы о системе обработки запросов сервером приложений, то пожалуйте :
    для каждого соединения с клиентом создается своя нить (в смысле Thread ), чем достигается распараллеливание процессов, а уж как сам MSSQL будет справляться с атаками ниток, ну ... тут уже ему самому поручается за всем ентим следить и если SQL 6.5 справлялся с ентим плохенько (использовал табличную блокировку, даже если надо было апдейтить одну лишь запись), то SQL 7.0 & 2000 вполне неплох К тому же мы сервером приложений снимаем с SQL-сервера часть нагрузки, организуя КЭШ определенных таблиц в серверной памяти, за счет чего резко ускоряется работа самой АБС

    Прокомментировать:


  • Аватар гостей
    Гость ответил
    2 Partner :
    "А что будет, если во время проведения документов, запустить расчет оборотной ведомости за предыдущий день?" - ну-у-у-у ... тут следующие моменты : в системе, как я уже отмечал, состояние всех счетов (начиная с аналитических и заканчивая самой верхней синтетикой) актуализировано (при проведении любого док-та состояние всего дерева подбрасывается), т.е. ни о каком "расчете" оборотки не может идти речи, надо только залезть в историю по счетам и вытащить значения, которые для любого (синт. или аналит. счета) представлены всего одной записью за каждый конкретный день таким образом, получение оборотки за любой день в нашем банке (банк довольно-таки большой, поверьте мне да вы уже наверное догадались о том, что ето за банк ) занимает в среднем около минуты. И как эта минута может повлиять на проведение документов ?

    Прокомментировать:


  • Partner
    Участник ответил
    Sun_Lin А что будет, если во время проведения документов, запустить расчет оборотной ведомости за предыдущий день?

    Прокомментировать:


  • Partner
    Участник ответил
    Sun_Lin А что будет, если во время проведения документов, запустить расчет оборотной ведомости за предыдущий день?

    Прокомментировать:


  • Аватар гостей
    Гость ответил
    2 Александр_Турчин :
    "платформа должна быть СУПЕРНАДЁЖНОЙ и СВЕРХБЕЗГЛЮЧНОЙ. Что (имхо) к продуктам MS, работающих в "напряжённом" режиме, никоим образом не относится..." - ИМХО, батенька, Вы неправы в последнем ... и вот почему :

    1. Ламеров в админы ни в коем случае пущать низзя, как показывает практика, если админ грамотный, то все будет ОК !
    2. Пользовать MS SQL нужно только как хранилище данных и механизм обработки транзакций (как впрочем и любую систему управления БД,имхо) - бизнес-правила, связи м/у таблицами и т.д. надо писать ручками в сервере приложений и ни в коем случае не отдавать это СУБД, ей это несвойственно - тогда вы поимеете возможность не зависеть от использованной СУБД и сможете легко перейти ... ну, к примеру, на Postgress под линух, предварительно обеспечив общение между сервером приложений и СУБД некоей библиотекой доступа, не перелопачивая все бизнес-правила

    И только при соблюдении этих условий Вы можете быть спокойны - все у Вас с MS будет работать чики-пики !

    Прокомментировать:


  • Аватар гостей
    Гость ответил
    Ну, скажу и от себя, если кому инетересно ...

    У нас "АйТи-банк", система работает на NT+MSSQL, время проведения одного документа 0.1 сек. (простая платежная операция), причем при проведении документа выполняется следующее :

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

    и еще куча всего

    причем сервер, на котором все это крутится вполне дохленький по нынешним временам HP

    вообщем, за 8 часов можно таким образом провести 288 тысяч документов.

    А вы говорите, "мелкая речка Урал" (с)

    Прокомментировать:


  • Харибда
    Участник ответил
    2 Partner
    Тогда и СУБД должна быть от MS, не правда ли? MS SQL с справится с ежедневным потоком в 100`000 документов? Кстати, какому количеству одновременно работающих пользователей это соответствует?
    Ну да я не об этом. Я пытаюсь решить вопрос, что должно быть определяющим при выборе-покупке крупных систем. С одной стороны можно выбирать исходя из своего виденья платформы и инструментов реализации системы, с другой- можно выбирать систему с точки зрения того, наколько технологична она построена и насколько она отвечает требованиям Заказчика. В обоих случаях мы в конечном итоге получаем нечто, отвечающее нашим запросам, и тут следует понимать, что важнее: платформа или заложенная технология. Вам решать.

    Прокомментировать:


  • Partner
    Участник ответил
    Харибда А есть ли какие-то другие аргументы в пользу выдвинутого Вами постулата?
    Почему технология MS?
    Изложу аргументы, как их вижу, в порядке важности.
    1.деньги (сервера, разработка, администрирование и т.д.)
    2.скорость разработки
    3.технология MS это то, что уже не раз приносило успех нашим проектам

    Прокомментировать:


  • Александр_Турчин
    Участник ответил
    Shuric : "я сказал в принципе про запад..." Однако речь идёт про платформу именно для АБС и именно для обработки большого количества документов ! А это значит, что эта самая платформа должна быть СУПЕРНАДЁЖНОЙ и СВЕРХБЕЗГЛЮЧНОЙ. Что (имхо) к продуктам MS, работающих в "напряжённом" режиме, никоим образом не относится...

    Прокомментировать:


  • Харибда
    Участник ответил
    2Partner
    Не совсем понятна логика. Почему если интернет система разработана на продуктах MS, то и банковская система должна быть на аналогичной платформе? Разумеется понятно, что это сильно уменьшает "зоопарк систем" и упрощает администрирование. А есть ли какие-то другие аргументы в пользу выдвинутого Вами постулата?

    Прокомментировать:


  • Vladimir Kuzovlev
    Участник ответил
    2 Ovchinnikoff
    Если быть точнее, то 3 версии. Есть еше реализация на платформе SUN/Solaris. Но там в качестве СУБД используется PSQL for SUN/Solaris.

    Прокомментировать:


  • Ovchinnikoff
    Участник ответил
    Спасибо, Владимир.
    Более чем исчерпывающая информация. Иными словами, вы в настоящее время поддерживаете 2 версии сервера приложений (или технологичсекого слоя) - для Pervasive или для DB2?

    Прокомментировать:


  • Shuric
    Участник ответил
    2 Александр_Турчин
    Если Вы заметили я не слова не сказал про Западные банки... я сказал в принципе про запад... а информацию, о предпочтениях MS я подчерпнул из востребованности IT специалистов там... и по-моему аргументировал...

    Прокомментировать:


  • Александр_Турчин
    Участник ответил
    2Shuric : "На отсталом западе большинство работают на ПО от мелкомягкого" - и откуда же такие сведения ? Примеры приведите pls, назовите несколько крупных банков, работающих с серверами под NT. А то как - то неаргументированно получается...

    Прокомментировать:


  • Vladimir Kuzovlev
    Участник ответил
    Ответы по очереди.
    Используется СУБД DB2/400 практически со всеми возможностями. В частности реляционный вход, внутренние механизмы мониторинга БД и пр. Насчет штатной версии - недалеко от истины, но это кассается прикладных задач - они идентичны по технологии и функциональности с версией 5.1 и RSL такой-же ( в смысле макросы написанные для интела спокойно функционируют на AS), а вот технологический слой (сервер приложений и т. п.) созданы специально для этой платформы. Проектов с большими объемами данных в банках действительно пока нет, но практическим примером может служить использование модуля "Зарплата и Кадры" в котором ведется более 4000 сотрудников. Тестирование-же проводилось в режиме 250000 транзакций в день более 600 пользователей. При таких нагрузках наша AS (720) справлялясь.
    С уважением,
    Владимир Кузовлев.

    Прокомментировать:


  • Ovchinnikoff
    Участник ответил
    Добрый день Владимир.
    Я внимательно слежу за российским рынком АБС, и в курсе наличия у вас АБС, функционирующей по управлением OS400. Вы используете встроенную СУБД DB2 или Pervasive умеет работать в этой ОС? Насколько я понял, у вас работает штатная версия RS-BANK?
    Мое заявление про "анонс" вызвано тем, что, как мне кажется, в тех условиях, для которых в общем-то и должна применяться АБС под OS400, она все же не используется. Я веду речь про большие объемы данных и высокие требования к производительности. Ведь именно тогда можно "ощутить преимущества" ОС и СУБД. Небольшой банк в этом смысле не показатель. Или я опять не в курсе, и ваша АБС работает с большими объемами данных и пользователей?
    С уважением.

    Прокомментировать:


  • Vladimir Kuzovlev
    Участник ответил
    2 Ovchinnikoff
    Российская Банковская система на AS/400 есть! Это RS-Bank/400. Причем это на просто маркетинговые слова, а реально работающая в промышленной эксплуатации (на двух площадках) полнофункциональная система, полноценно использующая все приемущества этой платформы. Работает в терминальном режиме.
    Если необходимо - могу подробнее.
    С уважением,
    Владимир Кузовлев.

    Прокомментировать:


  • orbit
    Участник ответил
    Опираться на M$ -- не серьезно!
    Вы хотите, чтобы Вашим Интернет-банком (понятно на IIS)
    удаленно поуправлял M$?
    Или важнее интеграция АБС с Вордом?

    Прокомментировать:


  • orbit
    Участник ответил
    >Да что Вы так на мелкомягкого-то накинулись?
    Не люблю просто Ж-)
    >orbit уж не из-под юниксов ли Вы на форум бродите?.. :-)
    Догадливы Вы! А что. запрещено? Про Ворд была шутка.
    А про IIS давно писали http://www.zdnet.com/zdnn/stories/ne...543490,00.html

    А про работу -- кому что, кто-то бумажки в Ворде пишет...

    Прокомментировать:


  • Shuric
    Участник ответил
    Да что Вы так на мелкомягкого-то накинулись?...

    orbit уж не из-под юниксов ли Вы на форум бродите?.. :-) Интегрировать АБС с вордом можно не зависимо от серверной части - пусть хоть она под теми же юниксами будет. А клиенты и так чаще всего написаны под мелкомягкие операционки... я так понял что интеграция нужна на серверном уровне... хотя бы из соображений экономии, чтобы не покупать доп. серверное ПО и не держать доп. людей на его администрирование.

    PS. На отсталом западе большинство работают на ПО от мелкомягкого (попробуйте туда устроися со знаниями PHP и юникс, либо ASP + VB+ IIS) и ничего - пока еще ни разу не слышал, чтобы БГ пытался управлять чьим-то И-банкингом...

    Прокомментировать:


  • Солнышко
    Участник ответил
    Может конечно я и не прав, но у меня давно сложилось такое мнение: "где технология БГ, там и рвется". Тем более на таких объемах. Я бы сто раз подумал, прежде чем переходил на технологию БГ, какой бы интегрированности при этом не достигалось бы.

    Прокомментировать:


  • Partner
    Участник ответил
    Наш банк в 1997 г. одним из первых в мировой практике (есть основания полагать, что первым) разработал и начал использовать Интернет √ Клиент. Внутренние разработки основаны на технологии Майкрософт (вплоть до MSF). Сейчас строим Интернет-Банк с большим перечнем услуг. Система интернетовского обслуживания - собственная. Масштаб обозначен мной в теме. Задача, перед решением которой стоим в настоящее время, состоит в выборе АБС. Для обеспечения широты предполагаемых операций клиентов и обозначенной интенсивности работы, Инет-система должна быть тесно интегрирована с АБС. Поэтому оптимальным представляется что бы и АБС опиралась на технологию от MS.

    Прокомментировать:


  • Partner
    Участник ответил
    Все правильно Г-н. Ovchinnikoff БГ = Майкрософт. Я уже понял необходимость конкретизировать задачу. Сделаю это, как только сформулирую ее в формате форума.

    Прокомментировать:

Обработка...
X