Leonid_V, смотри. По поводу выбора способа хранения данных. Есть целая матрица стратегий как и чего хранить. В основном она зависит от доступа. Обсуждать эту задачу нужно сразу в свете сразу трех прожекторов. Первое - это ООП. И объект должен максимально отражать бизнес. Тоесть это должен быть не массив массивов массивов. А именно коллекция абстрактных бизнес-объектов (отчеты) которые имеют под-типы (Основной отчет, Расширенный, Годовой и т.п.). Второй прожектор это перформанс. Объекты должны лежать в максимально-детализованном виде. Тоесть никаких JSON строк быть не должно. Должны быть Java Maps, Lists e.t.c. С вложениями. И есть третий прожектор - это экономия Java Heap если ты решил прогрузить терабайтный CSV файл. Третий пункт вообще-то противоречит первым двум. И если мы докатились до такого кейса то надо снова обсуждать и ООП и перформанс.
Вобщем как ты понимаешь здесь нету идеального решения. Есть матрица стратегий. И твой Java-ментор не смог тебе ответить просто потому что здесь нет лучшего решения. Здесь есть оптимальные для данного класса условий.
Сам по себе формат CSV - достаточно плоский. Он на 99% близок к реляционной таблице где в полях лежат атомы. Строки. Числа. Но не JSON документы. Если вы ступили на такой грешный путь - то вам дорога в другую (не реляционную систему). Mongo или CouchDb к примеру.
Когда мы работали с одним хедж-фондом - то загружали данные биржевых сводок из CSV в Apache Ignite и мы выбрали такой способ хранения как Vertical Arrays. Это обычные Java массивы которые хранят колонки таблицы. Они - примитивны. Int, Long, String. Но для нашего варианта доступа такой способ подходил лучше чем хранение Java entities. Грубо говоря мы развернули способ хранения на 90 градусов.
Даже такое бывает. Вот думай. Вопрос сложный. И на него нельзя просто так ответить в рамках тех условий что ты рассказал.
Neural Network, я думаю что тебя возьмут без опыта с обещанием что будешь учиться и работать. Хотя за РФ не могу говорить. У вас - сложнее все гораздо.
Neural Network, придумай что-нибудь. При 200 человеках на место - HR будет сортировать все резюме по количеству опыта. Вообще если ситуация так плоха - кидай к чорту Java/Android и переключись на что-то более редкое и нужное.
Вот эти пункты:
-проверить и изменить кодировку;
-проверить орфографию;
-убрать нечитаемые символы;
нужно очень детально расписать с примерами. Потому что сложность решения может меняться на порядки буквально в зависимости от 1-2 слов в этом задании.
Что такое проверить орфографию? Я - не знаю. Где достаточное условие проверки? Неясно.
Кодировки. Надеюсь речь не идет о симметричном шифровании. Но базовых кодировок с кирллицей
всего 4 (cp866/1251/Unicode16/utf8) и обычно задача сводится к проверке что текст статистически похож на кириллицу.
У меня часто такое было. Найдешь в торрентах нужную книжку в pdf. Свежак. Год издания - текущий. Качаешь. Открываешь. А там внутри - одна странчка с рекламой. И линка которая веден на сайт 100% фишинговый. Вот такую мерзость я часто видел.
PVkolos, мы теряем время. Что такое aiogram я всё равно не знаю. Да и никто тебе не скажет. Зачем тут астрология? Надо точнее. Сделай отчет профилирования и он покажет какая стока в коде сколько памяти сожрала.
Есть расширенная часть закона Амдала (это про HighLoad) которая показывает что начиная от некоторого количества потоков перформанс приложения будет резко падать. Далее запускай хоть 64 хоть 128 ядер. Они все будут драться за один спинлок или выбивать полезные странички из L1 и ожидать своих страничек к примеру и это займет их 99% времени. А оставшися 1% они будут посвящать полезной работе.
Лекарства от этого нету. Есть варианты - уменьшить число потоков и поднять тактовую частоту. И второе - просто переписать приложение по другому.
Дружище. Ищи конспект по курсу. Этот вопрос - седьмая вода на киселе. О каких этапах идет речь? Об исторических? Начиная от того как древние люди жгли костры чтоб информацию передать на расстояние. Это - тоже можно рассказать. Но лучше наверное понять контекст как излагал препод.
В качестве лирического отступления. Данная проблема решаема в MySQL хотя это нарушение 1НФ. Обычно в таблицах лежат атомарные значения с которыми мы работаем атомарно. Тоесть рассматривая их как единое целое. Если-же у нас регулярно возникает задача реплейсмента частей поля в таблице то такую таблицу надо срочно переделать. Она - не реляционная по смыслу.
Вобщем как ты понимаешь здесь нету идеального решения. Есть матрица стратегий. И твой Java-ментор не смог тебе ответить просто потому что здесь нет лучшего решения. Здесь есть оптимальные для данного класса условий.
Сам по себе формат CSV - достаточно плоский. Он на 99% близок к реляционной таблице где в полях лежат атомы. Строки. Числа. Но не JSON документы. Если вы ступили на такой грешный путь - то вам дорога в другую (не реляционную систему). Mongo или CouchDb к примеру.
Когда мы работали с одним хедж-фондом - то загружали данные биржевых сводок из CSV в Apache Ignite и мы выбрали такой способ хранения как Vertical Arrays. Это обычные Java массивы которые хранят колонки таблицы. Они - примитивны. Int, Long, String. Но для нашего варианта доступа такой способ подходил лучше чем хранение Java entities. Грубо говоря мы развернули способ хранения на 90 градусов.
Даже такое бывает. Вот думай. Вопрос сложный. И на него нельзя просто так ответить в рамках тех условий что ты рассказал.