С помощью Java Security Manager можно избирательно перекрыть приложению возможность прослушивать порты листенера, или создавать самому соединения. Но этот менеджер не различает ендпоинт и базу. Ему нужны цифры вида host:port или их комбинации и рулы разрешений на соотв действия.
Автор пытается построить свой прикладной протокол поверх сокетов. Этого не надо делать т.к такие протоколы уже созданы. Ключевые слова: jms, mq, apache-mq, kafka, rabbitmq, ibmmq.
Очень похоже на задачу об укладке рюкзака (knapsack problem). Можно начать с того что есть 2 рюкзака. Один изначально пуст. А в другом - все предметы. И есть некое значение массы (сумма весов всех предметов) деленная пополам.
Вот к ней надо стремиться.
Вопрос непонятен. Если CriteriaApi может получить stream произвольных объектов (UserEntity) то
к стриму всегда можно применить метод map и взять только нужый стрим полей.
C++ сегодня очень сложен как язык. Порог вхождения высок и новички часто обламывают об него зубы доходя лишь до арифметики указателей. Там - половина ньюкамеров можно выносить ногами вперед. Скорость разработки прикладного ПО под backend на Java значительно выше. Да и облачные технологии такие как Google Clound , Amazon AWS поддерживают все языки кроме С++. Вобщем если автор хочет быстрых денег - то лучше Java.
В С++ надо вырасти до седых волос чтобы представлять что-то серъезное потому-что стек С++ плотно уходит в операционную систему и железо. Невозможно знать просто С++. Надо быть немного сисадмином и железячником. Иначе в С++ делать нечего.
Не очень понятен смысл этого доклада. Вроде как it-археология еще не появилась как наука.
Java Appletts, ActiveX, Macromedia/Adobe Flash - это всё технологии которые умерли и браузеры их не поддерживают. В этом будет основная проблема при написании доклада. Некуда смотреть во время demo. Документация по ним скорее всего есть в архивах oracle.com (sun.com) надо просто искать мануалы от 90х 2000х годов на сайте производителя. Думаю что можно найти очень много старых электронных pdf книжек на эту тему.
Автор правильно написал в первом посту. dd if=/dev/urandom > /dev/sda3
Запись рандомного шума лучше чем любые фильмы. И быстрее.
Можно добавить через точку с запятой последовательность диск-дубликаций для всех дисков в системе.
Очень хочется посмотреть на разработчика который занимался компилляцией bash-scripts. Скрипты вообще создавались не для перформанса а просто для организации пакетного исполнения экзешников в определённом порядке или для инсталляции и развёртывания ПО.
Это очень коварный вопрос. Само по себе бэкапирование - это безсмысленная операция если нет четкого сценария ЧТО мы бекапим и КАК мы это дело будем поднимать. Ведь бэкап это тупо набор файлов. Образов или логических копий файлов. Поэтому успех этого мероприятия будет зависеть не от того берем мы rsync или tar или еще бох знает что. А от того какая конфигурация дисков на резервной железке. Какие ендпоинты надо поднять. И надо-ли вообще бэкапить всё? Для серверов приложений например на базе Tomcat/JBoss вам достаточно забэкапить только каталог приложений и настройки и возможно OS environment. Для баз данных там еще все запутаннее. По Oracle RMAN написана книжка размером с пятикнижие Моисея. Вобщем совет автору не бэкапить а провести сценарий полной инсталляции продукта в новое место. Оттуда и появится инструкция по техологии плановых бэкапов только нужный вещей.
SQLite - это одна из быстрых DBMS. Если у тебя что-то медленно работает то наверное ты так написал запрос. Или такой набор индексов построил. Или тебе реально не хватает возможностей SQLite. Насколько я помню там некоторые опции не поддерживались типа CONNECT BY PRIOR и возможно оконные и аналитические функции тоже. Вобщем не стоит сразу ругать инструмент если ты точно не разобрался чего тебе именно не хватает. Ато перейдешь на OracleXE а там еще медленнее будет.
LVM это старый боян. Кроме того он достаточно сложный в сопровождении т.к. надо знать и уметь штук 10 утилит типа lvcreate/pcreate/vgcreate e.t.c. и еще и знать и понимать какие ФС поверх него ставятся эффективно (с опцией растягивания или уменьшения размера).
Посмотри в сторону файловой системы ZFS. Это и LVM+файловая система в одном флаконе. Программные зеркала тоже поддерживаются и много опций восстановления. Утилиту надо знать и уметь только одну. Это - преимущество.
Ни один архитектор наперед не скажет вам сколько вы заплатите за 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 к примеру. Возможен вариант что проблему создают конкретные сайты которые Толи майнят на твоём боте Толи прогружают ненужный контент. Нужен мониторинг памяти по каждой сессии.
