mayton2019

Это очень коварный вопрос. Само по себе бэкапирование - это безсмысленная операция если нет четкого сценария ЧТО мы бекапим и КАК мы это дело будем поднимать. Ведь бэкап это тупо набор файлов. Образов или логических копий файлов. Поэтому успех этого мероприятия будет зависеть не от того берем мы rsync или tar или еще бох знает что. А от того какая конфигурация дисков на резервной железке. Какие ендпоинты надо поднять. И надо-ли вообще бэкапить всё? Для серверов приложений например на базе Tomcat/JBoss вам достаточно забэкапить только каталог приложений и настройки и возможно OS environment. Для баз данных там еще все запутаннее. По Oracle RMAN написана книжка размером с пятикнижие Моисея. Вобщем совет автору не бэкапить а провести сценарий полной инсталляции продукта в новое место. Оттуда и появится инструкция по техологии плановых бэкапов только нужный вещей.

SQLite - это одна из быстрых DBMS. Если у тебя что-то медленно работает то наверное ты так написал запрос. Или такой набор индексов построил. Или тебе реально не хватает возможностей SQLite. Насколько я помню там некоторые опции не поддерживались типа CONNECT BY PRIOR и возможно оконные и аналитические функции тоже. Вобщем не стоит сразу ругать инструмент если ты точно не разобрался чего тебе именно не хватает. Ато перейдешь на OracleXE а там еще медленнее будет.

Ни один архитектор наперед не скажет вам сколько вы заплатите за AWS услуги. Формула биллинга там - сложная и учитываем и транзакции и трафик и каллбеки (AWS-lambda) и ресурсы времени для инстансов. Поэтому единственные правильный путь - собрать работающий макет. Задеплоить его в AWS и понаблюдать под нагрузкой в течение месяца. Посмотреть какой пришел счет. И соотвествтенно экстраполировать на другие объемы.

Вокруг этого термина очень много спекуляций. Для БД в общем случае объектность не нужна т.к. базовый SQL Ansi-92 объектность не поддерживает и поэтому толку от объектности на уровне запросов - никакого. Вообще объектность это - метафора. Она очень часто завязана на языке и фреймворке и среде разработки (например Java-Spring). Само по себе наследование таблиц или типов например в Oracle поддерживается (CREATE TYPE .. UNDER) но % использования этой опции в продуктиве численно равен нулю. И вообще. Чтобы наследование было полноценным - нужен RTTI и рефлексия а для реляционных БД это означает что каждый data-row должен нести в себе информацию о типе. Это слишком накладно в общем случае. И для классической линейки RDBMS никто это не сделал.

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

MySQL - это не совсем DBMS. Это сборный лего-конструктор в котором каждая таблица в отдельности сама определяет свой уровень отказоустойчивости (т.н. engine). Поэтому обсуждать надёжность MySQL нет смысла без обсуждения того как была создана каждая таблица. In general - про надёжность сказать ничего невозможно.

Сначала топик начинался хорошо. Но непонятно зачем в последней строке автор ссылается на какие-то файлы. Был совершенно верный посыл. Интеграцию между PHP и NodeJS делать через enpoints. Схема - рабочая.

Уберите из постановки понятие файл. И всё заработает.

В отличие SQL, Lisp и прочих технологий где null/nil имеет смысловую семантику и позволяет выполнять операции в Java любая попытка применить любой метод к null выбрасывает немедленный NPE. Это означает что программист ЗАБЫЛ инициалировать объект. Это грубая ошибка и самое печальное что она не чекается компиллятором. Использование Optional в стримах необходимо чтобы защитить применение map/filter от внезапного NPE.
Пример который привел автор в начале топика просто неудачен. Он не раскрывает преимуществ Optional. Смотрите статью на сайте Баелдунга. Она - более наглядная.

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

Упирается в возможности Питона и AWS-Lambda. Насколько я помню там есть ограничения на память для лямбды и лимит на время для 1 сеанса хендлера. Но я думаю что можно решить эту задачу. Библиотеки сжатия должны быть потоковые. Тоесть без накопления результата в памяти. И степень сжатия надо поставить на store чтоб было максимально быстро.

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

Если эти headless браузеры - прожорливые то надо отказаться от них там где можно. Переписать часть ботов на Python к примеру. Возможен вариант что проблему создают конкретные сайты которые Толи майнят на твоём боте Толи прогружают ненужный контент. Нужен мониторинг памяти по каждой сессии.

Надо сначала понять роли. Клиент ты или сервер.

Дорог может быть миллион в зависимости от того что автор хочет получить на выходе.
Если - посчитать количество гласных букв - то одно. Если категоризировать слово или слова
то это другое. И возможно тут нужна предобработка слов. Стемминг или лемматизация.

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

Поэтому давайте в топике спросим а как звучит настоящее техническое задание?

Алгоритм нанесения damage должен быть совершенно одинаковый для всех. Просто у союзников должен быть множитель на 0.0 а у enemy соответственно 1.0.

По нейросетям обычно читают Саймона Хайкина. Но я не уверен что он писал про генерацию текста. Уж очень это специфично. Средний минимум для чтения - это очень странный вопрос. Вряд-ли есть такой критерий.

Это в школе называется - построить уравнение прямой по двум точкам.