Windows Search의 인덱싱 프로세스
이 항목에서는 인덱싱 프로세스의 세 단계와 각각에 관련된 기본 구성 요소에 대해 설명하고, 인덱싱 작업의 타이밍을 설명하고, 데이터 저장소 또는 파일 형식을 인덱싱하려는 타사 개발자를 위한 몇 가지 참고 사항을 제공합니다.
이 항목은 다음과 같이 구성됩니다.
개요
Windows Search는 .doc 또는 .jpeg 형식과 같은 다양한 파일 형식의 파일과 파일 시스템 또는 Windows Outlook 사서함과 같은 데이터 저장소의 속성 및 콘텐츠 인덱싱을 지원합니다. 인덱스에는 두 가지 종류가 있습니다. 즉, 속성의 전체 값을 기준으로 필터링 및 정렬을 허용하는 값 인덱스와 텍스트 속성 또는 콘텐츠 내에서 단어를 인덱싱하는 반전된 인덱스가 있습니다. 사용자 지정 파일 형식 또는 데이터 저장소가 있는 경우 항목을 올바르게 인덱싱하려면 Windows Search 인덱스가 어떻게 인덱싱되는지 이해해야 합니다.
인덱싱 프로세스는 Gatherer라는 Windows Search 구성 요소에 의해 제어되는 세 단계로 수행됩니다. 첫 번째 단계에서 Gatherer는 큐에 URL을 추가합니다. URL은 인덱싱할 항목을 식별하며 큐는 URL 목록의 우선 순위에 불과합니다. 두 번째 단계에서는 Gatherer가 다른 Windows Search 및 타사 구성 요소를 조정하여 항목에 액세스하고 해당 항목에 대한 데이터를 수집합니다. 마지막으로, 세 번째 단계에서 수집된 데이터가 인덱스로 추가됩니다.
다음 다이어그램은 인덱싱 프로세스를 통해 데이터의 주요 구성 요소 및 흐름을 보여 줍니다. 인덱스에 대한 데이터 수집에는 여러 구성 요소가 포함됩니다. 이들 중 일부는 Windows Search의 일부이며 일부는 타사 애플리케이션에서 제공됩니다. 사용자 지정 데이터 저장소 또는 파일 형식이 있는 경우 Windows Search는 프로토콜 처리기 및 필터를 사용하여 URL에 액세스하고 인덱싱을 위한 속성을 내보냅니다. Windows Search 구성 요소는 파란색으로 표시되고 타사 구성 요소는 녹색으로 표시됩니다.
1단계: 인덱싱을 위한 URL 큐
인덱싱의 첫 번째 단계에서는 데이터 저장소 업데이트에 대한 정보를 수집하고, 해당 정보를 알려진 크롤링 scope 비교한 다음, 트래버스할 URL 큐를 작성하여 인덱스에 대한 데이터를 수집합니다. FAT 드라이브와 같이 알림을 기반으로 하지 않는 원본의 경우 수집기는 인덱스의 데이터가 최신 상태로 유지되도록 크롤링 scope 전체 순회를 주기적으로 시작합니다. NTFS와 같은 원본의 경우 단일 크롤링만 있고 다른 모든 항목은 USN 변경 저널의 알림에 의해 처리됩니다. Microsoft Outlook의 크롤링도 없습니다. 다음 다이어그램은 비 크롤링 인덱싱을 위한 큐 프로세스의 개략적인 보기를 보여 주는 다이어그램입니다.
이 섹션의 나머지 부분에서는 Windows Search가 크롤링할 URL을 결정하는 방법을 설명하고 그 과정에서 몇 가지 중요한 용어를 정의합니다.
크롤링 범위 크롤링 scope 사용자가 더 빠른 검색을 위해 인덱싱하려는 항목에 대한 데이터를 수집하기 위해 Windows Search에서 트래버스하는 URL 집합입니다. Windows Search는 사용자의 문서 및 사진 폴더 경로와 같이 기본적으로 크롤링 scope 일부 URL을 추가합니다. 타사 애플리케이션, 사용자 및 그룹 정책 다른 URL을 추가할 수 있습니다. 마지막으로 사용자와 그룹 정책 URL을 명시적으로 제외할 수 있습니다. Windows Search는 추가된 모든 URL을 사용하고 제외된 URL을 제거하여 크롤링 scope 확인합니다. 이것은 Gatherer가 작업을 시작하는 URL의 작업 집합입니다.
Gatherer Gatherer는 크롤링 scope 내의 URL에 대한 정보를 수집하고 인덱서가 크롤링할 URL 큐를 만드는 Windows Search 구성 요소입니다. 크롤링 scope 항목이 추가, 삭제 또는 업데이트되면 데이터 저장소의 알림 공급자가 Gatherer에 알림을 받습니다. 초기 크롤링에서 gatherer가 크롤링 scope 루트에서 시작됩니다. URL은 프로토콜 처리기에 전달된 다음 적절한 IFilter에 전달됩니다. 필터는 일반적으로 더 많은 URL을 생성하는 디렉터리 열거형입니다. 알림은 안정적인 상태입니다. 일반적으로 각 데이터 저장소에는 이러한 알림을 제공하는 자체 프로토콜 처리기가 있습니다. 예를 들어 로컬 파일 시스템에서 USN 변경 저널 은 file:// 프로토콜 아래의 모든 URL에 대한 알림 공급자 역할을 합니다. 마찬가지로 Microsoft Outlook은 mapi:// 프로토콜의 모든 URL에 대한 알림 공급자 역할을 합니다. 사용자가 전자 메일을 수신, 이동 또는 삭제하면 Outlook에서 전자 메일의 변경된 상태 수집자에게 알 수 있습니다. 이러한 알림에서 Gatherer는 크롤링할 URL의 인덱싱 큐를 만듭니다.
큐 인덱싱 인덱싱 큐는 인덱싱하거나 다시 인덱싱해야 하는 항목을 식별하는 URL 목록입니다. Gatherer는 알림 공급자로부터 수신하는 URL을 크롤링 scope URL과 비교합니다. 크롤링 scope 내에 속하는 알림 공급자의 모든 URL은 Gatherer가 다음에 처리할 URL의 우선 순위를 지정하는 데 사용하는 큐에 추가됩니다.
우선 순위가 높은 알림, 일반 알림 및 주기적 크롤링의 세 가지 큐가 있습니다. 우선 순위가 높은 큐는 즉시 처리해야 하는 알림에 대한 것입니다. 예를 들어 사용자가 Windows Explorer 항목의 제목 속성을 변경하는 경우 변경 직후 Windows Explorer 보기를 업데이트해야 합니다. 일반 알림 큐는 나머지 모든 변경 알림에 대한 것입니다. 변경된 항목이 사용자에게 더 관심을 가질 가능성이 높기 때문에 알림 큐는 크롤링 큐 전에 처리됩니다. Gatherer는 FIFO(First out) 순서로 각 큐의 URL에 대한 데이터에 먼저 액세스합니다.
우선 순위 지정 및 Windows 7에 도입된 이벤트 API에 대한 자세한 내용은 Windows 7의 인덱싱 우선 순위 지정 및 행 집합 이벤트를 참조하세요. 크롤링 scope 관리 및 알림에 대한 자세한 내용은 변경 알림 제공 및 크롤링 범위 관리자 사용을 참조하세요.
2단계: URL 크롤링
인덱싱의 두 번째 단계에서는 수집기가 큐를 크롤링하고, 데이터 저장소에 액세스하고, 항목 스트림을 검색합니다. 먼저 Gatherer는 각 URL에 대한 적절한 프로토콜 처리기를 찾습니다. 그런 다음, Gatherer는 프로토콜 처리기에 URL을 전달합니다. 프로토콜 처리기는 항목에 액세스하고 항목 메타데이터를 다시 Gatherer에 전달합니다. Gatherer는 메타데이터를 사용하여 올바른 필터를 식별합니다.
다음 다이어그램은 URL 크롤링 프로세스에 대한 개략적인 보기를 보여 주는 다이어그램입니다. 이 단계에는 구성 요소 간의 상당한 조정 및 통신이 포함됩니다.
이 섹션의 나머지 부분에서는 Windows Search가 인덱싱을 위해 항목에 액세스하는 방법을 설명하고 관련된 각 구성 요소의 역할을 설명합니다.
Gatherer 크롤링 단계인 2단계에서 Gatherer는 우선 순위가 높은 큐부터 시작하여 큐의 URL을 처리합니다. 각 URL은 해당 프로토콜을 식별하기 위해 검사됩니다. 그런 다음 Gatherer는 해당 프로토콜에 대해 등록된 프로토콜 처리기를 조회하고 검색 프로토콜 호스트 프로세스에서 인스턴스화합니다.
검색 프로토콜 호스트 검색 프로토콜 호스트는 프로토콜 처리기에 대한 박스형 호스트 프로세스일 뿐입니다. 일반적으로 Windows Search는 시스템 보안 컨텍스트에서 실행되는 호스트 프로세스와 사용자 보안 컨텍스트에서 실행되는 두 개의 호스트 프로세스를 만듭니다. 이렇게 분리하면 사용자와 관련된 데이터가 시스템 컨텍스트에서 실행되지 않습니다.
또한 Windows Search는 호스트 프로세스를 사용하여 프로토콜 처리기의 instance 다른 프로세스 또는 애플리케이션과 격리합니다. 이렇게 하면 외부 애플리케이션이 프로토콜 처리기의 특정 instance 액세스할 수 없으며 프로토콜 처리기가 예기치 않게 실패하면 인덱싱 프로세스만 영향을 받습니다. 호스트 프로세스는 타사 코드(프로토콜 처리기)를 실행하므로 Windows Search는 프로세스를 주기적으로 재활용하여 성공적인 공격이 프로세스의 정보를 악용해야 하는 시간을 최소화합니다. 이 외에도 검색 프로토콜 호스트는 URL 크롤링 또는 항목 인덱싱에 영향을 주지 않습니다.
프로토콜 처리기 프로토콜 처리기는 데이터 저장소의 프로토콜을 사용하여 데이터 저장소의 항목에 대한 액세스를 제공합니다. 예를 들어 NTFS 프로토콜 처리기는 file:// 프로토콜을 사용하여 로컬 드라이브의 파일에 대한 액세스를 제공합니다. 프로토콜 처리기는 데이터 저장소를 트래버스하고, 새 항목 또는 업데이트된 항목을 식별하고, Gatherer에 알리는 방법을 알고 있습니다. 그런 다음 크롤링이 시작되면 프로토콜 처리기는 IUrlAccessor 개체를 Gatherer에 제공하여 항목의 기본 스트림에 바인딩하고 보안 제한 및 마지막으로 수정된 시간과 같은 항목 메타데이터를 반환합니다.
참고
프로토콜 처리기는 Windows Search 구성 요소가 아닙니다. 액세스하도록 설계된 특정 프로토콜 및 데이터 저장소의 구성 요소입니다. 인덱싱하려는 사용자 지정 데이터 저장소가 있는 경우 프로토콜 처리기를 구현해야 합니다. 프로토콜 처리기 및 구현 방법에 대한 자세한 내용은 프로토콜 처리기 개발을 참조하세요.
메타데이터 및 스트림 프로토콜 처리기의 IUrlAccessor 개체에서 반환된 메타데이터를 사용하여 Gatherer는 URL에 대한 올바른 필터를 식별합니다. Gatherer는 항목의 파일 이름 확장명을 구문 분석하고 해당 확장에 대해 등록된 필터를 조회합니다. Gatherer가 필터를 찾을 수 없는 경우 Windows Search는 메타데이터를 사용하여 시스템 속성 정보(예: System.ItemName)의 최소 집합을 파생시키고 인덱스를 업데이트합니다. 그렇지 않으면 Gatherer가 필터를 찾으면 인덱싱의 세 번째 단계가 시작됩니다.
3단계: 인덱스 업데이트
인덱싱의 세 번째 단계에서 Gatherer는 URL에 대한 올바른 필터를 인스턴스화하고 IUrlAccessor 개체의 스트림을 사용하여 필터를 초기화합니다. 그런 다음 필터는 항목에 액세스하고 인덱스에 대한 콘텐츠를 반환합니다. 사용자 지정 파일 형식이 있는 경우 Windows Search는 필터를 사용하여 URL에 액세스하고 인덱싱을 위한 콘텐츠와 속성을 내보냅니다.
다음 다이어그램에서는 데이터 액세스 프로세스의 개략적인 보기를 보여 있습니다. 이 단계에는 구성 요소 간의 상당한 조정 및 통신이 포함됩니다.
이 섹션의 나머지 부분에서는 Windows Search가 인덱싱을 위해 항목 데이터에 액세스하는 방법을 설명하고 관련된 각 구성 요소의 역할을 설명합니다.
Gatherer 이 단계의 시작 부분에서 Gatherer의 역할은 항목에 대한 올바른 필터를 인스턴스화하고 항목 스트림을 전달하는 것입니다. 이 단계가 끝나면 Gatherer는 필터 및 속성 처리기에서 내보낸 콘텐츠와 속성을 가져와 인덱스를 업데이트합니다.
호스트 필터링 필터 호스트는 필터 및 속성 처리기에 대한 호스트 프로세스일 뿐이며 검색 프로토콜 호스트와 유사한 용도를 제공합니다. 호스트 프로세스는 프로토콜 호스트 프로세스에서 프로토콜 처리기를 격리하는 것과 동일한 보안 및 안정성 이유로 필터 및 속성 처리기를 시스템의 나머지 부분과 격리합니다. 호스트 프로세스는 최소한의 권한으로 실행되며(파일 시스템에 액세스할 수도 없음) 보안 공격으로부터 보호하기 위해 때때로 재활용됩니다. 또한 Windows Search는 리소스 사용을 모니터링하여 필터가 너무 많은 리소스를 사용하는 경우 호스트 프로세스가 재활용되도록 합니다.
필터 필터는 인덱싱 프로세스에서 수집기 항목 정보를 내보내는 중요한 구성 요소입니다. 필터의 이름은 구현, IFilter 인터페이스에 사용되는 주 인터페이스의 이름을 따서 명명되며, 따라서 IFilters라고도 합니다. 필터에는 파일과 같은 개별 항목과 상호 작용하는 필터와 폴더와 같은 컨테이너와 상호 작용하는 필터의 두 종류가 있습니다. 둘 다 인덱스 데이터를 제공합니다.
수집기는 프로토콜 처리기의 IUrlAccessor 개체에서 반환된 메타데이터를 사용하여 특정 URL에 대한 올바른 필터를 식별하고 스트림에 전달합니다. Gatherer는 프로토콜 처리기를 통해 또는 파일 이름 확장명, MIME 형식 또는 CLSID(클래스 식별자)를 통해 올바른 필터를 식별합니다. URL이 컨테이너를 가리키는 경우 필터는 컨테이너의 속성을 내보내고 컨테이너의 항목(자식 URL)을 열거합니다. URL이 항목을 가리키는 경우 필터는 속성 읽기가 속성 처리기보다 더 복잡한 경우 텍스트 콘텐츠를 반환합니다. 일반적으로 필터는 항목 콘텐츠를 내보내고 속성 처리기는 항목 속성을 내보내는 것이 좋습니다. 그러나 필터가 속성 처리기를 인식하지 못하는 이전 애플리케이션에서 작동해야 하는 경우 필터를 구현하여 속성도 내보낼 수 있습니다.
참고
필터는 Windows Search 구성 요소가 아닙니다. 액세스하도록 설계된 특정 파일 형식 또는 컨테이너와 관련된 구성 요소입니다. 필터 및 사용자 지정 파일 형식 또는 컨테이너에 대해 필터를 구현하는 방법에 대한 자세한 내용은 Windows Search에서 필터 처리기를 만들기 위한 모범 사례를 참조하세요.
다음 표에서는 인덱싱 프로세스 중에 Gatherer가 필터(IFilter) 및 속성 처리기(IPropertyStore)에서 받은 결과를 나열합니다.
| IFilter | IPropertyStore | |
|---|---|---|
| 쓰기 허용 | 아니요 | 예 |
| 콘텐츠 및 속성 혼합 | Yes | 아니요 |
| 다국어 | Yes | 아니요 |
| 링크 내보내기 | Yes | 아니요 |
| MIME | Yes | 아니요 |
| 텍스트 경계 | 문장, 단락, 장 | 없음 |
| 클라이언트/서버 | 둘 다 | 클라이언트 |
| 구현 | 복합 | 단순 |
속성 처리기 속성 처리기는 특정 파일 형식에 대한 속성을 읽고 쓰는 구성 요소입니다. 필터가 콘텐츠에 대해 수행하는 것과 동일한 방식으로 항목에 액세스하고 수집기 속성을 내보낸다. 속성 처리기는 필터보다 구현하기 쉽습니다. 텍스트 기반 파일 형식이 매우 간단하거나 파일이 매우 작을 것으로 예상되는 경우 속성 처리기는 속성과 콘텐츠를 모두 내보낼 수 있습니다.
참고
속성 처리기는 Windows Search 구성 요소가 아닙니다. 액세스하도록 설계된 특정 파일 형식과 관련된 구성 요소입니다. 속성 처리기 및 사용자 지정 파일 형식에 대한 속성 처리기를 구현하는 방법에 대한 자세한 내용은 Windows Search용 속성 처리기 개발을 참조하세요.
속성 Windows Search는 속성의 큰 라이브러리를 포함하는 속성 시스템을 제공합니다. 필터 또는 속성 처리기에서 정의한 대로 모든 속성이 모든 항목에 나타날 수 있습니다. 사용자 지정 파일 형식이 있는 경우 파일 형식의 속성을 이러한 시스템 속성에 매핑하고 새 사용자 지정 속성을 만들 수 있습니다. 필터 또는 속성 처리기가 이러한 속성을 내보내면 수집기는 사용자가 속성을 사용하여 검색할 수 있도록 인덱스를 업데이트합니다. 파일 형식에 대한 사용자 지정 속성을 만들고 등록하는 방법에 대한 자세한 내용은 속성 시스템을 참조하세요.
SystemIndex SystemIndex라는 인덱스는 인덱싱된 데이터를 저장하고 속성 저장소와 항목 속성의 속성 및 콘텐츠에 대한 인덱스, 텍스트 콘텐츠 및 속성에 대한 반전된 인덱스로 구성됩니다. Gatherer가 인덱스를 업데이트한 후 Windows Search 및 기타 애플리케이션에서 인덱스를 쿼리할 수 있습니다. 인덱스 쿼리 방법에 대한 자세한 내용은 프로그래밍 방식으로 인덱스 쿼리를 참조하세요.
참고
스키마를 다시 등록할 때 이전에 정의한 속성의 특성에 대한 변경 내용은 인덱서에서 적용되지 않을 수 있습니다. 솔루션은 인덱스 다시 작성 또는 이전 속성을 업데이트하는 대신 변경 내용을 반영하는 새 속성을 도입하는 것입니다(권장되지 않음). 자세한 내용은 속성 시스템 개요의 구현자에 대한 참고를 참조하세요.
인덱싱 예약 방법
Windows Search가 처음 설치되면 크롤링 scope 전체 인덱싱을 수행하고 I/O 및 사용자 활동이 많은 기간 동안 일시 중지됩니다. 기본 크롤링 scope 문서, 음악, 사진 및 비디오와 같은 기본 라이브러리 위치로 구성됩니다. 알림은 초기 크롤링이 완료되기 전에 처리됩니다. 경우에 따라 수집기는 전체 크롤링 scope URL을 크롤링합니다. 이러한 전체 크롤링은 인덱스의 데이터가 최신인지 확인합니다. 예를 들어 알림 공급자가 알림을 보내지 못하거나 Windows Search Service 예기치 않게 종료되는 경우 수집기는 새 항목이나 변경된 항목에 대한 지식이 없으며 이러한 항목을 인덱싱하지 않습니다. 알림 전용 및 알림 사용의 두 가지 종류의 원본이 있습니다. 두 소스에서 수집기는 처음에 인덱스를 크롤링합니다. 초기 크롤링 후에는 USN 변경 저널 롤오버와 같은 오류가 발생하지 않는 한 알림 전용 원본이 다시 전체 크롤링을 수행하지 않습니다. 알림 사용 원본은 인덱서가 시작될 때 증분 크롤링을 수행하지만 실행하는 동안 알림을 수신 대기합니다. NTFS 및 Microsoft Outlook은 알림 전용입니다. 인터넷 Explorer 및 FAT는 알림을 사용하도록 설정됩니다.
구현자 참고
인덱스의 데이터 품질과 인덱싱 프로세스의 효율성은 주로 필터 및 속성 처리기 구현에 따라 달라집니다. URL이 파일 형식을 식별할 때마다 필터가 호출되므로 필터가 비효율적이면 인덱싱 프로세스가 크게 느려질 수 있습니다. 속성 처리기가 모든 파일 속성을 시스템 속성에 올바르게 매핑하지 않거나 이러한 속성을 올바르게 내보내지 않으면 인덱스의 데이터가 올바르지 않으며 나중에 해당 속성을 검색하면 잘못된 결과가 반환됩니다. 필터 또는 속성 처리기가 실패하면 인덱서는 데이터를 인덱싱할 수 없습니다.
Windows Search 이외의 애플리케이션 및 프로세스는 프로토콜 처리기, 필터 및 속성 처리기를 사용합니다. 구현은 예상할 수 없는 방식으로 해당 애플리케이션에 영향을 줄 수 있습니다. Windows Search 개발 가이드는 디자인 선택 사항 및 이러한 각 구성 요소 테스트에 대한 조언을 제공합니다.