Мы уходим с майнфрайм.

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

Я знаю историю Java на MF. До Java v4 движок на МФ писали в Sun, с v5 пишется в IBM. Разница как небо и земля. Для Java на МФ есть Specialty CPU - zip. Если коротко с Java на МФ сейчас все в шооколаде.

Вот поэтому поведение java-приложения может отлтчаться просто потому что движок пишут разные команды.

[iDesperado]

Влад мигрирует на 1/8 современного процессора, на 8 vcpu и 64 Gb ram. такая виртуалка в азуре стоит менее $100 в месяц.

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

типичная история. вместо того что бы накропать скриптик и активировть виртуалки на несколько нужных отладке часов вы сожгли пол года. а могли на оплатить как 2% от того компа.

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

Влад мигрирует на 1/8 современного процессора, на 8 vcpu и 64 Gb ram. такая виртуалка в азуре стоит менее $100 в месяц.

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

типичная история. вместо того что бы накропать скриптик и активировть виртуалки на несколько нужных отладке часов вы сожгли пол года. а могли на оплатить как 2% от того компа.

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

[iDesperado]

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

те кто в теме так с облаками не работают. так работают корпорации, которым сложно свои датацентры поддерживать. вам же видимо было выгоднее хостинг снять, там ресурсы минимум в трое дешевле.
бенефит облаков в динамике, в сервисах где платишь за запрос/мегабайты. кубер, динамические хадуп кластера. а просто жечь 24/7 виртуалку ... тут ничего не выгадаешь, да.

[liamkin]

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

Я знаю историю Java на MF. До Java v4 движок на МФ писали в Sun, с v5 пишется в IBM. Разница как небо и земля. Для Java на МФ есть Specialty CPU - zIIP. Если коротко с Java на МФ сейчас все в шооколаде.

Когда мы в 90-х начинали Яву, на писюганах, тоже был IBM JDK и Sun JDK. IBM Ява 1.1.7 забарывала Сановскую, там были опциешки полезные, например размер стэка для трэда, он должен умещаться в кэше проца - быть 256к или меньше. И ИБМ Ява видимо была написана прямее. В-общем мы ею пользовались. Сан конечно потом догнал, появились и там эти опции и оптимизации. Но сам факт!

[zVlad]

.....

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

Наш проект перехода приостановлен из-за перерасхода денег в том числе на Azure. А мы еще в самом начале, на уровне sandbox.

Кроме того, наши "архитекторы" закладывают QA размером в Production. И это будет не временно, для стрестеста, а постоянно. Два Production size в Azure! А к Production еще понадобится DR & Business Continuity. 4 раза по Production.
Каким он будет Production в Azure никто пока не занает, даже идей ни у кого нет. С чего-нибудь конечно начнут, но как он поплывет - загадка без ответа.

Я предлагал развернуть новую версию приложения на одном из наших МФ что есть безусловно возможно на том же Linux который они таргетируют в Azure. Причем для Linux версии мощность МФ была бы ровно в три раза больше чем та что имеется для версии не под Линух. И потом можно было в более четким пониманием какие же надо ресурсы перенестись в Azure. Этот вариант был оставлен без внимания. Значит будем гадать на кофейной гуще.

[iDesperado]

Я предлагал развернуть новую версию приложения на одном из наших МФ что есть безусловно возможно на том же Linux который они таргетируют в Azure. Причем для Linux версии мощность МФ была бы ровно в три раза больше чем та что имеется для версии не под Линух. И потом можно было в более четким пониманием какие же надо ресурсы перенестись в Azure. Этот вариант был оставлен без внимания. Значит будем гадать на кофейной гуще.

виртуалка D16 на 16 vcpu, 64Gb ram и 2Tb ssd в регионе канада стоит $817 в месяц, нужно быть полным неадекватом, что бы рассматривать вариант с МФ, который за активацию 64Gb ram затребует десятки тысяч долларов, еще несколько тысяч за ziip.
за пол года D16 виртулка сожжет $5k, ни один вменяемый манагер не будет искать путей эконмить на такой позиции. что за бюджет у проекта если $5k имеют в нем видимую долю ?

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

