Comments 92
Перерывая вчера старые коробки обнаружил древнюю книжку (на русском!) про AS/400 и OS/400. Пустил слезу.
На тестах производительности pSeries выигрывает у zSeries...
Да и перспективой Oracle DB на них большие проблемы...
древнюю книжку (на русском!) про AS/400 и OS/400
Если речь про Солтиса, то её стоит читать и временами перечитывать независимо от того, планируется ли работа с этой системой - технологии интересны сами по себе.
Не понимаю пассаж про "уходят в облака". А облака-то на чем работают? Просто на серверах новой архитектуры. И всегда будут компании, которые поставят себе свой сервер, а не уйдут в облако. Любопытно было бы почитать про отличие мейнфремов от современных подходов и, может, какие-то принципы взять из старой технологии, раз она столь жизнесопособна?
от 1 до 4 процессоров и от 8 до 32 Гб внутренней памяти
Как-то маловато. Или это конфиг двадцатилетней давности и с тех пор оно не развивалось ?
Написано же, что 2004 год. Вроде весьиа неплохо
Ibm z16 a01:
200 cpu Telum (8 ядер)
40 Tb ram
Ага, статья особенно актуальна для российских реалий в период активного импортозамещения.
А причем тут российские реалии? Слава богу русский язык не только в РФ в ходу. Знаю несколько стран где "хайтек говорит на русском". Знаю израильтян, которые русский выучили, чтобы читать техническую литературу. Культурный обмен в действии, в общем. И русскоговорящим (а не только россиянам) есть чем поделиться.
Застал ЕС ЭВМ, много где работали в начале нулевых.
Мне удалось на излёте (в середине 2010-годов) поработать с интересным кадавром - вся периферия была от ЕС (блочные терминалы ЕС-7920, ленточные накопители и т.п.) но при этом сам мейнфрейм IBM SYSTEM/370. На всем этом крутилась программа расчета зарплаты немаленького машиностроительного предприятия, написанная на PL/I. Повезло что в курсе операционных систем нам давали какие то основы JCL и совсем уж полным идиотом я себя не чувствовал.
В Газпроме Z-серия используется до сих пор
Довольно стремно вкладываться в обучение работе с умирающими технологиями. Пройдут годы и вот ты еще не пенсионер, но уже не такой молодой и гибкий, с никому ненужными в современном мире скилами.. так себе перспектива.
Когда пройдут годы, любые современные скиллы станут маловостребованными, причём популярные – раньше, чем мейнфреймовские.
Так вы эти годы будете развиваться.
Вот, к примеру, вы пошли по направлению бек-java, выходят новые версии явы, новые фреймворки, старые обновляются и получают новые фичи, вы все это изучаете и когда прошли годы ваш уровень все еще довольно актуален, если вы не ленились, конечно.
Даже если java тоже уйдет в категорию неактуальных древностей, произойдет это не внезапно и вы сможете плавно куда-то перейти на смежные направления, в Котлин ,например или еще куда-то.
А эти мэйнфреймы - во первых там мало что нового в принципе происходит, во вторых, когда они станут совсем не актуальными, все вами изученное и освоенное станет просто бесполезным грузом, интересным только техноархеологам. Это, конечно, не значит что на этом жизнь закончена, можно перейти в другое направление, но тут уже вам придется начинать по факту с нуля, с позиции джуна, а лет так в 50+ это уже не очень.. да и попробуй устройся куда-то, если ты пятидесятилетний джун..
Приведу в пример себя. Мне сейчас как раз под полтиник, и из первых шести изученных мной языков программирования на сегодня сколько-нибудь актуален и позволяет зарабатывать деньги только Фортран (который, как известно, является самым древним языком программирования вообще). А всего я за свою карьеру сменил около 15 языков в качестве источника средств к существованию. Правда, никогда после первого года не было такого, чтобы я в какой-то момент программировал только на одном языке.
При этом ни одна из технологий, изученных мной за первые, скажем, 10 лет трудовой деятельности не оказала сильного влияния на сложность изучения какого-нибудь Питона (это последний изученный мной на данный момент язык). На длинной дистанции играют роль только общая эрудиция и знание фундаментальных основ программирования. Ну и с какого-то момента изучения уже появляется не так много нового, в основном переизобретается старое. Вот люди, например, сейчас async/await для себя открыли, которые были ещё в макроассемблере IBM S/360 в 1966 году. Или MPI переизобрели из транспьютеров.
ЯП это фигня, его действительно изучить недолго имея опыт работы. А вот знание всяких фреймворков, тут сложнее, слишком много нюансов, которые узнаешь только с опытом работы именно с этим фреймворком. Да, это тоже не проблема для опытного человека, но время занимает, и руку набивать лучше на реальных проектах. Да еще и при этому у него возникает проблема замкнутого круга, как у джунов - без опыта на работу не берут, опыта работы (с обычным стеком, применяемым для конкретной работы) нет потому что на работу не берут.
Придя устраиваться куда-то java разрабом, с резюме в котором десяток языков но нет явы, нет Спринга, нет всяких там ломбоков и прочего, вы в лучшем случае сможете претендовать на джуна, несмотря на весь свой опыт работы.
Вот и получится, что все эти крутые скилы на мэйнфреймах окажутся бесполезными в плане трудоустройства, когда мэйнфреймы окончательно перекочуют в музеи.
Ну человек не будет же устраиваться Java разрабом в таком случае. Зачем ему идти в мейнстрим конкурировать с молодыми голодными (и немолодыми сытыми) специалистами? Даже если, предположим, он к 50 годам по-прежнему ориентируется на работу девелопера, то ему будет выгоднее при прочих равных условиях выучить что-нибудь новое или малоизвестное, где конкуренция меньше и цены выше.
Но мой-то пойнт в том, что Java запросто может перекочевать в музей раньше мейнфреймов, так как модель разработки другая и легаси мало. Как сейчас Фортран, который мне ещё в советской школе казался старьём - хоть и не на первых ролях, но пережил большинство языков, призванных его заменить.
Конечно, языки тут только для примера, и я согласен, что правильнее говорить о фреймворках. Но вам не так просто будет назвать используемый сейчас фреймворк хотя бы 20-летней давности (вне мейнфреймов и подобной техники).
Не, с "легаси мало на Яве" это вы промахнулись, вот чего-чего, а этого там с избытком. Все, конечно, возможно, но я думаю что Ява точно будет долгожителем, она уже долгожитель уже скоро 30 лет, для современного IT это уже солидный возраст.
Я не говорю что невозможно будет уйти с умершего направления, я скорее о том ,что сложность эта тем выше, чем дальше это направление от мейнстрима, а мейнфреймы от него уже прямо совсем отдалились. И если уж лезть в эту экологическую нишу, то надо десять раз подумать - как из нее потом будешь вылезать :)
А вот знание всяких фреймворков, тут сложнее, слишком много нюансов, которые узнаешь только с опытом работы именно с этим фреймворком.
Фреймворки - это Java, веб девелопмент и т.п. Скажем, в оптимизации перемножения матриц под новую железяку они мало помогут )
Честно говоря, есть ощущение, что IBM чуток проспал момент, и может повторить судьбу Нокиа
Дело даже не в том, что они поддерживают "старые" решения, а в том, что новые решения уже не их
Я как человек, непосредственно работающий с решениями IBM, считаю, что реальность прямо противоположна. Мало того, что все переспективные разработки у IBM, так она их переводит в контейнизированные микросервисы, которые работают в Cloudpaks. Все это великолепие работает на OpenShift платформе, ведь IBM не просто так купила RedHat. Кстати openShift доступна на хоть на bare-metal, vSphere, AWS, Azure. Также все мейнфреймы виртуализируются в контейнеры на Z-series (но это не моя область).
Ну смотрите
OpenShift - это прекрасно, но в реальности при наличии management Kubernetes в любом клауде - скорее попытка догнать авто на лошади. Причем уже довольно таки древняя. Да, когда он появился - это имело смысл. Сейчас - ну не знаю. Разве что каким то огранизациям, которые хотят жить on prem, и при этом готовы заплатить еще и за то, что им из бесплатного собрали решение :) Да, такие тоже есть, как правильно это большие организации, но и их время придет
Другие продукты - ну смотрите. Про перспективные не скажу, но пару лет назад, то с чем я работал (BPM, шина) в опции "деплоймент в контейнеры" были ограничены и даже по доке была видна ".опа", которую таки смогли всунуть в форточку.
Также нет никакого секрета в том, что многие "перспективные" разработки - это просто купленные решения, чтобы закрыть "дырку" в портфеле предложений. Не более того.
Но самое главное - IBM не имеет клауда. Точнее он то есть, технически, но как "неуловимый Джо" - он никому не нужен.
-----------------------------
CLoudPak - это просто маркетинг и не более того. Давайте вместе аккуратно снимем лапшу с ушей :)
OpenShift - это прекрасно, но в реальности при наличии management Kubernetes в любом клауде - скорее попытка догнать авто на лошади.
Я фигею в этом зоопарке! А на чем бежит то этот мэнэджет Кубернетес? Верхом на облаке? Какой провайдер используется для деплоя базовых VM? Где они бегут?
Я не оспариваю потерю лидерства IBM, но это вот "кому нужны сервера, все уже давно к кубере" - аж прямо не смешно уже..
p.s. В 1993 году работал с IBM RS/6000, OS/2. С тех пор нежно люблю голубые коробки.
А на чем бежит то это мэнэджет Кубернетес? Верхом на облаке? Какой провайдер используется для деплоя базовых VM? Где они бегут?
На чем крутится AWS, GCP или Azure я не скажу, так как я не владею такой информацией. Если вы ей владеете и можете поделиться - это просто прекрасно. Я, да и все с удовольствием почитаем
о это вот "кому нужны сервера, все уже давно к кубере" - аж прямо не смешно уже..
Да, я смотрю с точки зрения конечных потребителей, а именно компаний, который хотят получать ИТ-решения для своего бизнеса. Условно лет 10 назад IBM был в лидерах, имея:
готовые решения и платформы
сервисные подразделения по "железу"
сервисные подразделения по "софту"
сильный консалтинг
кучу малу интеграторов, чтобы делать грязную работу и брать на себя риски поддержки
Сейчас потеря рынка конечного пользователя фактически низводит компанию до "нишевых" решений или вообще не пойми чего
Сервера ... еще 10 лет назад застал миграцию с IBM Power миграцию на x86 (blades). Банально дешево, просто и поддерживает без проблем обычные решения на виртуалках. Большие "молотилки" оставались скорее чтобы не мигрировать все сразу. Плюс надо понимать, любой сервер устаревает и компания, которая его использует сталкивается с выбором:
покупать дорогую extended поддердку и "жить" дальше
мигрировать на новое
Поэтому чуда нет, даже если делаешь сервера, нужно бежать, чтобы просто оставаться на месте
Если вы ей владеете и можете поделиться - это просто прекрасно.
Знаю на чем бежит Google, но сказать не могу. Думаю все кто знает, по той же причине, поделиться не могут.
Поэтому чуда нет, даже если делаешь сервера, нужно бежать, чтобы просто оставаться на месте
Может я просто косноязычен и не смог донести простую мысль: число вычислительных задач растет. И все они должны бежать на ядрах и гигабайтах. Не столь важно как упакованных: generic cloud VM, serverless, mainframe или то же кубер. Есть потребность в вычислительных ресурсах. Про это все забывают. Физические серверы - это основа всего. Всегда будут инженеры, которые их обслуживают. Даже когда вымрут девопсы, программисты и SOC - админы, которым пророчут замену на ИИ. Никакой ИИ не заменит железного инженера и сетевика. Почему про это забывают?
Да, я смотрю с точки зрения конечных потребителей, а именно компаний, который хотят получать ИТ-решения для своего бизнеса.
Даже с этой точки зрения вы должны позаботиться о базовой инфраструктуре. Или купить готовую. Чудес не бывает! Ничто не "бежит в облаке" - просто кто-то за ваши деньги готов поддерживать для вас железную инфраструктуру скрывая ее под новым уровнем асбстракции. Который тоже требует ресурсов и за которые вы тоже платите!
p.s. Простой пример. Делал POC для одной компании. Они арендовали большие машины для varnish в облаке. Так вот перевод на on-prem окупает покупку железа за 4-5 месяцев и далее экономия в 4 раза по отношению к арендованным! Вот на чем AWS зарабатывает миллиарды. Да, нужен доп. персонал. Но на сотне серверов это затраты невеликие.
В последнее время консультирую многих на гибридные (100% загружаем on-prem, а спайки докупаем в cloud) или 100% on-prem solutions. Люди начинают считать деньги. Cloud хорош для startup, для зрелой продуктовой компании это расточительно.
для зрелой продуктовой компании это расточительно
В этот момент HeidelbergCement смотрит на вас с улыбкой )))))
Про это все забывают. Физические серверы - это основа всего. Всегда будут инженеры, которые их обслуживают. Даже когда вымрут девопсы, программисты и SOC - админы, которым пророчут замену на ИИ. Никакой ИИ не заменит железного инженера и сетевика. Почему про это забывают?
Потому что, как я написал, IBM было про "все". Даже если они будут и дальше продавать сервера - это даже не падение, это по сути превращение из лидера в нишевого производителя :)
p.s. Простой пример. Делал POC для одной компании. Они арендовали большие машины для varnish в облаке. Так вот перевод на on-prem окупает покупку железа за 4-5 месяцев и далее экономия в 4 раза по отношению к арендованным!
Вы не то считаете :) Покупка "железа" в клауде выглядит странно и непонятно. Точнее всегда можно найти компанию, которой это подойдет, но в целом это не очень эффективно
Переезд на SaaS/PaaS куда более выгодно смотрится
Люди начинают считать деньги. Cloud хорош для startup, для зрелой продуктовой компании это расточительно
Очень сомнительно, если честно. Разве что вы считаете железо против железа, что не особо имеет смысл. Либо как раз считаете правильно, чтобы продавать "железо". Это нормально и правильно, только я то у вас ничего не покупают. Мне то зачем это рассказывать :)
Никакой ИИ не заменит железного инженера и сетевика.
Они остануться у клауд-провайдеров :) Безо всякого ИИ
Для примера, ну или для поиска истины, давайте попробуем задеплоить "большую молотилку" под обычную SQL базу. Но для серьезной конторы конечно.
Так чтобы с DR (желаетельно с нормальным разнесением), в кластере. Я думаю, много зрелых продуктивых компаний живут на таком
---------------
Или банальный другой пример, когда продуктовые решения состоят из кучи компонентов на различных технологиях. Условно веб-морда, серверная часть, кеш, брокер сообщений, SQL, noSQL, elastic, ML. И все это растянуть в кластера, тот же DR. Ну и конечно сверху накрутить WAF, посередине всякие там firewall, AD. Сбоку поставить сбор логов, мониторинг. Желательно снизу подкрепить серваками с виртуализацией, дисковыми стойками з разнесением по дата центрам, ленточками. Ничего особенного, правда.
Вот только настраивая все это барахло самим у вас штат народу будет такой, что за эту сумму можно будет купить ресурсов в клауде по самое не хочу. И все эту орду народу содержать, учить, искать новых спецов
Да, большая серьезная социальная контора может себе позволить трудоустроить столько народу. Вопрос только зачем?
Кстати, если это продуктовая контора еще и работает в отраслях, где желательно сертифицироваться на отраслевой стандарт - но не забудьте это все прогнать через этот чудо процесс
Вы описали NUTANIX solution - все в одном от одного вендора и on prem. Я один админил 8 кластеров NUTANIX и это была не основная нагрузка. В коробках было всё: VM, DATA PROTECTION (AZ) с дедупликацией, ClusterFS, managed K8s и SDN конечно.
Все уже придумано до нас )
A IBM мне тоже жалко. Но, может, просто потому что это мое голопузое детство (os/2, rexx, rs6000..)?
Знаю на чем бежит Google, но сказать не могу.
Если где-то в углу стоит мейнфрейм с SAP для бухгалтерии, то это не значит что на нём "бежит Google".
Есть немало организаций, у которых такие объёмы данных, что связываться с облаком нерентабельно, выгоднее построить собственный датацентр.
Старая добрая DB/2 работает на мейнфреме с такой скоростью, которая для других баз данных на другой аппаратуре за сравнимые деньги недоступна.
На мейнфреме можно поставить Linux на одной из partitions, а на него, в свою очередь, Kubernetes, OpenShift и т.д. Правда, в этой сфере у мейнфремов нет особых преимуществ перед конкурентами, поэтому так их обычно не используют. Но выброшенными эти деньги в любом случае не будут.
4. Облако у IBM есть, и кое-кто им пользуется.
Ну, наверное. Но даже среди банальных "жирных" котов вроде банком, телекома или страховых ничего фееричного в объемах нет. Плюс вы же понимаете, что делательно строить два, а еще лучше три. Между ними строить "быстрые и толстые" каналы, и потом "растягивать" решения
Не буду спорить, по моему опыту - все как и у всех. Ничего особенного нет. База куда эффективнее "разгоняется" стороними технологиями вроде кеша или noSQL или column-based. Если нет потребности "держаться" за реляционную алгебру, мир сразу становится шире
Я лучше тут анекдот вставлю:
Умирает народный писатель, член союза писателей, обладатель многих премий. В комнате, заставленной книжными шкафами с его произведениями столпилась в скорбном молчании родня. Умирающий открывает глаза и шепчет свои последние слова:— Есть у меня на сердце одна боль, одна не сбывшаяся мечта… Давно, когда я еще был студентом, послали нас на картошку в один из колхозов. Познакомился я там с одной девочкой… Однажды ночью позвал я ее на сеновал… Снял я с нее всю одежку, повалил в стог сена… И вот, я давлю, а попка у нее в сено уходит, я давлю, а попка проваливается… Эх как взять бы тогда, да все мои книги, ей под задницу и затолкать!
Да, я знаю. Но тут поезд ушел скорее всего навсегда. Вот прям сейчас заполнял анкеты внутри организации для того, чтобы взять девопса на проект. В вопросе про клауды на проекте варианты очевидны :)
Лично мне чуток печально, что такая большая компания на ровном месте превратилась в памятник самой себе и забронзовела :( Тем более с ней у меня были кое ккакие разные и продолжительные отношения
"База куда эффективнее "разгоняется" стороними технологиями вроде кеша или noSQL или column-based." :-)
Попробуйте "разогнать" OLTP базу у которой 5000 insert в секунду в одну таблицу (или несколько) все проверяют (до своего исполнения) одно уникальное значение поля в другой таблице и после успешной проверки это же уникальное значение модифицируют.... :-)
Зависит от задачи и бизнес логики
Можно вполне писать в кеш, и потом скидывать в базу
А что это за активность такая, 5000 в секунду? Может там вообще надо смотреть на это, как на поток?
Да пишите вы куда угодно... :-) Чудес же не бывает... :-)
Если область памяти читается и модифицируется множеством потоков/процессов одновременно (что и происходит в данном случае) вы будете иметь проблемы с блокировками в любом случае....
Не спасет вас новомодные микросервисы, шардинг и т.п. (только хуже будет), и только скорость CPU и памяти даст вам прирост....
Если у вас 5000 финансовых транзакций в секунду которым требуется проверить, что одна определенная сумма баланса не менее "чего-то" и каждая финансовая операция воздействует на этот "единый баланс"....
Если у вас 5000 финансовых транзакций в секунду которым требуется проверить, что одна определенная сумма баланса не менее "чего-то" и каждая финансовая операция воздействует на этот "единый баланс"....
Мне трудно представить бизнес задачу где 5000 транзакций в секунду воздействуют на "единый" баланс. К сожалению, такого опыта у меня нет. Ну правда, это какой должен быть даланс, чтобы по нему проходило в одну секунду 5000 транзакций
Если же 5000 транзакций с разных счетов - тогда, все что бы написали выше - прекрасно работает. А дальше надо смотреть на нюансы.
Мне трудно представить бизнес задачу где 5000 транзакций в секунду воздействуют на "единый" баланс.
Какой-нибудь Озон со своей стороны и со стороны банка, например. Или другая крупная розничная сеть в часы пиковой нагрузки.
Судя по статистике, Озон в 4 квартале 2022 года продал 174.6 млн заказов, что составляет 22 выполненных заказа в секунду в среднем за 3 месяца. Очевидно, в часы пиковой нагрузки (днём/вечером, перед праздниками и т.д.) это значение намного больше, плюс ещё на один успешный заказ приходится какое-то количество отменённых операций.
А если не ограничиваться “балансом”, то это нормальная ситуация в задачах сбора и обработки данных. Это именно то, что называется OLTP, и для чего, собственно, изначально и придумывались в IBM реляционные базы данных и язык SQL.
Смотрите, критично именно транзакции по "одному счету", что и было выделено.
Остальное - почти всегда отлично распределяется
Так это один и тот же банковский счёт Озона. По крайней мере, я не вижу смысла для Озона заводить много счетов, чтобы упростить процессинг банку.
Ну а в сборе и обработке это всегда по определению один объект. Происходит что-то интересное, одни клиенты регистрируют об этом данные от датчиков, другие в то же время их обрабатывают.
Та озон - это просто еквайринг, как и любой магазин. Там вообще счет возникает далеко и оптом.
Я не уверен, что надо тратить время и пояснять схему, но если вы очень хотите ...
Про IoT - ну там же ж совсем другие решения. Никто в базу сырые данные не пишет. Зачем вам это?
Но если кому-то зачем-то очень надо - в мире происходит столько всего, что наверняка кто-то так и делает
А что это за активность такая, 5000 в секунду?
Ну вот сходу вижу, что на NYSE десятки миллионов сделок в день, причём активность явно неравномерная, так что в пиковые моменты может быть и столько.
В посте было 5000 транзакций в секунду с ОДНОГО счета. Для биржи конечно операций много, но так чтобы 5000 по одной сущности ... сомнительно. А если по разным ... ну тогда вы же понимаете, что даже очень большая транзакционная молотилка великолепно режется на "партиции" в любых смыслах этого слова
Все просто, даже очень... :-)
У банка есть эквайринговая сеть (ну к примеру 10000 банкоматов, 50000 POS теримналов + пара-тройка больших маркетплейсов торгующих через интернет + прием коммуналки на сайте и т.п.) принимающая карты (и в том числе "чужих банков" которых скажем два-три и с которыми у вас есть договор на прямые взаиморасчеты). Поскольку терминалы и торговцы ваши (вам с ними и рассчитываться в любом случае т.к. они "услугу или товар предоставили"), а вот вероятность что "чужой банк" вам возмещение (по операциям своих клиентов) не предоставит (денег не переведет) - всегда есть. В таком случае "чужому банку" вы "говорите" - я (как банк эквайер) готов обслуживать ваших клиентов по их картам, но для исключения моих рисков (что вы со мной не рассчитаетесь после того как я обслужу ваши карты) вы вносите на свой счет в моем банке "страховой депозит" в том размере какой сочтете сами необходимым. Пока средства на вашем счете есть - я обслуживаю ваши карты.
Вот и все. Вы обслуживаете карты "чужих" клиентов по этому правилу. И каждая операция с чужой картой проверяет наличие суммы этой операции на счете чужого банка и если сумма на счете позволяет, уменьшает сумму на этом счете на свою величину.... :-)
Операций по чужим картам много, но все они "проходят" через один "страховой счет".
И еще "одна мелочь".... Кроме собственно суммы операции по одной "чужой карте" через тот же счет может проходит "сумма комиссии" которую вы м.б. возьмете по данной операции с "чужого банка".... Т.е. на одну операцию по чужой карте может проходить более одной операции через "страховой счет" чужого банка.... :-)
Ну, странная схема, если честно.
Во-первых банк явно не маленький. Возможно сбер (там много извращенцев), но это не точно.
Во вторых, чтобы выйти на число 5000 в секунду, это надо чтобы клиенты ДРУГОГО банка делали такой объем операций. В общем - можно поздравить оба банка. Первого с такой сеткой, второго - с таким числом клиентов. Но я допускаю, что такие двое нашлись и они решили сэкономить, исключив из схемы платежную систему, чтобы не делиться комиссией. Ок, пусть будет, и пример реален.
Отдельный вопрос ко второму банку, которому ради комиссии в 1% (ну 2%, и то, это не точно) надо морозить на корсчете первого банка сумму в 100%, которая чисто на "коротких" операциях могла бы принести больше денег - но я не финансист, пусть будет схема реальной.
Опять же, я допускаю, что такое возможно, но меня гложут смутные сомнения, что Visa/Master делают точно также. Иначе чисто на остатках на корсчетах уже можно жить. Но так далеко нюансы карточного бизнеса я не копал, если вы знаете больше - буду рад если поделитесь инфой
---------------------------------------------
Вопрос первый. По логике. Какая б не была мощная молотилка, но если решать задачу в лоб, то у вас все транзакции стают в очередь. А дальше без вариантов, грубо говоря никакой паралелизм не возможен и рулит только тактовая частота проца.
Либо паралелизм возможен и тогда ... возвращаемся к кешам и прочим "ускорителям".
Отдельный вопрос, а зачем решать задачу "ровно в 0". Если у вас поток, в котором даже есть пики, это не мешает упростить схему в виде:
собирать такие операции в отдельном офлайн потоке
суммировать там по времени
применять одной суммой по корсчету
при снижении остатка на корсчете ниже минимума, который больше 0 - либо сразу заморозить, либо ну там и быть - перейти в режим "онлайн"
Но переход в режим "онлайн" не имеет смысла, так как скорее всего (если все так быстро), то через минуту условно деньги все равно закончатся и какая в общем-то разница. Пользователи будут получать отказ
Ну и понятно такой кор счет явно может быть вынесен отдельно от "основного" решения, так как таких партнеров явно немного.
------------
И про комиссию. Обычно никто этим не сношает мозг и в карточной части применяют "одной строкой". Потому что потом все равно карточный бек спокойно и без суеты "распедалит" что к чему. Тем более бывают крос валютные операции и т.д.
Но я приблизительно накидал, детального ТЗ и живого заказчика прередо мной нет :)
:-) Для информации... Китайский/индийский/<....> банк (даже не входящий в первую пятерку) делает внутри страны операций больше чем сбер у нас.
Варианты "отложенная проверка" или "не точная проверка" или "прогнозируемая проверка" конечно остаются всегда и являются возможными (хотя и "костыльными") решениями (ровно так же как и не online расчет комиссий), но мы то говорим о организации "прямой и в лоб" проверке через запросы/statemen в БД. И "вот тут" никакие "новомодные решения" работы с БД не работают, от слова совсем....
То что банки/финансисты считают считают комиссии по Online операциями "не в online" это не их желание... :-)
Я не думаю что вам понравится ситуация если вам "заблокируют" операции по карте в 1000 рублей если у вас еще доступно 10 000 (по причине "через минуту условно деньги все равно закончатся")....
К примеру одна минута при 1000 TPS - 60 000 операций - значит 60 000 "не обоснованных в принципе" отказов в обслуживании....
Для информации... Китайский/индийский/<....> банк (даже не входящий в первую пятерку) делает внутри страны операций больше чем сбер у нас.
Давайте запомним, что число операций не критично, пока не существует ОДНОГО счета, по которому их до фига. Просто много - вообще не проблема. Мы это уже выяснили ранее
Варианты "отложенная проверка" или "не точная проверка" или "прогнозируемая проверка" конечно остаются всегда и являются возможными (хотя и "костыльными") решениями (ровно так же как и не online расчет комиссий), но мы то говорим о организации "прямой и в лоб" проверке через запросы/statemen в БД. И "вот тут" никакие "новомодные решения" работы с БД не работают, от слова совсем....
Смотрите. Задача хорошего аритектора не "пробивать стены лбом". Для этого человечество придумало более узкоспециализированные решения, известные еще со времен Древней Греции. Задача архитектора показать, что есть разные опции и разная цена. И хорош тот, кто показал что можно "решать в лоб" за миллион, или обойти за 10 тысяч. Гордится тем, что мы "смогли" - несколько "туповато" :)
Я не думаю что вам понравится ситуация если вам "заблокируют" операции по карте в 1000 рублей если у вас еще доступно 10 000 (по причине "через минуту условно деньги все равно закончатся")....
В указанном мной примере с "рагульной" схемой и кор. счетом это не критично, так как банк эмитент "словит" поток отказов на мнуту позднее. Какая разница? Главное он их словит и получит по самое "не хочу" в карму от своих клиентов. Возможно после этого перейдет на нормальную. Вы же еще помните, я надеюсь, что в вашем примере банк эквайер авторизируте карточную операцию по двух счетам (клиента и кор счета банка)? И заканчиваются деньги именно на втором
И мне будет ОЧЕНЬ интересно узнать, как любая архитектура поможет ускорить задачу, если ее "программно" свели к очереди, где транзакции выполняются одна за одной? Я только могу представить "разогнать частоту камня". А вы?
Кстати поток операций можно сводить в кучу ДО авторизации. Условно, получаете два потока. Первый - все транзакции. Второй - поток к кор счету, которые на лету группируется в пакеты по однйо секунде. И вуаля. Имеем решение в "онлайн". И не надо покупать "динозавра" за много денег с extended поддержкой
И мне будет ОЧЕНЬ интересно узнать, как любая архитектура поможет ускорить задачу, если ее "программно" свели к очереди, где транзакции выполняются одна за одной?
Их не обязательно физически выполнять одна за одной, достаточно гарантировать эквивалентный этому результат. Если говорить про DB2, то последовательная обработка блокировок не означает последовательной обработки вызывающих эти блокировки запросов. Обычно в нагруженном кластере один сервер занимается чисто блокировками, остальные обработкой данных.
Акцентирую внимание: нагруженная OLTP система обрабатывает столько запросов, что только одна очередь блокировок от этих запросов зачастую требует производительности целого большого компьютера и является узким местом. А обработка самих запросов – это отдельное дело.
1. Правила настраивает не эмитент, а эквайер (который не готов терять средства), а это означает что банк эмитент "не получит" операции минимум за период максимального таймаута выделенного для авторизации собственного клиента именно банку эмитенту (обычно не более 10 сек). А 10 сек - это 50 000 операций.... Так что будут "страдать" именно клиенты чужого банка.
2. Операции по корсчету банка издателя банк эквайер может делать только после того как банк издатель их (на своей стороне) авторизует/одобрит по своим клиентам. Иначе "появляются вопросы" типа - "я отказал клиенту, а по корсчету операция прошла"....
3. Про варианты выбора я согласен с вами, но часто требования бизнеса могут быть довольно жесткие, и выбирают из многих вендоров того кто более им соответствует....
Но собственно вопрос то в "модных" решениях (очередной "серебряной пуле" которых уже много было) не решающих по факту "узких" мест OLTP производительности....
Мне кажется, либо мы обсуждаем с вами какой-то вымышленный пример с вашей подачи, ну честно ...
Visa / Master таким не страдают, насколько мне известно, так как банки в целом - это не фирмы однодневки и смысла устраивать боттлнеки на ровном месте нет. Проще сделать клиринг раз в сутки и взять свой процент. Даже если что-то где-то пойдет не так - на большом обороте это вообще все равно.
Если что-то идет нет так - открывается "диспут" и вопрос решается в его рамках. Это тоже происходит часто, так как на таком объеме любой редкий кейс будет происходить с завидной регулярностью.
В ващем примере эквайер изображает из себя платежную систему с собственными странными правилами
10 секунд - я стесняюсь спросить, а как же 3ds? Там несколько минут, а это де факто стандарт для интернет покупок
В любом случае, я потерялся. Если экваер дает добро на операцию по карте партнера эмитента, с которым прямой договор сначала блокируя сумму на "корсчете" - то если там нет денег, то какая разница, секундой раньше или позже остановится обслуживание клиентов банка партнера? Ну банк партнер не успеет же мгновенно среагировать? Ну и ... опять я не понимаю в чем выгода "рагульной" схемы, так как эмитент добровольно морозит огромную сумму за жалкий процент.
Мне кажется, это какой-до дикий кейс и он настрлько редкий, что мне проще согдаситься, чем пытаиься понять его логику. Тем более, авторизация не равна списанию от слова совсем, а только начадо истории. Строить такую сложную онлайн логику - это какая-то клиника. Тем более в стандартизованном мире карточных операций, где все описано и понятно.
:-) Для того чтобы понимать нужно быть "в теме"....
Не смущает же никого сейчас что банки "морозят" депозиты на расчетных счетах в VISA и MC. :-)
Те же VISA и MC имеют несколько "региональных" центров, замыкающих на себя межбанковский трафик региона и обменивающихся только "межрегиональным" трафиком (с учетом того что внутрибанковский Online трафик туда и не попадает). И у той же VISA в ее центрах стоит по десятку IBM P Series серверов (по крайней мере так было еще лет 10 назад).
Использование Single Message протоколов обмена (авторизация=финансовой операции), вместо Dual Message (где финансовые могут "приходить" и вообще без авторизации) все более актуально при дальнейшем развитии постоянной Online связи.
В середине 2000-х сбер начал (с большой "помпой") внедрять IBM P System (топовые на тот момент P795) в свои региональные центры (с разделением на front и back системы) и Греф "топил" за них, в середине 2010-х новые "эффективные менеджеры" (с новыми откатами) начали очередной виток "развития"...
Не смущает же никого сейчас что банки "морозят" депозиты на расчетных счетах в VISA и MC. :-)
А разве Visa/MasterCard устраиваюти "цирк" на стороне экваера?
Схема с "депозитом" не нова, но делать из него часть транзакционного механизма - зачем?
---------------
Лично я молотилки от IBM тоже застал 10+ лет назад, даже часть решений, где я был архитектором на них внедрял. Но в реальности, потом "железячники" переключились на блейды на x86. Для OLTP систем так точно, так как они отлично масштабируются горизонтально.
А большие "молотилки" - ну можно нарезать с помпой LPAR и типа эффективно юзать ядра. А потом возникают сайд-эффекты вроде лицензирования, необходимость нарезать пулі ядер под каждую отдельную технологи.
А стоимость высокая, AIX надо изучать отдельно, как и возможности гипервизора ....
:-) А чем принципиально "страховой депозит" издателя в VISA отличается от "страхового депозита" издателя в банке эквайере (или страхового депозита банка в платежной системе). И еще раз повторю, что не от "хорошей жизни" расчет комиссии и проверку баланса на "страховом депозите" делают не в Online (а в Offline или псевдо Online)... А потому что нет транзакционной технологии (включая БД и прочую технологическую обвязку) позволяющую делать это "без костылей"....
Ну смотрите
"Страховой депозит" по всей видимости отличается степенью разумности его использования :) Плюс я предполагаю, что для Visa/Mastercard большинство банков выступают как эмитент, так и экваер, поэтому из задача делать клиринг и возвращать/получать разницу :) В вашем кейсе, насколько я понял, дорога с односторонним движением
Давайте еще раз. Задача архитектора не решать задачу в лоб, а помогать заказчику найти оптимальное решение.
Ну зачем нужен депозит? Очеввидно для митигации риска неплатежа от банка партнера, который участвует в платежной системе. Т.е. финансово дело идет так
каждый день идут операции
в конце "операционного" дня надо подбить баланс и раздать участникам процесса кто сколько должен
в этом месте кто-то может отказаться от выполнения своих обязательств
В ответ можно забрать депозит и идти за остатком в суд. Но фишка в том, что это бывает не так часто. Ну реально.
Плюс есть история по каждому банку, средние обороты, маскимальные ...
Итого решение, которое не стоит почти ничего ничего, работает без каких либо сложностей, а edge cases типа "ты мне не заплатил" все равно потребуют ручного урегулирования
В то же время "онлайн" решение явно сложнее и дороже + есть риск получить массовые отказы в авторизации, которые не добавляют "удовлетворения" конечным клиентам. Вопрос - зачем?
Ну даже если найдется редиска и решит не платить. Депозит забрали, остальное покрыто тем, что было заработано до того. Плюс эта редиска получит такую "торпеду" в репутацию, что можно считать закончится на ровном месте. Плюс можно выбить через суд
---------------
Технически. Ну как бы видите это решение? Если вы отказываетесь от группировки, тогда вы получаете "очередь кающихся грешников", которые обрабатываются строго последовательно. Все, приехали. работает только тактовая частота проца. Ну потому что ПОСЛЕДОВАТЕЛЬНО. Все что тут ускоряет вопрос - это максимальное приближение к процу данных, т.е. кеш + способность движка базы это поддерживать. Базы уже давно умеют работать с часто используемыми данными в памяти без задрачивания медленных дисков. Дальше уже задача аппаратной архитектуры эту память "перенести" поближе к процу. Что тоже умеют уже все. Так как таких "ОБЩИХ" ячеек мало - требуется не очень много.
Допустим я размещу это в кеше в памяти (к примеру банальный Redis) с асинхронной репликацией (он вроде умеет). Получится и быстро, и с относительно разумным RPO. Либо другой кеш взять, тут за такой бюджет можно и свое решение написать :) В любом случае жить это все будет в памяти и довольно таки надежно.
Но это в общем, ясно что такое решение надо проектировать долго и внимательно
:-) В вашем понимании "последовательно" это как? В "понимании" банка издателя в последовательности его ответов одобрения на транзакционные запросы (и "по факту" это верно). Не важно что на 5000 транзакций посланных ему 5 секунд назад он не прислал ответа, важно что он уже ответил на 5000 транзакций отправленных ему секунду назад. И именно эта сумма может быть списана с его депозита и именно эти клиенты получат деньги в банкомате или оплатят заказ (сделают перевод) в интернет магазине банка эквайера. Вам логика понятна?
Не проблема сделать 20 000 операций в БД, проблема сделать их в соотвествии с заданной клиентом бизнес логикой. Конечно проще всего "подогнать" бизнес логику под "существующую технологию" и отвечать клиенту - "вот где карту получали - в то отделение и идите....". Аналогия вам надеюсь понятна?
А насчет "надежности" в памяти.... Чудес не бывает... Падают любые процессы и OS...
Что же касается "выбить через суд" и т.п. - если бы было "все просто и легко" никто бы и не стал "заморачиваться" с ACID и Online обработкой финансов в принципе (как впрочем и было лет 40 назад)... Чеки и кредитные карты в оффлайн тогда "рулили"...
Ну так все верно. Эмитент авторизовал операцию, и на эту сумму условно раз в секунду идет списание :)
Причем тут аналогии, которые не имеют отношения к вопросу? Равно как и отсылки к древним временам
Давайте проще, авторизует ли самостоятельно Виза/Мастер операции ориентируясь на сумму депозита банка эмитента? Если нет - вот стандарт отрасли :) Смысл гордится решением "тачка на квадратных колесах"?
Плюс я так и не понял, а вы не ответили, как мейнфрейм, или сервак на пауерах вам поможет в данном случае? Либо я могу заподозрить, что в вашем случае так и сделали (в смысле либо авторизуют оптом, либо вообще не парятся супер точностью)
Давайте свернем обсуждение edge case в карточном мире и упросит до деталей, как железки IBM помогают решать такие задачи. Я ведь не покупаю, а вы не продаете. Куда интереснее аполитично обсудить, чем архитектура IBM ких сервевор тут поможет
:-) "тачка на квадратных колесах" - это текущие и предлагаемые вами решения...
Собственно мой комент возник на ваше утверждение - "База куда эффективнее "разгоняется" стороними технологиями вроде кеша или noSQL или column-based. Если нет потребности "держаться" за реляционную алгебру, мир сразу становится шире"...
Проблема производительности текущих OLTP баз чаще всего не в скорости/объеме дисков и не в количестве CPU/ядер, а в эффективности CPU и скорости работы с памятью (поскольку блокировки на уровне блока), а в блоке памяти лежит достаточно много модифицируемых данных....
Ну как-то странно называть "тачкой на квадратных колесах" варианты решений, который допускают использование всех доступных решений на рынке баз данных.
Тут как раз "квадратные колеса" - это про использование того что есть, хотя уже изобрели круглые
Проблема производительности текущих OLTP баз чаще всего не в скорости/объеме дисков и не в количестве CPU/ядер, а в эффективности CPU и скорости работы с памятью (поскольку блокировки на уровне блока), а в блоке памяти лежит достаточно много модифицируемых данных...
А что такое "эффективность CPU"? Скорость работы с памятью - так кешей уже развелось, мама не горюй. Вы ж понимаете, что в вашем примере ячейка памяти с "балансом" маленькая и влезет в люболй кеш. А скорость обработки зависит только от таковой частоты, так как даже многопоточность не поможет.
В этом и проблема, что если архитектор допустил "очередь кающихся грешников", то вся система работает в один поток на частоте проца и быстрее аж никак. Ну просто никак, если уж такое допустили. А вот если паралелить, тогда вылезают особенности тех или иных архитектур, и вообще - куча вариантов.
Я вот не могу понять, вроде ж очевидно, по Вашим словам вы свели скорость работы системы к одному потому авторизаций по корсчету (понятно, транзакции по картам других банков счастливо миновала чаша сия). Понимаете - один поток никак не разгоняется кроме как таквовой частотой (ну еще иногда способностью проца делать "больше" операций за такт. А те же пауеры (раз уж вы P795 вспомнили), лениво проверять, но по памяти не такие уж и шустрые. Из прикол в том, что вы можете купить большую молотилку и рещать много задач на лету. Либо условно одну задачу типа большого расчета, которая отлично паралелиться. А на одном потоке она будет не быстрее условного рабочего лаптопа
Вопрос же простой, есть четкая постановка задачи, и она не параллелится. Ваши "архитектурные предложения" не решают поставленную задачу, и вместо этого вы предлагаете "разнообразные костыли". Да рабочие, но не решающие поставленную задачу. И проблема тут не в БД как таковой, а в архитектурых особенностях работы CPU (особенно многоядерных) с памятью как таковой. Кроме частоты CPU и памяти на уровне OS есть параметры влияющие как на время блокировки "захваченной на модификацию" области памяти одним процессом, так и на время через которое другой процесс OS пытается (после не успешного "захвата") "захватить на модификацию" эту же область памяти. На уровне приложения OS ПО (в частности различные БД) так же по разному реализуют работу в многопоточности и так же часто имеют "собственные" механизмы блокировки доступа....
То что "кешей много и разных" только усложняет (и даже замедляет) процедуры работы CPU с одной областью памяти (типа область в кеше на одном ядре, а модифицирует другое ядро и т.п.).
Вопрос же простой, есть четкая постановка задачи, и она не параллелится.
Про задачу мы уже обсудили выше. Задача ИТ, архитекторов, пояснять заказчику, что "стоит" то или иное требование :)
Кроме частоты CPU и памяти на уровне OS есть параметры влияющие как на время блокировки "захваченной на модификацию" области памяти одним процессом, так и на время через которое другой процесс OS пытается (после не успешного "захвата") "захватить на модификацию" эту же область памяти.
Если это все происходит в базе, то ничего такого не происходит. Причина проста и банальна. Вы "очередь кающихся грешников" тривиальным образом можете построить до базы, чтобы не перегружать ее движок лишними сессиями (зачем вам все это, если все равно задача в один поток), проверками наличия блокировки и т.д.
Раз вы не отбились от "бизнеса" и ему нужна однопоточная реализация и никак иначе - примите это как ваше "локальное поражение" и выстроите очередь как можно раньше. Тогда она будет выполняться максимально быстро, так как в этом ее основная задача. К примеру, у вас поток транзакций, неважно где. Пусть будет кафка. Выбираете транзакции чудо-партнера с такой схемой и обрабатываете отдельно строго последовательно. Все. Этот поток отлично работает на максимально быстром CPU в своей "песочнице" и никому больше не мешает. Можно даже отдельную "молотилку" выделить, все равно на одном потоке.
Базе тоже прекрасно. У нее "кающихся грешников" обрабатывает одна сессия, никто вперед не лезет, блокировку не спрашивает. Все максимально быстро и без лишнего перерасхода энергии. Но я бы все равно балан такого банка попробовал положить в условный редис, если он даст больше скорости (а обычно он мега быстрый)
Вы просто реально "не в теме", мое описание процесса содержит хорошо если 10% бизнес условий (скажем так "самое узкое место").
Очень сильно напоминает ajile подход - " Видим путь в тумане только на 5 метров в одном направлении, но все равно бежим туда, может и добежим в конечную точку, а может нет..."
Вы же как "архитектор" не разбираясь до конца в сути уже начинаете предлагать конкретные решения. :-)
Почему именно kafka, почему именно redis? "Стильно, модно, молодежно?" Как то блокчейна не хватает и IA... :-)
Что значит "строго последовательно" 10 операций поступили извне в одну и ту же милисекунду, где тут последовательность? "Последовательность транзакций/операций" может только на уровне БД или единой очереди "возникнуть"....
И еще раз - последовательность поступления карточных операций по времени <> последовательности взаимодействия этих операций с балансом единого счета + между временем поступления карточной операции и временем ее взаимодействия с балансом единого счета может пройти до 10 секунд.
Опять же очень сильно упрощенно, по основным шагам и при положительных проверках, в одной БД транзакции получаем -
Внешний входящий запрос на карточную операцию в БД (по сути insert операции).
Проверка единого баланса издателя на допустимость операции к исполнению (по сути select баланса)
Отправка запроса на одобрение издателю карт (по сути update операции)
Проверка таймаута ответа (10 секунд)
Получение авторизации/одобрения издателем (по сути update операции)
Дебетование единого баланса издателя карты (по сути update баланса)
Положительный ответ на внешний входящий карточный запрос
Получение подтверждения что ответ получен внешним источником операции (по сути update операции)
Каждый "шаг" по пути обработки по сути "добавляет" новую информацию к первоначальному карточному запросу. И так можно сделать в нужном количестве потоков получения карточных операций (поскольку поступают они на множество сетевых портов). И последовательностью и целостностью действий/информации в этом случае "рулит" БД (это гарантирующая составляющая обработки данных). "Падает" один процесс - остальные работают, целостность информации всегда есть. Еще часто этот процесс "разбивают" на 2 "короткие" транзакции в БД (1-3 и 5-8) + очередь в БД на 4 шаге. Что-то более оптимального насколько мне известно не придумали....
Ваши "идеи" -
последовательность входящей очереди обработки организовывать самостоятельно (kafka или redis) (один процесс/поток не сможет)
Проверка баланса (из базы)?
Отправка запроса на одобрение издателю карт (видимо по порядку очереди поступления?) Каким образом фиксировать выполнение этой операции? Еще одна очередь?
Проверка таймаута ответа (10 секунд)
Получение авторизации/одобрения издателем (видимо еще одна отдельная очередь со своим порядком?)
Дебетование единого баланса издателя карты (видимо периодическое в БД, по сумме операций из очереди выше?)
Положительный ответ на внешний входящий карточный запрос. Еще одна очередь? Ее порядок?
Получение подтверждения что ответ получен внешним источником операции
Запись всей информации по операции в БД. Где взять "всю информацию"? Из всех очередей выше? Или "перекладывать" ее из очереди в очередь?
Что делать при проблемах/тормозах в любой из очередей? Дублировать + контролировать "вручную" (дополнительным процессом) и обрабатывать все возможные ситуации? Именно это вы называете оптимальной "архитектурой"?
Ну смотрите
Во-первых, как я писал выше, меня смущает 10 секунд. 3DS встал и вышел? Или схема только для физических POS-терминалов. Если второе - ОК. Если первое - мдя, это все что я могу сказать цензурное, как пользователь, у которого забрали 3DS, который меня оберегает.
Дальше у вас стандартная дилема, которая возникает при авторизации в двух источниках операции, один из которых имеет право тупить. Она банальна и проста. В шаге 2 вы предварительно убедились, что денег хватает в источнике "корсчет". Через 10 секунд приехал "одобрямс от источника "эмитент", но денег уже нет. В итоге пишем источнику эмитент - спасибо, но нет. Вертай назад :)
Проблема логически нерешаемая, так как всегда есть кейс, который создат rollback на ровном месте. Вы можете либо блокировать сумму сразу на "корсчете" на шаге 2, но тогда будете ловить rollbaсk, если операцию не авторизовал "эмитент". Либо ждать авторизации "эмитента", но тогда ловите rollback на "корсчете". Сорян, тут без варианов. Самое смешное, что вообще по фиг. Можно вообще делать полный ассинхрон со сборкой в конце результатов, но результат такой же.
Что еще более смешное, в кейсе когда, на корсчете вот прмя сейчас закончились деньги, в худшем случае ваше решение 10 секунд "замучает" сторону "эмитента" запросами на авторизацию, которые потом придется отменять :) Потому что авторизация по "корсчет" проходит через 10 секундю И пока на шаге 2 были деньги, к шагу 6 деньги закончились :) Но это такое - по ходу, над эмитентом в вашей схеме можно издеваться в любой форме
----------------------------
По вашему алгоритму БД максимально мучается шагами 2,6, так как по условно "корсчету" все время идут транзакции изменения (привет блокировки и "очередь кающихся грешников", которая реализована дорогой "базой"). Ну и все равно шаг 7 уже делается строго последовательно, так как перед ним есть шаг 6.
Я бы рассмотрел возможность однопоточно делать шаг 2 сразу с авторизацией на стороне "корсчета". Все равно, если денег нет - смысл дальше мучать эмитента? (да, есть edge case, если какая-то операция, которая не пройдет авторизацию на стороне эмитента и "вернет" свою сумму на "корсчет", но - ну тогда эта сумма какой-то операцией да и будет использована). Итого, все транзакции сначала списывают средства с корсчета (можно в редисе, так как он скорее всего будет быстрее,либо в другом решении, которое на тестах даст максимальную скорострельность в один поток при необходимом уровне RTO/RPO), а потом максимально многопоточно авторизируемся на стороне "эмитента", так как это его уже забота, как делать быстрым свой сервис. Если все ОК, шаг 6 не нужен (а это 99.999 кейсов - т.е. мы уже сэкономили тонну ресурсов, не благодарите). Если не Ок, ну ладно - вернули сумму на корсчет назад.
Как делать распределенные транзакции надежно и нарисовать под это надежное решение - написано тонна книг, статей и страниц в инете. В любоим случае эта проблема и так у вас есть, так как эмитент явно не в той же базе пасется.
Если очень хотите заморочиться, можете на шаге "2" делать условно "авторизацию" (аля блокировка по карточному счету, ну вы по ходу в курсе), а потом асинхронно, после шага 7 - ее подтерждать. Это уже чисто вкусовщина и по сути игра словами.
3DS - это не про финансы... Это тупо проверка что "клиент реально твой" и идет "на стороне издателя". Ее результат тупо "пристегивается" к запросу операции.
:-) Если все "в одной транзакции" - БД рулит корректным состоянием данных. На 2 шаге проверяется что текущий баланс минус сумма самой операции более 0. И поскольку последовательный "порядок" операций контролируется БД (а "по другому" ни одна ACID БД не работает), то все будет OK нужная сумма "будет всегда" и "отрицательный" ответ авторизации не изменит баланс. Учите теорию баз. "Проблемы" возникают только с блокировками в данном случае.
А вот вариант "уменьшить" блокировки путем "деления" на две транзакции - и приводит к описанным вами "проблемам" - через 10 секунд "порядок" исполнения меняется (баланс м.б. не таким как при первой транзакции проверки баланса). И вот тут реально и начинается "отдельная песня". С дополнительными "искусственными" транзакциями/операциями отмены/корректировки и т.п.
Читайте свои "тонны книг", но согласно математике 2+2 равно 4, а не "5 если продаем и 3 если покупаем" - как вы предлагаете. :-) Любые "авторизации" + "подтверждения" еще более нагружают и усложняют систему. Любые взаимодействия с "внешними" сервисами/"прокладками" увеличивают время "блокировки" или меняют "исходный" порядок операций.
И мы пока еще даже "не касались" "проблем устойчивости и надежности" всей системы "в целом"... :-)
3DS - это не про финансы... Это тупо проверка что "клиент реально твой" и идет "на стороне издателя". Ее результат тупо "пристегивается" к запросу операции.
Это про Вашу задачу :) В процесс авторизацию транзакции на стороне эмитента это входит (и вообще, если много доругих опций авторизации), но в 10 секкунд это точно не пролезет. Поэтьому мне это сразу бросилось в глаза.
На 2 шаге проверяется что текущий баланс минус сумма самой операции более 0. И поскольку последовательный "порядок" операций контролируется БД (а "по другому" ни одна ACID БД не работает), то все будет OK нужная сумма "будет всегда" и "отрицательный" ответ
Если вы делаете просто SELECT, а не SELECT FOR UPDATE - то нет :) А если вы делаете SELECT FOR UPDATE - то вы его не делаете, так как он лочит row на 10 секунд между шагами 2 и 6 :)
Просто проверьте на условном Oracle или DB2 при уровне изоляции по умолчанию :)
Еще раз... 3DS проверка - отдельная процедура и не имеет отношения к обработке карточной операции. Точнее имеет (поскольку использует параметры карточной) но выполняется "независимо" и завершается до процесса авторизации (а вот он уже использует ее данные).
Если в транзакции вы используете select for update то - блокировка длится до commit/rollback. Причем тут 10 секунд? 10 секунд это допустимый максимум ответа, а не постоянная величина....
Лочится не "строка" - а "блок данных" (там и N строк м.б.) причем в памяти...
Впрочем от IBM и ее технологий мы уже "ушли далеко". Но... Только на IBM P тот же Oracle без "пауз в работе БД" ("провалов" TPS) позволял менять количество доступных OS виртуальных ядер (ни одна платформа этого не позволяет) и только IBM динамически может перераспределять общие/единые ресурсы между виртуальными машинами.
Еще раз... 3DS проверка - отдельная процедура и не имеет отношения к обработке карточной операции. Точнее имеет (поскольку использует параметры карточной) но выполняется "независимо" и завершается до процесса авторизации (а вот он уже использует ее данные).
В вашем алгоритме, которые выше, это шаг "Получение авторизации/одобрения издателем (по сути update операции)". Проверка 3DS может являеться частью этого шага, либо как я писал, по вашей схеме не ходят операции от Интернет торговцев. Либо вы сознательно пошли на упрощение схемы (пользователи такое не любят, если думают о безопасности). Я вообще начинаю подозревать, что эта схема вообще возможна для двух банков, связанных особой связью вроде общего процессинга :)
Если в транзакции вы используете select for update то - блокировка длится до commit/rollback. Причем тут 10 секунд? 10 секунд это допустимый максимум ответа, а не постоянная величина....
Ну смотрите, в вашем алгоритме "Шаг 2: Проверка единого баланса издателя на допустимость операции к исполнению (по сути select баланса)". По сути он бесполезный, так как реальное изменение баланса происходит в шаге 6 "Дебетование единого баланса издателя карты (по сути update баланса)", между которыми 10 может быть до 10 секунд за счет шага 4 :) Соответствено варианты:
алгоритм делает избыточный шаг 2, так как к шагу 6 значение баланса эмитента может поменяться очень и очень сильнго (мы же помним про изначальные 5000 операций в секунду, что нам дает до 50000 тысяч операций между шагами 2 и 6). Поэтому шаг 6 сразу вместо 2 выглядит логично и просто
алгоритм может делать на шаге 2 select for update, тогда это имеет смысл логически, но все встанет, так как row lock будет длиться с шага 2 по шаг 6, а это до 10 секунд
Игры с уровнем изоляции скорее всего ничего не дадут :)
Лочится не "строка" - а "блок данных" (там и N строк м.б.) причем в памяти...
Я боюсь спросить, какой движок вы испрользуете :) Если Oracle, то вам сюда и рядом: https://docs.oracle.com/en/database/oracle/oracle-database/12.2/cncpt/data-concurrency-and-consistency.html#GUID-1D60EFCC-03F4-4A04-B099-1B4DE5D02C47. Лочится строка, иногда не только - но это скорее в силу рагульности структуры, чем "так надо". Также там все про "как это обойти, если очень надо".
И я думаю, что все нормальные движки так работают, так как зачем одной сессии ловить "ожидание", если другая меняет соседнюю строку? Тем более, "под капотом" помимо лока все равно надо делать shapshot старого варианта строки
Впрочем от IBM и ее технологий мы уже "ушли далеко". Но... Только на IBM P тот же Oracle без "пауз в работе БД" ("провалов" TPS) позволял менять количество доступных OS виртуальных ядер (ни одна платформа этого не позволяет) и только IBM динамически может перераспределять общие/единые ресурсы между виртуальными машинами.
Ну такое. Ну добили вы ядер конкретному LPAR. Так они для этого должны быть свободны в пуле, где он есть, значит они и так у вас были. Память вы не добавите, а часто это связано. Т.е. играться ядрами вы можете, а память надо нарезать по максимуму изначально. Дальше есть нюанс лицензирования. Если вы взяли (тут по памяти, сейчас может уже не так) опцию лицензирования Оракла по ядрам, то вам надо лицензировать все ядра пула. Т.е. даже если они пиковые - надо платить за них все время, даже если вы их используете два раза в год. Т.е. опция хорошая, но не для бедных. Плюс тогда оптимально шарить эти ресурсы вам желаться с другими базами, чтобы не переплачивать за лицензии. А они миогут быть тоже заняты
С учетом цены и скидок Оракла (опять же, когда я этим занимался) от типа проца, возможгно решение на обычных "молотилках" выйдет по деньгам куда интереснее. А если брать современника P795 условную экзаадату (видел того на картинках, но тем не менее), то смысл селить oracle на P795 и нее варианты пропадает от слова совсем. Разве что она уже есть, и тогда ее надо применить, чтобы не выбрасывать. Либо в этот раз звезды сошлись так, что вам при покупке IBM зашел лучше (обычно просто занесли, но это действительно не про технические моменты)
1) "Проверка 3DS может является частью этого шага" - не является... 3DS проверка это опциональный шаг выполняемый до авторизации.
2) "между которыми 10 может быть до 10 секунд" - именно может, а не всегда проходит (по факту "в среднем" 1,5 секунды отдельные пики до 2, 2-10 только штучные на периоде в сутки).
3) "иногда не только" - всегда поскольку это принцип работы OS с памятью на любых платформах.
4) На LPAR вы динамически (и даже автоматически на уровне виртуализации) можете "распределить" все ресурсы (и CPU и память и IO). На других платформах "в ручную" так же (HP,Oracle). Но только IBM это делает без "фриза" всей OS (и ее процессов) под нагрузкой на момент изменения количества CPU и RAM. Тесты были на всем (включая Exadata, HP UX и т.п. решениях). Если есть у вас возможность проверить - можете убедиться. :-)
Что касаемо Exadata то для прикладных OLTP систем она "особо" не лучше любых навороченных Enterprise систем. Единственное ее неоспоримое преимущество - один вендор при использовании Oracle DB.
1) "Проверка 3DS может является частью этого шага" - не является... 3DS проверка это опциональный шаг выполняемый до авторизации.
Ну ОК, в целом да, вы добавляете это как параметр в финальном запросе, который был получен ранее "торговцем", тут я скорее всего попутал :)
2) "между которыми 10 может быть до 10 секунд" - именно может, а не всегда проходит (по факту "в среднем" 1,5 секунды отдельные пики до 2, 2-10 только штучные на периоде в сутки).
Ну одна секунда, какая разница? За одну секунду пролезет 5000 запросов. Какой смысл делать шаг 2 (запрос), если до выполнения шага 6 еще выполнится 5000 транзакций и баланс изменится?
И по прежнему надо держать в голове, что шаг 6 все равно делается однопоточно, а для навороченного движка это дорогая "операция", если сравнивать с другими технологиями
На LPAR вы динамически (и даже автоматически на уровне виртуализации) можете "распределить" все ресурсы (и CPU и память и IO). На других платформах "в ручную" так же (HP,Oracle). Но только IBM это делает без "фриза" всей OS (и ее процессов) под нагрузкой на момент изменения количества CPU и RAM. Тесты были на всем (включая Exadata, HP UX и т.п. решениях). Если есть у вас возможность проверить - можете убедиться. :-)
Я это знаю. Я про другое. Для критической системы это не нужно, так как ей проще сразу выдать все и не играть в "виртуализацию". Потому что иначе, если она требует сейчас и много, то значит либо до того ядра простаивали, либо другая система встала и вышла. Про память я тут не уверен, если честно.
Суть в том, что за цену P795 можно набрать раза в три больше ресурсов на условной х86
Это все было актуально лет 10 назад. Дальше приложения завернулись в контейнеры и отлично масшабируются на любом железе. А базе проще либо нарезать сразу все (если мы такие супер критикал), либо снять с нее нагрузку / выровнять, чтобы не делаеть из нее узкое место, с которым надо героически бороться за много денег
Что касаемо Exadata то для прикладных OLTP систем она "особо" не лучше любых навороченных Enterprise систем. Единственное ее неоспоримое преимущество - один вендор при использовании Oracle DB.
Она будет лучше ценой, так как лицензии Оракла на ней будут стоить намного дешевле за ядро. Если у вас конечно Оракл. Если условная DB2 - то тогда конечно нет. Так как Оракл недешев даже с корпоративными скидаками - это тоже фактор
Да-уж... DML транзакции БД выполняются всегда "последовательно" (см. SCN).
:-) "Набирайте" сколько хотите пока не случится такое - https://habr.com/ru/news/800851/
У вас в контейнере БД работает? :-)
"Я не настолько богатый, чтобы покупать дешевые решения..." :-)
Да-уж... DML транзакции БД выполняются всегда "последовательно" (см. SCN).
Если вы меняете ОДНУ строку - то да :) Шаг 6 в данном случае выстраивает "очередь кающихся грешников" для всех транзакций по одному эмитенту.
Мы ж с ЭТОГО начали. Если строк, которые меняются МНОГО - от отлично работает шардинг/партиционирование - и того большая молотилка нужна для большого отката. В вот если нет - тогда мы как раз и разбираем пример изменений по одному счету :)
У вас в контейнере БД работает? :-)
Я могу только еще раз приложить написанное :)
Это все было актуально лет 10 назад. Дальше приложения завернулись в контейнеры и отлично масшабируются на любом железе. А базе проще либо нарезать сразу все (если мы такие супер критикал), либо снять с нее нагрузку / выровнять, чтобы не делаеть из нее узкое место, с которым надо героически бороться за много денег
Я думаю, очевидно, что крутится в контейнере, а что - нет.
"Я думаю, очевидно, что крутится в контейнере, а что - нет." - я тоже... :-)
И не очень понял как контейнеры относятся к нашему предмету обсуждения - "работы OLTP БД"....
Что касается "нарезать" сразу - то пару раз в году (на праздники) нагрузка на БД и приложение раза в 3 выше чем остальные 360 дней. Будете "резать" с этим учетом? А под StandBy и DRS еще "нарезать" (с учетом что StandBy без нагрузки раза в 2-3 требует меньше ресурсов)? Очень экономно... А под пару периодических нагрузочных тестовых систем (плюс с десяток под функциональные тесты) - еще ресурсов "заранее нарезать"? Я уж про межкластерные сетевые требования и задержки (при отсутствии специализированных шин обмена) и не говорю... :-)
И не очень понял как контейнеры относятся к нашему предмету обсуждения - "работы OLTP БД"....
Они относятся к теме мейнфреймов, больших железок, которые умеют динамически "выдавать/забирать" ядра. Раньше, когда виртуализация была основным и почти единственным способом scaling и не только, мир жестянок рулился самими дестянками и производителями средств вирутализации. И тогда возможность купить большую "молотилку" с крутым безопасным гипервизором была просто необходимостью для больших корпораций. Безопасность тоже кстати была очень важна, как и уязвимости. Тут POWER'ы давали всем 100 очков вперед, ну или почти всем
Но, с появлением контейнеров, практических реализаций map-reduce потребность в таких мостнрах стала стремительно сокращаться либо ушла в клауд "под низ".
Но это касается приложений. Базы данных пошли по другому пути, так как они крайне плохо скейляться горизионтально на лету (почти все). Появлись много noSQL решений, которые в обмен на рпотерю "крутой" транзакционности дали скорострельность, гибкость и все такое. Соответственно в части баз вместо универсального решения: берем ORacle + молотилку побольше, появилось много-много альтернатив, которые в том числе снова не требуют больших дорогих "молотилок".
Поэтому к конкретному примеру - нет, а к теме, где мы общаемся - очень даже
Что касается "нарезать" сразу - то пару раз в году (на праздники) нагрузка на БД и приложение раза в 3 выше чем остальные 360 дней. Будете "резать" с этим учетом?
Ну чуда ж нет. Если ядра нужны на пике - они должны быть :) дальше две опции - они просто не используются, либо их надо у кого-то временно забрать. А они как в анекдоте
Париж. Ресторан.
Официант подходит к девушке:
– Мадам, что желаете?
– Я бы хотела то, что ест вон тот мужчина.
– Мадам, боюсь это невозможно.
– Почему?
– Он не отдаст
Я уж про межкластерные сетевые требования и задержки (при отсутствии специализированных шин обмена) и не говорю... :-)
В вашем случае вынесение "общего" баланса в отдельную сущность решает все эти проблемы :)
Я ж сразу писал, базу можно и нужно резать. Иногда - по сервисам и доменам. Единый баланс с мега частыми update - на Redis или любой другой более быстрый аналог
Тут главное - не надо создавать монстра, и не надо им решать задачи в лоб.
Поэтому в этом случае вообще все будет летать и жить на найдешевейших х86, тем более там часто однопоточная задача будет даже быстрее, так как они разгоняются куда лучше
Все эти сложности - исключительно следствие использование дорогих и устаревших решений, которые потом ими же героично и решаются :)
Даже можно не трогать базу, а сделать отдельное решение по авторизации "на стороне экваера", которое будет происходить до авторизации "на стороне эмитента". Как минимум по той последовательности что вы написали
"Появлись много noSQL решений, которые в обмен на рпотерю "крутой" транзакционности дали скорострельность, гибкость и все такое." - именно "все такое" но не ACID....
Тут "главный критерий", а кто будет "расплачиваться" при "потере" нескольких млн. $ + репутации, когда "замечательные" решения "потеряют" финансовые транзакции? :-) Опять видны "уши" agile - "будем решать проблемы по мере их поступления"
У людей постоянно занимающихся тестами на производительность и устойчивость высокопроизводительных технологических OLTP решений (включая кластеризацию, виртуализацию, контейнеризацию, шардирование баз на разных уровнях) - "есть другое мнение", чем у "теоретиков" начитавшихся маркетинговой чуши.
"Появлись много noSQL решений, которые в обмен на рпотерю "крутой" транзакционности дали скорострельность, гибкость и все такое." - именно "все такое" но не ACID....
Да дался вам тот ACID :) Тем более он все равно как недостижимый идеал :)
Тут "главный критерий", а кто будет "расплачиваться" при "потере" нескольких млн. $ + репутации, когда "замечательные" решения "потеряют" финансовые транзакции? :-)
Да никто не будет, просто да - лет 15 назад, даже 10 я тоже был наверное такой. Но это проходит с опытом внедрения других решений.
Просто я могу сравнить как работают разные решения, а не только большие и дорогие из 90х.
Вы даже себе не можете представить. какой это был глоток свежего воздуха, когда ты вырываешься их затхлой среды банковских решений, а потом снова возвращаешгься туда, но уже напитавшись более-менее современными решениями
Опять видны "уши" agile - "будем решать проблемы по мере их поступления"
А чего тут решать, тот же редис выдает 10ки тысяч операций записи в секунду и относительно несложно растягивается в кластер
У людей постоянно занимающихся тестами на производительность и устойчивость высокопроизводительных технологических OLTP решений (включая кластеризацию, виртуализацию, контейнеризацию, шардирование баз на разных уровнях) - "есть другое мнение", чем у "теоретиков" начитавшихся маркетинговой чуши.
Мне приходилось в составе большого банка проходить разніе тесты своих решений на все перечисленное, включая полный отказ сайта :)
Это не уникальный опыт :)
Просто не всем дают 100500 мильонов денег :) А делать надо :)
:-) У каждого свой реальный опыт и кругозор... Отказ "сайта банка" несет "немного" другие последствия, чем отказ центрального процессинга целой страны или платежной системы банка с 50 млн. активных клиентов и гигантской эквайринговой сети...
Ну такое ... эпичность и важность задачи еще не повод создавать "bottleneck" либо хаять все, что стоит меньше условного миллиона как несостоятельное решение :) И уже тем более говорить, что это единственно возможное :)
А уж использовать это как аргумент ...
В реальности я видел, как косячат люди которые сидят на таких же "важных" решениях, разница только в "апломбе". Косяки же те же самые.
в реальности в железе IBM уже давно все проспали, в софте еще не все, но почти
Дело в том, что американская система занятости в 2020 году всё ещё зависела от COBOL (сейчас ситуация несколько поменялась). И после того как из-за пандемии выросло количество безработных, инфраструктура не выдержала возросшей нагрузки. В итоге всё пришлось спешно чинить, приглашая существующих специалистов по COBOL
Недавно тут была статья, где писали, что в условиях повышенной нагрузки эти системы на COBOL работали без проблем, как часы. Нагрузки не выдержали и легли веб-сервера и другие модные-стильные-молодёжные обёртки вокруг COBOLа.
Сталкивался с ситуацией, когда спецов по майнфремам искали из омерик и лондонов на просторах России, и даже такие нашлись. Старые , замшелые, диабетики и вообще с ожирением, но не пугающиеся больших стоек и дисководов под 40 кг. ;-)
Да и в РФ есть конторы по прежнему , где не трогают "что работает".
COBOL и DIBOL за океаном ещё в ходу, есть спрос. В общем то что мейнфреймы ещё живут - хороший знак, что инженерия не вся ещё пошла в винтель и линьюх-вей.
IBM продолжает выпускать и поддерживать мэйнфреймы. Кто с ними до сих пор работает и где брать специалистов?