Несколько наблюдений.
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 вместе с целым ворохом софта.
Ну в это не классификация а фасетизация. Эти три области могут вполне себе перекрываться.
Есть микро-контроллеры с ОС ? Есть наверное. Куда их положить? Они заходят в пункты 1 и 3 одновременно.