те кто в теме так с облаками не работают. так работают корпорации, которым сложно свои датацентры поддерживать. вам же видимо было выгоднее хостинг снять, там ресурсы минимум в трое дешевле.

У нас разные клиенты. Некоторые хотят быть модными и им вынь да подай облако.

[zVlad]

Миграция в Оракл с GoldenGate уперлась в офигенно медленный и в тоже время офигенно ресурсоемкий процесс извлечения данных из таблицы с LOB колонками. Времена на сравнительно небольшие об'емы просто ужасные. Экстраполяция показывает что нам нужны месяца чтобы всю таблицу перебросить таким образом.
Я знаю что там не так и знаю как это исправить, но надо переписывать extract программу. Не сильно, но надо.

[Flash-04]

А что вы там храните в таких колонках, если не секрет?

[zVlad]

А что вы там храните в таких колонках, если не секрет?

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

[liamkin]

А что вы там храните в таких колонках, если не секрет?

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

Ну вы же сами подсказываете ответ на свой вопрос. Проведите чистку базы от устаревших данных.
Ну и поищите, чем там сейчас в Оракле заменили LOB - потому что с этим ЛОБом у них всегда были проблемы. Лучший вариант - хранить ссылку на файл, а сам ЛОБ засунуть в файл. Файлы копировать в облако отдельно с помощью rsync.

[iDesperado]

Ну вы же сами подсказываете ответ на свой вопрос. Проведите чистку базы от устаревших данных.
Ну и поищите, чем там сейчас в Оракле заменили LOB - потому что с этим ЛОБом у них всегда были проблемы. Лучший вариант - хранить ссылку на файл, а сам ЛОБ засунуть в файл. Файлы копировать в облако отдельно с помощью rsync.

причем тут оракл ? у них GG за млн вечнозеленных не может вытащить из МФ данные.

[Flash-04]

Похоже камень преткновения именно эти LOB колонки. Видимо конвертация на них тормозит как не в себя.

[iDesperado]

Похоже камень преткновения именно эти LOB колонки. Видимо конвертация на них тормозит как не в себя.

судя по фразе "ресурсоемкий процесс извлечения данных из таблицы с LOB" - тупо дохнет МФ. но оно и понятно, 2 ядра 6Gb ram. у меня телефон серьезней ресурсами обладает.

[liamkin]

Похоже камень преткновения именно эти LOB колонки. Видимо конвертация на них тормозит как не в себя.

судя по фразе "ресурсоемкий процесс извлечения данных из таблицы с LOB" - тупо дохнет МФ. но оно и понятно, 2 ядра 6Gb ram. у меня телефон серьезней ресурсами обладает.

ну как вы можете сравнивать такое? какой терморесурс мобильного проца и мэйнфрэймовского?
Да, современный писюк в теории должен крыть мэйнфрэйм. Но не кроет. Потому что мэйнфрэйм делали до эпохи "загорелых". Ассемблер. Время транзакции БД меньше секунды. Правильное мощное IO.
У мэйнфрэйма есть два больших недостатка - отсутствие новых молодых кадров для поддержки, и платежи в ИБМ за процессорное время. Кстати - второй недостаток присущ всем облачным решениям. Поэтому я противник публичных облаков.

[iDesperado]

ну как вы можете сравнивать такое? какой терморесурс мобильного проца и мэйнфрэймовского?
Да, современный писюк в теории должен крыть мэйнфрэйм. Но не кроет. Потому что мэйнфрэйм делали до эпохи "загорелых". Ассемблер. Время транзакции БД меньше секунды. Правильное мощное IO.
У мэйнфрэйма есть два больших недостатка - отсутствие новых молодых кадров для поддержки, и платежи в ИБМ за процессорное время. Кстати - второй недостаток присущ всем облачным решениям. Поэтому я противник публичных облаков.

