次の方法で共有

Windows 데스크톱 검색

  • [アーティクル]

 

많은 피드백중의 하나는 서비스를 무효화해서, 선택적인 구성요소로 설치하는 것입니다. 이 분야에 대한 우리 목표는 이전의 포스트에서 다뤘습니다. 이런 종류의 컨트롤에 대한 필요성의 요인은 여러가지 있지만, 중요한 요인은 다양한 플랫폼 구성요소의 성능 및 리소스 소비율에 관련한 인식입니다. Windows의 목표는 개발자들이 안정성 높고, 일관성 있는 플랫폼 ― 개발자가 항상 시스템 서비스가 제공되는 장소로서 의지할 수 있을 뿐만 아니라, 모든 고객에게 혜택을 줄 수 있는 OS 의 기능을 목표로 할 수 있는 장소 ― 를 제공하는 것에 있습니다. 동시에 우리는 시스템 리소스의 활용면에서 효율적인 ― 비용 대비 장점이 훨씬 뛰어난 정도의 ― 방법으로 이것을 실천해야 합니다. 사용자 일부는 손으로 계산하는 이외, 이 방정식의 해답은 얻을 수 없다고 인식하고 있습니다. 차의 성능을 최대화 하려면, 수동 변속 밖에 없다고 믿는 사람이 있듯이. 이 포스트에서는 널리 이용 가능한 플랫폼 구성요소 및 풍부한 최종 사용자 기능을 제공하기 위한 데스크톱 검색 기능을 검토하는 것과 동시에 관련하는 엔지니어링기반에서 절충 및 모든 사용자에서 훌륭한 해결책을 구축하기 위해서 채택하고 있는 기법에 대해 설명합니다. 이 포스트는 Find and Organize 팀 Chris McConnell 의 도움을 받아 작성하였습니다. -- Steven

드라이브의 램프가 격렬하게 점멸하는 원인은 검색 인덱스를 생성 중이라고 믿고 있습니까? 친구와 슈팅 게임을 플레이 하고 있을 때 뒤지는 이유가 이것이라고 믿고 있습니까? 만약 이것들을 정말로 믿고 계신다면, 이번은 확실히 당신을 위한 포스트입니다. Find and Organize 팀은 「Windows 검색」서비스를 담당하고 있습니다. 우리는 이것을 간단히 「인덱서」라고 부릅니다. 일부의 Vista 고급 사용자에서는 「인덱서를 무효로 했으면 좋겠다」라고 반복해서 말하고 있습니다. 그들은 인덱서가 PC 의 귀중한 시스템 리소스를 다 사용하는것에 비해 비교적은 얻을 수 있는 것이 거의 없다고 합니다. 우리가 원격 측정 한(원격 측정법) 데이터에 의하면, 인덱스 생성 서비스를 무효로 하는 것은 기껏해야 Vista 사용자의 약 1.5% 입니다. 위에 쓴 것과  같이,  인식이 그들을 그렇게 하도록 만들었다고 생각합니다.

이 문서는 인덱서 역할을 명확화하고 및 인덱서가 시스템 리소스를 어떻게 사용하는지를 조사한 결과에 대해 설명하겠습니다. 우선, 인덱스 생성 서비스의 기능에 대해 이야기하는 것부터 시작합시다. 그것은 무엇을 위한 것일까요?  왜 그것을 동작 하게 해야만 할까요?

인덱스의 목적

요즘의 PC 는 문서, 사진, 음악, 비디오 등, 다양한 종류의 파일이 있습니다. 사용자가 PC 에 저장하는 파일의 수는 급속히 증가하고 있습니다. 아무리 파일을 잘 정리해 두었다 해도 원하는 것을  찾는 것은 점점 더  어려워 지고 있습니다. 점차, 이러한 파일에는 컨텐츠를 기술하는 메타데이터 속성 대량으로 포함되어 있습니다. 전형적인 음악 파일에는 아티스트, 앨범명, 출시 년도, 장르, 연주 시간 등, 음악을 찾을 때 매우 도움이 되는 정보를 기술한 특성이 포함됩니다.

