Лучший способ хранить большие текстовые файлы с возможностью поиска - PullRequest
2 голосов
/ 18 сентября 2011

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

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

Он также должен быть быстрым и максимально эффективным (использование памяти и процессора). Будет учитываться любой формат хранения (текстовые файлы MySQL, JSON или XML и т. Д.), Если запросы можно выполнять без учета форматирования. Размер и количество файлов на самом деле не имеют значения, так что разделение книг или даже глав на отдельные файлы мне подходит.

Еще одна важная вещь, которую нужно иметь в виду, это то, что я хочу использовать метод поиска, способный искать по нескольким стихам. Таким образом, поиск «, но вечную жизнь для Бога послал не Его Сын » вернул бы Иоанна 3: 16,17 . Спасибо за все идеи!

Ответы [ 2 ]

2 голосов
/ 18 сентября 2011

Существует множество различных поисковых систем с открытым исходным кодом, которые созданы именно для того, что вы пытаетесь сделать. Solr, Elastic Search, Xapian, Whoosh, Haystack (для Django) и другие. Есть и другие посты на С.О. и в других местах, где есть преимущества использования одного против другого, но ваши требования достаточно просты, чтобы любое из них было более чем удовлетворительным (и легко масштабируемым с минимальными усилиями, если ваш проект взлетает, что всегда приятно знать). Итак, посмотрите на их примеры и посмотрите, какой из них выглядит наиболее интуитивно понятным - возможно, Solr - самый популярный и единственный, с которым я работал, но Elastic Search использует тот же самый популярный бэкэнд Lucene, и его, очевидно, гораздо легче получить и работает, поэтому я бы начал там.

Что касается фактической реализации, вы захотите проиндексировать каждый стих как отдельный «документ», если вы хотите вернуть один стих (или просто номер стиха). Поисковая система обрабатывает ранжирование результатов на основе релевантности (обычно, если вам интересно, с использованием алгоритма tf / idf).

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

Слово предостережения - если вы не знакомы с индексированием поиска, даже для чего-то, разработанного так, чтобы быть гибким, как Elastic Search, вероятно, все же потребуется некоторое время и усилия для настройки, поэтому, если вы абсолютно нужно , чтобы быстро это запустить и запустить, и вы уже знакомы с MySQL, я полагаю, он может работать (он выполняет полнотекстовый поиск). Но это, безусловно, не лучший инструмент для работы, поэтому, если это проект, в который вы вложили деньги, вы поблагодарите себя позже, если потратите немного времени на изучение одной из этих поисковых систем. Как указывали другие, это может быть излишним с точки зрения количества текста, с которым вы имеете дело, но оно будет чрезвычайно гибким в том, как вы можете искать по этому тексту, который, кажется, вам нужен. Например, добавление других требований позже будет очень простым (например, вы можете позволить людям ограничить свой поиск только совпадениями в красном тексте).

1 голос
/ 18 сентября 2011

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

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

Если стих представляет собой простой текст, вы можете легко сделать его доступным для поиска, сохранив его в MySQL и создав для него индекс FULLTEXT.Таким образом, вы можете выполнять поиск достаточно эффективно и даже использовать подстановочные знаки и т. Д.

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

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

...