mayton2019

Есть простейший запрос SELECT * from Table.
...
Реально ли как-то ускорить в этом случае?

Есть много мест в application где может что-то замедлятся . И это не обязательно SQL. Это может
быть веб-приложение, которое медленно отрисовывает таблицу. Или это может быть сетевой канал
который медленно отдает данные. Чтоб заниматься оптимизацией - нужно точно-точно знать где
оптимизировать. Или это будут зря потраченные усилия. Кроме того для UI например важно
получение 1 page вместо того чтобы загружать миллиард строк. Поэтому нужно знать какой %
результата выборки вы хотите использовать сразу (сию секунду) после получения и что
можно отложить на потом. Мой опыт подсказывает что пользователь вообще не воспринимает
информацию больше чем 1 абзац текста. Поэтому разгонять UI для отдачи миллиарда строк
нет никакого смысла.

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

Держи всегда файл открытым. Если это для Windows - то пользователю не запрещается открывать его на ЧТЕНИЕ в текстовом редакторе в этот момент.

И не забудь добавить ротацию логов там по минутам или часам или суткам. Чтоб не было 1 файла в петабайт.
Такой точно нигде не откроешь.

может вырасти вычислительная нагрузка

Какие-то непонятные страхи. Что там куда вырастет? Я не вижу в работе логгера вычислительной нагрузки.
Давай чтоб-не было в вопросе всяких метафор типа "безболезненно", "прелестно".... и так далее - дай
цифры. Сколько будет записей в день. Сколько на пике в секунду. Как часто пользователь будет лог
открывать. Что он будет с ним делать? Будет ли редактировать(!) ?

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

id name     path  parent
-----------------------
1  Беларусь 1     null
2  Россия   2     null
3  Минск    1.3   1
4  Москва   2.4   2
5  СПБ      2.5   2
6  Невский  2.5.6 5

Ну а дальше - select... connect prior и получим ранжированый курсор по дереву. Там-же будет
доступно виртуальное поле level. И обходом этого курсора можно сделать JSON документ.
Если level растет - то увеличиваем indentation и открываем вложенный элемент соотв.

Если go-lang поддерживает stremable json writers то даже лучше.

Смотрю ролики по программированию. Заинтересовали ролики Немчинского (хотя некоторые вещи он объясняет крайне непонятно для новичка).

Немчинский - популист и популяризатор своей собственной it-школы. Обычно в каждом видосе - реклама.

У него есть контр-образовательная позиция. Он например считает что после 1 курса универа надо сразу идти работать и наплевать на диплом вообще.

Во многих роликах Немчинский говорит, что надо использовать классы через интерфейсы.
....
У меня есть класс 1, в нем есть методы. Класс 1 используется в классе 2. Зачем интерфейс?

Не смотрел видео. Но в этом вобщем-то есть смысл для создания слабой зацепленности и InversionOfConrol.
Новичку такое объяснить нельзя. Нужны месяцы и годы чтобы понять. Желательно не на синтетических
уроках а на реальных боевых проектах где МНОГО кода. Именно обилие кода и требование проводить
сложны рефакторинги, замены движков одни на другие и цикл постоянной доработки - мотивируют к
внедрению базовых интерфейсов вместо классов.

То что ты не понял с 1 раза - это нормально. Я тоже когда изучал ооп и полиморфизм на примере Borland Pascal
тоже подумал что это туфта и я это использовать никогда не буду ибо незачем.

Можно привести пример на php и показать выгоду такого подхода?

Тут я не уверен. Вроде в PHP OOP есть с 5 версии. А есть ли там механики полиморфизма - ХЗ.
Пускай знающие прокоментируют. Но если есть - то хороший пример переключения
функционала например с Db MySQL на Postgresql без переписывания бизнес-логики.
В идеале у вас переключение должно произойти в 1 строчке кода. Если удалось - значит
метод работает.

Тут Spark не имеет никаких преимуществ перед обычным приложением. Скорее всего чтение из json не распараллелится. Такой он вредный json.