검색 인덱스 생성 기술은 Windows 초기로 거슬러 올라가는데, Microsoft 는 Windows Vista에서 보다 많은 사용자에 대해서 이 기능을 사용하도록 하고 있습니다. Vista 이전의 Windows 검색 기능은 매우 원시적으로,  대부분의 경우, 파일 이름이나 수정할 때, 크기와 같은 단순한 파일 속성이나, 응용 프로그램 고유의 데이터가 가지는 응용 프로그램 고유의 인덱스를 의지하여,  컴퓨터에서 파일을 하나씩 일일이 찾는 기능이었습니다. 또, 보다 포괄적인 검색 옵션을 사용하여, Windows 범위내에서 파일 내용을 조사할 수도 있었지만, 이것은 그다지 사용되지 않았습니다. 이것은 지극히 기본적인 기능이었습니다 ― 모든 파일을 완전히 동일하게 취급하고, 파일에서 이용할 수 있는 풍부한 메타데이터 특성은 이용하지 않았습니다.

Windows Vista에서는 인덱스 생성 서비스가 기본값에서 유효하게 설정되어, 인덱스가 있는 다양한 파일 형식이나 속성에 대한 확장 지원이 있습니다. 인덱서는 PC 에 저장된 폴더를 살펴보고, 그 내용을 카탈로그화하여, 파일을 빠르게 검색할 수 있습니다. Windows 는 음악 파일에 색인이 있는 경우에 사용자가 가장 많이 검색할 것 같은 음악 고유의 속성을 추출하는 방법도 알고 있습니다. 이렇게 하면 예전에는 불가능했던, 보다 강력한 파일검색과 보다 풍부한 정보 표시 지원이 가능합니다. 그러나, 이 인덱스 생성 기능은 공짜로 손에 넣을 수는 없습니다. 여기에서 엔지니어링이 흥미로워 집니다. 시스템 자원에 관해 말하면, 이 기능을 구현하기 위해 지불해야 하는 비용은 제로가 아닙니다. 또, 그 대가를 언제, 어떻게 지불할지에 대한 절충도 있습니다. 이것은 인덱스 생성만의 일이 아닙니다. 모든 기능에서  비용과 장점 사이에서 절충을 하고 있습니다.

절충

많은 검색 솔루션은 기존은 「grep」모델을 따르고 있습니다. 즉, 어떠한 검색도 검색 대상이 되는 파일을 모두 읽어 드립니다. 이 경우, 검색 실행을 기다리는 시간을 대가로 해서 지불한 것이 됩니다. 검색하는 파일의 수가 많으면 많을수록, 검색할 때마다 기다리는 시간도 길어집니다. 다시 같은 검색을 실시하는 경우, 한번 더, 이 대가를 「지불」 합니다. 그러나, 검색 기능은 그만큼 강력하지는 않았기 때문에 담보는 그만큼 가치가 있는 것이 아니었습니다. Windows Vista에서는 인덱서는 사용자가 검색하기 전에 모든 파일을 읽어들이기 때문에 검색했을 때에는 일반적으로, 보다 빨리 응답합니다.  이 때문에 인덱서는 최초로 한 번만, 모든 파일을 스캔하면 됩니다. 사용자가 검색을 실행할 때마다가 아닙니다. 파일이 변경되었을 경우, 인덱서는 통지 (푸쉬 이벤트)를 받아, 이 파일을 한번 더 읽어들일 수 있게 됩니다. 인덱서는 파일을 읽는 경우, 보다 강력한 검색이나 표시를 가능하게 하도록, 이 파일에 대해 적절한 관련정보를 추출합니다. 여기에는 인덱스가 항상 최신으로, 곧바로 검색에 사용할 수 있을 정도로 빠르게 이 작업을 실시하는 것 뿐만아니라, 시스템 성능에 마이너스의 영향을 주지 않는 듯한 방법을 취해야 하는 어려움이 있습니다. 이 작업에서는 항상 비용과 장점의 균형을 취해야 합니다. 또, “선량한 Windows 시민”의 입장을 유지하면서, 인덱스가 항상 최신 상태임을 보장하기 위해서, 인덱서가 하는 일은 여러가지가 있습니다.

모범적 시민

