Комментарии 20
От Опенвея ушли чтоли?
интересно как на надежности отразится, довелось эту хреновину в проде понаблюдать (не у сбера, но всеже)
Platfrom V Pangolin — реляционную СУБД корпоративного уровня, которая соответствует высоким требованиям к безопасности, доступности, надёжности и производительности.
Я понимаю, почему они не пишут «допиленный постгрес», но я напишу. Это он, постгрес, хоть и с неким объемом ин-хаус доработок.
С довольно приличным объёмом доработок даже на 2022 г.
Чем СУБД Pangolin отличается от open source версии PostgreSQL?
В Platform V Pangolin более 30 крупных улучшений/оптимизаций, что позволяет получать лучшие результаты по производительности и быстродействию по сравнению с PostgreSQL. В том числе оптимизации для работы с платформой «1С:Предприятие», доработки, снимающие имеющиеся ограничения при работе с секционированными таблицами и др. Кроме того, в продукте увеличена битность идентификаторов транзакций (XID) до 64 бит, что позволяет избежать достижения исчерпания счётчика для любой нагрузки, в ванильном же PostgreSQL под счетчик транзакций по-прежнему выделено 32 бита, что вполне позволяет достичь wraparound за 2-3 дня со значительной деградацией или даже недоступностью.
Большинство доработок относится к обеспечению безопасности СУБД. Прозрачное шифрование хранимой информации и параметров подключения, гибкое управление парольными политиками, защита от привилегированных пользователей и т.д. Создавая продукт, мы ориентировались на банковские стандарты в области защиты данных.
Ну, оценить по пресс-релизу я не могу. Да и знаем мы цену пресс-релизам.
В любом случае, даже если объем доработок приличный - это не «российская субд». Это допиленный пг, в чем нет ничего плохого.
Блин, если из всего того они пишут, что мы где-то int на long поменяли, то видимо там все "улучшения" такие.
Даже замена «int» на «long» в высоконагруженной системе, напрямую участвующей в банковских транзакциях, это большая работа. Надо убедиться, что внесённое изменение не вызовет проблем ни в одном из модулей, исправить те модули, где проблема всё-таки возникает, провести тестирование... По сути, то же самое, что в очередной раз решить проблему 2000-го года. В каких-то системах она решалась просто, а какие-то системы ещё долго простаивали после смены цифр на календаре. Кроме того, надо учитывать и уровень ответственности. Банковская система, конечно, напрямую не является критической для жизни человека. Но если с транзакциями по карточкам начнёт происходить что-то непонятное, то и на здоровье людей это может сказаться — как клиентов, так и работников банка.
О какой ответственности вы говорите, где вы это видели хоть в одном софте, дайте посмотреть.
Я не уверен что они сами сделали этот патч(он есть в ПРО, в мейнстрим он уже давно лежит, но там вроде пока не дошли еще)
Если вдруг что Platform V DataGrid - это Apache Ignite, лично мне гуглить пришлось.
Там была смешная история про инновации и ошибки, стоящие длительного времени не очень успешных ниокр.
Сбер купил часть Питерской компании, которая писала ignite. Начальники с сейлами поговорили и решили, что из ignite (а точнее, из его коммерческой ветки под названием gridgain) можно сделать распределению субд, которая закроет все потребности сбера. Спустили эту задачу на этаж ниже, и вот тут разработчики гридгейн офигели, когда десант экспертов из сбера пришел и начал накидывать им в панамку требования типа транзакцонной целостности на сотнях узлов и бекапов с point in time восстановлением.
Прошли года, игнайт сильно доработали, но транзакционной субд «как оракул» он от этого не стал.
В названии статьи сбивает с толку формулировка «перевёл выпуск банковский карт», тогда как в статье речь идёт о полной процессинговой системе, в которой выпуск является одним из этапов. Что касается выбранного инструмента — реляционной СУБД — то он выглядит несколько тяжеловесным для такой задачи. Но у банка есть свои архитекторы, им виднее. Возможно, решили во всех продуктах использовать один инструмент, что тоже имеет смысл.
Что касается выбранного инструмента — реляционной СУБД — то он выглядит несколько тяжеловесным для такой задачи
Так оракл же тоже реляционная СУБД, тот продукт на котором работал сбер был буквально написан на PL/SQL и на Java...
к сожалению не знаю технических подробностей именно сбера, но вообще задача банковского процессинга не такая однозначная чтобы решить какой подход лучше
Я видел один процессинг который работал на СУБД Informix вообще без транзакций (а целостнность обеспечивалась силами платежной системы и сверкой балансов)...мне это казалось крайне странным решением (и до сих пор кажется)...вообще я так понимаю в этой сфере нет какогото единственного правильного подхода
В принципе, поиск в сети даёт много примеров использования PostgreSQL в качестве key-value storage. Возможно, он может конфигурироваться, чтобы быть достаточно эффективным в таком варианте. Я же исходил из того, что в транзакционной системе преобладают операции добавления записей в хранилище, а построение отчётов с высокой долей вероятности выполняется на реплике основной базы данных.
Кстати, можно вспомнить Borland Interbase, которая перевоплотилась в Firebird и по сей день здравствует. В своё время читал, что её использовала компания Боинг в системах заказа билетов. Это даёт ещё одно направление локализации информационных технологий на стеке PascalABC.NET + Firebird. Российское происхождение первого, кстати, трудно оспаривать. О промышленных же системах на Паскале пока что не слышно.
В принципе, поиск в сети даёт много примеров использования PostgreSQL в качестве key-value storage
процессинг это не key-value
там довольно сложные схемы карточных продуктов со связями с договорами, схемами начислений всяких комиссий, распределения направлений процессинга и т.п.
Но ведь взаиморасчёты между банками и начисление манибэк не обязательно производить онлайн, одновременно с транзакцией? А на этапе обработки транзакции важно проверить, разрешена ли она, и в случае положительного решения записать её реквизиты. Для принятия решения требуется проверить карточку по стоп-листу, узнать остаток средств, валюту платежа, банк-эмитент и банк-эквайер. Кажется, что такая проверка может быть быстрее выполнена поиском по ключу в нескольких таблицах, нежели выполнением запроса в реляционной БД. Ну а обработка выполненных транзакций может неспешно выполняться в учётно-операционной системе, к которой не предъявляется высоких требований по нагрузке.
то как вы описываете, так и было до середины 10х годов гдето было, но вообще на таком принципе и работают все МПС
но сейчас то всем хочется кнопАчку нажал - сразу денежки прилетели, а не ждать 3-5-30 суток пока платежки прогрузятся везде
вот и начинаются приседания всякие с прямыми запросами в другие банки, в МПС, во всякие сопутствующие сервисы...все прям сразу хотят бонусы, кешбеки, проверку фрода
взять например Electron-Electronic-maestro карты с обязательной авторизацией или "настоящие" дебетовые карты...это не кредитка-standard где сделал транзакцию и плевать чё там с ней будет там блин такие заумные условия одобрения транзакции иногда бывают капец.
Другие новости
«Сбер» перевёл выпуск банковских карт на собственную платформу на базе Platform V DataGrid