База данных в таких случаях не подходит. Она не умеет индексировать "по ключевым словам". И выражения с LIKE обычно дают плохие планы выполнения т.к. искомое стоит в середине строки. Классический базёвый индекс в таких случаях не работает. Можно поробовать оффлайновый индекс по товарам с использованием Apache Lucene. Но это потребует определённых усилий по подготовке и актуализации такого индекса. Грубо говоря его надо постоянно синхронизировать по новым товарам.
На базе стандартного файлового API скорее всего невозможно. Объясню почему. Linux оперирует файловым API на уровне команд open/close/seek/read/write. Это основа которая работает для всех файловых систем. Если опуститься на уровень какой-то специфичной файловой системы (например vfat) то можно наверное порезать файл на кусочки кратные размеру блока файловой системы без пере-аллокаций. Но это - грязный хак который будет работать только под root и только для specific файловой системы. И только для особых условий (граница блока). Вобщем технически это сделать можно но использование этой утилиты будет носить "разрушительный" характер наподобие утилит parted, fdisk, mkfs.* и прочих. Сильно сомневаюсь что такая утилита будет полезна и востребована. Лучше пользоваться нормальным API.
Такой IDE не существует. И не будет существовать. Объясню почему. В инфо-технологиях существует класс задач которые нельзя решить "просматривая глазами код". Например нельзя доказать что код обладает каким-то свойством. Например свойством что он остановится с гарантией после 100000 итераций. Чтобы такое доказать надо этот код скомпилировать и запустить. Грубо говоря рантайм или собственно работа кода является доказательством его правоты. И никакие статические анализаторы не способны глянуть глубже чем рантайм.
Почему здесь важен рантайм? потому что автор говорит об алгоритмах сортировки и из контекста вытекает что его интересуют задачи именно производительности и скорости.
Еще альтернативный вариант - просмотр кода человеком. Это работает. Иногда.
Статические анализаторы могут просто подсказать какую-то простую ошибку типа потенциальный NPE или выход за границы массива. Но только в очень простых кейсах.
В книге Холдена Карау - "Изучаем Spark" - глава 9 Spark SQL этому вопросу уделелено 1-2 странички. Можно почитать.
Кешировать "каким-то образом" можно "всё что угодно". Redis и прочие коробочные решения для кешей - работают
но они к технологии Spark не имеют никакого отношения. Собственно их можно советовать как универсальный
совет для любых систем которые имеют back-end. Интеграция их же со спарком это вообще отдельный вопрос.
С помощью 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 никто это не сделал.
