Айтишники на пенсии

[zVlad]

АццкоМото, на прошлой неделе я был в Крыму, четыре дня, и каждый день ходил по маршрутам. Один из них со смотровой площадки в Ласпи через Куш-Кая, мыс Айя, по средней полке до Балаклавы. Больше 20 км. Хочешь, в следущем году пройдем этот маршрут вместе? Или слазаем на Ай-Петри по Таракташской тропе, по которой я ходил в прошлом году? Я там чуть не сдох, на самом деле.
Никто не знает когда покинет этот, в общем то неплохой мир, дай нам всем, и тебе, АццкоМото, лично бог здоровья и долгих лет жизни. Я приношу свои извинения за мой вчерашний резкий ответ, я всю ночь сожалел об этом, но это надо быть идиотом чтобы додуматься написать: "Остаётся дождаться, когда последний зВлад умрет от старости.". То что ты лет на десять младше меня вовсе не означает что ты дождешься моей смерти. Мне тебя жалко, и я тебя прощаю.

[Mark]

...Oracle Database is licensed separately. Refer to Oracle Database Licensing Information for additional information.

У нас тут интресная дискуссия намечается - правда совсем не по теме топика Похоже нам пора в отдельную тему Может модераторы нас отделят? а то как то в пенсионерах не охота тусоваться
Теперь возвращаясь к Exa и лицензиям, вторым (после performance) selling point в Exa pre-sales training стоит license consolidation (я как раз сдавал тест не так давно:)). Т.е. когда продается Exa, то клиенту пропихиваются и лизензии на базу (в 90% случаев) и old agreements пересматриваются (и во многих случаях канселятся). Из моего недавнего опыта, все что quarter-rack и выше продается вместе с лицензиями на базу (причем чем больше rack, тем выше дискаунт) - для многих CIO, license consolidation savings так же или даже более важно чем перформанс.
Про Exa on Sparc - увидим как оно пойдет - сейчас пока рано говорить, но опять же все таки key performance factor on Exa это storage cells а не compute nodes. Попробуйте подключить ZFS к infiniband и перенести базу туда - вроде 40Gbps и в обычных условиях на commodity hardware вполне себе нормально, но по сравнению с Exa storage cells - "совсем не айс"...

[mskmel]

А WLM используется не для того чтобы "потребитель не прибил", а для того чтобы у каждого потребителя была достигнута та цель (response time, пропускная способность) и качество услуги о которой была договоренность в SLA. Почуствуйте разницу.

Всё верно, но с одной оговоркой "В условии нехватки ресурсов." А их достаточно.

Вы используете потому что у Вас есть смешанная нагрузка на отдельный сервер. Но задавать как таргет responce time, например, Вы не можете.

Цифры были приведены выше, я работаю в той же индустрии. Более свежие паблик цифры: "We can more quickly process 65 billion daily transactions for data charging, while providing real-time information for customer inquiries, increasing customer satisfaction, and reducing costs.” SK Telecom
То что делается распределенными системами (в данном случае 24 nodes cluster) - полностью набитый мейнфрейм не потянет, даже исходя из маркетинговых "транзакций в секунду" заявленных самим IBM (z13 3.5млрд маркетинговых vs 65 млрд реальных). На одну систему data charging, для оператора средней руки, надо почти 20 полностью набитых МФ + DR + Sand pit. 20МФ=20 стоек это без системы хранения (СХД), которая тоже места займёт не меньше

Вычислительные ресурсы для 24 nodes cluster, включая несколько ПБ места, стоят примерно 2.5млн и займут 3 стойки. Можно ли купить 20 полностью забитых z13 за эти деньги? То что их на место 3х стоек не поставить я и так понимаю.

P.S. Добавление ресурсов (серверов) это не только новые сервера

LPAR\vPar и прочие vXXX имеются не только на zOS. Так что не всегда больше ресурсов = больше серверов. Хотя согласен, доступность ресурсов - развращает. С другой стороны не надо иметь отдельных людей настраивающих еще и ресурс менеджеры на бедном на ресурсы железе. Люди, как Вы выше посчитали, тоже стоят дорого. Особенно те кто и ресурс менеджер поймёт, и что приложения делают.