인덱서를 모범적인 Windows 시민으로 만들기 위해 다양한 노력을 해 왔습니다. 우리는 이 건에 대해, 세부 사항 백서를 발행했지만,  그 중 중요한 부분을 몇가지를 여기서 소개하고자 합니다. 가장 먼저, 인덱서는 특정 폴더를 감시할 뿐입니다. 이것에 의해, 인덱서가 해야 하는 일의 양이 사용자가 검색할 것 같은 파일에만 제한됩니다. 또, 사용자가 PC 를 연속적으로 사용하고 있을 때는 인덱서는 작업 속도를 떨어뜨립니다. 인덱서는 PC 작업 수준에 따라, 파일 색인 속도를 느슨하게 하거나 또는 완전히 정지합니다. 인덱서는 파일 로드에는 우선 순위가 낮은 I/O 와 CPU 를 사용합니다. 또 로드중에 다른 응용 프로그램에서 이 파일에 대한 액세스가 요청되면,  바로 이 파일을 릴리스합니다.

인덱서에 대한 이러한 문제를 모두 해결하는 것은 중요합니다. 왜냐하면, 이것은 우리 팀이 빌드하고 있는 Windows Search 등의 기능 만이 아니라, Windows 플랫폼 전체에서 중요한 일이기 때문입니다. PC에서 파일 내용을 검색하는 능력이 필요한 응용 프로그램은 다수 있습니다. 이러한 응용 프로그램이 각각의 독자적인 인덱서를 구축하면 어떻게 되는지, 상상해 보세요. 이러한 응용 프로그램이 모두 훌륭한 일을 한다 해도 PC 에서는 불필요한 장황한 처리를 많이 해야 합니다.  문서를  하나 저장 할 때마다, 이러한 다른 인덱서가 빨리 새 버전을 로드하기 위해 액세스 하고, 갑자기 처리가 활발해집니다. 이런 문제에 대처하기 위해, 인덱서는 다른 응용 프로그램이 이용하기 쉽도록 설계되어 유연성과 확장성을 갖춘 개방적인 플랫폼과 API를 개발자에 제공하고 있습니다. 이 API 는 Windows 에코시스템 전체의 요구를 충족할 수 있을 만큼 유연하게 설계되어 있습니다.  상자에서 꺼낸 그대로의 상태의 인덱서는 기본값 설정으로, 대략 200 개의 일반적인 파일의 종류에 대한 정보를 가지고,  약 400개의 속성 카탈로그를 생성 할 수 있습니다. 또, 언제라도 응용 프로그램에 새로운 파일의 종류나 속성을 추가하는 것이 가능합니다. 또한 응용 프로그램은 전자 메일과 같이 파일을 기반으로 하지 않은 데이터 유형의 인덱스 생성에 대한 지원을 추가할 수도 있습니다. Microsoft Office Outlook 및 OneNote, Lotus Notes, Windows Live Photo Gallery, Internet Explorer 8, Google Desktop Search 는 현재, 인덱서를 활용하고 있는 응용 프로그램의 극히 일부입니다. 모든 확장가능시스템과 같이, 시스템 서비스용 구성요소의 창조적인 용도를 개발자가 찾아내는 일은 자주 있습니다. 타블렛 PC 구성요소가 자필 정밀도를 향상시키기 위해서 컨텐츠 인덱스를 활용하는 방법도 이 일례입니다.

연속적인 진화

인덱서의 성능이나 안정성을 향상시키기 위해서, 우리는 계속해서 노력하고 있습니다. 버전 3 은 Windows Vista 와 함께 출시되었습니다. 이 버전에서는 다음 기능을 진화시켰습니다.

  • 인덱서는 사용자 단위의 프로세스 대신, 시스템 서비스로서 동작합니다. 이것에 의해, 다중사용자 시나리오로의 영향을 최소한으로 억제할 수 있습니다. 예를 들어, 1 개의 시스템 근처의 카탈로그 수를 1 개로 제한하여, 카탈로그 크기가 작아져, 같은 내용의 인덱스를 여러번 재생성되는 것을 막을 수 있습니다. 또 그 서비스는 강력하다는 특징이 있습니다.
  • PC 응답에 대한 인덱스 생성의 영향을 최소한으로 억제하기 위해, 인덱서는 우선 순위가 낮은 I/O를 사용합니다. Windows Vista 이전에는 모든 I/O 는 동등하게 다뤄졌습니다.

