легкая индексация документов для обработки менее 250 тыс. потенциальных записей


10

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

И даже тогда, когда мне нужно было обслуживать некоторые сложные данные и вычисления, которые требовали интенсивного использования базы данных, мне не нужно было обрабатывать более 250 тысяч потенциальных записей. Развертывание всего экземпляра Solr или ES только для того, чтобы справиться с этим, казалось пустой тратой.

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

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

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

  • Отсутствие функций обычно присутствует в полнотекстовых движках.

У баз данных была та же проблема, что и необходимость развертывания в качестве сервера, а затем появился SQLite, и внезапно мы смогли развернуть базу данных, которая содержалась в одном файле. Мой Googling ничего не дал - интересно, существует ли что-то подобное для полнотекстовой индексации / поиска.

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


5
Пожалуйста, не проводите здесь свое исследование рынка. Вопрос здесь не по теме. Возможно , вам повезет , если вы спросите об этом в onstartups , хотя вы должны сначала прочитать их FAQ.
Одд

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

16
Это сайт о концептуальных проблемах в разработке программного обеспечения. Пожалуйста, не спрашивайте о концептуальных проблемах, возникающих у вас при разработке программного обеспечения.
PSR

3
Там есть хороший вопрос ... Я думаю, что его просто нужно очистить, чтобы сделать его более четким и конкретным.
GrandmasterB

3
Если ваша единственная жалоба на SQLite - это отсутствие текстовой индексации, почему бы просто не использовать модуль расширения SQLite FTS4 ?
Брайан

Ответы:


2

Вы знаете, я должен сказать, рассмотреть вопрос об использовании Redis.

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

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

    Первое, что он делает, это дает вам полный список слов во всем вашем наборе. Все, что НЕ найдено в этом списке, автоматический возврат «нет результатов». Я бы посоветовал ранжировать результаты ниже, чем нижние 5-20% популярности (при выполнении поискового запроса по индексу), а также просто сказать, что нет результатов ».

  • Если вы используете что- то вроде redis или даже просто создаете свою собственную структуру памяти, вы можете объединить документы с файлами дескрипторов или файлами мини-БД и страницами, которые описывают каждый конкретный документ назад и вперед в память. Сохраняйте общие поиски в памяти, возможно, заставляя их конкурировать за слоты или давая им время на жизнь, которое увеличивается при каждом поиске.

  • Чтобы пойти дальше, начните сохранять справочные данные, которые группируют ссылку / ref / pointer / index / независимо от двух или более документов и пула ключевых слов или фраз. В основном вы получаете накачанное облако тегов.

  • Кроме того, сделайте обнаружение фразы, отслеживая, когда за словом в вашем словаре следует или предшествует точная строка, обычно в документах с подобными метаданными / заголовком. Это интенсивно, но для визуализации данных требуется всего один проход.

  • Чем больше способов разделить ваши данные и сохранить группы, связанные друг с другом, в реальном использовании, тем лучше.

  • Укажите вероятность правильности, отслеживая каждый раз, когда пользователь нажимает на результат, который не входит в тройку лидеров. Улучшение обнаружения фраз за счет просмотра пользовательских запросов, которые не дали идеальных результатов. Заставьте ваши запросы соответствовать запросам клиентов.

  • Нужно ли следить за обновлениями документов? Сценарии Chronjobs / shell или запланированные задачи / batch script могут помочь. Существуют различные варианты планирования и написания сценариев, хотя очевидно.

  • Тратьте диск, набирайте скорость, теряйте сложность. Сохраните несколько деревьев ваших документов и / или деревьев ссылок на документы. Выполняйте поиск только по тем деревьям, для которых были соблюдены критерии, или, по крайней мере, предпочитайте, чтобы в большинстве случаев результат получался быстрее.

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

  • Так много вещей.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.