Попробуй просто выкачать json через hdfs tools и толкнуть его в кликхаус обычным java или python ротложннием. И jdbc лучше не использовать. Если у кликхауса есть другой API то бери его. Будет быстрее чем jdbc.

Делать его бином тоже как-то не хочется

Не совсем понятно почему не хочется. Экономишь память? Или время иниализации бина?

У тебя проблема вовсе не в Spring. Здесь если убрать Spring за скобки - то ты также будешь ломать
голову над тем как разложить твои данные по методам.

Попробуй реши эту задачу вообще без Spring. Будет простое ООП-решение. Вот затащи его потом
в Spring и вопрос сам собой решится.

Рекурсия нужна при обработке иерархических данных. Например - обойти файлы и каталоги
в файловой системе и выполнить какое-то действие. Или действие с условием. Например если
в текущем фолдере есть фолдер .git - то выполнить какой-то git script.

Рекурсия может понадобиться при работе с документами XML/JSon (шаблон composer). И хотя
в некоторых API рекурсия может быть частично скрыта за языками XPath/JSonPath тем не меннее
ее рекурсивная природа остается налицо. Кроме того если вам достался узкий API типа DomDocument
без поисковых диалектов - то обойти его можно на любом ЯП с рекурсивной функцией.

Рекурсия нужна при парсинге сайтов. Это вобщем просто более расширенная трактовка работы с файловой
системой. Если Url-s это как-бы файлы в web пространстве и они имеют ссылки друг на друга - то вы
можете рекурсией это все обходить.

Рекурсия почти всегда нужна при работе с графами. Берите любой алгорим на теорию графов и я готов
спорить что 99% он будет содержать рекурсию.

Все настольные игры (шахматы-шашки) в основе своего алгоритма альфа-бета поиска с отсечениями и
BWF базируются на рекурсии.

Tar и gzip это очень старые утилиты. Им по 30-40 лет. И создавались они в те времена когда симметричное шифрование еще не было так развито.

Но архивчик можно после упаковки зашифровать другими утилитами например openssl.

openssl enc -in file.txt -out encypted_file.txt -e -aes256

Я так делал когда шифровал бекапы oracle dbms.

Если переписать чуть лучше скрипт - то можно объединить операции tar->gzip->openssl в один пайплайн
без воздания промежуточных файлов.

Попробуй замени any на bytes.
map<string,bytes> property = 1;

Это скорее всего неправильно.

SELECT  name, number_plate, violation
FROM fine
GROUP BY name, number_plate, violation
HAVING count(*) > 1

если используется GROUP BY то в выражении SELECT должна стоять функция агрегации (count в данном случае)

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

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

И на качество самого аккумулятора влияет качество лития. Тут надо смотреть что за завод его делал. Из чего. Но тут я не спец. Нужны химики.

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

Это мне кажется интересная часть задачи которую можно обсудить. Остальное - уже решено.

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

Это значит, мне надо сделать 1000 репозиториев, в каждом Х методов (получение по ID, получение по значению поля, одного объекта, коллекции...). И ещё 1000*Х методов в контроллерах....

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

Мне кажется что внедрение WebFlux идет от "реактивного манифеста". Вообще классические сервлетные серваки которые раньше поддерживались Tomcat/Jetty сегодня могут быть прозрачно подменены на netty, на уровне конфигураций бута, что как-бы приближает нас к асинхронщине. И современному бизнес-разработчику практически будет безразлично, написан ли его контроллер на блокирующем IO или на каком-то другом. По сути речь идет о диспетчеризации ресурсов. Где создавать поток. А где и хватит единого потока диспетчера на всех.

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

Да нет такой метрики. В bigdata запросы могут по несколько часов или несколько суток работать.

Во всем что работает с вебом - надо выйти на быструю отрисовку landing page. TTFB. Не более 3х секунд желательно.

На олимпиадах обычно подбирают такие задачи где вам не понадобятся ни http клиент ни json парсер.

Вам понадобится знание алгоритмов и способность быстро синтезировать новые. Для этого уровня разработки будет достаточно самых базовых сущностей языка.