본문으로 건너뛰기
최종 수정: 에

Lance 하이브리드 검색 성능 모범 사례

Lance에서 벡터 또는 전문 검색을 수행할 때 스칼라 조건도 적용해야 한다면 이 가이드를 참고하세요. 필터를 배치하고, 인덱스 세그먼트를 구성하고, 반복되는 필터링 작업을 식별하는 방법을 설명합니다. 여기서 하이브리드 검색은 검색 결과에 스칼라 필터링을 결합하는 것을 뜻합니다. 벡터 TVF와 전문 검색 TVF를 각각 호출한다고 해서 두 결과의 순위가 자동으로 융합되지는 않습니다.

노트

Lance Catalog는 실험적 기능이며 Apache Doris 4.2부터 지원됩니다. 먼저 Lance Catalog에서 접근 방법을 설정하고 리더/라이터 호환성 요구 사항을 확인하세요. Doris는 기존 Lance 인덱스를 읽습니다. 인덱스는 호환되는 Lance 도구로 구축하고 유지 관리하세요. 최신 Lance SDK나 업스트림 제안이 사용 중인 Doris 빌드에 포함된 리더의 지원을 보장하지는 않습니다.

1. 후보 필터를 검색 내부에 배치하기​

정수형 id, 문자열 category, 문자열 content, 그리고 차원이 넷인 벡터 embedding을 포함하도록 설정된 테이블에서, 후보 생성에 영향을 주어야 하는 조건은 TVF의 filter 매개변수에 지정하세요. 벡터 인덱스의 차원과 거리 측정 방식은 쿼리와 일치해야 하며, 텍스트 열에는 커밋된 FTS 인덱스가 있어야 합니다.

SELECT id, _distance
FROM vector_search(
    "table" = "lance_catalog.default.items",
    "column" = "embedding",
    "query_vector" = "[0.1,0.2,0.3,0.4]",
    "metric" = "l2",
    "top_k" = "20",
    "filter" = "category = 'book'",
    "use_index" = "true"
)
ORDER BY _distance ASC, id;

이 쿼리는 조건에 맞는 행 가운데 가까운 이웃을 최대 20개 검색합니다. 근사 검색이므로 행이 20개 반환되었다고 해서 재현율이 입증되는 것은 아닙니다. 필터를 적용한 전문 검색은 다음과 같습니다.

SELECT id, _score
FROM full_text_search(
    "table" = "lance_catalog.default.items",
    "column" = "content",
    "query" = "storage engine",
    "query_type" = "match",
    "operator" = "and",
    "top_k" = "20",
    "filter" = "category = 'book'",
    "coverage_mode" = "strict"
)
ORDER BY _score DESC, id;

이 쿼리는 일치하는 문서를 최대 20개 반환하며 BM25 점수로 순위를 매깁니다. TVF 밖에 지정한 WHERE category = 'book'은 의미가 다릅니다. Doris가 Lance에서 이미 생성한 후보를 전역 TopN 전에 필터링하며, 제거된 후보는 자동으로 보충되지 않습니다. EXPLAIN에서 해당 조건이 Doris Scan 연산자 안에 표시되더라도, TVF 밖에는 검색 후 적용하려는 조건만 두세요.

2. 병렬 작업의 단위 이해하기​

Query snapshot
  -> FE plans physical search-index segment splits
  -> Each split: scalar Prefilter -> vector or full-text candidates
  -> Doris residual filtering -> local TopN -> global TopN
  -> Optional deferred fetch of output columns