Большие дата центры стоят десятки, сотни млн. денег. Т.е. в этом плане, стоимости, распределенные системы давно уже обогнали системы на МФ.

Цифры по консолидации самим IBM были - меняется стойка на стойку, так что для обеспечения одинакового сервиса надо одинаковое количество квадратных метров в ДЦ. Но в стойку х86 влазит сильно больше памяти, что критично и для задач типа БД, и традиционных полчищь jvm. Windows\Linux патчики ставить людей можно нанять здесь и сразу, часто совсем не дорого, а на МФ надо рыть по всему миру. Потом холить и лелеять, чтобы не сбежали.

[mskmel]

Теперь возвращаясь к Exa и лицензиям, вторым (после performance) selling point в Exa pre-sales training стоит license consolidation (я как раз сдавал тест не так давно:)). Т.е. когда продается Exa, то клиенту пропихиваются и лизензии на базу (в 90% случаев) и old agreements пересматриваются (и во многих случаях канселятся).

Я эту кухню частично знаю, даже с дуру проходил курс на эту тему, но он был для клиентов, так что врать могли безбожно
Exa SL6 - посмотрим, закинул удочки "пощущать". X6-8 не хочется, X6-2 вроде как мало ядрышек

[zVlad]

....
Цифры были приведены выше, я работаю в той же индустрии. Более свежие паблик цифры: "We can more quickly process 65 billion daily transactions for data charging, while providing real-time information for customer inquiries, increasing customer satisfaction, and reducing costs.” SK Telecom
То что делается распределенными системами (в данном случае 24 nodes cluster) - полностью набитый мейнфрейм не потянет, даже исходя из маркетинговых "транзакций в секунду" заявленных самим IBM (z13 3.5млрд маркетинговых vs 65 млрд реальных). На одну систему data charging, для оператора средней руки, надо почти 20 полностью набитых МФ + DR + Sand pit. 20МФ=20 стоек это без системы хранения (СХД), которая тоже места займёт не меньше

Вычислительные ресурсы для 24 nodes cluster, включая несколько ПБ места, стоят примерно 2.5млн и займут 3 стойки. Можно ли купить 20 полностью забитых z13 за эти деньги? То что их на место 3х стоек не поставить я и так понимаю.

....

Эти Ваши расчеты слишком упрощены и слишком условные. Вы берете 3.5 млрд/day одних транзакций и сравниваете их с 65 млрд./day совершенно других. Хуже всего Вы продолжаете рассматривать МФ как обычный сервер. А это далеко не так.

Тем не менее я не стану утверждать что в Вашем приложении МФ уместен. Такие вещи надо анализоравать не на форумe по принципу кто шустрее и ловчее манипулирует цифрами, а более основательно со всеми релевантными и адекватными данными, пробами и т.п..

Ну и чтобы закончить напомню (если Вы знали, но забыли) IBM уже давно уже поставляет zEnterprise это когда МФ работает в одной упряжке с блэйд центрами на x86 или Power оптимально распределяя работу. В этом случае workload выполняется там где ее лучше выполнять, в зависимости от характеристик нагрузки: на МФ или на блэйдах.

[mskmel]

Эти Ваши расчеты слишком упрощены и слишком условные. Вы берете 3.5 млрд/day одних транзакций и сравниваете их с 65 млрд./day совершенно других.

Беру единственно известные цифры от ИБМ, других цифр увы нет, максимально оптимально названные маркетологами. В реальных транзакциях rating and charging будут более скромные цифры думаю.

"100-200 МФ в принципе не нужно ни одному бизнесу, точнее нет такого бизнеса которому бы понабилось столько МФ, нет такой нагрузки вычислительной." (с)

То что у вас нет, или вы не видели, десятков ТБ сырых данных обрабатываемых ежденевно, это не значит что другим безнесам не надо это обрабатывать. Каждая транзакция это денежка, пусть немного центов, но денежка. Один data charging, а это только часть задач, потенциально съест 40-50МФ.

Я давно не работаю в High-Frequency Trading, там объемы поменьше конечно, но тоже много. Только на одну из подзадач для торговли на London Stock Exchange было 6 (шесть) Fujitsu Primepower 2500 о 128 головах каждый, которые отнюдь не простаивали.

