Мы ищем разрозненные источники данных в нашей компании. У нас есть информация в нескольких базах данных, которые необходимо искать в нашей внутренней сети. Первые эксперименты с полнотекстовым поиском (FTS) оказались неутешительными. Мы внедрили пользовательскую поисковую систему, которая очень хорошо работает для наших целей. Однако мы хотим быть уверенными, что делаем «правильные вещи» и не упускаем ни одного замечательного инструмента, который облегчит нашу работу.
Что нам нужно:
- Поиск столбцов
- возможность поиска по столбцу
- мы отмечаем, какие столбцы в таблице доступны для поиска
- Сохранять некоторую связь между столбцом БД и данными
- мы предоставляем расширенную фильтрацию по результатам
- облегчает (в стиле амазонки) фильтрацию
- фильтр, предоставленный путем группировки результатов и позволяющий пользователю фильтровать их с помощью флажка
- это отличная функция, пользователям очень нравится
- Частичное совпадение слов
- у нас много уникальных идентификаторов (идентификатор продукта и т. Д.).
- уникальные идентификаторы могут иметь подразделы со значением (местоположение и т. Д.)
- или может быть доступна только часть (когда пользователь ищет)
- или (из-за явно неудачного решения по проекту) в id может быть пробел
- это основная функция, которую мы реализовали сейчас через CHARINDEX (MSSQL) и INSTR (ORACLE)
- использование функций индекса индекса оказалось эквивалентным (+/-) в MSSQL по сравнению с полным текстом
- не тестировал на Oracle
- однако поиск по обоим типам БД: очень быстрый
- Мы используем преимущества индексированных (MSSQL) и материализованных (Oracle) представлений для увеличения скорости
- это огромный выигрыш, материализованные представления Oracle лучше, чем индексированные представления MSSQL
- оба обеспечивают ускорение в ситуациях присоединения только для чтения (например, поиск компании и продукта)
- Поиск, который соответствует ожиданиям пользователя от парадигмы CTRL-f -> введите текст -> найти совпадения
- Полнотекстовый поиск не является лучшим в этой области (медленное и непоследовательное соответствие)
- частичное совпадение (см. «Частичное совпадение слов»)
Приятно иметь:
- Поиск базы данных в режиме реального времени
- пропустить индексирование пропустить, это не сложное требование
- орфографическое предложение
Что нам не нужно:
- Нам не нужно индексировать документы
- На данный момент поиск наших источников данных - самая важная вещь
- даже когда мы ищем документы, мы будем искать частичное совпадение слов и т. Д.
- Рейтинг
- Наш собственный простой алгоритм ранжирования оказался намного лучше, чем эквивалент FTS.
- Пользователи это понимают, мы понимаем, это почти всегда актуально.
- Морфологический
- Просто не нужно запускать [run | run | running]
- Расширенный поиск операторов
- совпадение фраз или / и т. Д.
- согласно Якобу Нильсену http://www.useit.com/alertbox/20010513.html
- большинство пользователей используют простые поисковые фразы
- очень немногие используют расширенный поиск (когда он доступен)
- также в Информационной архитектуре, 3-е издание, стр. 185
- "немногие пользователи пользуются ими [расширенные функции поиска]"
- http://oreilly.com/catalog/9780596000356
- наша Amazon-подобная фильтрация позволяет в любом случае улучшить фильтрацию (через пользовательское тестирование)
- Полнотекстовый поиск
- Мы обнаружили, что результаты не всегда "имеют смысл" для пользователя
- Поиск с помощью FTS трудно настроить (набор операторов соответствует ожиданиям пользователей)
- Операторы расширенного поиска не ходят
- они нам не нужны, потому что
- пользователи их не понимают
- Производительность была очень близка (+ / 1) к функциям индекса индекса
- но результаты иногда просто "странные"
Вопрос:
Существует ли решение, позволяющее нам сохранить пару «ключ-значение» «фильтрующей функцией», предлагающее сопоставление по столбцам, частичное сопоставление слов и остальные функции, без необходимости полнотекстового поиска?
Я открыт для любых предложений. Я задавался вопросом, может ли быть полезным хранилище данных nosql для документа / хеш-таблицы (MongoDB и др.)? (http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mongo). Любой опыт работы с ними приветствуется.
Опять же, просто убедитесь, что мы ничего не пропустили с нашей собственной настроенной версией. Если есть что-то "с полки", я был бы заинтересован в этом. Или, если вы создали что-то из некоторых компонентов, какие компоненты (поисковые системы, хранилища данных и т. Д.) Вы использовали и почему?
Вы также можете сделать свою точку зрения для FTS. Просто убедитесь, что он соответствует вышеуказанным требованиям, прежде чем сказать «просто используйте полнотекстовый поиск, потому что это единственный инструмент, который у нас есть».