쿼리 경로분할 기준결과
인덱스 기반 벡터 검색선택된 물리적 벡터 인덱스 세그먼트. 인덱스로 처리되지 않는 프래그먼트에는 Flat Search 분할이 생성됨스칼라 인덱스 세그먼트가 벡터 쿼리의 분할 수를 독립적으로 결정하지 않습니다. 인덱스가 없는 데이터가 지연 시간을 좌우할 수 있습니다.
전문 검색선택된 물리적 FTS 인덱스 세그먼트기본 strict 커버리지 모드는 인덱스로 처리되지 않는 프래그먼트가 있으면 쿼리를 거부하고, index_only는 이를 제외합니다. 전문 검색에는 Flat Search 대체 경로가 없습니다.
일반 스칼라 스캔자체 스캔 계획을 따르며, 스칼라 인덱스 세그먼트나 프래그먼트 그룹을 사용할 수 있음스칼라 쿼리만 포함된 계획에서 필터 적용 벡터 쿼리의 병렬도를 추론하지 마세요.

lance_fragments_per_split은 일반 프래그먼트 스캔의 그룹화를 제어하며, 물리적 벡터 인덱스 세그먼트 수를 제어하지는 않습니다. 파이프라인 인스턴스나 스캐너 동시 실행 수를 늘려도 플래너가 생성한 수보다 많은 벡터 세그먼트 분할을 만들 수는 없습니다. Lance 스캐너도 내부적으로 병렬 작업을 수행할 수 있으므로 Doris 스캐너 하나가 CPU 스레드 하나에 해당하는 것은 아닙니다.

검색 분할이 S개라면 각 분할은 최대 top_k + offset개의 후보를 반환할 수 있습니다. 따라서 잔여 필터링과 전역 TopN 이전, 병합 전 후보 수의 상한은 S * (top_k + offset)입니다. 세그먼트를 늘리면 작업 분산이 개선될 수 있지만 세그먼트별 준비, 필터링, 후보 병합, 동시 메모리 수요도 증가합니다.

3. 세그먼트 수가 아닌 프래그먼트 커버리지 정렬하기​

프래그먼트는 데이터 단위입니다. 인덱스 세그먼트는 프래그먼트 집합을 담당하는 독립적인 인덱스입니다. 논리적 인덱스는 하나의 인덱스 이름 아래 물리적 세그먼트를 묶습니다. IVF 파티션, BTree 페이지, FTS 포스팅 블록은 인덱스 내부 단위이며, 어느 것도 Doris 검색 분할을 정의하지 않습니다.

다음 예시에서는 데이터 프래그먼트 여덟 개를 사용합니다.

배치벡터 커버리지스칼라 커버리지프래그먼트 범위 스칼라 리더에서 필터링에 미치는 영향
정렬됨V0={0,1,2,3}, V1={4,5,6,7}B0={0,1,2,3}, B1={4,5,6,7}각 벡터 분할에는 대응하는 스칼라 세그먼트만 필요합니다.
스칼라 쪽이 더 잘게 나뉨위와 같음프래그먼트마다 하나씩, 세그먼트 여덟 개각 분할이 스칼라 세그먼트 네 개를 선택하며, 어느 것도 벡터 경계를 넘지 않습니다.
스칼라 쪽이 더 크게 나뉨위와 같음B0={0,1,2,3,4,5,6,7}두 벡터 분할이 같은 스칼라 세그먼트를 조회할 수 있습니다.
개수는 같지만 경계가 교차함위와 같음B0={0,1,4,5}, B1={2,3,6,7}두 스칼라 세그먼트가 모두 두 벡터 분할과 겹칩니다. 개수가 같아도 정렬되는 것은 아닙니다.

프래그먼트 범위 가지치기는 겹치는 프래그먼트가 없는 스칼라 세그먼트를 건너뜁니다. 일부만 겹치면 세그먼트가 유지됩니다. 술어를 평가하기 전에 더 작은 BTree를 자동으로 다시 만들거나 모든 포스팅 목록을 잘라내지는 않습니다. 반복 쿼리는 캐시에 저장된 인덱스 내용을 재사용하더라도 검색과 행 ID 집합 구성은 반복할 수 있습니다. 유지된 세그먼트의 BTree 조회가 반드시 모든 페이지를 스캔하는 것은 아니며, 비용은 술어와 일치하는 항목에 따라 달라집니다.