Хуже всего Вы продолжаете рассматривать МФ как обычный сервер. А это далеко не так.

Это необычный сервер, но с обычными ТТХ виде количества ядер, TB RAM и т.п., которые транслируются в SPECjbb, SPECintrate, TPS, etc Да сопроцессоры, да ресурс менеджер, да и та технология и эта. Но аналогичные технологии good enough есть и у конкурентов, если они всё еще были нужны конечно.

Аналогичные истории про незаменимость и волшебность IBM pSeries и топовых Sun Fire рассказывали в середине 2000х, что особенная архитектура и т.д. и т.п., сейчас с этих ящиков уже или сбежали или бегут быстро.

Ну и чтобы закончить напомню (если Вы знали, но забыли) IBM уже давно уже поставляет zEnterprise это когда МФ работает в одной упряжке с блэйд центрами на x86 или Power оптимально распределяя работу.

Блейд центры от ИБМ (Леново) это ругательное слово, весь смысл "самого надежного железа" в виде МФ теряется. х86 бизнес ИБМ продал китайцам 2.5 года назад.

[АццкоМото]

АццкоМото, на прошлой неделе я был в Крыму, четыре дня, и каждый день ходил по маршрутам. Один из них со смотровой площадки в Ласпи через Куш-Кая, мыс Айя, по средней полке до Балаклавы. Больше 20 км. Хочешь, в следущем году пройдем этот маршрут вместе? Или слазаем на Ай-Петри по Таракташской тропе, по которой я ходил в прошлом году? Я там чуть не сдох, на самом деле.
Никто не знает когда покинет этот, в общем то неплохой мир, дай нам всем, и тебе, АццкоМото, лично бог здоровья и долгих лет жизни. Я приношу свои извинения за мой вчерашний резкий ответ, я всю ночь сожалел об этом, но это надо быть идиотом чтобы додуматься написать: "Остаётся дождаться, когда последний зВлад умрет от старости.". То что ты лет на десять младше меня вовсе не означает что ты дождешься моей смерти. Мне тебя жалко, и я тебя прощаю.

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

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

[Мальчик-Одуванчик]

МФ сегодня живы не более, чем программируемые калькуляторы и ламповые усилители: формально последний не изничтожили, фактически — давно.

Заметил что как у народа появляются деньги, так ламповый усилитель им подавай. А недавно всплеск на виниловые пластинки пошел, в местном Фрайзе секция пластинок уже побольше чем с музыкой на компакте будет.

[DVK]

МФ сегодня живы не более, чем программируемые калькуляторы и ламповые усилители: формально последний не изничтожили, фактически — давно.

Заметил что как у народа появляются деньги, так ламповый усилитель им подавай. А недавно всплеск на виниловые пластинки пошел, в местном Фрайзе секция пластинок уже побольше чем с музыкой на компакте будет.

Конечно. Тёплый ламповый звук это как 100% надежность МФ. Кто-то верит.

[zVlad]

АццкоМото, на прошлой неделе я был в Крыму, четыре дня, и каждый день ходил по маршрутам. Один из них со смотровой площадки в Ласпи через Куш-Кая, мыс Айя, по средней полке до Балаклавы. Больше 20 км. Хочешь, в следущем году пройдем этот маршрут вместе? Или слазаем на Ай-Петри по Таракташской тропе, по которой я ходил в прошлом году? Я там чуть не сдох, на самом деле.
Никто не знает когда покинет этот, в общем то неплохой мир, дай нам всем, и тебе, АццкоМото, лично бог здоровья и долгих лет жизни. Я приношу свои извинения за мой вчерашний резкий ответ, я всю ночь сожалел об этом, но это надо быть идиотом чтобы додуматься написать: "Остаётся дождаться, когда последний зВлад умрет от старости.". То что ты лет на десять младше меня вовсе не означает что ты дождешься моей смерти. Мне тебя жалко, и я тебя прощаю.

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

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

Спасибо за приглашение. Меня давно манят эти края, но они казались и кажутся такими далекими.
Честно говоря меня сразу смущало множественное число, но что-то другое пересилило. Еще раз извините.

