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

[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 миллионов файлов. В двух партишенах (две разные файловые системы). Без проблем.

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

[alex_127]

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

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

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

не так супер сложно. been there.
https://docs.microsoft.com/en-us/sql/re ... rver-ver15

[StrangerR]

Транзакционность то конечно, но если файлы всегда _пишем новый_ то оно решается легко (базу коммитим после записи файла). А содержимое файла никто не гарантирует. Даже господь бог. Речь тут про то что если не нужна супер транзакционность и файлов очень много или это нечто вроде логов (когда мелкие потери не страшны) то база хуже файлов. Когда нужна транзакционность то конечно, лучше базы зверя нет.

[Dmitry67]

Многие data storage умеют создавать crash consistent snapshots файловой системы

[zVlad]

Транзакционность то конечно, но если файлы всегда _пишем новый_ то оно решается легко (базу коммитим после записи файла). А содержимое файла никто не гарантирует. Даже господь бог. Речь тут про то что если не нужна супер транзакционность и файлов очень много или это нечто вроде логов (когда мелкие потери не страшны) то база хуже файлов. Когда нужна транзакционность то конечно, лучше базы зверя нет.

У нас на самом деле используется и то и другое. Кроме тех документов что в DB2, в LOB хранятся есть примочки не на MF где хранятся доки в файлах. Проблем с примочкой больше чем с DB2. Точнее с DB2 их нет нет вообще, а с примочкой есть постоянно. Осебенно с DR.

[zVlad]

Вчера было собрание с представителями Оракл. Фактически "ори" расписались в их неспособности решать проблемы с их же софтом, который они впаривают за большие деньги. Я пытался их расшевилить на использование более новых версий GG в которых используются иные механизмы доступа к DB2. Но они и представители нашего клиента зассали из-за того что формально эти их новые версии нашу старую версию DB2 не "поддерживают". В кавычках потому что конечно же поддерживают. Я это знаю.
Вчера я сделал промежуточную таблицу где LOB заменил на классические varchar и varbinary. 3GB улетели из DB2 в Azure за две минуты и 4 секунды с тем же GG, который те же 3GB, но называемые CLOB и BLOB жует 6 часов в той же DB2. Причем почти все эти 6 часов именно в DB2 и именно CPU, а не ввод-вывод. Из двух же минут CPU только 30 секунд.
Вот такие талантливые программисты работают в Оракл.