Доброго дня.
Вопрос будет без кода, нужны ваши идеи в плане реализации.
Стоит задача отображать логи работы системы в админке. Пользователь может фильтровать логи по типам событий, может выбирать диапазон времени за которое хочет просмотреть события. Что самое неприятное в этой задаче, та кэто то, что нет какой-то конкретной идеи формирования самого файла логов. В одной подсистеме один файл логов - событие за одни сутки. В другой, один файл это 1 Мбайт логов. В связи с этим приходится писать “универсального бойца”, который к тому же должен быстро работать. Сейчас я изобретаю свой велосипед, но может он уже есть, кто знает подскажите?
Мое решение работает крайне медленно. И выдает порядка 90 секунд на чтение 2-х файлов размер 80 Мбайт каждый.

Алгоритм, который я реализую:
1. Собираю все файлы с расширение .log в массив, который сортирую в порядке убывания даты последнего редактирования файла. ()
2. Отбрасываю файлы, которые явно не подходят мне по дате.
3. Остальные файлы читаю по очереди по 8 Кбайт (значение получено эмпирическим путем).
4. В каждом куске ищу нахлжу первое вхождение целой строки, проверяю ее дату на вхождение в пользовательский периода. Если дата не входит, беру следующие 8 Кбайт. Если входит. Ищу ту запись которая является приграничной. И т.д. пока не найду приграничную запись конца периода.
4. После чего склеиваю эти словари в один (каждый приходится разворачивать, чтобы сохранить хронологию событий).

P.S. Читаю файл частями, т.к. в связи с неизвестным размером файла лога, могу занять всю память.

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

SergeyChmutov
А вы сейчас базу данных не изобретаете?

FishHook
SergeyChmutovА вы сейчас базу данных не изобретаете?

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

SergeyChmutov
Например когда база не доступна и соответсвенно логи, по которым можно было бы понять что в системе произошло. Может не так вас понял.

Что значит база недоступна? Вы пишите свои логи в файлы. Ваши файлы могут быть недоступны? База данных это тоже набор файлов, только они особым образом структурированы и индексированы. То что вы сейчас придумываете для ускорения ваших действий

SergeyChmutov
читаю по очереди по 8 Кбай

SergeyChmutov
В каждом куске ищу нахлжу первое вхождение целой строки

это как раз и есть попытка структурировать и индексировать.

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

SergeyChmutov
Если я иду в сторону изобретение велосипед под название БД, вероятно, это правильно направление (в моем частном случае)?

Скорее всего нет. Вообще, когда админские задачи пытаются решать программированием, то скорее всего делают какую-то ерунду. Вы же наверняка не первый человек, которому пришлось обрабатывать большое количество логов? Наверняка есть готовый набор инструментов на любой вкус.

SergeyChmutov
Только принято решение (не мной), хранить логи в файлах. Если я иду в сторону изобретение велосипед под название БД

Для логов нужны не совсем базы данных. Это даже скорее не базы данных.

https://en.wikipedia.org/wiki/Time_series_database
https://dzone.com/articles/5-data-storages-for-better-log-management
https://www.fluentd.org/

SergeyChmutov
3. Остальные файлы читаю по очереди по 8 Кбайт (значение получено эмпирическим путем).

Это и замедляет скорость, и даёт неточность, и усложняет код через усложнение алгоритма анализа.

SergeyChmutov
4. В каждом куске ищу нахлжу первое вхождение целой строки, проверяю ее дату на вхождение в пользовательский периода. Если дата не входит, беру следующие 8 Кбайт. Если входит. Ищу ту запись которая является приграничной. И т.д. пока не найду приграничную запись конца периода.

Надо сделать читатель записей лога. То есть сначала ты ему подаешь сырые данные какими-то блоками, он их разделяет по границам записей и выдаёт на выход уже правильно разграниченные записи. И вот когда у тебя получаются точные отдельные записи, тогда с ними и можно работать в плане анализа.

SergeyChmutov
Сейчас смотрю в сторону того, чтобы искать (бинарным поиском) границы периода только в файлах

Не надо искать в файлах. Это сырые данные. Надо их привести к очищенным данным и искать в очищенных то, что нужно найти.

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

SergeyChmutov
нужны ваши идеи в плане реализации.

Добавлю что для выдачи вам идей нужно больше информации.
1 Насколько часто идут запросы (если нагруженная админка то наверное часто). Какие требования к быстродействию и ограничения по памяти? Какие требования по актуальности данных при выполнении запросов (За время выполнения запроса данные дозапишутся, должны они присутствовать в результатах?)
2 Приведите примеры в виде фрагментов Лог файлов. Пока вроде по вашему описанию у события есть тип и время и описание. Но непонятно насколько сложно парсить данные. Сколько есть типов событий, насколько часто меняется формат логов.
3 По архитектуре системы допустимо ли изменить метод логгирования? Допустима ли запись в базу данных?
по идеям.
Неплохо сразу писать логи в tsdb (или для упрощения системы в бд вашего сайта).
Если не можете первое то обычный подход перегонять логи в tsdb по мере появления. Для этого обычно в базе создают структуры указывающие на последние прочитанные данные, чтобы потом читать с этого места, а в базе устраивают постепенное вытеснение старых данных.

В общем вчера копался в своем коде и нашел узкое (действительно узкое место), которое забирало на себя около 80-90% времени выполнения. Стыдно признать этим оказалась пагинация, которая была реализована, по уже подготовленному JSON. Сейчас перенес ее в контроллер. И теперь вуаля). Правда осталось разобраться, как быстро фильтровать события по их типу.