mayton2019

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

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

XFS - хорошая система. Я все магнитные блины в нее переформатировал но не было такого опыта с мелкими.
У меня как раз очень большие файлы лежат. Датасеты.

Еще я-бы предложил посмотреть на саму прикладную задачу с точки зрения коррелированного доступа.
Например каждый пользователь читает свой index.htm, avatar.jpg, e.t.c. Имеет смысл этот сет файлов
запаковать в очень быстрый архив. По сути в пакет даже без сжатия чтобы по заказу быстро отдавать
эту пачку по сети (user_id.pack). А там уж браузер разберется. Пришлем лишнее - не страшно. Все равно пакет летит.
Главное что теперь у нас нет россыпи мелких файлов а есть среднего размера упаковки на каждого
пользователя по user_id.

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

У папки нет хеш-сумм. По крайней мере пока мы не договорились о порядке обхода файлов.
Дело в том что

hash(file1, file) <> hash(file2, file1)

поэтому порядок важен.

Мы не можем доверять естественному порядку файлов. Потому что для NTFS - он (допустим) лексикографический.
А для флешки (FAT32) файлы могут лежать в рандомном порядке и поэтому хеш такого фолдера может
быть разным.

Используй join() для последовательного выполнения потоков.

быстро сравнить структуры БД и сделать скрипт, который приводит одну БД к структуре второй?

В этой задаче - большое количество подводных камней. Например что делать если в двух БД есть одинаковые
поля но имеющие разный тип (NUMERIC / VARCHAR). Дилемма... Что делать с исчезающими полями?
Удалять? Дилемма...

Я вообще не видел коробочных решение которые бы работали на "раз-два-три". Всегда есть нюансы.
И есть conditions которые нужно вбить или вкрутить в эти решения.

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

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

А в базе - отслеживать бухгалтерию вот как предлагали уже.

Переключение функционала с одного на другой обеспечивается с помощью ООП шаблонов
например RCWP (Replace Condition With Polymorphism).

А если нужно на ходу обновлять версию - то посмотри в документацию по ClassLoader и почитай
еще про технологию OSGI.

Чтобы консольное приложение не выводило логи можно сделать так
> application.exe 2>&1 > NUL

Непонятно, зачем тебе 2Тб под swap. Наверное цель - какая-то другая у тебя.

На самом последнем stage (я думаю gradle это позволяет) тебе надо просто добавить еще один
шаг - очистка артифакта от Java9 modules. Я-бы это сделал в простом случае просто распаковкой
артифакта во временный фолдер. Удалением файлов модулей и упаковкой обратно.

Что то вроде.

jar x .... -d target/temp  
find -type f -name module-info.class -delete
jar c ....

Есть проект GraalVM. В нет большая часть этих задач решена. И я для себя делал утилиты на java которые
работают в data pipelines. Но проект GraalVM имеет спектр ограничений. Почитай. Возможно не любой
код он сможет правильно собрать.

Использовали мы также graal для сборки AWS Lambda. Но это был сложный опыт. Я никому не советую повторять.

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

Короче это не панацея.

Ну слушай. В микросервисах нет математической формулы правильности архитектуры. Все итеративно.

Ты пишешь.

Запросы от каждого микросервиса к Auth service будут замедлять систему

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

И вообще микросервисы тоже с нуля начисто никто не пишет. Это процесс итеративный. Опытным путем
так сказать.

Можно генерить случайное целое число с запасом в 2 разряда. А потом кастить в double и делить на 100.

Но ты должен помнить что double - это сложный формат и он не мапится на десятичную систему 1:1
Обычно многие это забывают и ловят артефакты.

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

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

Поскольку мы не видим HTTP-кода ошибки то мы имеем дело не с веб-сервером а с каким-то умным устройством
которое работает фильтром. Возможно файрвол.

Надо искать специалистов по сетям и безопасности и спрашивать что не так. Возможно IP не подходящий.

Вот https://www.wordclouds.com/

Кликхаус относится к классу column-oriented dbms. Это означает что data-row как таковой отсуствует.
Строк нет. Но есть столбцы которые хранятся физически консолидировано. И когда ты указываешь
SELECT * то это заставляет кликхаус сделать гораздо больше действий чем надо на самом деле. В
силу этой колоночатой организации. Сами строки - виртуальны и чтобы их сформировать кликхаус
должен вычитать физических данных гораздо больше чем реляционка. Столбец - больше чем ячейка.

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

select avg(amount) from my_table;
Тогда кликхаус сработает быстрее чем Oracle или PG. В силу этой особенности формата.

А то что ты делаешь - экспорт во внешние файлы лучше вообще не делать. Или делать редко
или как-то по другому. Явно это не сильная сторона такой системы.

Тебе нужно проанализировать статистику по негативным ответам проверки прокси.
Если большая часть ответов - это socket timeout - то сделай таймаут не 5 секунд а 0.5 секунды.

Почему Map не реализует интерфейс Collection? Я сказал что у Collection сигнатура методов не подходит для мапы, на что получил еще один вопрос "Так почему бы, например, вместо put(key, value) не использовать add(new Entry(key, value))?

Я не знаю кто-ж такие вопросы задает. Это вобщем не инженерные а философские вопросы.
Можно предположить что добавление в Map - возвращает булевый результат. И мы
по логике правильного программирование не имеем права его игнорировать.

Про отпуск - вообще непонятно. Ну скажи дексыть всегда готов. Когда выходить. Нужна сменка? Флюрография?