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

[Ion Tichy]

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

[Dmitry67]

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

При всем уважении, не останавливает. Перестает чиститься лог на время бэкапа - так как он может понадобиться, и лог начинает пухнуть

Вас наверное смутило то, что вы видели сообщение, "IO suspended, blah blah" - такое действительно делает SQL по команде от VSS (shadow copy) при выполнении storage level backup. Но этот фриз буквально на несколько секунд - чтобы обеспечить консистентность бэкопов разных volumes между собой

Интересно что если все файлы базы на одном volume, то VSS не нужен - drive snapshot is always crash-consistent

[Dmitry67]

Отцы, то есть экзадата типа GPU в мире баз?
А какого рода примитивы поддерживаются?

[iDesperado]

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

агенты это люди ? они 24x7 работают ? dev, test, preprod - ничего этого нет ? отдельно стоящего dwh и репортинга у системы нет ?

[Flash-04]

Отцы, то есть экзадата типа GPU в мире баз?
А какого рода примитивы поддерживаются?

Про экзадату тоже слышал много интересного.

А вот как то я рассказывал, как у нас на одной БД Oracle RMAN помирал.

[StrangerR]

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

агенты это люди ? они 24x7 работают ? dev, test, preprod - ничего этого нет ? отдельно стоящего dwh и репортинга у системы нет ?

Дев весь динамический пытаются сделать, это да. С разными феериями по пути.

Препрод должен быть точной копией прода, с этим все просто. На фига там динамика?

И забавно но некоторые клиенты открыто пишут - никаких докеров! В требованиях.

[iDesperado]

Дев весь динамический пытаются сделать, это да. С разными феериями по пути.

Препрод должен быть точной копией прода, с этим все просто. На фига там динамика?

не знаю. но судя по всему вам очень важно, что бы в облаке не получилось на $30 дороже. ну вот тот даже препрод можно поднимать по кнопочке или в рабочие часы. баксов $30 экономия.

я уже чуток утомился, но повторяю, облака прут не только от динамики и доступности ресурсов, а от ценника на софт. вчера корпорации платили миллионы за лицензии на всякие DWH и аналитику, а теперь строят из говна и палок в облаках (хадупы, дата лейки, кастомизации postgres) и реально переводят огромные хоронилища.

[StrangerR]

Дев весь динамический пытаются сделать, это да. С разными феериями по пути.

Препрод должен быть точной копией прода, с этим все просто. На фига там динамика?

не знаю. но судя по всему вам очень важно, что бы в облаке не получилось на $30 дороже. ну вот тот даже препрод можно поднимать по кнопочке или в рабочие часы. баксов $30 экономия.

я уже чуток утомился, но повторяю, облака прут не только от динамики и доступности ресурсов, а от ценника на софт. вчера корпорации платили миллионы за лицензии на всякие DWH и аналитику, а теперь строят из говна и палок в облаках (хадупы, дата лейки, кастомизации postgres) и реально переводят огромные хоронилища.

У нас и облака и своя сеть, и большая часть живет в нашей сети - дешевле получается раз наверное в 5 минимум если не в 10. Но продакшены клиенты строят в основном в амазоне и в азуре хотя впрочем вопросы вида _а если враг нажмет кнопку и одним движением пальца снесет весь наш бизнес, что мы станем делать_ умные клиенты задают.

А так, все таки на своем облаке (стоят несколько десяток 2U серверов) выходит дешевле чем на AWS в разы, от 2 до 10 раз дешевле. Эти облака - гостиница экономичная - хочешь подушку клади сантик, хочешь простыню еще сантик, хочешь одеяло еще сантик, и так сантик за сантиком, сантик за сантиком...

(Я кстати кидал ссылку - я выложил на гитхаб опен соурс роутер который работает с этими облаками - создает VTI туннели - мы их несколько десятков используем, очень удобно, чем все на одну железку циськину накручивать а потом еще и с правами там бодаться).

PS. Ценник на софт - тут скорее в огород Ораклу камешек, так как одна из причин массового спрыгивания с в общем то очень неплохой Ораклиной базы - совершенно неприличные и совершенно непрозрачные ценники. Чем то мне ораклиные ценники напоминают здешнюю медицину - так же ничего никогда не поймешь и так же никто по лист прайсу никогда ничего не покупает. И да, если к простой базе прикрутить хорошие ресурсы то она полетит не хуже крутой базы но на слабых ресурсах - а ресурсы дешевеют куда быстрее чем _хорошие базы_. С другой стороны, наши вроде сделали все на Кассандрах, а сейчас обсуждают _не вернуться ли на SQL_ так как _не взлетает оно что-то, не взлетает_. Хадуп я там тоже слышал, но это ну явно не для финансовых транзакций то, хотя чую проблемы _мы тут засунули 100 миллионов документов в какую то фиговину а теперь их надо оттуда выковырять для миграции_ еще предстоят.

[zVlad]

Неожиданный всплеск реакций. Я на все сообщения ответить не смогу, слишком много, в том числе откровенной чуши написано. Но на некоторые вещи отреагирую.
Вчера прогнали initial load аналогом ГГ от ИБМ - IBM InfoSphere Data Replication. Запишите это название - моджет пригодиться если нужна хорошая репликация. Так вот то что ГГ делает за 6 с лишним часов IDR сделал за 5 минут.
У нас LOB хранятся средствами DB2. Это совершенно нормально, никогда не вызывало никаких проблем. Миграция в Оракл идет также с использованием типов данных LOB.
С Ораклом я открыл SR. Не по собственной воле, проект попросил. Я знаю почему их подход медленный, им надо заново переписать Extract для DB2. Был бы у меня их исходный код я бы его сам исправил, но кода у меня нет.
Клиент мнется переходить на IDR - кто-то вписался за Оракл и неудобно. Собственно и вендор софта тоже за Оракл топит.

