Зачем (или не должен) поисковый запрос возвращать только идентификаторы документов?

Question

Итак, для нового проекта я создаю систему для сайта электронной коммерции. Идея заключается в том, чтобы импортировать продукты у поставщиков и вместо того, чтобы вставлять их непосредственно в наш каталог, мы будем хранить всю информацию в промежуточной области. У каждого поставщика есть своя стадия (т. Е. Таблица в базе данных), а затем я буду сглаживать несколько промежуточных областей в единый объект (в настоящее время это одна таблица, но позже, возможно, в Sphinx или Solr). Затем наши мерчандайзеры смогут искать соответствующие поля промежуточных продуктов (имя и описание) и показывать список продуктов, которые соответствуют, а затем выбирать, чтобы эти продукты были перенесены в живой каталог. Поиск будет запрашивать одну таблицу (сплющенные области постановки).

Мой проект позволяет хранить только поля с возможностью поиска и фильтрации в одном плоском столе - например, имя, описание, поставщик_ид, поставщик_prod_id и т. д. И поисковые запросы возвратят только идентификаторы совпадающих элементов и класс (поставщик_ид), которые будут использоваться для определения, в какой области этапов находится продукт.

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

Я чувствую себя довольно уверенно только в том, что поля поиска доступны в сплющенной таблице, а поиск возвращает только пары классов/идентификаторов, которые могут быть использованы для извлечения всех других необходимых метаданных о продукте (простой выбор * из класса class_table, где id (1,2,3)).

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

Есть ли я на правильном пути? Как я могу убедить другого инженера, почему важно хранить только поля с возможностью поиска и возвращать только идентификаторы? Или, что конкретно, почему поисковое приложение возвращает только идентификаторы объектов?

Answer 1

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

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

Answer 2

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

Answer 3

Вы должны использовать каждый инструмент для своих целей. Полнотекстовая поисковая система, такая как Solr или Sphinx, отлично подходит для поиска текстовых полей и ранжирования хитов. Он не имеет особого преимущества в том, чтобы извлекать сохраненные данные выборочно. Для этого оптимизирована база данных. Итак, да, вы на правильном пути. Пожалуйста, см. Search Engine versus DBMS по другим вопросам, связанным с тем, чтобы решить, что хранить в поисковой системе.

Answer 4

Вы можете рассматривать Solr как мощный индекс, так как индекс возвращает ID, было бы логично, что solr делает то же самое.

Вы можете использовать параметр запроса solr fl, чтобы запрашивать только идентификаторы, например fl=id.

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

Сказанное должно иметь значение, как вы строите свои объекты в своей функции поиска, либо из БД, используя уникальное имя solr для получения идентификаторов, либо из возвращаемых полей solr (при условии, что они сохранены) или даже сочетание обоих. Подумайте, solr, чтобы получить «выделенные» поля содержимого и БД для других. Опять же, если вам не нужна подсветка, это не проблема.

Answer 5

Я использую Solr с тысячами документов, но возвращать только идентификаторы по следующим причинам:

Для Solr: - если какая-то синхронизация ошибка Append, это не имеет большого значения (особенно в вашем случае , отображение другой цены может быть большой проблемой ... это похоже на то, что элемент будет не в нужном месте, но данные верны) - вы сэкономите много времени, потому что, когда вы не попросите Солра вернуться «описание» документов (я имею в виду много строк текста)

Для вашей базы данных: - вы можете кэшировать свои результаты, так что это еще быстрее с идентификатором (вам не нужны все данные из Solr каждый раз !!!) - вы создаете результаты таким же образом (вам не нужен конкретный метод если вы хотите построить HTML из Solr, и другой метод из вашей БД)

Я думаю, что есть намного больше ...