Andrey_Epifantsev, у всех этих нейро-сетевых решений - проблемы с декартовой геометрией.
Не знают они что такое отрезок. Прямая. Перпрендикуляр. Вот поэтому я и предлагаю все нечеткое
доверить сети (подложка) а все строгое (шрифты) доверить нормальному графическому пакету.
HollyAngel, ну сорян. Ничего больше предложить не могу. Но звуко-поглощающие материалы
для стен - это самое лучшее. А ширма может быть шторкой или чем-то складным.
Да. Автор пишет про "научные вычисления". Скорее всего кафедра будет иметь виды на 2-3 главные
задачи и под них будут брошены почти 100% ресурсов. Под все остальное - по остаточному принципу.
Поэтому я-бы тут вообще не делал никаких контейнеров. Мне кажется что просто разделение
этого сервера по времени - самый простой и оптимальный подход.
Контейнеры - только усложнят поиск узких мест когда будут проблемы с перформансом и непонятно
будет как их решать. В конце все просто придут к single-user-mode.
Несколько наблюдений.
1) Elasticsearch не ищет в файлах сразу. Он строит текстовый индекс. Это займет какое-то
время. Тоесть холодный старт для приложения будет скорее всего неприятен.
2) Обычно Elasticsearch оперирует такими единицами как документ. Документ также
является содержанием ResultSet. Поэтому здесь надо поставить
вопрос что будет документом в случае с парсингом этой простыни? Может 1 строка. Может блок
строк. Может всегда 1 главный документ но со ссылкой на номер строки (здесь надо уточнить работает
ли это).
3) Elasticsearch любит фильтрацию. Возможно не стоит индексировать "START-block" чтоб не зашумлять индекс.
CityCat4, с моей точки зрения (я сужу по LinkedIn) рынок вакансий в мире сильно ушел от десктопов в сторону. Разумеется вы можете привести вашу статистику.
Я не говорю что в промышленности десктопов нет. Я просто напоминаю какой % разработчиков читающих хабр вообще попадает в эту самую промышленность.
А как ты будешь угадывать где символ делимитер а где настоящий?
Я к чему это спрашиваю. Есть автоматизация замен символов в unix системах например через sed, awd, tr
и прочие утилиты. Но чтобы они заработали нужен четкий алгоритм.
SqRs, есть такой старый троллинг Oracle DBA. Приходит джун и говорит -
а почему alter index rebuild ускоряет выборки с индексами.
Опытные ораклисты выпадают из штанов в ответ. Но это работает. В основном там идет
несколько эффектов которые в совокупности улучшают фактическое время работы запросов.
Но это не означает что нужно регулярно пересоздавать индексы. Это просто повод на подумать
как такое удачное состояние индексов и таблиц сберечь на будущее так, что-бы это удачное состояние
было стационарно и не зависело например от периодических удалений или загрузок новых данных.
Роман Кофф, но тема вопроса неправильно написана. Никто не видит проблемы в том как дропать таблицы. Можешь дропать их хранимой процедурой или скриптом из psql. Внешним приложением можно.
Друзья. Мы пошли вообще не туда. Давайте я верну вас к фразе с которой начинается вопрос.
Чтобы избежать факапов при работе с БД решил написать скрипт, который «безопасно» грохает таблицы в БД.
Мне кажется что нужно обусдить что автор делает на самом деле и уже после этого предлагать стратегии отката.
Откат изменений - это АБСОЛЮТНО стандартное коробочное решение для таких БД как Oracle и (я верю) Postgresql при условии что были активированы правильные режимы журналов (archivelog, point-in-time-recovery).
Если это решение не подошло - то тогда можно обсуждать хитрости и трюки которые мы здесь придумали в частности создание новых БД.
Мы живем в эпоху вируализации и сейчас за 5 минут можно создать не то что БД но и ОС в docker вместе с целым ворохом софта.