important

이 이점은 실제 리더 경로에 따라 달라집니다. 프래그먼트 범위로 스칼라 인덱스를 로드하는 Lance의 V2 필터 적용 읽기 경로에서는 관련 없는 스칼라 세그먼트를 검색 전에 제외할 수 있습니다. 레거시 V1 데이터 파일 경로는 논리적 스칼라 인덱스를 더 넓은 범위에서 평가한 뒤 행 ID를 제한할 수 있습니다. 여기서 V1/V2는 Doris 릴리스나 벡터 인덱스 유형이 아닌 데이터 파일 형식을 가리킵니다. 모든 리더 버전이나 FTS 경로에서 같은 방식으로 가지치기한다고 가정하지 말고, 각 쿼리 유형의 계획과 프로파일을 확인하세요.

자주 함께 사용하는 열의 벡터, 스칼라, FTS 인덱스를 구축할 때는 같은 프래그먼트 그룹을 사용하세요. 각 스칼라 세그먼트가 담당하는 검색 세그먼트 안에 포함된다면 스칼라 세그먼트를 더 잘게 나눌 수 있습니다. 벡터 세그먼트와 FTS 세그먼트에 서로 다른 크기가 필요하다면 공통 기반 그룹을 각각 합치는 방식을 고려하고, 스칼라 세그먼트가 두 종류의 경계 안에 모두 들어가도록 하세요. 이는 겹침 가능성을 줄이기 위한 배치 정책이며, 모든 실행 경로가 이를 활용한다는 보장은 아닙니다.

시작 세분화 수준 선택하기​

모든 경우에 적합한 세그먼트당 행 수나 바이트 크기는 없습니다. 워크로드를 처리할 수 있는 BE 수를 기준으로 시작한 다음, 재현율과 목표 동시 실행 수준을 고정한 상태에서 BE당 균형 잡힌 검색 세그먼트 하나와 BE당 소수의 세그먼트를 비교하세요. 이는 실험 기준점이며 반드시 따라야 하는 비율은 아닙니다.

워크로드구축 시 우선순위측정할 주요 절충점
지연 시간에 민감한 필터 적용 벡터 검색균형 잡힌 벡터 그룹과 그 안에 포함되는 스칼라 커버리지가장 느린 분할의 시간과 반복 필터링 및 후보 확산
높은 동시 실행 수준의 검색쿼리당 과도한 분할 확산을 피하고 재사용할 수 있는 파티션을 유지QPS, P95 지연 시간, CPU 대기열, 최대 메모리를 함께 측정
범위가 넓은 스칼라 필터 또는 흔한 FTS 검색어그룹의 균형을 맞출 때 일치 건수, 텍스트 길이, 포스팅 크기를 고려행 수가 같아도 필터링 및 검색 비용은 다를 수 있음
잦은 데이터 추가같은 새 프래그먼트 그룹에 대해 관련 인덱스를 모두 구축새 데이터의 커버리지와 작은 세그먼트의 누적 사이의 절충점
매우 큰 개별 프래그먼트인덱스를 구축하기 전에 데이터 파일 크기를 계획프래그먼트 기반 커버리지에서는 하나의 프래그먼트를 서로 겹치지 않는 여러 커버리지 그룹으로 나눌 수 없음

행 수뿐 아니라 인코딩된 벡터/그래프 크기, 스칼라 값 분포, 텍스트/포스팅 크기도 측정하세요. 각 벡터 세그먼트에 IVF/PQ 설정에 필요한 학습 데이터가 충분하도록 하세요. nlist(IVF 파티션 수)와 물리적 세그먼트 수는 별개의 선택 사항이며, 하나를 변경해도 다른 하나가 자동으로 조정되지는 않습니다.

4. 하나의 그룹화 계획으로 관련 인덱스 구축하기​

