#azure #azure-cognitive-search
#azure #azure-когнитивный поиск
Вопрос:
Я использую Azure Search complex types preview API (2017-11-11-Предварительный просмотр) для фильтрации / огранки по сложным типам. Все мои фильтры и фасеты создаются для свойств вложенного типа (не корневого типа) и выглядит так, как будто они объединяются не на правильном уровне вложенности, а только через корень документа. Например, у меня есть следующий документ в поисковом индексе
{
apartmentComplexId: "1",
apartmentTypes: [
{
bedroomCount: 1,
bathroomCount: 2
},
{
bedroomCount: 2,
bathroomCount: 3
}
]
}
apartmentTypes.bedroomCount и apartmentTypes.bathroomCount огранены и отфильтрованы. Результат фасета для dataset вернет
{
"apartmentTypes/bedroomCount": [
{
"count": 1,
"value": 1
},
{
"count": 1,
"value": 2
}
],
"apartmentTypes/bathroomCount": [
{
"count": 1,
"value": 2
},
{
"count": 1,
"value": 3
}
]
}
Когда я выполняю следующий запрос:
$filter=apartmentTypes/any(x: x/bedroomCount eq 1)amp;facet=apartmentTypes/bathroomCount
моя коллекция фасетов в ответе содержит все два возможных значения фасета для bathroomCount — 2 и 3 со значением 1 для каждого из них.
{
"apartmentTypes/bathroomCount": [
{
"count": 1,
"value": 2
},
{
"count": 1,
"value": 3
}
]
}
На следующем шаге я пытаюсь использовать данные фасета в моем более конкретном фильтре
$filter=apartmentTypes/any(x: x/bedroomCount eq 1 and x/bathroomCount eq 3)
Упс, у меня пустой результирующий набор.
Я понимаю, что более правильная строка фильтра должна быть чем-то вроде
$filter=apartmentTypes/any(x: x/bedroomCount) and values/any(x: x/bathroomcount eq 3)
но мне нужна именно такая функциональность — найденный объект должен содержать элемент в своей коллекции со всеми фасетными результатами.
Комментарии:
1. Фасетирование и фильтрация работают в области документа, а не в области элементов сложной коллекции (хотя вы можете написать коррелированные фильтры для сложной коллекции, как в вашем первом примере). Это сделано специально. Можете ли вы объяснить немного подробнее, почему второй фильтр не будет работать для вашего сценария?
2. Я добавил результаты фасета для каждого шага для более подробного объяснения
3. На самом деле это не объясняет, почему вам «нужна именно такая функциональность». Может помочь, если вы опишете это в терминах интерфейса конечного пользователя, который вы пытаетесь создать. На данный момент я не понимаю, почему вы просто не создали правильный некоррелированный фильтр.
4. У меня есть список жилых комплексов с типами квартир. И я хочу отфильтровать этот список по свойствам типа квартиры — количеству спален, ванных комнат и так далее. Поэтому, когда пользователь ищет комплексы с апартаментами с 2 спальнями и 1 ванной комнатой — я не могу показать ему комплексы, которые содержат апартаменты с 2 спальнями или 1 ванной комнатой.
5. Спасибо. Я переименовал поля в ваших примерах, чтобы привязать их к актуальной проблемной области. Это упрощает рассуждения. Теперь я понимаю, почему вы хотите выполнить фильтр, который помещает условие «и» внутри «любого» — это имеет смысл. Но, согласно вашему вопросу, если вы выполняете фильтрацию по жилым комплексам, которые содержат 1 спальню и 3 ванные комнаты, вы должны не получить результатов, поскольку такого типа апартаментов не существует. Проблема в том, как представлены фасеты?
Ответ №1:
Фасетирование и фильтрация работают в области документа, а не в области элементов сложной коллекции (хотя вы можете написать коррелированные фильтры для сложной коллекции, как в вашем первом примере). Это сделано специально.
В вашем сценарии это приводит к несоответствию ожиданий пользователя поведению системы. Как пользователь, если я просматриваю фасеты, описывающие апартаменты, я, естественно, предполагаю, что фильтрация происходит и в квартирах, но на самом деле это происходит в комплексах квартир. Вот почему пустой результирующий набор в вашем примере такой неинтуитивный.
Я бы рекомендовал моделировать ваши индексы в соответствии с тем, как пользователи будут перемещаться. Предполагая, что пользователи обычно ищут квартиры, а не жилые комплексы, попробуйте создать apartmentType тип документа и при необходимости денормализовать информацию о жилом комплексе.
Тем временем, пожалуйста, рассмотрите возможность создания элемента в «Голосе пользователя«, чтобы помочь нам расставить приоритеты при добавлении поддержки коррелированных фасетов по сравнению со сложными коллекциями.