[adda_]

Конечно. Тёплый ламповый звук это как 100% надежность МФ. Кто-то верит.

Звук действительно другой. Но надо иметь уши и любить музыку. Кстати я об этом знал еще задолго до того как об этом начали говорить. Где то в начале семидесятых когда произошел переход с ламп на транзисторы.
И таки до сих пор исполнители предпочитают лампу в усилителях.

[АццкоМото]

Спасибо за приглашение. Меня давно манят эти края, но они казались и кажутся такими далекими.
Честно говоря меня сразу смущало множественное число, но что-то другое пересилило. Еще раз извините.

да ладно, вам-то чего извиняться? ну и вы уж извините, раз уж выходит, что обидел

ЗЫ. а понятие "далеких краев" давно мутировало с тех пор, как МФ были в моде/size]. сегодня удаленность измеряется скорее баблом, и камчатка-курилы это действительно дорого, а врангеля (там я не был) - дорого пугающе

[АццкоМото]

МФ сегодня живы не более, чем программируемые калькуляторы и ламповые усилители: формально последний не изничтожили, фактически — давно.

Заметил что как у народа появляются деньги, так ламповый усилитель им подавай. А недавно всплеск на виниловые пластинки пошел, в местном Фрайзе секция пластинок уже побольше чем с музыкой на компакте будет.

В дорогих (а дешевых-то поди уже и нет) ламповых усилках есть свой шарм. Есть своя церемония. Как покурить сигарету, сигару или трубку. Вроде один хрен, а разница есть.
А винил - немножко другое, он слишком вышел в тираж. Когда он везде и стоит копейки - уже не то. А вот когда я в то ли 2006 то ли 2008 году подарил пластинку на дняффку другу - это было прикольно - он даже не сразу понял, что это

ЗЫ. только что смотрели "бриллиантовую руку" семьей. и вот когда похмельного никулина жена пыталась разбудить будильником.... моя жена объясняет дочке: это будильник. а мне приходиццо абиснять: алярм клок. к чему я это. мейнстримовый покупатель сегодня воспринимает весь этот винтаж (не путать с митингом навального) совсем не так, как мы, старики

[zVlad]

......
То что у вас нет, или вы не видели, десятков ТБ сырых данных обрабатываемых ежденевно, это не значит что другим безнесам не надо это обрабатывать. Каждая транзакция это денежка, пусть немного центов, но денежка. Один data charging, а это только часть задач, потенциально съест 40-50МФ.

Я давно не работаю в High-Frequency Trading, там объемы поменьше конечно, но тоже много. Только на одну из подзадач для торговли на London Stock Exchange было 6 (шесть) Fujitsu Primepower 2500 о 128 головах каждый, которые отнюдь не простаивали.

Хуже всего Вы продолжаете рассматривать МФ как обычный сервер. А это далеко не так.

Это необычный сервер, но с обычными ТТХ виде количества ядер, TB RAM и т.п., которые транслируются в SPECjbb, SPECintrate, TPS, etc Да сопроцессоры, да ресурс менеджер, да и та технология и эта. Но аналогичные технологии good enough есть и у конкурентов, если они всё еще были нужны конечно.

Аналогичные истории про незаменимость и волшебность IBM pSeries и топовых Sun Fire рассказывали в середине 2000х, что особенная архитектура и т.д. и т.п., сейчас с этих ящиков уже или сбежали или бегут быстро.

