smilingcheater

1. А сборщик мусора и всё Java API тоже на уровне железа будешь реализовывать?
2. Что будешь делать, когда выйдет новая версия Java? Отказываться от нового софта? Отказываться от старого софта и переходить на новый железный процессор?
3. Что будешь делать со всем тем ПО, которое не для JVM создано?
4. Уверен ли ты, что сможешь создать аппаратную реализацию java-машины, которая будет эффективнее, чем классический процессор и JIT?

1) Хранить картинки в бд крайне кривое решение. Это может быть оправдано только в случае когда там хранится пара иконок, вставленная в текст прям через <имг срц="тут_бэйз64_строка"... и нет желания все это переделывать ради 2 кастомных микрокартинок. В остальном - конвертировать в картинку и хранить на диске. В бд писать путь до картинки. Если это какой-то аватар или картинка, связанная с другим объектом, соответственно заводить отдельную таблицу на картинки и связь один-к-одному или один-ко-многим, в зависимости от ситуации. В худшем случае поле в той же таблице, если точно будете знать что других картинок к объекту относиться не будет, но это должен быть путь до реальной картинки на диске.
2) Почему хранение в бд - плохая идея: При каждом запросе у вас будет вытаскиваться пару мегабайт данных из бд, передаваться по каналу соединения с бд, помещаться в память, и после этого еще нужно программно отдавать картину, кроме прочего картинка в бэйс64 занимает примерно на 30% больше места.
Когда у вас есть картинка на диске, вы просто вставляете путь до нее, это ~50 символов, и сервер отдает ее БЕЗ УЧАСТИЯ ПРОГРАММНОЙ ЧАСТИ, средствами вебсервера и ОС. Это быстрее, потребляет меньше памяти и занимает меньше места в хранилище.

«There are only two hard things in Computer Science: cache invalidation and naming things» — Phil Karlton

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

Мне кажется тут ноут с виндой без вариантов.

Самое отвратительное из известных решений. В БД храним путь к файлу и любые мета данные. Файл лежит в файловой системе. Там его и конвертируем в любой удобный формат и разрешение. Никаких полумер. Картинкам в БД не место.

Корневые зоны очень дорого стоят. И просто так их вам никто не зарегистрирует.
То что вы написали звучит как "Хочу собственную страну".

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

Существует только один способ улучшать работу нейросетей - продолжить обучение на новых данных.

Сам термин взлом здесь не применим. НС оперируют нечеткой логикой поэтому никакого взлома
нет. Есть просто детерминированное поведение выхода в зависимости от входа.

Если у вас задача потребляет CPU по максимуму, то да - распараллеливать её на большее количество процессов, чем имеется в наличии потоков - бессмысленно.
Но обычно задача по добавлению записи в БД потребляет не слишком много поцессора. А если речь про "парсинг", где процессор 99% времени ждет пакет из сети, распараллеливать можно хоть на десятки процессов.
Конкретное количество зависит от потребления процессора конкретной задачей.

Количество потоков не всегда равно количеству ядер, умноженному на два. Надо смотреть на конкретный процессор. Тем более на VPS, где процессор тоже виртуальный.

Если говорить про конкретный пример, то в идеале конечно надо написать нормальный код, который запишет в БД несчастные 3 тыщи товаров меньше чем за секунду. А заниматься параллелизмом уже когда счет пойдет на сотни тысяч. Тем более что цифра скорее всего взята с потолка. Я много повидал говнокода на своем веку, но такой, чтобы добавление одного товара занимало 30 секунд я даже вообразить себе не могу.

Единственная загадка - при чем тут "web", если речь идет про CLI. И, если уж говорить про веб, то с какой радости он "однопоточный".

Нет такого понятия "вытянуть видеокарту".
Если процессорной производительности будет недостаточно, то простаивать будет и 4090 и 1030.

Для большей части современных игр достаточно производительности современного i3 процессора.
12600K - это сильно с запасом. Скорее всего, нагрузка в играх на процессор будет не более 50%, разумеется, при адекватной утилизации мощности видеокарты.

Давайте отделим мух от котлет и пофилософствуем на тему трансцендентного понятия "вытянет"... :)

1) Для начала поймем, что процессор и видеокарта выполняют разные операции. Процессор готовит материал, а карта визуализирует. Соответственно нагрузка на процессор растет с частотой кадров видеокарты, но рост этот недетерминирован, меняется от места в игре, от настроек графики, от игры к игре, от количества игроков и т.д.
Оттуда мудрость - чем мощнее видеокарта тем выше вероятность, что процессор начнет упираться. Но когда это наступит и где? Кому ведомо?

2) Далее надо отметить, что не все движки игр реально многоядерные. Есть такие ситуации, где задачи не делятся между ядрами. Ну не всегда 9 женщин могут выносить одного ребенка за 1 месяц.
Оттуда мудрость - чем выше частота одного ядра, тем иногда это полезнее, чем количество ядер. И есть задачи, где i3 будет быстрее, чем i5 за ту же цену.

3) Иногда процессор или видеокарту покупают по тем же причинам, по которым берут большие черные джипы (своего рода "членоудлиннитель").
Оттуда мудрость - иногда надо брать 4090 и процессор 10400, не для того чтобы играть, а для того, чтобы ПОКАЗЫВАТЬ. Ибо денег на что-то одно, а чувство собственной важности лучше растет от указанной связки, чем от чего-то типа i9 13900k + GTX1050.

4) Умудренные опытом люди, давно, успешно и много раз пережившие "апгрейдные лихорадки" - становятся меркантильны и прагматичны. Они даже не меряются ФПС (вот с i7 - их, допустим, всего 175, а с i9 - аж 184!). Они понимают, что ИХ глаза столько не видят. Они сидят на мониках 60-75 Гц и не парятся.
И например их игровая прелесть, Хогвардс там какой, или Фаллаут очередной - прекрасно идут на 10-м поколении интел и старом RTX 2070 в FullHD и на 60 Гц, и далее нефиг тратить деньги.
Оттуда мудрость - какая разница, что кого потянет, есть оптимальное соотношение "общая цена"/"производительность" под конкретную задачу. Какая разница, что длиннее в попугаях - 175 ФПС или 185, если на мониторе выставлено 75?

"...- Палубной команде - ставить трал!
- Поставить можно клизму. Трал отдают... " (С) Ю. Иванов "История пропавшего корабля"

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