우리는 Windows XP 및 Vista 에 대한 기능 강화로,  이미 Windows Search  Version 4 를 출시했습니다. Version 4 는 다음과 같이 성능 및 안정성 향상이라는 면에서 한층 앞서가고 있습니다.

  • 정렬, 필터 처리, 그룹화가 필요한 쿼리를 위한 대폭적인 기능 강화. 예를 들어, Vista에서는 다음과 같은 점이 강화되었습니다.
    1. 정렬이나 그룹화를 실시하면서 모든 결과를 얻는다는 점이 강화되었습니다. 전형적인 쿼리 속도는 최고 38% 향상됩니다.
    2. CPU 시간은 80% 삭감됩니다. 
    3. 메모리 사용량은 20% 삭감됩니다.
  • Outlook 가 온라인모드로 동작하고 있을 때, Exchange 서버의 부하는 95% 이상 줄어듭니다. 기존의 Windows Search 버전에서는 온라인모드로 동작하고 있는 대량의 Outlook 클라이언트에 의해, Exchange 서버의 처리 능력을 넘어버립니다. 
  • 안정성에 대해는 다음과 같은 점이 강화됩니다.
    1. 인덱스의 생성 작업을 정지시키는 원인이 된다는  사용자가 보고한 상황에 대응하기 위해서, 다수의 기능 수정을 실시했습니다.
    2. 인덱서에서 인덱스 파괴를 방지하고, 손상된 인덱스를 복구하는 기능을 강화했습니다. 그 결과,  손상된 카탈로그를 검색하여 자동적으로 재구축됩니다. 기존  버전에서는 이것은 특별한 경우에게만 행해졌습니다.
    3. 안정성의 문제를 추적하여, 수정하기 쉽도록 새로운 로그 및 이벤트를 추가했습니다.

우리는 가까운 시일내에 PDC에서 발표되는 Windows 7 에 탑재되는 인덱서 성능 및 안정성을 높이기 위해서, 한층 더 많은 기능 개선을 실시하고 있습니다.

그런데도 인덱서가  번거롭다고 생각되는 분은 다음을 시험해 보세요.

  • Vista 또는 XP 를 사용 한 경우는 Windows Search 4 를 다운로드하여, 설치해 주세요.
  • Vista 를 사용 한 경우는 Windows Live Gadget Gallery에서 Indexer Gadget을 다운로드 하여, 설치 해 주세요.우리 팀원이 생성한 이 가젯을 사용하면, 인덱스가 있는 아이템 수를 빠르게 확인할 수 있습니다. 또, 인덱스 생성을 일시 정지하거나 작업 속도를 떨어뜨리지 않고, 전속력으로 실행할 수 있습니다.
  • “차의 내부 및 엔진을 살펴보는 것을 좋아하는 분은 Windows 작업 관리자나 리소스 모니터를 사용하여, SearchIndexer, SearchFilterHost, SearchProtocolHost 의 세가지 프로세스를 감시해 주세요.

사용하고 있는 시스템이 늦은 것은 인덱서가 원인이라는 혐의가 있는 경우는 PC에서 작업을 하면서, 이 가젯을 관찰해 주세요.문제가 발생하고 있을 때, 인덱스가 붙은 아이템 수가 크게 변화했을까요? 인덱서를 일시 정지하면, 시스템이 회복할까요? 그런데도 아직, 문제가 발생할 것 같다면, 아무쪼록 우리에게 알려주세요.우리는 항상 여러분의 검색 기능을 보다 좋게 만들기 위해 노력하고 있습니다. 피드백을 보내주실 곳은 idx-help@microsoft.com 입니다.

Chris McConnell

Find and Organize

Comments

  • Anonymous
    January 24, 2009
    윈도우즈의 검색은 인덱서가 만든 인덱스의 도움을 받는데 인덱서의 실행은 윈도우즈 비스타의 성능에 큰 영향을 못 미친다. 윈도우즈 비스타에 도입된 "I/O 우선순위

  • Anonymous
    January 24, 2009
    윈도우즈의 검색은 인덱서가 만든 인덱스의 도움을 받는데 인덱서의 실행은 윈도우즈 비스타의 성능에 큰 영향을 못 미친다. 윈도우즈 비스타에 도입된 I/O 우선순위에 의해 인덱서의 I/O는 최대한 억제된다.

  • Anonymous
    February 11, 2009
    데스크톱 검색에 관한 토론과 전자 메일은 Windows 7 엔지니어링에 관한 아키텍처 논의가 깊어질 수 있는 기회를 주었습니다. 많은 댓글에서 대체 구현 방법이 제안되어, 우리는 다른