Doris에는 열 간 인덱스를 자동으로 정렬하는 매개변수가 없습니다. 호환되는 SDK가 지원하는 경우 Lance 분산 구축 API를 사용하세요. 다음은 작업을 조율하는 패턴이며, 바로 실행할 수 있는 데이터셋 생성기나 벤치마크 설정은 아닙니다.

# ds is an existing LanceDataset at the chosen build snapshot.
# groups contains non-empty, disjoint lists of actual fragment IDs.
# vector_params and fts_params are validated for the schema and SDK version.
# Keep writes and compaction paused for this simple coordinator example.
visible = {fragment.fragment_id for fragment in ds.get_fragments()}
assigned = [fragment_id for group in groups for fragment_id in group]
assert groups and all(groups)
assert len(assigned) == len(set(assigned))
assert set(assigned) == visible

specs = [
    ("embedding_idx", "embedding", "IVF_PQ", vector_params),
    ("category_idx", "category", "BTREE", {}),
    ("content_idx", "content", "INVERTED", fts_params),
]
segments = {name: [] for name, _, _, _ in specs}
for fragment_ids in groups:
    for name, column, index_type, params in specs:
        segment = ds.create_index_uncommitted(
            column,
            index_type,
            name=name,
            fragment_ids=fragment_ids,
            **params,
        )
        segments[name].append(segment)

# These are three separate commits, not an atomic multi-index publication.
for name, column, _, _ in specs:
    ds.commit_existing_index_segments(name, column, segments[name])

입력은 다음과 같이 준비하고 검증하세요.

  1. 구축 계획을 확정하세요. 하나의 스냅샷에서 실제 프래그먼트 ID를 열거하세요. ID가 연속적일 필요는 없습니다. 행 수와 예상 인덱스 바이트를 기준으로 그룹의 균형을 맞추세요. 관련된 모든 열에 정확히 같은 그룹을 재사용하세요. 모든 분산 작업자는 같은 구축 버전을 열어야 합니다.
  2. 호환되는 설정을 선택하세요. IVF_PQ에는 벡터 차원과 샘플 크기에 적합한 거리 측정 방식, num_partitions, num_sub_vectors를 지정하세요. 논리적 인덱스의 모든 세그먼트에서 인덱스 설정을 일관되게 유지하세요. FTS에서는 분석기/토크나이저 설정을 일관되게 유지하고, 구문 검색이 필요하면 with_position을 활성화하세요.
  3. 벡터 모델 전략을 선택하세요. 지원되는 다중 세그먼트 구축 방식에서는 세그먼트별로 독립적으로 학습할 수 있습니다. 나중에 물리적 병합을 위해 모델을 공유해야 한다면 작업자에게 동일한 IVF 중심점과 PQ 코드북을 제공하세요. 독립적으로 학습한 세그먼트를 무작정 병합하거나 HNSW 그래프가 병합 후에도 유지된다고 가정하지 말고, SDK에서 지원하는 작업 흐름을 확인하세요.
  4. 먼저 구축한 뒤 게시하세요. 각 구축 작업은 고유한 UUID를 가진 물리적 세그먼트를 반환합니다. 성공한 결과를 수집하고 커버리지와 호환성을 확인한 다음 각 논리적 인덱스를 커밋하세요. 서로 다른 열이나 작업자 결과에 동일한 물리적 UUID를 할당하지 마세요. 이 예시는 새로운 논리적 인덱스 이름을 가정합니다. 교체, 재시도, 실패 후 정리에는 별도의 조정 정책이 필요합니다.
  5. 결과 매니페스트를 검증하세요. 각 인덱스에 대해 실제 세그먼트별 프래그먼트 커버리지를 계획한 그룹과 비교하고, 누락되거나 겹치는 커버리지가 있는지 확인하세요. 세그먼트 수만 같아서는 충분하지 않습니다. Lance 인덱스 메타데이터를 사용하세요. Filesystem Catalog 테이블의 Doris SHOW INDEX는 논리적 인덱스 이름, 유형, 필드를 확인하는 데 도움이 되지만 이 커버리지 검사를 대신하지는 않습니다.

