フォローアップ: Windows デスクトップ検索

  • Article

デスクトップ検索に関するディスカッションと電子メールは、Windows 7 のエンジニアリングに関するアーキテクチャのディスカッションを深める機会を与えてくれました。たくさんのコメントで代替の実装方法が提案されていたため、私たちは別のアプローチとそれに関するさまざまな賛否両論を話し合おうと考えました。このアプローチは、私たちが Windows 7 で苦労して実現しようとしているエンジニアリングのバランスについて示す良い例です。このフォローアップは Chris McConnell が執筆しています。--Steven (あと一週間に迫った PDC で会いましょう！)

Windows デスクトップ検索に関する前回のポストにはすばらしいフィードバックをいただき、ありがとうございました。ここでは、多数出された問題点をまとめ、私たちがアーキテクチャに関して行った選択とその理由についていくつかコメントしてみました。

ファイル システムとの統合

何人かの方が指摘しているように、実装で可能な 1 つの形態として、インデックス サービスとファイル システムを統合し、ファイルが更新されたら即座にインデックスも更新されるようにするという方法があります。Windows デスクトップ検索では、これとは違うアプローチを選択しています。ファイル システムの統合には 2 つの側面があります。1 つはファイルが変更されたことの検知で、もう 1 つはファイルが「閉じ」られ、使用可能と見なされる前の実際のインデックス更新です。NTFS ファイル システムでは、ファイルが変更されると必ずインデクサーに通知されます。インデクサーは初期のインデックス作成時以外は NTFS ファイル システムをスキャンしません。私たちが統合とは異なる選択をしたのは、2 番目の点 (ファイルが閉じられるときに即座にインデックスを更新する) について考えたからです。新しいインデックスが作成されるまでその新しいファイルは検索対象になりませんが、即座にインデックスを更新するという方法によって、それが回避できるというメリットがあります。しかしこの方法には多くの潜在的なデメリットが付随します。私たちは、ほぼリアルタイムでありながらより高い柔軟性が得られるという理由により、インデックス サービスとファイル システム処理を切り離すことにしました。私たちが選んだアプローチのいくつかのメリットを次に示します。

  1. 使用されるリソースが少ないこと。システムに1 つ、グローバルなインデックスを用意しました。それは、1 つの単語とシステムの中でその単語を含むすべてのドキュメントをマッピングしています。1 つのファイルに含まれるすべての単語に対して、インデックスを作るのです。たとえば 1 つの文書であればそれに含まれる膨大な数の個別のインデックスが作成され更新されることになります。これらの変更に追従し、かつ個々のファイルと同じような堅牢さでインデックスの変更を確実に実行していくには、高いコストがかかります。インデクサーは、このような変更をスケジュールおよび集約して全体で実行される作業を大幅に減らし、CPU の使用やディスク I/O を少なくできるように設計されています。ファイルが閉じられたときにインデックス作成が発生しないことで、システムはより堅牢になります。また、必要に応じてインデックス作成をやり直すこともできます。
  2. ファイル システム処理がインデックス サービスより優先されること。ファイルが堅牢に更新され、使用可能になっていることは、ファイルを使用するアプリケーションにとっては大前提です。ファイルを閉じる処理にインデックス作成を含めることによってファイルが使用可能になるのが遅れることは避けなければなりません。ファイルの検索は重要ですが、実際のファイル操作のほうがもっと重要です。私たちは、アプリケーションがファイル システムに関して最高のパフォーマンスを求めるために、それらが個別にインデクサーのオンまたはオフを決定する状況は望ましくないと考えています。
  3. 多くのファイル タイプを扱えること。マイクロソフトは Windows の一部として多くの共通ファイル タイプ用の抽出プログラム (iFilter や IPropertyHandler) を提供しています。ファイル タイプは他にも多数あるため、マイクロソフト以外の開発者が独自の抽出プログラムを作成できるようにすることも重要です。Vista (および Windows 7) では、このような抽出プログラムは、セキュアでシステム全体のパフォーマンスに影響を与えないことが保証された限定的なプロセスで実行されます。ファイルが使用可能になる前にインデックスを作成しなければならない場合、抽出プログラムがすべてのファイル システム処理に影響を与える (故意であってもなくても) おそれがあります。
  4. インデックスの有効性がファイルにより異なること。ファイルが閉じられるときにインデックス作成をする場合、ファイルにインデックスが付けられる順序を制御することは不可能です。しかしファイル操作とインデックス作成を切り離す（インデックス作成は後でまとめて行う）ことにより、インデックスを付けるファイルの優先順位付けが可能になります。たとえば、音楽はバイナリ ファイルよりずっと頻繁に検索されることが考えられます。音楽ファイルとバイナリ ファイルの両方が変更された場合、インデクサーは音楽ファイルに先にインデックスを付けます。ほとんどのユーザーにとってインデックスを付ける価値のないファイルもあります。いくつかのコメントでは、ドライブ全体にインデックスを付けてはどうかという提案もありました。それももちろん可能です。また、そうする価値が本当にあれば、インデックスを付けるフォルダーを追加することも簡単にできます (インデックスの削除もできます。ただし、削除はずっとまれなので、[コントロール パネル] の [インデックスのオプション] で管理します)。しかしほとんどのユーザーにとっては、システム ファイルにインデックスを付けることはコストでしかありません。このようなユーザーがシステム ファイルを検索することはなく、検索結果にそれらが表示されたら逆に混乱することになってしまいます。
  5. 1 つのファイル システム内のファイルがすべてとは限らないこと。Windows は多様性をサポートしていく使命があります。Windows には FAT32 や CDFS など、多くの異なるファイル システムがあり、私たちはそれらも検索できるようにしたいと考えています。最初はNTFS のみを検索対象にするとしても、いずれその他のファイル システムと何らかの関連性を持たせる必要が出てきます。また、多くのアプリケーションは独自のニーズに合わせて最適化されたデータベースを持っています。たとえば、Outlook には電子メールのデータベースがあります。ファイルのみにインデックスを付けた場合、Outlook がファイルのみを使用することになってそれまでの経験が無駄になるか、ファイル システムとデータベースの両方に重複した機能を持つように実装を複雑化しない限り、このデータベース内の電子メールにインデックスを付けることはできません。

