Есть система, которая хранит полуструктурированные данные – протоколы обработки запросов. В настоящее время она хранит протоколы в виде простых файлов в иерархии каталогов на дешевом файловом системе.

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

Размер проблемы

• <10 миллионов новых файлов данных создаются ежедневно
• ~5 запросов в день (на самом деле всего несколько случаев ежедневно)
• полуструктурированные данные
• размер одного файла данных варьируется от 1 кБ до ~10s МБ (долгая обработка с множеством исключений)
• требуемый срок хранения – несколько недель

Текущее решение

Поскольку соотношение запросов и записей составляет 5/10M и данные не полностью структурированы, не имело смысла беспокоиться о системе управления базами данных. Запуск такого сервера + хранилища не был бы эффективен.

Таким образом, это свелось к использованию grep с несколькими аргументами. Запросы определенно не быстрые, но…

Есть ли лучшее и экономически эффективное решение?

• Использование альтернативы “быстрому grep”? Я слышал о ripgrep и т.д.
• Миграция на программное обеспечение, подобное базе данных, недорого индексирующее полуструктурированные данные? Запуск Elasticsearch стоит $$$, и, насколько мне известно, не очень хорошо обрабатывает полуструктурированные данные из коробки.

Если вы хотите оставаться на бесплатном текстовом инструменте, hypergrep является самым быстрым или одним из самых быстрых альтернатив grep. Он полностью сосредоточен на скорости, в отличие от, например, упомянутого ripgrep.

SOLR

• удивительно быстро обрабатывает данные
• может обрабатывать неструктурированные данные… в основном вы будете использовать поиск по свободному тексту
• в то время как его парсеры могут принимать текст на языке, таком как английский, и токенизировать его таким образом, чтобы понимать стемминг (слова “baby” и “babies” являются одним и тем же понятием), вы можете избежать этого для технического текста. Это может потребовать некоторой настройки, например, если ваш поиск обычно включает слова: будут ли они близко размещены или просто где-то. Все это очень настраиваемо.
• если вашим пользователям потребуется возможность поиска по синонимам, это может быть поддержано.
• слова, которые не добавляют ценности индекс, могут быть опущены. Они называются стоп-словами. “the” является примером для английского языка.
• вы можете сохранить поля, используемые для управления индексом, например, дату записи, и можете удалять на основе дат
• он может обслуживать запросы при обновлении индекса (некоторое внимание к пакетным обновлениям в “commit”)
• это не просто установить в кластерном окружении, но, возможно, масштабируемость производительности/устойчивость не являются проблемой
• не требует большого объема ОЗУ; он строит индексы на диске