Follow up : Windows 데스크톱 검색
데스크톱 검색에 관한 토론과 전자 메일은 Windows 7 엔지니어링에 관한 아키텍처 논의가 깊어질 수 있는 기회를 주었습니다. 많은 댓글에서 대체 구현 방법이 제안되어, 우리는 다른 접근 방식과 거기에 관한 다양한 찬반양론을 서로 이야기하려 합니다. 이 접근 방식은 우리가 Windows 7 에서 어렵게 구현하려는 엔지니어링 균형에 대한 좋은 예입니다. 이 글은 Chris McConnell 이 집필했습니다. --Steven (일주일 앞으로 다가온 PDC에서 만납시다!)
Windows 데스크톱 검색에 관한 이전의 포스팅에 대한 훌륭한 피드백을 주셔서 감사합니다. 여기에서는 다수의 문제점을 요약, 우리가 아키텍처에 관해서 행한 선택과 그 이유에 대해 몇가지 말씀드립니다.
파일시스템의 통합
몇 분이 지적하였듯이, 구현 가능한 하나의 형태로서 인덱스 서비스와 파일시스템을 통합하여, 파일이 업데이트되면 바로 인덱스도 업데이트 되도록 하는 방법이 있습니다. Windows 데스크톱 검색에서는 이것과는 다른 접근 방식을 선택하고 있습니다. 파일시스템 통합에는 두가지 측면이 있습니다. 하나는 파일이 변경된 것을 감지하는 것이고, 다른 하나는 파일이 「닫혀지고」사용가능 하다고 보여지는 전의 실제 인덱스 업데이트입니다. NTFS 파일시스템에서는 파일이 변경되면 반드시 인덱서에 통지됩니다. 인덱서는 초기의 인덱스 생성할 때 이외는 NTFS 파일시스템을 스캔하지 않습니다. 우리가 통합과는 다른 선택을 한 것은 두번째 점 (파일이 닫혀질 때 바로 인덱스를 업데이트 한다)을 고려했기 때문에입니다. 새로운 인덱스가 생성 될 때까지 그 새로운 파일은 검색대상이 되지 않지만, 바로 인덱스를 업데이트 한다는 방법으로 그것을 회피할 수 있는 장점이 있습니다. 그러나 이 방법에는 많은 잠재적 단점이 있습니다. 우리는 거의 실시간이면서, 보다 높은 유연성을 있는 점에서 인덱스 서비스와 파일시스템 처리를 분리하기로 했습니다. 우리가 선택한 접근 방식의 몇가지 장점을 다음에서 보여줍니다.
- 사용되는 리소스가 적은 것. 시스템에 하나의 글로벌인덱스를 준비했습니다. 그것은 1 개의 단어와 시스템에서 그 단어를 포함한 모든 문서를 매핑하고 있습니다. 하나의 파일에 포함된 모든 단어에 대해 인덱스를 만듭니다. 예를 들어 1 개의 문서에 포함된 방대한 양의 개별 인덱스가 생성되어 업데이트 됩니다. 이러한 변경에 따라, 개개의 파일과 같은 강력하게 인덱스 변경을 확실히 실행하려면, 비용이 많이 듭니다. 인덱서는 이러한 변경을 스케줄 및 집약하여 전체로 실행되는 작업을 큰폭으로 줄여, CPU 사용이나 디스크 I/O 를 줄일 수 있도록 설계됩니다. 파일이 닫혀있을 때는 인덱스 생성을 하지 않는 것으로, 시스템은 보다 강력해집니다. 또, 필요에 따라서 인덱스 생성을 다시 할 수도 있습니다.
- 파일시스템 처리가 인덱스 서비스보다 우선되는 것. 파일이 강력히 업데이트되어, 사용 가능해진 것은 파일을 사용하는 응용 프로그램에서는 대전제입니다. 파일닫기 처리에 인덱스 생성을 포함하여, 파일이 사용 가능하게 됨에 따라 시스템이 느려지는 것은 피해야 합니다. 파일 검색이 중요하지만, 실제의 파일 작업이 더 중요합니다. 우리는 응용 프로그램이 파일시스템에 관해서 최고의 성능을 요구하기 위해서, 그것들이 개별적으로 인덱서의 on 또는 off 를 결정하는 상황은 바람직하지 않다고 생각합니다.
- 많은 파일 유형 취급할 수 있는 것. Microsoft는 Windows 의 일부로서 많은 공통 파일 유형 용무의 추출 프로그램 (iFilter 나 IPropertyHandler)을 제공하고 있습니다. 파일 유형은 그 밖에도 여러 가지가 있기 때문에, Microsoft 이외의 개발자가 독자적인 추출 프로그램을 생성할 수 있도록 하는 것도 중요합니다. Vista ( 및 Windows 7)에서는 이러한 추출 프로그램은 안전하고 시스템 전체의 성능에 영향을 주지 않는 것이 보장된 한정적인 프로세스에서 실행됩니다. 파일이 사용 가능하게 되기 전에 인덱스를 생성해야 하는 경우, 추출 프로그램이 모든 파일시스템 처리에 영향을 줄 (고의이던 아니던) 우려가 있습니다.
- 인덱스 유효성이 파일에 의해 다른 것. 파일이 닫힐때 인덱스 생성을 하는 경우, 파일에 인덱스를 붙이는 순서를 제어하는 것은 불가능합니다. 그러나 파일 조작과 인덱스 생성을 분리하여 (인덱스 생성은 다음에 모아서 실행), 인덱스를 붙이는 파일의 우선 순위가 가능해집니다. 예를 들어, 음악은 이진 파일보다 훨씬 빈번히 검색되는 것을 생각할 수 있습니다. 음악 파일과 이진 파일 모두가 변경되었을 경우, 인덱서는 음악 파일에 먼저 인덱스를 붙입니다. 대부분의 사용자에서 인덱스를 매기는 가치가 없는 파일도 있습니다. 몇가지 댓글에서는 드라이브 전체에 인덱스를 붙이면 어떨지 라는 제안도 있었습니다. 그것도 물론 가능합니다. 또, 그렇게 하는 가치가 정말로 있다면, 인덱스를 붙이는 폴더를 추가하는 일도 간단하게 할 수 있습니다 (인덱스 삭제도 할 수 있습니다. 다만, 삭제는 훨씬 보기 드물어서,[컨트롤 패널] 의 [인덱스 옵션] 에서 관리합니다). 그러나 대부분의 사용자에서는 시스템 파일에 인덱스를 붙이는 것은 비용이 듭니다. 이러한 사용자가 시스템 파일을 검색할 것은 없고, 검색 결과에 그것들이 표시되면 반대로 혼란스러워 집니다.
- 하나의 파일시스템 내의 파일이 모두라고는 할 수 없음.Windows 는 다양성을 지원해야 할 사명이 있습니다. Windows 에는 FAT32 나 CDFS 등 많은 다른 파일시스템이 있고, 우리는 그것들도 검색할 수 있도록 지원하고자 합니다. 우선은 NTFS 만을 검색대상으로 하지만, 곧 그 외의 파일시스템과 어떠한 관련성을 갖고 있을 필요성이 있습니다. 또, 많은 응용 프로그램은 독자적인 요구에 맞추어 최적화된 데이터베이스를 가지고 있습니다. 예를 들어, Outlook 에는 전자 메일의 데이터베이스가 있습니다. 파일에만 인덱스를 붙였을 경우, Outlook 이 파일만을 사용하게 되어 지금까지의 경험이 필요 없어 지거나 파일시스템과 데이터베이스 모두에 중복 한 기능을 가지도록 구현을 복잡화하지 않는 이상 이 데이터베이스내의 전자 메일에 인덱스를 붙일 수 없습니다.
고도의 쿼리
많은 사용자가 고도의 쿼리(검색 조건)를 간단하게 입력할 수 있는 사용자 인터페이스(UI)가 부족한 것에 대한 불만을 보여주었습니다. Microsoft의 많은 제품에는 다수의 고도의 쿼리의 UI 가 있지만, 이것들은 일반적으로 충분히 정의된 조회언어 (SQL)나 고유의 영역 (Outlook 의 [고도 검색] 등)을 의식한 것입니다. Vista에서는 우리는 더 현재의 사용자가 익숙한 방법, 즉 단일 편집 컨트롤로 쿼리 문제에 대처하고 싶었습니다. 이 구현에서는 그러한 편집 컨트롤에서 풍부한 조회 언어를 지원합니다. 이것은 사용자가 웹 검색의 표준 쿼리와 고도의 쿼리 양쪽 모두에 익숙한 것과 같은 접근 방식입니다.
우리는 다음의 두가지 관찰 결과에서 이 접근 방식에 이르렀습니다.
- 검색의 가장 중요한 요소는 검색 용어입니다. 일반적으로는 단일 용어로 충분합니다 (또, 웹 검색에서 알고 있도록, 검색의 대부분은 1 개 또는 2 개의 단어입니다).그리고, 정밀도를 높이기 위해서, 축소 표시, 정렬, 선행 입력 등의 파일시스템 도구를 사용하여, 결과를 한층 더 좁힐 수 있습니다.
- 속성 기반의 검색을 할 수 있는 고도의 쿼리의 UI 설계를 검토하는 것이 맞는 말이지만, 그러한 UI 는 한 걸음 나아가 PC를 잘 다루고자 하는 사용자 이외에는 사용하기 불편합니다. 지금까지 언급한 것처럼, Windows 검색은 기본값에서 300 을 넘는 속성에 대응하여, 모든 속성을 표시하면 UI 는 사용할 수 없게 됩니다. 가장 자주 사용되는 속성만을 표시한다면, 여러분은 그 외의 속성을 어떻게 처리할까요. 자주 사용되는 응용 프로그램 별로, 또는 시간, 이름, 파일 특성 등의 특성 별로 속성을 그룹화할까요? Outlook의 [Advanced Find]의 인터페이스를 평가하는 사용자도 있겠지요.그러나, 이 경우도 몇가지의 문제가 있거나, 이 UI 가 그룹이나 관련성이 있는 속성이 특정 영역 내의 것임을 알 수 있을 것입니다.
Vista 설계에서는 우리는 정확한 쿼리를 실행해야 한다는 피드백을 반영했습니다. Vista 의 접근 방식은 모든 속성을 다루며, 상당히 자연스러운 구문을 사용할 수 있는 기능이 풍부한 조회 언어를 지원하는 것이었습니다. 예를 들어, 「from:gerald sent:today」라고 입력하면, 「Gerald」가 오늘 보낸 모든 전자 메일이 검색됩니다. 큰 문제는 사용자가 조회 언어를 모르는 것입니다. Windows 7에서는 우리는 사용자가 문맥내의 조회 언어 사용 방법을 이해할 수 있도록 지원하는 것에 중점을 두었습니다. 현재로서는 Vista 쿼리 구문은 이정도 알려져 있습니다. 이 구문과 경험의 대부분은 우리가 현재 사용하고 있는 웹 검색과 비슷합니다.
또, 현재 지원되지 않는 서브 문자열 일치에 대해도 다수의 댓글이 있었습니다. 이것도 고도의 쿼리에 관한 전체적인 논의의 일부입니다. 쿼리를 효율적으로 실행하기 위해서, 인덱서는 개개의 단어에 근거한 인덱스를 구축합니다. Vista에서는 우리는 검색 UI 에 「입력 진행과 함께 검색 실행」을 도입했습니다. 이 기능은 뒤에 인덱스가 붙일 수 있었던 단어에 대한 접두사(Prefix)의 일치로서 구현됩니다. 때문에 「foo」라고 입력하면, 「food」나 「football」 등, 이러한 문자로 시작되는 모든 단어가 검색됩니다. 한층 더 재미있는 것은 「foo net」이라고 입력하면, 「food」와「network」이라는 두개의 단어를 포함한 항목이 일치합니다 (문자 그대로 「foo net」라는 어구를 일치시키는 경우는 이러한 단어를 인용부호로 둘러쌉니다. 이것도 고도의 쿼리 구문 1 개의 예입니다).우리는 주로 임의의 속성 내에서 단어를 검색하는 것에 중점을 두었지만, 파일 이름이 특별하다는 것에 의문의 여지는 없습니다. 이것을 염두에 두고, 우리는 파일 이름에 대한 접미사(Suffix) 쿼리를 지원합니다. 「food」라고 입력하면, 「GoodFood」등의 「food」로 끝나는 파일이 반환됩니다. 이것은 파일 이름을 반대로 하고, 그것을 단어로서 인덱스를 붙이는 것으로 구현됩니다. 예를 들어, 「GoodFood」의 반대의 파일 이름은 「DooFdooG」가 되어, 이것을 단어로서 인덱스를 붙입니다. 접미사 쿼리의 「food」는 반대의 파일명 인덱스를 사용하여 접두사(Prefix) 쿼리의 「doof」에 변환됩니다. 이것은 상당히 좋은 아이디어라고 생각합니다. 이와 같이, 우리는 모든 속성으로 접두사(Prefix) 일치를 지원하여, 파일 이름에서는 접미사 일치를 지원하지만, 서브 문자열의 일치는 지원하지 않습니다.
성능과 권한
성능과 권한 향상에 중점을 둔 댓글도 많이 있었습니다. 그리고, 우리는 이러한 의견에 전적으로 동의합니다. 우리는 Windows 가 보다 적은 리소스로 보다 많은 작업을 실행하도록 항상 노력하고 있습니다. 인덱스 서비스를 모두 무효로 하는 사용자에 대해서는 이 연속적인 개선에 의해서 한번 더 인덱스 서비스를 사용하여 주시길 바랍니다. 모든 파일을 제대로 정리해도 파일 검색이 편리하지 않다고 생각하는 사용자도 시작 메뉴 검색이나 전자 메일 검색, 또는 Internet Explorer 8 의 주소 막대 검색은 편리하다고 느끼실 것입니다. 우리는 Windows 전체의 성능과 권한 향상에 노력해 왔습니다. 이러한 노력의 일부는 벌써 Windows Search 4 로 형태가 되었고, Windows 7에서도 이해해 주실 수 있겠지요.우리는 인덱스 서비스의 비용, 배터리 수명, 권한, 쿼리 속도 스크롤 속도 등의 모든 차원에서 개선을 실시해 왔습니다. 또, 성능 문제의 추적을 지원하는 훌륭한 도구도 가지고 있습니다. idx-help@microsoft.com으로 연락해 주시면 성능을 추적하여 수집하는 방법을 알려 드리겠습니다. 그 데이터를 우리에게 전송해 주시면, 새로운 개선을 하도록 노력하겠습니다.
Chris McConnell
Find and Organize 팀