高度なクエリ

多くのユーザーが高度なクエリ（検索条件）を簡単に入力できるユーザーインターフェース（UI）が不足していることへのフラストレーションを示しています。マイクロソフトの多くの製品には多数の高度なクエリの UI がありますが、これらは通常十分に定義された照会言語 (SQL) や固有の領域 (Outlook の [高度な検索] など) を意識したものです。Vista では、私たちはもっと現在のユーザーが使い慣れた方法、つまり単一の編集コントロールでクエリの問題に対処したいと考えました。この実装では、そのような編集コントロールで豊富な照会言語をサポートしています。これは、ユーザーが Web 検索の標準クエリと高度なクエリの両方で使い慣れているのと同じアプローチです。

私たちは、次の 2 つの観察結果からこのアプローチに至りました。

  1. 検索の最も重要な要素は検索する用語です。通常は単一の用語で十分です (また、Web 検索からわかっているように、検索の大半は 1 つまたは 2 つの単語です)。そして、精度を高めるために、縮小表示、並べ替え、先行入力などのファイル システム ツールを使用し、結果をさらに絞り込むことができます。
  2. プロパティ ベースの検索ができる高度なクエリの UI の設計を検討することは理にかなっていますが、そのような UI は一歩踏み込んでPCを使いこなそうとするユーザー以外には使いにくいものです。これまでにも言及したように、Windows サーチは既定で 300 を超えるプロパティに対応しており、すべてのプロパティを表示したら UI は使用できなくなるでしょう。最もよく使用されるプロパティのみを表示するとしたら、皆さんはその他のプロパティをどのように処理するでしょうか。よく使用されるアプリケーションごとに、または、時間、名前、ファイル属性などの属性別にプロパティをグループ化するのでしょうか。Outlook の [高度な検索] のインターフェイスを評価するユーザーもいるでしょう。しかし、この場合もいくつかの問題に気づいたり、この UI がグルーピングや関連性のあるプロパティが理解された特定の領域内でのものであることがわかるでしょう。

