Быстрый текстовый поиск по журналам - PullRequest
8 голосов
/ 02 октября 2008

Вот проблема у меня, у меня есть набор журналов, которые могут расти довольно быстро. Они делятся на отдельные файлы каждый день, и размер файлов может легко увеличиться. Чтобы уменьшить размер, записи старше 30 дней очищаются.

Проблема в том, что я хочу найти в этих файлах определенную строку. Прямо сейчас поиск Бойера-Мура невыносимо медленный. Я знаю, что такие приложения, как dtSearch, могут обеспечить действительно быстрый поиск с использованием индексации, но я не совсем уверен, как реализовать это, не занимая вдвое больше места, чем уже занимает журнал.

Могу ли я проверить какие-либо ресурсы, которые могут помочь? Я действительно ищу стандартный алгоритм, который объяснит, что я должен сделать, чтобы построить индекс и использовать его для поиска.

Edit:
Grep не будет работать, так как этот поиск необходимо интегрировать в кроссплатформенное приложение. Я никак не смогу включить в нее любую внешнюю программу.

То, как это работает, заключается в том, что есть веб-интерфейс с браузером журналов. Это говорит с пользовательским бэкэндом веб-сервера C ++. Этот сервер должен искать журналы в разумные сроки. В настоящее время поиск по нескольким выступлениям журналов занимает много времени.

Редактировать 2: Некоторые из этих предложений хороши, но я должен повторить, что не могу интегрировать другое приложение, это часть контракта. Но чтобы ответить на некоторые вопросы, данные в журналах могут отличаться от полученных сообщений в специальном формате здравоохранения или сообщений, относящихся к ним. Я полагаюсь на индекс, потому что, хотя перестройка индекса может занять до минуты, поиск в настоящее время занимает очень много времени (я видел, что это занимает до 2,5 минут). Кроме того, многие данные отбрасываются еще до их записи. Если не включены некоторые параметры ведения журнала отладки, более половины сообщений журнала игнорируются.

Поиск в основном происходит следующим образом: пользователю в веб-форме представлен список самых последних сообщений (передаваемых с диска по мере их прокрутки, yay для ajax), обычно они хотят искать сообщения с некоторая информация в нем, возможно, идентификатор пациента или какая-то строка, которую они отправили, чтобы они могли ввести эту строку в поиск. Поиск отправляется асинхронно, и пользовательский веб-сервер линейно просматривает журналы по 1 МБ за раз для получения некоторых результатов. Этот процесс может занять очень много времени, когда журналы становятся большими. И это то, что я пытаюсь оптимизировать.

Ответы [ 6 ]

5 голосов
/ 02 октября 2008

grep обычно хорошо работает с большими журналами (иногда 12G +). Вы также можете найти версию для Windows здесь .

2 голосов
/ 02 октября 2008

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

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

Кроме того, кого это волнует, если индекс больше, чем сами файлы? Если ваша система действительно такая большая, с такой большой активностью, то несколько десятков концертов для индекса - конец света?

2 голосов
/ 02 октября 2008

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

Лучший механизм текстового поиска для интеграции с пользовательским веб-приложением?

Как реализовать функцию поиска на сайте?

0 голосов
/ 03 октября 2008

Вы можете проверить источник для BSD grep. Возможно, вы не сможете положиться на grep, но ничего не говорит о том, что вы не можете воссоздать подобную функциональность, верно?

0 голосов
/ 02 октября 2008

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

0 голосов
/ 02 октября 2008

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

Сколько времени занимают эти поиски сейчас?

...