그룹화 계획을 공유한다고 해서 모든 작업자 결과를 하나의 세그먼트로 병합해야 하는 것은 아닙니다. 그렇게 병합하면 유지하려던 경계가 사라집니다. 구축/커밋 API와 지원되는 병합 작업 흐름은 Lance Distributed Indexing을 참고하세요.

유지 관리 중에도 정렬 유지하기​

  • 관련 벡터, 스칼라, FTS 세그먼트는 같은 새 프래그먼트 그룹을 사용해 추가하세요. 게시할 때마다 쿼리 스냅샷의 커버리지를 확인하세요. 데이터가 추가된 후 인덱스 게시가 완료되기 전까지 FTS strict 모드가 쿼리를 거부할 수 있습니다.
  • 압축, 재작성, 인덱스 최적화를 배치 변경으로 취급하세요. 작업과 리더 버전에 따라 인덱스가 다시 매핑되거나 재구축될 수 있으므로, 이전 경계가 유지된다고 가정하지 말고 결과 커버리지를 확인하세요.
  • 하나의 배치 계획에 따라 작은 그룹을 합치세요. 혼합 쿼리 성능이 정렬에 좌우된다면 각 인덱스를 서로 관련 없는 그룹으로 독립적으로 최적화하지 마세요.
  • 온라인 유지 관리에는 스냅샷/충돌 처리 및 복구 기능을 갖춘 조정자를 사용하세요. 인덱스별 개별 커밋으로는 모든 열을 원자적으로 전환할 수 없습니다. TVF는 최신 main 스냅샷을 읽으며, TVF의 table 인수로 과거 버전이나 태그를 선택할 수 없습니다.

논리적 인덱스와 업스트림 계획​

Lance의 인덱스 형식은 논리적 인덱스와 물리적 세그먼트를 정의합니다. 분산 인덱스 추적 이슈는 인덱스 유형 전반에 걸친 공유 세그먼트 수명 주기를 추적합니다. 이 모델은 서로 다른 열에 동일한 프래그먼트 경계를 강제하지 않습니다. 열 간 그룹화와 유지 관리는 여전히 작업 조율의 책임입니다. 업스트림 로드맵을 Doris의 자동 정렬 기능으로 간주하지 마세요.

5. 필터와 메모리를 함께 조정하기​

관찰된 현상다음 실험정확성 또는 리소스 제약
선택도가 매우 높은 필터에서 벡터 결과가 너무 적거나 재현율이 낮음필터 배치와 인덱스 커버리지를 확인하고, 제한된 데이터셋에서 프로브 설정과 정확 검색 기준값을 비교지연 시간을 줄이려고 프로브 수를 낮추면 재현율이 낮아질 수 있습니다. 프로브를 늘려도 필터를 통과하지 못하는 행을 결과에 포함할 수는 없습니다.
범위가 넓은 필터에서 큰 Prefilter 집합이 생성됨정렬된 배치와 스칼라 술어의 실제 선택도를 비교인덱스를 사용해도 일치하는 행 ID를 대량으로 구체화하는 비용은 사라지지 않습니다.
벡터 분할 수가 늘면서 스칼라 작업이 반복됨세그먼트 커버리지의 교집합과 리더 경로를 비교캐시가 준비된 상태에서도 분할 수가 늘면 필터링이 증폭될 수 있습니다.
콜드 쿼리가 느림대표적인 벡터와 검색어를 사용해 콜드 프로파일과 웜 프로파일을 비교한 쿼리의 워밍업으로 운영 환경의 전체 작업 데이터가 캐시에 들어오는 것은 아닙니다.
웜 상태의 혼합 트래픽이 느려짐목표 동시 실행 수준에서 공유 캐시 미스와 CPU 대기열을 측정스칼라, 벡터, FTS 인덱스 내용이 한 BE의 동일한 세션 인덱스 캐시 예산을 두고 경쟁할 수 있습니다.
큰 top_k, 깊은 offset, 또는 넓은 출력의미가 허용하는 범위에서 요청 후보 수를 줄이고 지연된 가져오기를 확인후보 힙, 행 ID 마스크, 정제 작업, 가져오기 버퍼도 추가 쿼리 메모리를 사용합니다.