[zVlad]

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

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

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

В Оракле тоже LOB.

[zVlad]

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

Нет никаких проблем с LOB в DB2.

[zVlad]

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

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

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

У нашего клиента "свои" мэйнфрэймы все 24*7 их и платят они не за время.

[zVlad]

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

В данном случае select ничего не блокирует.

[zVlad]

Оракл на данный момент отделался отпиской об устаревшей версии DB2 и как результат устаревшей версии GG. Сделали туманные намеки что может быть версия GG официально не поддерживающая нашу версию DB2 все таки будет работать. Ни слова о том о чем знаю я и в чем на самом деле проблема. Так что решения нет. И патроны у них кончились похоже.

[zVlad]

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

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

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

Вы не те базы данных используете. У нас больше 3 терабайт в таблице с LOB и все пучком. А с файлами были бы проблемы.
В тоже время у меня есть вопросы к вендору сделавшему ограничение длинны LOB столбцов 4КБ-ами. Это глупо, но все работает без проблем. 500 партиций по которым случайным образом разбрасываются доки.

[StrangerR]

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

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

Хотя если в ДБ2 ЛОБы хорошо заточены то и ладно. НО я бы напрягся, все таки проще когда все это отдельно. У меня под 5 терабайтов - около 30 миллионов файлов. В двух партишенах (две разные файловые системы). Без проблем.

[uncle_Pasha]

все таки проще когда все это отдельно. У меня под 5 терабайтов - около 30 миллионов файлов.

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

[iDesperado]

большая часть живет в нашей сети - дешевле получается раз наверное в 5 минимум если не в 10.

Но продакшены клиенты строят в основном в амазоне и в азуре

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

моей компании датацентр свой стоил 2 млн евро в год, я думал это дно, но когда управление передали субподрядчику с мировым именем понял, что дно далеко не было пройдено. у нас свой хадуп уже лет 7, на нем до сих пор нет секьюрити. и некому это сделать, т.к. задача не чисто админская, весь рукописный софт перелопачивать нужно. спустя 4 года все таки заставили проверить бэкап, запросили - через месяц технари написали, что были заняты, прошло более двух недель и данные ушли на ленту. восстановить не получится, тикет закрыли. потом пошли слухи, что ленты компания хранит в здании на против, а в здании пол года как сидит другой арендатор. как так вышло не понятно, где ленты не понятно. т.е. где-то гуляют персональные данные миллионов клиентов, местами с детальными медицинскими счетами. теперь все хозяйство отдали "профи" (субподрядчику с мировым именем), а профи подключаются к узлам и накатываю вручную патчи, каждый узел уникален. запросили новые узлы в кластер, а они все разные - где-то centos, где-то redhat, где-то своп вырублен, где-то включен. т.е. еще есть люди которые умеют ставить системы не из образа, а вручную.
в облаке тоже бывает не все гдадко, но такого дна уже не будет.

[StrangerR]

большая часть живет в нашей сети - дешевле получается раз наверное в 5 минимум если не в 10.

Но продакшены клиенты строят в основном в амазоне и в азуре

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

Ответ - Liability. Мы сами не хотим. Слишком высокая ответственность. Но под девелопмент и под университет - офигенная экономия.

Есть смешанные варианты, есть клиенты которые у себя все строят.

[Komissar]

моей компании датацентр свой стоил 2 млн евро в год, я думал это дно, но когда управление передали субподрядчику с мировым именем понял, что дно далеко не было пройдено. у нас свой хадуп уже лет 7, на нем до сих пор нет секьюрити. и некому это сделать, т.к. задача не чисто админская, весь рукописный софт перелопачивать нужно. спустя 4 года все таки заставили проверить бэкап, запросили - через месяц технари написали, что были заняты, прошло более двух недель и данные ушли на ленту. восстановить не получится, тикет закрыли. потом пошли слухи, что ленты компания хранит в здании на против, а в здании пол года как сидит другой арендатор. как так вышло не понятно, где ленты не понятно. т.е. где-то гуляют персональные данные миллионов клиентов, местами с детальными медицинскими счетами. теперь все хозяйство отдали "профи" (субподрядчику с мировым именем), а профи подключаются к узлам и накатываю вручную патчи, каждый узел уникален. запросили новые узлы в кластер, а они все разные - где-то centos, где-то redhat, где-то своп вырублен, где-то включен. т.е. еще есть люди которые умеют ставить системы не из образа, а вручную.
в облаке тоже бывает не все гдадко, но такого дна уже не будет.

это не облако дешевое, это у вас на фирме бардак

[Komissar]

все таки проще когда все это отдельно. У меня под 5 терабайтов - около 30 миллионов файлов.

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

правильное замечание.

[StrangerR]

все таки проще когда все это отдельно. У меня под 5 терабайтов - около 30 миллионов файлов.

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

правильное замечание.

Документы ТОЛЬКО добавляются. Так что никаких проблем. Если нужен полный дамп, бэкапим базу потом документы. Там могут попасть новые доки которых еще нет в базе, но не наоборот.

[Dmitry67]

реально переводят огромные хоронилища.

Хоронилища данных - в мемориз!!!
Data graveyard вместо Data lake

[Flash-04]

Ну можно подумать Amazon Glacier не оно

[zVlad]

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

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

Хотя если в ДБ2 ЛОБы хорошо заточены то и ладно. НО я бы напрягся, все таки проще когда все это отдельно. У меня под 5 терабайтов - около 30 миллионов файлов. В двух партишенах (две разные файловые системы). Без проблем.

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