Быстрый поиск текста по журналам

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

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

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

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

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

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

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


search full-text-search scalability algorithm
person ReaperUnreal    schedule 02.10.2008    source источник
comment
попробуйте использовать grep в качестве внешнего инструмента, если он достаточно быстрый, вы можете взять исходный код gnu grep и интегрировать его непосредственно в свое приложение.   -  person gbjbaanb    schedule 02.10.2008
comment
Я бы хотел, но это юридическая проблема, если я включу это, я спросил о том, чтобы пойти по этому пути.   -  person ReaperUnreal    schedule 02.10.2008

Ответы (6)


arrow_upward
2
arrow_downward

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

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

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

person PeterAllenWebb    schedule 02.10.2008

arrow_upward
5
arrow_downward

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

person changelog    schedule 02.10.2008
comment
Правильно. Это и моя первая мысль, но OP действительно должен предоставить немного больше контекста, чтобы оценить, насколько полезным может быть это предложение. - person dmckee --- ex-moderator kitten; 02.10.2008

arrow_upward
2
arrow_downward

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

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

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

person davr    schedule 02.10.2008

arrow_upward
0
arrow_downward

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

Как долго сейчас продолжаются эти поиски?

person PeterAllenWebb    schedule 02.10.2008

arrow_upward
0
arrow_downward

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

person Hank Gay    schedule 02.10.2008

arrow_upward
-2
arrow_downward

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

person nathan    schedule 02.10.2008