재사용되는 인덱스 작업 데이터 전체의 크기를 고려하고 동시 쿼리 메모리를 위한 여유를 남기세요. 캐시 용량은 프로세스 메모리 제한이 아니며, 메타데이터 캐시를 늘려도 인덱스 캐시는 늘어나지 않습니다. 인덱스별 데이터 크기 계산식, HNSW 그래프 비용, 캐시 범위, Doris BE 설정 예시는 Lance 쿼리 모범 사례를 참고하세요.

6. 계획과 프로파일로 검증하기​

동일한 쿼리 집합, 데이터셋 스냅샷, 인덱스 유형/설정, top_k, 재현율 목표를 기준으로 비교하세요. 배치나 매개변수는 한 번에 하나씩 변경하세요. 선택도가 높은 필터와 범위가 넓은 필터, 다양한 벡터/검색어, 콜드 및 웜 실행, 목표 동시 실행 수준을 포함하세요. P50/P95, 처리량, 결과 건수, 재현율, BE별 최대 메모리를 기록하세요.

단계확인할 정보해석
FE 메타데이터 및 계획Execution Summary → Lance Metadata Metrics: MetadataReadTime, IndexMetadataReadTime, SplitPlanningTime 및 해당 CallsCatalog 메타데이터 접근과 분할 계획을 BE 검색과 구분하세요. 전체 메타데이터 시간에는 하위 단계의 시간이 포함됩니다.
계획 및 커버리지EXPLAIN: lanceSearchIndexSegments, lanceSearchIndexFragments, lanceSearchUnindexedFragments; LanceSearchPlan: LancePlannedIndexSegmentCount, LancePlannedIndexedFragmentCount, LancePlannedFlatSearchFragmentCount계획되고 할당된 검색 작업을 나타내며 완료된 검색을 나타내지는 않습니다. Flat Search 집계는 벡터 쿼리에 적용되며 FTS에는 적용되지 않습니다.
리더 설정 및 배치 읽기LanceTiming: LanceDatasetOpenTime, LanceScannerConfigureTime, LanceScannerNextTime, LanceArrowToDorisBlockTime열기/설정, Lance 읽기, Doris 변환을 구분하세요. 배치 읽기 시간에는 내부 검색, I/O, 디코딩, 대기가 포함됩니다.
행 ID PrefilterLanceScan: RowIdPrefilterLoads, RowIdPrefilterInputRows, RowIdPrefilterInputBatches, RowIdPrefilterIds, RowIdPrefilterLoadTime, RowIdPrefilterInputTime, RowIdPrefilterBuildTime입력 대기/읽기와 마스크 구성은 전체 데이터 적재 시간의 일부입니다. 이 값은 행 ID 로더를 설명하며, 모든 스칼라 술어나 최종 후보 집합을 설명하는 것은 아닙니다.
스칼라 세그먼트 경로LanceScalarIndex: LanceScalarIndexSegmentsRequested, LanceScalarIndexSegmentsSearched, LanceScalarIndexSegmentFallbacks, LanceScalarIndexCandidateRows, LanceScalarIndexCandidateEvaluationTime, LanceScalarIndexSegmentSearchTime후보 평가 시간에는 세그먼트 검색 시간이 포함됩니다. 후보 수는 프래그먼트 제한/전체 필터링 이전 값이며, 반복 작업에서 후보가 다시 집계될 수 있고 카디널리티를 확인할 수 없으면 값이 영으로 남을 수 있습니다.
인덱스 재사용 및 I/OLanceIndex: LanceIndexCacheHits, LanceIndexCacheMisses, LanceIndexObjectLoads, LanceIndexComponentsLoaded, LanceIndexComparisons; LanceIO: LanceIOReadBytes, LanceIOReadOps, LanceIOReadRequests객체/구성 요소 데이터 적재, 캐시 조회, 검색 작업을 구분하세요. 데이터 적재 횟수는 캐시 미스 횟수가 아니며, 실행 I/O는 전체 원격 트래픽을 모두 나타내지 않습니다.
벡터 파티션 선택 및 검색LanceIVFPartitionsConsidered, LanceIVFPartitionSelectionTime, LanceIndexPartitionsSearched, LanceVectorIndexDeltasSearched, LanceIndexPartitionLoadTime, LanceIndexSearchTime, LanceIndexDistanceTopKTime파티션 선택과 실제 검색을 구분하세요. 거리 계산/Top-K 시간에는 필터링과 힙 작업이 포함되며 검색 시간과 겹칩니다. FTS도 검색한 파티션 수를 보고합니다.
대기 및 동시 실행LanceIndexPrefilterWaitTime, LanceIndexCpuQueueWaitTime, LanceScanTaskWaitTime인덱스 Prefilter 대기, CPU 작업 대기열 대기, FilteredRead 작업 대기를 구분하세요. 어느 값도 전체 I/O 대기 시간이나 Doris 스케줄링 시간을 나타내지는 않습니다.
출력 가져오기행 ID 가져오기/구체화 정보: LanceRowIdFetchCalls, LanceRowIdFetchRows, LanceRowIdFetchTotalTime, LanceRowIdTakeReadTime, LanceArrowToDorisBlockTime 및 데이터 캐시 바이트 카운터가져오기 전체 시간에는 읽기/변환 하위 단계가 포함되며 별도의 통계 경로를 사용합니다. 내보낸 동일한 값을 독립적인 작업 시간으로 다시 더하지 마세요.
전체 지연 시간가장 느린 Scanner, 의존성 대기, FE 대기/가져오기/쓰기, 클라이언트에서 측정한 경과 시간겹치는 연산자의 시간이나 병렬로 실행된 모든 Scanner의 시간을 합쳐 쿼리 지연 시간으로 계산하지 마세요.

