Azure AI 검색의 성능 향상을 위한 팁
이 문서는 키워드 검색의 쿼리 및 인덱싱 성능을 향상하기 위한 팁과 모범 사례 컬렉션입니다. 검색 성능에 가장 큰 영향을 줄 수 있는 요소를 알면 비효율성을 방지하고 검색 서비스를 최대한 활용하는 데 도움이 될 수 있습니다. 몇 가지 주요 요소는 다음과 같습니다.
- 인덱스 구성(스키마 및 크기)
- 쿼리 디자인
- 서비스 용량(계층, 복제본 수 및 파티션 수)
참고 항목
대량 인덱싱 전략을 찾고 계신가요? Azure AI 검색에서 대용량 데이터 세트 인덱싱을 참조하세요.
인덱스 크기 및 스키마
쿼리는 더 작은 인덱스에서 더 빨리 실행됩니다. 이는 부분적으로 검사할 필드가 더 적은 기능이지만, 시스템에서 이후 쿼리를 위해 콘텐츠를 캐시하는 방식으로 인해 발생할 수 있습니다. 첫 번째 쿼리 후에도 일부 콘텐츠는 더 효율적으로 검색되는 메모리에 남아 있습니다. 인덱스 크기는 시간이 지남에 따라 증가하는 경향이 있으므로 한 가지 모범 사례는 스키마와 문서 모두에서 인덱스 구성을 정기적으로 다시 방문하여 콘텐츠를 줄일 수 있는 기회를 찾는 것입니다. 그러나 인덱스가 적절한 크기인 경우 복제본을 추가하거나 서비스 계층을 업그레이드하여 용량을 늘리는 것만이 유일하게 보정할 수 있는 방법입니다. "팁: 표준 S2 계층으로 업그레이드" 섹션에서는 수직 스케일 업과 수평 스케일 아웃 결정에 대해 설명합니다.
스키마 복잡성은 인덱싱 및 쿼리 성능에 부정적인 영향을 미칠 수도 있습니다. 과도한 필드 특성은 제한 사항 및 처리 요구 사항을 기반으로 합니다. 복합 형식은 인덱싱하고 쿼리하는 데 더 오래 걸립니다. 다음 몇 가지 섹션에서는 각 조건에 대해 살펴봅니다.
팁: 선택적 필드 특성 사용
검색 인덱스를 만들 때 관리자 및 개발자가 범하는 일반적인 실수는 필요한 속성만 선택하는 것 아니라 필드에 사용할 수 있는 모든 속성을 선택하는 것입니다. 예를 들어 필드가 전체 텍스트 검색 가능일 필요가 없는 경우 검색 가능 특성을 설정할 때 해당 필드를 건너뜁니다.
필터, 패싯 및 정렬 지원을 사용하는 경우 스토리지 요구 사항을 4배로 늘릴 수 있습니다. 제안기를 추가하면 스토리지 요구 사항이 더 늘어납니다. 특성이 스토리지에 미치는 영향에 대한 설명은 특성 및 인덱스 크기를 참조하세요.
요약하면 과도한 특성의 결과는 다음과 같습니다.
필드의 콘텐츠를 처리하고 검색 반전 인덱스 내에 저장하는 데 필요한 추가 작업(검색 가능한 콘텐츠가 포함된 필드에만 "검색 가능" 특성 설정)으로 인해 인덱싱 성능이 저하됩니다.
각 쿼리에서 처리해야 하는 더 큰 표면을 만듭니다. 검색 가능으로 표시된 모든 필드는 전체 텍스트 검색에서 검사됩니다.
추가 스토리지로 인해 운영 비용이 증가합니다. 필터링 및 정렬에는 분석되지 않은 원래 문자열을 저장하기 위한 추가 공간이 필요합니다. 필요하지 않은 필드에는 필터링 가능 또는 정렬 가능 특성을 설정하지 마세요.
대부분의 경우 과도한 특성으로 인해 필드 기능이 제한됩니다. 예를 들어 패싯 가능, 필터링 가능 및 검색 가능 필드인 경우 필드 내에 16KB의 텍스트만 저장할 수 있지만, 검색 가능한 필드는 최대 16MB의 텍스트를 저장할 수 있습니다.
참고 항목
불필요한 특성만 피해야 합니다. 필터와 패싯은 검색 환경에 필수적인 경우가 많으며, 필터가 사용되면 결과를 정렬할 수 있도록 정렬이 필요한 경우가 많습니다(필터 자체는 정렬되지 않은 집합으로 반환됨).
팁: 복합 형식에 대한 대안 고려
복합 데이터 형식은 JSON 문서에 있는 부모-자식 요소와 같이 데이터에 복잡한 중첩 구조가 있는 경우에 유용합니다. 복합 형식의 단점은 복잡하지 않은 데이터 형식에 비해 콘텐츠를 인덱싱하는 데 필요한 추가 스토리지 요구 사항 및 추가 리소스가 있다는 것입니다.
경우에 따라 복합 데이터 구조를 컬렉션과 같은 더 단순한 필드 형식에 매핑하여 이러한 단점을 방지할 수 있습니다. 또는 필드 계층 구조를 개별 루트 수준 필드로 평면화하도록 선택할 수 있습니다.
쿼리 디자인
쿼리 구성 및 복잡성은 성능에 가장 중요한 요소 중 하나이며 쿼리 최적화는 성능을 크게 개선시킬 수 있습니다. 쿼리를 설계할 때 다음 사항을 고려합니다.
검색 가능한 필드 수. 검색 가능한 필드가 추가될 때마다 검색 서비스에 더 많은 작업이 필요합니다. "searchFields" 매개 변수를 사용하여 쿼리 시 검색되는 필드를 제한할 수 있습니다. 성능 향상을 위해 관심 있는 필드만 지정하는 것이 가장 좋습니다.
반환되는 데이터 양. 많은 양의 콘텐츠를 검색하면 쿼리 속도가 느려질 수 있습니다. 쿼리를 구조화할 때 결과 페이지를 렌더링하는 데 필요한 필드만 반환한 다음, 사용자가 일치 항목을 선택하면 조회 API를 사용하여 나머지 필드를 검색합니다.
부분 용어 검색 사용. 접두사 검색, 퍼지 검색 및 정규식 검색과 같은 부분 용어 검색은 결과를 생성하기 위해 전체 인덱스 검색을 수행해야 하므로 일반적인 키워드 검색보다 계산 비용이 더 많이 듭니다.
패싯 수. 패싯을 쿼리에 추가하려면 각 쿼리에 대한 집계가 필요합니다. 패싯에 대해 더 많은 “개수”를 요청하면 서비스에서 추가 작업을 해야 합니다. 일반적으로 앱에서 렌더링하려는 패싯만 추가하고 필요한 경우가 아니면 패싯에 대해 높은 수를 요청하지 않도록 합니다.
큰 skip 값.
$skip매개 변수를 큰 값(예: 천 단위)으로 설정하면 엔진에서 각 요청에 대해 더 큰 문서를 검색하고 순위를 지정하기 때문에 검색 대기 시간이 증가합니다. 성능상의 이유로, 큰$skip값을 피하고 필터링과 같은 다른 기술을 사용하여 많은 수의 문서를 검색하는 것이 가장 좋습니다.높은 카디널리티 필드 제한. 높은 카디널리티 필드는 상당히 많은 수의 고유 값이 있는 패싯 가능 또는 필터링 가능한 필드를 나타내며, 결과적으로 결과를 계산할 때 상당한 리소스를 소비합니다. 예를 들어 제품 ID 또는 설명 필드를 패싯 가능 및 필터링 가능으로 설정하면 문서 간에 대부분의 값이 고유하므로 높은 카디널리티 필드로 간주됩니다.
팁 : 필터 조건을 오버로드하는 대신 검색 함수 사용
쿼리가 점점 더 복잡한 필터 조건을 사용함에 따라 검색 쿼리의 성능이 저하됩니다. 사용자 ID를 기준으로 결과를 자르는 필터를 사용하는 방법을 보여 주는 다음 예제를 살펴봅니다.
$filter= userid eq 123 or userid eq 234 or userid eq 345 or userid eq 456 or userid eq 567
이 경우 필터 식을 사용하여 각 문서의 단일 필드가 가능한 사용자 ID의 많은 값 중 하나인지 확인합니다. 보안 조정(쿼리를 실행하는 사용자를 나타내는 보안 주체 ID 목록에 대해 하나 이상의 보안 주체 ID가 포함된 필드 확인)을 구현하는 애플리케이션에서 이 패턴을 찾을 가능성이 가장 높습니다.
많은 수의 값이 포함된 필터를 더 효율적으로 실행하는 방법은 다음 예제와 같이 search.in 함수를 사용하는 것입니다.
search.in(userid, '123,234,345,456,567', ',')
팁 : 느린 개별 쿼리에 대한 파티션 추가
일반적으로 쿼리 성능이 저하되는 경우 복제본을 추가하면 문제가 해결되는 경우가 많습니다. 그러나 완료하는 데 너무 오래 걸리는 단일 쿼리 문제인 경우 어떻게 할까요? 이 시나리오에서 복제본을 추가하는 것은 도움이 되지 않지만 더 많은 파티션이 도움이 될 수 있습니다. 파티션은 데이터를 추가 컴퓨팅 리소스로 분할합니다. 두 개의 파티션은 데이터를 절반으로, 세 번째 파티션은 1/3로 분할하는 식입니다.
파티션을 추가할 때의 한 가지 긍정적인 부작용은 병렬 컴퓨팅으로 인해 느린 쿼리가 더 빠르게 수행된다는 것입니다. 많은 문서와 일치하는 쿼리 또는 많은 수의 문서에 대한 개수를 제공하는 패싯과 같이, 선택 수준이 낮은 쿼리를 병렬화했습니다. 문서의 관련성을 채점하거나 문서를 계수하는 데 상당한 계산이 필요하므로 파티션을 추가하면 쿼리를 더 빨리 완료할 수 있습니다.
파티션을 추가하려면 Azure Portal, PowerShell, Azure CLI 또는 관리 SDK를 사용합니다.
서비스 용량
쿼리가 너무 오래 걸리거나 서비스에서 요청을 삭제하기 시작하면 서비스에 과부하가 걸립니다. 이 경우 서비스를 업그레이드하거나 용량을 추가하여 문제를 해결할 수 있습니다.
검색 서비스의 계층과 복제본/파티션 수도 성능에 큰 영향을 줍니다. 점진적으로 더 높은 각 계층은 더 빠른 CPU와 더 많은 메모리를 제공하며 둘 다 성능에 긍정적인 영향을 미칩니다.
팁: 새 대용량 검색 서비스 만들기
2024년 4월 3일 이후 지원되는 지역에서 만든 기본 및 표준 서비스에는 기존 서비스에 비해 파티션당 스토리지가 더 들어 있습니다. 더 높은 계층 및 더 높은 청구 가능 요금으로 업그레이드하기 전에 계층 서비스 제한을 다시 검토하여 같은 계층이 최신 서비스에서 필요한 스토리지를 제공하는지 확인합니다.
팁: 표준 S2 계층으로 업그레이드
표준 S1 검색 계층은 고객이 시작하는 경우가 많습니다. S1 서비스의 일반적인 패턴은 시간이 지남에 따라 인덱스가 증가하며, 이에 따라 파티션이 더 많이 필요합니다. 파티션이 많을수록 응답 시간이 느려지므로 쿼리 로드를 처리하기 위해 더 많은 복제본이 추가됩니다. 짐작할 수 있듯이 S1 서비스를 실행하는 데 드는 비용은 이제 초기 구성 이상의 수준으로 진행되었습니다.
이 분기 시점에서 중요 한 질문은 현재 서비스의 파티션 또는 복제본 수를 점진적으로 늘리는 대신 상위 계층으로 이동하는 것이 유용한지 여부입니다.
용량 수준이 증가한 서비스의 예로 다음 토폴로지를 생각해 보세요.
- 표준 S1 계층
- 인덱스 크기: 190GB
- 파티션 수: 8개(S1에서 파티션 크기는 파티션당 25GB)
- 복제본 수: 2개
- 총 검색 단위 수: 16개(8개 파티션 x 2개 복제본)
- 가상 소매 가격: $4,000 USD 이하/월(250 USD x 16개 검색 단위 가정)
서비스 관리자가 여전히 더 높은 대기 시간 비율을 확인하여 다른 복제본을 추가하는 것을 고려하고 있다고 가정합니다. 이렇게 하면 복제본 수가 2에서 3으로 변경되고, 이에 따라 검색 단위 수가 24로 변경되며, 결과적으로 $6,000 USD/월의 가격이 됩니다.
그러나 관리자가 표준 S2 계층으로 이동하도록 선택한 경우 토폴로지는 다음과 같습니다.
- 표준 S2 계층
- 인덱스 크기: 190GB
- 파티션 수: 2개(S2에서 파티션 크기는 파티션당 100GB)
- 복제본 수: 2개
- 총 검색 단위 수: 4개(2개 파티션 x 2개 복제본)
- 가상 소매 가격: $4,000 USD 이하/월(1,000 USD x 4개 검색 단위 가정)
이 가상 시나리오에서 설명한 대로 처음에 더 높은 계층을 선택한 것처럼 비슷한 비용이 발생하는 더 낮은 계층의 구성을 사용할 수 있습니다. 그러나 더 높은 계층에는 고급 스토리지가 제공되므로 인덱싱 속도가 빨라집니다. 또한 더 높은 계층에는 추가 메모리뿐만 아니라 훨씬 더 많은 컴퓨팅 성능도 있습니다. 동일한 비용으로 동일한 인덱스를 지원하는 더 강력한 인프라를 사용할 수 있습니다.
추가된 메모리의 중요한 이점은 더 많은 인덱스를 캐시할 수 있으므로 검색 대기 시간이 단축되고 초당 쿼리 수가 늘어난다는 것입니다. 이 추가 기능을 사용하는 경우 관리자는 복제본 수를 늘릴 필요도 없고, 잠재적으로 S1 서비스를 유지하는 것보다 더 적은 비용을 지불할 수 있습니다.
팁: 정규식 쿼리에 대한 대안 고려
정규식 쿼리 또는 정규식은 특히 비용이 많이 들 수 있습니다. 이렇게 하면 고급 검색에 매우 유용할 수 있지만 실행에 많은 처리 능력이 필요할 수 있으며, 정규식이 복잡하거나 많은 양의 데이터를 검색하는 경우 특히 그렇습니다. 이러한 모든 요소는 검색 대기 시간을 높이는 데 영향을 줍니다. 이러한 상황을 완화하려면 정규식을 단순화하거나 복잡한 쿼리를 더 작고 관리하기 쉬운 쿼리로 분할합니다.
다음 단계
서비스 성능과 관련된 다른 문서를 검토합니다.