Библиотека для индексации документов Golang?

Question

[DollyPapper]

Всем привет. Есть следующая задача. Есть некоторый лог файл по которому нужно искать из приложения. Файл может быть очень большой, по этому просто проходится по нему для каждого поискового запроса не варик. Ищу какое-то решение, или подход к проблеме.
Структура записи в этом логе всегда одинаковая, типа: event: role: time: и тд.
Допустим есть 100 записей в логе с event: "login". Нужно иметь возможно некоторый индекс, который хранит, что для event: "login" в файле имеются 100 записей в строках n, n+100, n+50000 и тд. Чтобы можно было быстро вытащить эти строки.
Смотрел в сторону полнотекстового поиска, но решение не подходит по нескольким причинам. Первая: нельзя использовать готовые поисковые движки типа эластика, потому что приложение хостится у разных заказчиков и доступа к этим инстансам чтобы их админить мы не имеем, а чем больше подвижных частей, тем более вероятно, что оно отвалится. Есть решения для го в качестве библиотек полнотекстового поиска, но они как я понял индексируют именно вхождения в документы, а у меня он один и мне нужно идексировать где конкретно в документе находится то что я ищу.
Может кто сталкивался с подобной задачей, направьте на путь верный пожалуйста)

Comments

[Дмитрий]

не совсем понятно. Логи у вас лежат? Или где то там?

[DollyPapper]

Дмитрий, где то там. Софт on-premise, хостится у заказчиков. Заказчики хотят эти логи видеть в веб морде и уметь по ним фильтровать.

[Дмитрий]

DollyPapper, а как вы к ним собираетесь обращаться что бы проиндексировать?

[DollyPapper]

Дмитрий, всмысле как? Они на том же сервере где и наш софт. Этот лог по сути огромный txt файл.

[Дмитрий]

DollyPapper, а. то есть у вас есть приложение которое работает на серваках, оно генерирует логи, и в этом приложении вам надо сделать фильтрацию по этим логам? А есть аргументы не использовать для генерации и хранения этих логов какую нибудь файловую бд тот же sqllite?

[DollyPapper]

Дмитрий, есть. Задача изначально была поставлена, что ФСТЕК требует эти логи в виде тестового файла (хз зачем, просто приняли как данность мимо меня). Теперь тот же ФСТЕК хочет чтобы была возможность смотреть и в веб морде и в тестовом файле. Больше аргументов нет.

[Дмитрий]

DollyPapper, А в сторону каких нибудь реализаций btree или b+tree индексов смотрели?

https://github.com/datastream/btree
https://github.com/timtadh/fs2/tree/master/bptree

[DollyPapper]

Дмитрий, да, сейчас как раз изучаю вопрос в сторону скорее inverted индексов.

Answer 1

[mayton2019]

Когда-то давным давно использовали logrotate. Эта утилита просто дробила лог на дневные и часовые
и прочие доли. Это позволяло искать быстрее. Если ты заранее знаешь что событие произошло например
за последние сутки а не за последние 10 лет к примеру. Но logrotate может не работать под Windows.

Коробочного решения для твоего вопроса я не знаю. Кроме Elastic ничего не приходит в голову.

Есть еще программный продукт Splunk. Но я его никогда не использовал поэтому советовать не буду. Почитай сам.

Вообще тебе нужен разработчик. Я думаю что дешевле всего трекать отдельные логи по событию event:login к примеру. Я так делал для сужения поиска. Для библиотек log4j это конфигурируется на уровне приложения.
Там как-то добавляется appender + rule.

Answer 2

[rPman]

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

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

Под БД я имею в виду любой инструмент который умеет индексировать записи и выделять структурные элементы (твои event: role: time: и тд.), причем возможна ситуация, когда сами данные дополнительно хранить не обязательно (хватит только индекса и информации о том где эти данные лежат),

в одном месте

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

p.s. От текстовых, а точнее не структурированных, логов лучше избавляться с самого начала разработки, причем буквально на столько, чтобы приложение вообще ничего не выдавало в stdout и stderr (кроме собственно хелпа и данных, если это потоковые инструменты), причем конечно красивее централизованно красиво собирать логи по сети в хорошую БД, но не обязательно, иногда даже простая сериализация объектов в php:serialize/json по событиям по строчкам в тот же лог файл уже лучше, ведь такие файлы обрабатывать на порядок проще (json можно парсить на скорости гигабайты в секунду потоковыми парсерами, и это в одном потоке)... ну на это на сколько я знаю куча библиотек написано, в т.ч. прямо встроенные в ОС

Answer 3

[darst]

Читай лог файл и пиши данные, например, в кликхаус.

Comments

[DollyPapper]

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

Читай сначала вопрос

[darst]

DollyPapper, прочитал. У вас задача сводится к тому, что нужно сделать бд, чтобы быстрее искать данные. И ещё раз, вы сами себе усложняете жизнь и собираетесь делать, то что до вас уже сделано. Поставьте тот же грейлог на строне заказчика, загрузите в него файл лога и через api забирайте те данные, которые вам нужно выводить на странице. Можете установить его на отдельный сервер и предоставить доступ к веб интерфейсу, тем кому надо.

Answer 4

[lelvisl]

https://github.com/google/codesearch