메트릭 정의와 범위는 Lance 쿼리 프로파일 참고 문서를, Dataset 데이터 캐시 바이트와 BE 전체 Session 메트릭은 캐시 효과 확인을 참고하세요. 쿼리 수준의 인덱스 캐시 카운터는 Session 전체 값의 차이가 아닙니다.

프로파일의 상세 수준은 실행 중인 FE/BE와 포함된 Lance 계측에 따라 달라집니다. Scanner 메트릭은 미리 등록되므로 값이 영이면 네이티브 경로에서 해당 메트릭을 보고하지 않았을 수도 있습니다. 실행 콜백은 스트림이 완료되어야 작동하므로 실패하거나 취소되거나 일찍 종료된 스캔은 집계가 불완전할 수 있습니다. 값이 없거나 영이라는 사실만으로 인덱스나 필터가 사용되지 않았다고 단정할 수는 없습니다. LanceScannerNextTime은 내부 검색 및 대기 타이머와 겹치므로 값이 높다고 해서 스토리지 병목이 입증되지는 않습니다. 이 메트릭으로 읽기 구간을 설명할 수 없다면 남은 시간을 스토리지에 귀속하기 전에 CPU/I/O 추적을 수집하세요.

필터가 없는 벡터 쿼리에서는 세그먼트 범위 최적화를 지원하는 리더가 선택된 인덱스 세그먼트 전체가 스캔의 프래그먼트 범위 안에 있을 때 모든 행 ID의 열거를 피할 수 있습니다. 실제 스칼라 술어는 여전히 평가해야 하며 삭제 및 가시성 처리도 남을 수 있습니다. 정렬은 피할 수 있는 작업을 줄이지만, 필터 적용 검색에서 Prefilter 비용이 없어짐을 보장하지는 않습니다.

Report issue