Spring Integration тут не нужен. Он - ближе к обработке событий.
Вот эти два пункта
прочитать файл ( xml) - распарсить с доменную модель
3.Сохранить в базу данных
надо расписать поподробнее.
Насчет Spring Batch я не уверен. Он пока выглядит овер-проектированием.
После того как ты распишешь подробно что делают все stages этого джоба
тогда и можно обсудить применимость Spring Batch.
Эх лет 20 назад можно было спокойно писать на такие темы. Славное было время. udaff.com, bash.org, фишки, пикабушки. Щас кругом - наблюдатели смотрят. Чтоб никто не оскорбился. Вобщем я удалил посты своего мужского шовинизма. Но я это делаю исключительно из уважения к правилам комьюнити. Моё-же мнение остается моим.
Вспоминается сразу весь пост-модерн Пелевина. SNUFF. "Сомелье" и наука как услуга. Я думаю имеет смысл изучать как работает ИИ чтобы встроиться в био-цепочку как можно ближе к раздаче денег.
Lev, я-бы сказал следующее. Питон не должен быть первым языком. Все таки определенная дисциплина программирования должна быть выдана в качестве первого урока. Это как в музыке. Сначала тебя учат просто как правильно держать музыкальный инструмент. А потом когда ты уже станешь профи - можешь держать его как угодно. Но пока ты гимназист - будь добр. Следуй советам ментора. Поэтому языки строгой типизации должны быть сначала. Это как математика. Волюнтаризм и либеральность пойдут потом.
Версия Docker - последняя, недавно скачанная с сайта
ты очень любезный собеседник. Версия - последняя. Даже и нечего сказать.
И Windows у тебя без минорной версии. Чтож... Будешь зарплату получать - не смотри
в последние цифры. Пускай бухгалтер тебе округляет до тысяч.
История приключений автора не особо интересна потому-что натворил он очень много и нет доказательств что Docker раньше работал. Поэтому я предалагю выкинуть вообще всю историю событий и пойти от фактов. А именно от того что мы имеем сейчас.
Нужны версии софта Windows и Docker. И не делай скриншоты. Модератор удалит. Копи-пасть текст.
Если докер выдает ошибку текстом - то копируй сюда текст.
Парсинг - это такая рисковая штука. Нет контракта. Нет гарантий что API не изменится завтра. Действительно лучше вложить свои силы в что-то более понятное.
Никита Преснов, давай порассуждаем. Вот когда ты устанавливаешь игру. Тебя-же не беспокоит что там 100 000 файлов и ресурсы и музыка и dll и картинки. Верно?
У тебя просто создается ярлык.
Так может и у тебя нет проблемы в количестве файлов. А может тебе просто взять инсталлировщик. Собрать инсталляцию и передать это блондинке как игру. Устновил. Ярлык на столе. И пользуйся.
Vitsliputsli, есть старый фокус селективности. Он больше относится к мангитным дискам. Считается что если вы делаете выборку по индексу и выбираете более 3-5% строк - то использование indexscan уже не эффективно. Проще сделать Fulltablescan.
Как сейчас - не знаю. В эпоху SSD такой параметр как seek time перестал играть роль для индексного поиска.
И чтоб определить эту границу переключения - нужен был CBO. Для SSD я думаю что были подкручены коэффициенты. Всегда проще сделать так чем менять rules. Потому что CBO это как-бы персептрон и менять его поведение лучше коэффициентами чем логикой алгоритма.
Vitsliputsli, я раньше хорошо помнил как работает оптимизатор Oracle. Сейчас после Databricks/catalyst у меня каша в голове. Тем более что этих CBO.... каждая овоще-база делает свой. Вобщем точно не помню. Но в идеале оптимизатор должен работать не на RBO это точно.
Будет ли оптимизатор рисковать полагаясь на статистику
это вопрос сложный. Старые рекомендации от оракла образца 2010 года писали что надо
просто пересобрать статистику. Там процедура была gather_table_stats. Она и так по скедулеру
работала ежесуточно. И предполагалось что количество строк в крупных БД - стационарно
или меняется не сильно. Ну если их - миллионы - то загрузка там сто тыщ строк в день
особо не делает погоды. Были краевае кейсы когда CBO ошибался. Но философия такова
что для крупных систем если оптимизатор угадывал эффективность плана хотябы в 9 запросах
из 10 то это уже был успех. Потому что тюнить запросы на ходу DBA не успевали. Особенно
там где кодо-генерация. Всякие ORM/Hibernate и динамический SQL и билдеры отчетов. Там даже доступа к исходнику не всегда можно получить.
Да. Это правда для всех игровых технологий. Хочешь поднять fts - уменьшай screen-resolution.
Мы это знали еще во времена 3dfx, NVidia карт и ускорителей.
И за 25 лет ничего вобщем не изменилось. Пикселы "имеют значение".
Насчет Literoom я не знаю. Надо понять какие технологии он использует. И тут проще действовать
по аналогии. Запускать игру. Смотреть все сенсоры видеокарты. Фиксировать. И потом лайтрум
и тоже смотреть какие части техно-стека или какие элементы конвейера грузятся или перегреваются.
И если лайт-рум это облачное приложение и оно использует просто сеть - то тогда разрешение тоже
объясняет задержки. Больше информации надо передавать.
Dmitry Bay, я тоже ошибался. И убивал бекапы случайно. Обычная опечатка. Вообще
бэкапить не очень сложно. А сложно гарантировать что файловая свалка пригодна к восстановлению.
А это - еще более сложная задача чем бэкап. Потому-что тренировочные восстановление - ресурсоемкие.
Есть еще стратегия. Я правда не знаю как она называется. Я ее называю тик-так.
У вас есть 2 хранилища. И вы бэкапите по четным неделям на первое. И по нечетным неделям
на второе. При таком подходе если одно хранилище умирает или недоступно - у вас есть второе максиммум
давности 2 недели.
Еще у бэкапа есть другая проблема. Он не страхует вас от обычных человеческих ошибок. Вы если
имеете доступ на удаление можете сами что-то случайно удалить. Рука дрогнет. Вот с этой точки зрения
кассета стриммера даже как-то надежнее выглядит. Ну там и записывать неудобно. Но и удалить случайно
тоже не получиться.
Есть еще идея чтоб форматировать бєкапные диски в BtrFS/ZFS и просто делать снапшоты. Но я
этот вопрос не исследовал так глубоко чтоб рекомендовать это. Да и в адрес Btrfs пока еще идут
жалобы. Тут - цена рисков - насколько мы доверяем Oracle/FreeBDS и есть ли шанс восстановить
если диск поврежден или какая-то неведомая ошибка возникает в использовании. Тут - нет теоретически
верного ответа. Тут просто время и практика должны быть главным аргументом.
Вот эти два пункта
надо расписать поподробнее.
Насчет Spring Batch я не уверен. Он пока выглядит овер-проектированием.
После того как ты распишешь подробно что делают все stages этого джоба
тогда и можно обсудить применимость Spring Batch.