Вы очень легкомысленно делаете оценки сколько нужно МФ для того-то. 20 МФ, теперь 40-50. Вы пытаетесь натягивать презерватив на глобус. Причем в последнем Вы скорее добъетесь успеха чем в оценке количества МФ для знакомых Вам приложений ИТ.
3.5 лярда транзакций упомянутых ИБМ попадались мне (если дадите ссылку буду благодарен) и я помню мелькнула мысль типа ну кто вас за язык тянет ведь найдутся примеры с бОльшим количеством и ими будут тыкать. Так и получилось, и я не лукавлю говоря что такая мысль мне пришла до того как Вы использовали эти числа.
У меня небольшое приложение на МФ, это верно. С небольшим количеством транзакций примерно 2.5 млн. в неделю. Но у нас с этим справляется и весьма легко даже в пиковые часы (в основном эти 2.5 млн. выполняются за 30 часов работы: 5 дней по 6 часов, 3-4 часа до обеда и 2-3 часа после). Это то что меряется для отчета клиенту, это только продакшн OLTP часть работы. Объем продакшн БД не более 5 ТБ. На этом же МФ в другой партиции (всего на этом МФ две партиции, но он также DR site для продакшн с другого МФ) в одной системе стоят несколько dev, один qa, два training, sandbox. Здесь работают программисты, идет учеба в классах работе в приложении. Базы данных есть у каждого региона (так мы их называем), причем qa размера продакшн БД. В обейх партициях постоянно выполняются пакетные задания по графику.
Все это выполняется на весьма скромном по ТТХ МФ, скромном даже с точки зрения Ваших представлений о серверах. Это МФ выпуска 2012 года, не z13, a zBC12. Всего 4 кора не на максимальной скорости. Всего 32 ГБ памяти (24 в продакшн, и 8 в тест), 4 Ficon channels на диски, 4 сетевых порта. 1000 MIPS показатель мощности процессоров. Не заменяя стойки мы можем нароститься до 6 коров для zOS плюс 6 для Java, 5000 MIPS, 496 GB, 128 каналов ввода-вывода (суммарно для всех внешних устройств, включая сетевые карты. Старшее семейство, в 2012-ом, zEC12, это 78500 MIPS, 101 cores, 3 TB, более 300 каналов ввода-вывода.
Я не для того привожу эти ТТХ чтобы показать какой МФ крутой по ТТХ, а для того чтобы Вы увидели на чем выполняется наше приложение, параметры которого я тоже дал и могу сказать что на 4 корах и 32гб это ни на какой другой платформе выполнить невозможно было бы и у меня есть доказательство - я приводил его здесь на форуме, и могли бы примерно прикинуть сколько таких приложений как наше можно было бы гонять на полность нафаршированном zBC12 и zEC12 - МФ образца 2012 года. Параметры z13, МФ образца 2015 года в сети доступны.
При этом наш МФ далеко не загружен и на него можно добавлять работу, например, как я уже говорил перенести Web морду с семи AIX серверов.
Я и в середине 2000 знал и понимал что ничего такого волшебного в pSeries и SunFire нет. Как не было и нет ничего волшебного в х86, включая кластеры на них. А вот на МФ было (включая кластеры) и есть, и пить ....

P.S. Посмотрел ТТХ z13s, это следущий шаг после нашего zBC12. Однопроцессорная (один кор) конфигурация z13s на полной, неограниченной микрокодом скорости дает 1430 MIPS, мы используем сейчас 1000 Mips МФ. В шестипросессорной конфигурации 1076 mips получается на уровне "I" в диапазоне уровней от "А" до "Z". Цена что за 1 процессорную что за 6 процессорную конфигурацию будет примерно одинаковой.

[АццкоМото]

У меня небольшое приложение на МФ, это верно. С небольшим количеством транзакций примерно 2.5 млн. в неделю.

Хотел написать, что с таким мощным потоком транзакций (аж четыре штуки в секунду!) может справиться телефон. но по некоторому размышлению пришел к выводу, что это скорее территория пультов от телевизора

[zVlad]

У меня небольшое приложение на МФ, это верно. С небольшим количеством транзакций примерно 2.5 млн. в неделю.

Хотел написать, что с таким мощным потоком транзакций (аж четыре штуки в секунду!) может справиться телефон. но по некоторому размышлению пришел к выводу, что это скорее территория пультов от телевизора

На самом деле, как я говорил выше, 90% этих транзакций выполняются в течении 30 часов, т.е. где-то 25 транзакций в секунду для 90% транзакций. Но это не главное.
Что Вы, АццкоМото, понимаете под транзакцией? Как Вы определили что телефон, нет пульт управления телевизором, мог бы справиться с той работой которая была выполнена в 2.5 млн. наших, конкретных транзакциях? Объясните, пожалуйста.

[АццкоМото]

У меня небольшое приложение на МФ, это верно. С небольшим количеством транзакций примерно 2.5 млн. в неделю.

Хотел написать, что с таким мощным потоком транзакций (аж четыре штуки в секунду!) может справиться телефон. но по некоторому размышлению пришел к выводу, что это скорее территория пультов от телевизора

На самом деле, как я говорил выше, 90% этих транзакций выполняются в течении 30 часов, т.е. где-то 25 транзакций в секунду для 90% транзакций. Но это не главное.
Что Вы, АццкоМото, понимаете под транзакцией? Как Вы определили что телефон, нет пульт управления телевизором, мог бы справиться с той работой которая была выполнена в 2.5 млн. наших, конкретных транзакциях? Объясните, пожалуйста.

Дорогой зВлад. Транзакция — это неделимая совокупность операций, которая должна либо закончиться успехом, либо обосраться, но не изменить ничего (немного неточно, но суть такова).

Понятно дело, что чисса тиаритиски эта совокупность операций может включать в себя "досчитать до бесконечности. Три раза". Но на практике все куда тривиальнее. 30-часовая транзакция не занимает и миллисекунды у пульта от телевизора, остальное — ожидание. И, конечно, если каждая из 4х транзакций в секунду залипает в новом треде или процессе, который 30 часов подряд спрашивает "нучотам?", то и МФ можно нагнуть. Но если фключить моск (да так иногда делают), то и микроволновая печь справится

[zVlad]

У меня небольшое приложение на МФ, это верно. С небольшим количеством транзакций примерно 2.5 млн. в неделю.

Хотел написать, что с таким мощным потоком транзакций (аж четыре штуки в секунду!) может справиться телефон. но по некоторому размышлению пришел к выводу, что это скорее территория пультов от телевизора

На самом деле, как я говорил выше, 90% этих транзакций выполняются в течении 30 часов, т.е. где-то 25 транзакций в секунду для 90% транзакций. Но это не главное.
Что Вы, АццкоМото, понимаете под транзакцией? Как Вы определили что телефон, нет пульт управления телевизором, мог бы справиться с той работой которая была выполнена в 2.5 млн. наших, конкретных транзакциях? Объясните, пожалуйста.

Дорогой зВлад. Транзакция — это неделимая совокупность операций, которая должна либо закончиться успехом, либо обосраться, но не изменить ничего (немного неточно, но суть такова).

Понятно дело, что чисса тиаритиски эта совокупность операций может включать в себя "досчитать до бесконечности. Три раза". Но на практике все куда тривиальнее. 30-часовая транзакция не занимает и миллисекунды у пульта от телевизора, остальное — ожидание. И, конечно, если каждая из 4х транзакций в секунду залипает в новом треде или процессе, который 30 часов подряд спрашивает "нучотам?", то и МФ можно нагнуть. Но если фключить моск (да так иногда делают), то и микроволновая печь справится

Молодца! Формально теорию знаете. Можете даже тест пройти и получить сертификат каких-нибудь там наук у Микрософта. Экспертом стать. Уверен уже некуда складывать эти сертификаты.
На самом деле то определение что привели Вы это транзакция в смысле целостности данных. Более общее определение транзакции это единица работа - Unit of Work. И не в смысле, например, сантиметра для измерения длины, а в смысле содержания действий разного характера и трудоемкости, а также в смысле наличия начала и конца. Пакетное задание выполняющееся часами для системы будет одной транзакцией, и добавление одной строки в базу данных тоже может рассматриваться как одна транзакция.
Среднее время выполнения тех наших 2.5 млн. транзакций не более одной секунды. Учет этого времени ведется по пяти различным группам и среднее время в группах от 0.5 сек до одной сек. Пусть будет 1 секунда. Значит общее время нахождения в системе 2.5 млн. транзакций равно примерно 29 суток. А как я уже не раз отмечал 90% этих 2.5 млн. выполняются в пиковые часы: 5 перидов по 6 часов каждый - 30 часов.
Интересно, правда? Ваши комментарии?
Еще, согласитесь, интересно было бы знать, поскольку приложение наше это приложение базы данных, сколько DML statements выполнялось в этих 2.5 млн. транзакций. Я мог бы эту информацию дать. Вы хотите ее от меня? Вам это чем-нибудь сможет помочь понять отличие сноповязальной машины от пулемета Максим, например?
А то что большенство наших транзакций это как правило выполнение нескольких программ (минимум одной) бизнес логики с обращениями в БД Вам скажет о чем-нибудь?

[АццкоМото]

Молодца! Формально теорию знаете. Можете даже тест пройти и получить сертификат каких-нибудь там наук у Микрософта. Экспертом стать. Уверен уже некуда складывать эти сертификаты.
На самом деле то определение что привели Вы это транзакция в смысле целостности данных. Более общее определение транзакции это единица работа - Unit of Work. И не в смысле, например, сантиметра для измерения длины, а в смысле содержания действий разного характера и трудоемкости, а также в смысле наличия начала и конца. Пакетное задание выполняющееся часами для системы будет одной транзакцией, и добавление одной строки в базу данных тоже может рассматриваться как одна транзакция.

Не вполне понятно, зачем вы пересказали меня, только значительно хуже

Среднее время выполнения тех наших 2.5 млн. транзакций не более одной секунды. Учет этого времени ведется по пяти различным группам и среднее время в группах от 0.5 сек до одной сек. Пусть будет 1 секунда. Значит общее время нахождения в системе 2.5 млн. транзакций равно примерно 29 суток. А как я уже не раз отмечал 90% этих 2.5 млн. выполняются в пиковые часы: 5 перидов по 6 часов каждый - 30 часов.
Интересно, правда? Ваши комментарии?

И каких комментариев вы ждете? Что в час пик у вас аж в среднем 20.8 транзакций в секунду, а не 4, как в среднем за неделю?

Еще, согласитесь, интересно было бы знать, поскольку приложение наше это приложение базы данных, сколько DML statements выполнялось в этих 2.5 млн. транзакций. Я мог бы эту информацию дать. Вы хотите ее от меня? Вам это чем-нибудь сможет помочь понять отличие сноповязальной машины от пулемета Максим, например?
А то что большенство наших транзакций это как правило выполнение нескольких программ (минимум одной) бизнес логики с обращениями в БД Вам скажет о чем-нибудь?

Нет, не надо мне ничего про DML statements. Единственное, что меня может заинтересовать - суть транзакций. Ибо пока все кричит о жопоголовом дизайне, но не зная сути доказать это невозможно

[zVlad]

Не вполне понятно, зачем вы пересказали меня, только значительно хуже

Я хотел было еще раз попытаться разжевать что поддержание целостности данных в БД через commit или rollback это лишь один вид транзакций, но потом подумал а должен ли я заниматься ликбезом, и ответил себе: нет не должен.

[zVlad]

.....Нет, не надо мне ничего про DML statements. Единственное, что меня может заинтересовать - суть транзакций. Ибо пока все кричит о жопоголовом дизайне, но не зная сути доказать это невозможно

Жаль, я надеялся что количество выполненных DML, которых намного больше чем количество транзакций, что то Вам скажет. Ну не хотите так не будем.
Вы спрашиваете о сути наших транзакций и не дождавшись этого называете их творением "жопоголового дизайна". А вдруг окажется что все в порядке? Кто тогда будет выглядеть жопоголовым?
Ладно, попробую описать "суть транзакций", хотя я далеко не девелопер этого приложения. Транзакции нашего приложения делятся на два вида:
- совокупность Кобол программ выполняемых в CICS и реализующих заданную бизнес логику с обращением в БД DB2 (на языке SQL, если хотите), выполняемых по запросам работников нашего клиента в оперативном режиме с целевым временем ответа не более 1 секунды (это контролируемый SLA параметр за не соблюдение которого следуют штрафы);
- удаленные запросы в DB2 из WebSphere, которые, кстати, в те 2.5 млн. не входят. Это могут быть вызовы хранимых процедур или прямых DML.

Если Вам что-то не ясно не торопитесь делать поспешные выводы, задайте дополнительный вопрос. Я дам дополнительные пояснения.

[АццкоМото]

.....Нет, не надо мне ничего про DML statements. Единственное, что меня может заинтересовать - суть транзакций. Ибо пока все кричит о жопоголовом дизайне, но не зная сути доказать это невозможно

Жаль, я надеялся что количество выполненных DML, которых намного больше чем количество транзакций, что то Вам скажет. Ну не хотите так не будем.
Вы спрашиваете о сути наших транзакций и не дождавшись этого называете их творением "жопоголового дизайна". А вдруг окажется что все в порядке? Кто тогда будет выглядеть жопоголовым?
Ладно, попробую описать "суть транзакций", хотя я далеко не девелопер этого приложения. Транзакции нашего приложения делятся на два вида:
- совокупность Кобол программ выполняемых в CICS и реализующих заданную бизнес логику с обращением в БД DB2 (на языке SQL, если хотите), выполняемых по запросам работников нашего клиента в оперативном режиме с целевым временем ответа не более 1 секунды (это контролируемый SLA параметр за не соблюдение которого следуют штрафы);
- удаленные запросы в DB2 из WebSphere, которые, кстати, в те 2.5 млн. не входят. Это могут быть вызовы хранимых процедур или прямых DML.

Если Вам что-то не ясно не торопитесь делать поспешные выводы, задайте дополнительный вопрос. Я дам дополнительные пояснения.

Бро, я вроде был предельно ясен: все указывает на жопоголовость, но без знания сути этого не доказать. Отсюда следует, что возможно никакой жопоголовости нет. Хотя поверить в это трудно.

А вот все эти Кобол, веб-сфера и прочие умные слова не имеют никакого отношения к сути. Просто инструменты.

Приведу пример, до крайности упрощённый. Вот у вас есть поток данных. Их все нужно сохранить. А ещё — высчитать текущее среднее. Один погромист будет сохранять в базу банных, а потом делать к ней запрос. Другой — просто сохранять и хранить в оперативке текущую сумму и количество данных. Фефективность различается на порядки. Ощущение, что у вас погромисты первого типа.

Если я пойму, в чем именно суть транзакции (например: выпуск ещё одной акции ОйБеЭм и пересчет долей всех 100500 акционеров), я могу почесать жопу и прикинув хрен к носу сказать либо "ого, всего в секунду уложились, круто!", либо — "ну я же говорил, жопоголовы"

[АццкоМото]

Не вполне понятно, зачем вы пересказали меня, только значительно хуже

Я хотел было еще раз попытаться разжевать что поддержание целостности данных в БД через commit или rollback это лишь один вид транзакций, но потом подумал а должен ли я заниматься ликбезом, и ответил себе: нет не должен.

Если вы не заметили, я БД не упоминал от слова "совсем". Так что ликбез существует только в вашей голове. Я дал вполне сносное, хотя и не идеальное определение. Вы же дали чудовищное.

[zVlad]

......

Если я пойму, в чем именно суть транзакции (например: выпуск ещё одной акции ОйБеЭм и пересчет долей всех 100500 акционеров), я могу почесать жопу и прикинув хрен к носу сказать либо "ого, всего в секунду уложились, круто!", либо — "ну я же говорил, жопоголовы"

Вы слыхали про такой класс приложений, называемых Enterprise Resource Planning, ERP. Это многомодульные комплексы приложений автоматизирующие различные задачи, области деятельности предприятия. SAP R3 одно из таких. Наше называется Asset Suite:
http://new.abb.com/enterprise-software/ ... -suite-eam

[zVlad]

Не вполне понятно, зачем вы пересказали меня, только значительно хуже

Я хотел было еще раз попытаться разжевать что поддержание целостности данных в БД через commit или rollback это лишь один вид транзакций, но потом подумал а должен ли я заниматься ликбезом, и ответил себе: нет не должен.

Если вы не заметили, я БД не упоминал от слова "совсем". Так что ликбез существует только в вашей голове. Я дал вполне сносное, хотя и не идеальное определение. Вы же дали чудовищное.

Когда Вы говорите "должно обосраться, но вернуть данные в исходное состояние" Вы говорите о журнале изменений, на основание которого только и можно это сделать, а также о commit и rollback. Софт который имеет такие функции и элементы обычно называются БД. Вы конечно можете использовать другие названия, если хотите, но мне эти названия не известны и особой нужды их знать у меня нет.