이유는 1-3mln + 데이터 항목 (~ 50GB)이있을 때 패싯에 대해 올바른 숫자를 반환 할 수없는 Algolia를 사용하고 있기 때문입니다. 우리는 검색합니다. Algolia techs가 확인한 바에 따르면 검색 시간을 최적화하므로 잘못 계산하여 데이터를 줄이는 것이 더 빠릅니다. 그리고 그들은 주로 FTS에 초점을 맞추고 있습니다.수백만 개의 항목을 검색 할 때 Azure 검색이 패싯에서 올바른 개수를 반환합니까?
그냥 Azure 검색에 대한 접근 방식을 확인하고 싶습니다. 우리는 Azure 검색에 의존 할 수 있습니까? 아니면 우리 자신을 얼굴을보아야합니까?
주로 말하는 경우 사례 - 판매 할 수있는 항목 (SKU)이 많은 전자 상거래 앱 (인터넷 상점)이며 우리는 패싯 필터링을 통해 검색 할 수있는 기능을 제공하고자합니다.
하늘색 검색은면 처리 된 필드의 고유 값 수보다 크거나 같은 수를 요구하지 않는 한 정확한면 수를 보장하지 않습니다. 당신은 10 개 개의 고유 값으로 category 필드가 예를 들어,이 부정확 한 수를 반환 할 수 있습니다
GET /indexes/myindex/docs?facet=category,count:3&api-version=2016-09-01
을이 정확한 카운트를 반환하는 동안 :
그러나
GET /indexes/myindex/docs?facet=category,count:10&api-version=2016-09-01
count에 큰 값을 사용하는 많은 고유 값은 성능에 부정적인 영향을 줄 수 있습니다.
이
는 official docs on Azure Search facets 내지 : 카운트 파라미터가 고유 용어의 수보다 적은 경우, 결과가 정확하지 않을 가참고. 이는 패어 닝 쿼리가 샤드에 분산되는 방식 때문입니다. 카운트가 증가하면 일반적으로 용어 집계의 정확성은 향상되지만 성능 비용은 증가합니다.
흥미로운 부분 정확도에 대한 discussion on the MSDN forums도 있습니다.
고마워요! 그것은 제가 예상했던 종류의 대답이었습니다. 우리 측의 Az Search를 평가하여 거대한 카운트에 대한 perf lags를 찾아 낼 것입니다. – zmische
그냥 호기심 - 카운트의 정확성이 왜 그렇게 중요한가요? 아주 짧은 시간에 엄청난 양의 데이터에 대한 정확한 계산을 계산하는 것은 어려운 문제입니다. 그렇지 않으면 모든 사람이 그렇게 할 것입니다. :-) 어떤 검색 솔루션을 선택하든 상관없이 성능에 대한 정확성을 절충해야 할 수도 있습니다. –
Bruce Johnston - 상점 사이트에서 최종 사용자에게 "T-shirts 125; Hats - 150"과 같은 올바른 개수를 표시하는 것이 좋으므로 그 중 하나 (모자)를 선택하면 페이지 합계가 150 자로 끝납니다. 350 또는 다른 번호가 아닙니다. 그것은 단지 사용자를 혼란스럽게합니다. – zmische