Vista の設計では、私たちは正確なクエリを実行すべきであるというフィードバックを取り入れました。Vista でとられたアプローチは、すべてのプロパティを扱いかなり自然な構文が使用できる機能豊富な照会言語をサポートすることでした。たとえば、「from:gerald sent:today」と入力すると、「Gerald」から今日送られたすべての電子メールが検索されます。大きな問題は、ユーザーが照会言語を知らないことです。Windows 7 では、私たちはユーザーがコンテキスト内の照会言語の使用方法を理解できるように支援することに重点を置きました。現在のところ、Vista のクエリの構文は、このリンクである程度わかるようになっています。この構文とエクスペリエンスの大部分は、私たちが現在使用している Web 検索と似ています。

また、現在サポートされていないサブ文字列の一致についても多数のコメントがありました。これも、高度なクエリに関する全体的なディスカッションの一部です。クエリを効率的に実行するために、インデクサーは個々の単語に基づいたインデックスを構築します。Vista では、私たちは検索 UI に「入力の進行とともに行われる検索」を導入しました。この機能は、裏側ではインデックスが付けられた単語に対するプレフィックスの一致として実装されています。そのため、「foo」と入力すると、「food」や「football」など、これらの文字で始まるすべての単語が検索されます。さらに面白いことに、「foo net」と入力すると、「food」と「network」という単語を含む項目が一致します (文字通り「foo net」という語句を一致させる場合は、これらの単語を引用符で囲みます。これも高度なクエリの構文のもう 1 つの例です)。私たちは、主として任意のプロパティ内の語を検索することに重点を置いてきましたが、ファイル名が特別だということに疑問の余地はありません。このことを念頭に置き、私たちはファイル名に対するサフィックス クエリをサポートしています。「food」と入力すると、「GoodFood」などの「food」で終わるファイルが返されます。これは、ファイル名を逆にして、それを単語としてインデックスを付けることによって実現されます。たとえば、「GoodFood」の逆のファイル名は「DooFdooG」となり、これを単語としてインデックスを付けます。サフィックス クエリの「food」は、逆のファイル名インデックスを使用してプレフィックス クエリの「doof」に変換されます。これはなかなかいいアイデアだと思っています。このように、私たちはすべてのプロパティでプレフィックスの一致をサポートし、ファイル名ではサフィックスの一致をサポートしますが、サブ文字列の一致はサポートしません。

パフォーマンスと市民権

パフォーマンスと市民権の向上に重点を置いたコメントもたくさんありました。そして、私たちはこれらの意見に完全に同意しています。私たちは Windows がより少ないリソースでより多くの作業を実行するように常に努力しています。インデックス サービスをすべて無効にしているユーザーに対しては、この継続的な改善によってもう一度インデックス　サービスを使っていただけるように願っています。すべてのファイルをきちんと整理していてファイルの検索が便利だと思っていないユーザーも、スタート メニューの検索や電子メールの検索、または Internet Explorer 8 のアドレス バーの検索は便利だと感じていただけるのではないでしょうか。私たちは、Windows 全体のパフォーマンスと市民権の向上に努めてきました。このような努力の一部はすでに Windows Search 4 で形になっており、すぐに Windows 7 でもおわかりいただけるでしょう。私たちは、インデックス サービスのコスト、バッテリ寿命、市民権、クエリ速度、スクロール速度などのあらゆる次元で改善を行ってきました。また、パフォーマンスの問題の追跡を支援するすばらしいツールも持っています。idx-help@microsoft.comまでご連絡いただければパフォーマンスのトレースを収集する方法をお知らせします。そのデータを私たちへお送りいただくことによって、さらなる改善をしていきたいと考えています。

Chris McConnell

Find and Organize チーム