там софт - гавно мамонта. тухлое и абсурдное. тот же db2 блокирует данные даже на банальном селекте. что толку от асемблера, если оно все упрется в блокировки на чтение и встанет колом из-за дедлоков на ровном месте. том самом месте, где загорелый нарисует невменяемый селект, который современная субд прожует не моргнув глазом без блокировок и совершенно консистентным результатом.
опять же, никакой асемблер не компенсирует крошечный объем памяти, что заставляет МФ насиловать механические hdd. любая субд на жава уделает такой МФ на три порядка. три, просто потому, что имеет возможность забубенить терабайты в кеш и практически не касаться дисковой подсистемы.

[Flash-04]

Большой объем памяти конечно помогает. А разве select блокирует в DB2?

[Flash-04]

>>Время транзакции БД меньше секунды.

Рыдал. А в современных БД серверах больше? даже в древнем clipper на pc-ках было меньше секунды при использовании индексов.

[iDesperado]

Большой объем памяти конечно помогает. А разве select блокирует в DB2?

да, db2 блокирует что бы получить что-то консистентное. это классический блокировочник. там есть грязное чтение и в последних версиях костыли в стиле last committed, но костыли выдают неконсистентный набор. RC, RR и Serializable - блокируют при чтении.

[StrangerR]

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

Это да. НО это просто таки редчайшие случаи.

У нас уже проходили. В новой версии (Next Gen) продукта пришли архитекторы которые когда то пахали на гугл. И нарисовали.. много красивостей, тут рядом на стенке висит схема из одних квадратиков амазонных.

Вот только я им сразу предсказал что так как приложение обслуживает агентов а не публику, то их скалабилити динамическая нафиг не нужна будет. Да и с докерами вопрос еще будет.

Тут совсем недавно, на каком то митинге с потенциальным клиентом, он, прослушал всю эту лапшу на уши, задал резонный вопрос - у меня говорит 200 агентов. Вчера, сегодня, завтра. И зачем мне динамическое скалирование, когда их количество и соответственно нагрузка на систему сильно не меняются. Ну и с докерами - уровень добавляем, а зачем, не всегда знаем.

[StrangerR]

А что вы там храните в таких колонках, если не секрет?

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

А вы чего, файлы в базе данных хранили? Тогда ой. У нас это китайцы пытались учудить, но им сразу руки пообрывали _чтобы файлы - были в файловой системе_. И это нас спасает. А то только чтоо обсуждали - старая версия закрывается, как перетащить к клиенту документ сторейдж, а там всего то каких то 30 миллионов и терабайт 5 документов. Было бы это чудо в базе данных, мы бы давно померли. А так, без особых проблем - тар + зип наше все, как и симлинк.

[StrangerR]

Непонятно и про бэкапы в оракле
В сиквеле бэкап ничего не останавливает и не требует consistency. Как записалась так записалось.

Consistency востанавливается во время restore в самом конце, когда делается redo/undo

Ну вообще то, останавливает. Перестает писаться база и пишется реду лог если я конечно не очень путаю. На транзакции это, естественно, не влияет, хотя почепму то иногда влияет на реплицировани.

А потом апплаится накопленный REDO. В оракле примерно так же. Вообще конечно там куча оптимизаций, возможно что RMAN умеет вытаскивать блоки из логов и знает что где лежит. Но суть то остается - замораживается в той или иной форме база на момент бэкапа (ну или дописываается UNDO рядом).

Сам процесс мне напомнил как наш клиент с нашего софта соскакивал. Три захода (их купили, у купившего свой софт). Сначала супер проект по миграции. А там документов - много миллионов, благо не в базе а в файлах (попытку китайцев писать в базу пришибли на взлете). Потратили кучу денег, ничегоо не вышло - не шмогла. Потом еще заход, другие индусы, тот же ауткам.

