Производительность фильтрации поиска Azure по Edm.Int32 и Collection (Edm.String)

Я использую поиск Azure на своем сайте электронной коммерции и теперь хочу реализовать фильтрацию.

Я столкнулся с проблемой с производительностью. У меня есть указатель с продуктами. Каждый продукт относится к категории. Каждая категория может иметь вложенные подкатегории. Моя бизнес-цель - когда покупатель находится на странице категории, мне нужно показывать продукты даже из подкатегорий, поэтому я сомневаюсь, как сохранить это отношение (продукты к категориям) в индексе продуктов лазурного цвета. Я рассматриваю две возможности:

  1. Я могу хранить только идентификатор категории товаров в поле с типом Edm.Int32. Затем, когда клиент переходит в эту категорию, я запрашиваю свой sql-сервер, чтобы получить все идентификаторы подкатегорий, а затем создавать свой запрос для индексации, как это

categoryId eq 34 или categoryId eq 36 или categoryId eq 37 ...

  1. Другой способ - создать поле с типом Collection (Edm.String) и сохранить идентификатор категории продуктов и идентификаторы вложенных категорий в этом поле, а затем мой запрос для индексации будет выглядеть следующим образом

categoryIds / any (c: c eq '35')

Так какой путь будет быстрее?


azure azure-cognitive-search faceted-search
person Volodymyr Gorodytskyi    schedule 28.03.2017    source источник
comment
Вы упомянули запрос SQL Server в варианте №1. Придется ли вам сделать это и для варианта №2?   -  person Bruce Johnston    schedule 29.03.2017
comment
Да, но дело не в этом. Я написал это для примера. Я могу хранить идентификаторы категорий в локальном кеше, поэтому получение идентификатора категории или идентификатора категории с идентификаторами подкатегорий не будет проблемой с производительностью.   -  person Volodymyr Gorodytskyi    schedule 29.03.2017
comment
Спасибо. Я просто хотел прояснить этот момент, прежде чем пытаться ответить на ваш вопрос.   -  person Bruce Johnston    schedule 30.03.2017

Ответы (1)


arrow_upward
1
arrow_downward

Вариант №2, вероятно, быстрее, поскольку количество документов в индексе будет намного меньше, но единственный способ убедиться в этом - провести некоторые эксперименты с вашими данными и запросами. Общая производительность запроса будет зависеть от других факторов, например от того, выполняете ли вы полнотекстовый поиск, фасетирование, геопространственную информацию и т. Д.

person Bruce Johnston    schedule 29.03.2017
comment
Спасибо. Я провел несколько тестов и пришел к выводу, что оба варианта занимают примерно одинаковое время, около 300 мс. Существенной разницы не заметил. - person Volodymyr Gorodytskyi; 30.03.2017
comment
В этом есть смысл. Вероятное выполнение фильтра для ваших запросов является лучшим вариантом и линейно зависит от количества индексируемых уникальных терминов, а не от количества документов. - person Bruce Johnston; 30.03.2017