И наконец в третьем заходе кто то допер. Не надо мигрировать. Будем заводить по новой в новой системе (точнее старой но другой) когда экспирейшен случится. Так за год всех перезаведем. Ну и примерно так и вышло, хотя теперь онри ломают голову как взять для комплаенсов и сохранить на 7 лет 30 миллионов документов да еще и как их увязывать с объектами. Ну да это у них голова болит, я им обешал выдать тар файлы по 1 на месяц и пусть делают что хотят... А так, тупая миграция таких объемов - высший пилотаж и чаще носом в гранит.

[StrangerR]

Так то оно так, а Oracle сильно ускорился с тех времен? Обычно продукты тяжелеют со временем

Те же БЛОБы планомерно перепилили на SecureFiles.
RAC на Экзадате заметно быстрее стал, не только потому что железки быстрее, но и за счёт новых механизмов.
Оптимизатор и само исполнение execution plan стали умнее.
У них выбора нет кроме как тюнить. Сейчас сильно продвигается Multi-Tenant, в т.ч. в их Клауде, а это не средняя мелкая базулька среднего клиента в одном инстансе часто надо одной VM, а сразу пучок PDB.

Тут в топике про GG zVlad спрашивает, так 11 и 19 GG вообще небо и земля.

Идея гонять Оракл на Azure VM мне не понятна, т.к. много датацентров Оракла рядом с Азур и имеют приличные линки между друг-другом.

Это мне и ораклисты говорили. Но цены, цены... Это надо и с Ораклом и с Азуром. Потом, если оракл не на экзадате то он супер быстрым не будет. А на экзадате он будет супер дорогим. Вообще у Оракла ценовая модель такая.. никто в ней до конца, по моему, разобраться не может. У нас клиенты массово ползут на MS SQL и... барабан... на Постгрес (видимо, сработало старое правило _если к кирпичу приделать моторчик то и кирпич самолет... ресурсы ныне дешевы особенно если не в AWS). Так то конечно, Ораклисты всех впечатляют цифрами. Но потом приходят финансисты, и тоже впечатляются, цифрами... (В итоге сколько я не искал клиентов желающих попробовать на оракл облаке - ни один сейлс такого не нашел, и с самой базой похоже аналогично).

Интересно как может быть облако соптимизироваno под какую угодно БД и что не могло бы быть сделано в другом облаке?

ну там уже ответили - экзадата. Сторейдж которая на уровне райд контроллера выполняет примитивы баз данных - запросы то база пилит на примитивы над одной табличкой, так вот эти примитивы выполняют дисковые полки прямо на себе. В итоге ускорение там просто фантастическое. Но дальше оракл хочет денег. Много денег. Очень много денег. И в итоге толку нуль от этой фичи. Так как ее никто кроме жирных котов получить не способен.

[StrangerR]

Вопрос дилетанта... А почему у вас Оракл в Azure? У них ведь вроде есть свой клауд (OCI?), который теоретически соптимизирован под их же БД. Или с Оракл клауд есть какие-то known issues?

Ну у нас вот полиси _что клиент хочет то и сделаем_. Сделали POC и использовали - AWS, Азур, IBM облако (которое недоразумение ходячее). Сделали POC под Гугл и Алибабу.

Пришел Оракл, сказал _а давайте с нами_. Мы сказали _будет клиент - сделаем_. И за все время ни единый клиент не захотел. Где то была статья, объясняющая этот фантастичский просер Оракла. Вроде бы, оно из за их бизнес модели - то на чем они деньги получали как то не ложилось на модель облачного сервиса. Ну и цены, цены, я поглядел на цены на ихнюю _автономную базу_ тоже офигел.

Хотя конечно, у них позиция идеальная. Была.
- Линукс . СВой. хороший. даже с ZFS (в обычных лицензия не позволяет).
- База. Своя. Хорошая. Экзадата вообще дас ист фантастиш.
- Жаба. Своя. Хорошая.
- Даже Саны по идее ихние. И что бы не добавить в облако еще и способность хостить сан приложения.

И при всем том - фантастический рынок фейл. Я до конца так и не понял, как они такого добились. Но.. добились.