И еще раз к вопросу о поиске

  • Article

Вашикомментариииэлектронныесообщениявочереднойразпредставилишансрассказать о особенностях разработки Windows 7. Пользователиоставилинемалокомментариев , предлагающихальтернативныйподходк реализации поиска, поэтому мы подумали, что было бы здорово поговорить о них и их плюсах и минусах . Этоявляетсяещеоднимпримероминженерногобаланса, которого мы пытаемся достичь вWindows 7 . Итак , словоКрисуМакКоннелу . -- Стивен

Спасибо за ваши отзывы и комментарии к статье о механизме поиска в Windows. В данной статье я попытался подытожить мнения пользователей, снабдив их комментариями, которые позволят лучше понять сделанные архитектурные изменения и причины их появления .

Интеграциясфайловойсистемой

Как отметили читатели, одной из возможных реализаций механизма является интеграция индексатора в файловую систему, чтобы при обновлении файла происходило автоматическое обновление индекса. В Windows Desktop Search используется другой подход. При интеграции с файловой системой возникает два момента: необходимо точно определить момент, когда файл подвергается изменениям, и провести индексацию файла до того момента, когда он будет снова доступен для чтения/записи. В файловой системе NTFS в случае изменений в файлах индексатор получает уведомления. Индексатор никогда не выполняет сканирование NTFS – лишь первый раз при создании индекса. Если выполнять индексацию по закрытии файла, то в течение некоторого времени он будет недоступен для файловых операций, покуда не завершена процедура индексации. И тут проявляется масса недостатков такого подхода. Мы предпочли вынести индексатор за пределы файловой системы, поскольку это дает больше свободы, практически не сказываясь на скорости индексации. Вот лишь несколько преимуществ выбранного нами подхода:

1. Требуется меньше ресурсов. Обратные индексы являются всеобщими. Обратные карты индекса конкретного слова соотносятся с каждым документом, содержащем это слово. Индексирование отдельного файла требует обновления индекса на каждое уникальное слово, обнаруженное в документе. Таким образом, изменения в одном документе могут привести к обновлению различных индивидуальных индексов, что может довольно дорого обойтись для системы. Структура индексатора предполагает планирование и накопления изменений для того, чтобы снизить нагрузку на систему в смысле процессорного времени и дискового ввода-вывода. Система остается устойчивой потому, что процедура индексации происходит не только при закрытии файла, и в случае необходимости может быть перезапущена в любой другой момент времени.

2. Файловые операции имеют приоритет над индексированием. Возможность мгновенного закрытия файла и его доступность для дальнейших изменений является необходимым условием, обеспечивающим возможность использования файла приложением. Мы не желаем, чтобы индексирование файла становилось причиной увеличения времени закрытия файла. Поиск файлов, безусловно, важен, но он не важнее самой работы с ними. Однако, мы также не хотим, чтобы каждое приложение самостоятельно решало, включать или отключать индексатор лишь потому, что разработчики хотят обеспечить ему более высокую производительность.

3. Существует масса типов файлов. В состав Windows входят экстракторы (IFilter/IPropertyHandler) для наиболее распространенных типов файлов. Как известно, существует огромное количество других типов файлов, поэтому крайне важно обеспечить разработчикам возможность создания экстракторов для них. В Vista (и Windows 7) экстракторы выполняются в закрытом процессе, гарантирующем безопасность и не влияющем на производительность системы в целом. Если проводить индексирование перед тем, как файл становится доступным, экстрактор может оказать влияние (намеренно или нет) на все проводимые в данный момент файловые операции.

4. Некоторые файлы имеют большую значимость для индекса, чем другие. Если индексирование проводить при закрытии файла, не будет возможности контролировать очередность индексации. Наша же реализация позволяет расставлять приоритеты. Так, к примеру, поиск музыкальной композиции более вероятен, нежели поиск двоичного файла. Если музыкальные и двоичные файлы одновременно подверглись изменениям, индексатор в первую очередь проведет индексацию музыкальных файлов. Некоторые файлы для большинства пользователей не имеют никакого значения, поэтому проводить их индексацию, по крайней мере, неразумно. Некоторых пользователи высказали идею о необходимости индексации всего жесткого диска. Сделать это достаточно просто – просто добавьте нужные вам папки в настройках индексатора (через панель управления “Indexing Options”). Для львиной доли пользователей индексирование системных файлов является пустой тратой своего и процессорного времени, поскольку они никогда не будут искать их, а в большинстве случаев появление в результатах поиска системного файла сочтут недоразумением.

5. Не каждый объект является файлом. Windows поддерживает такие файловые системы, как FAT32 или CDFS, и поэтому ничего удивительного в нашем стремлении обеспечить возможность поиска в таких системах нет. Если интегрировать поиск лишь в NTFS, тогда другие системы останутся за бортом. Многие приложения используют для своих нужд собственные базы данных. Например, Outlook использует базу данных сообщений. Если индексировать лишь файлы, тогда сообщения электронной почты было бы невозможно проиндексировать до тех пор, пока сообщения в Outlook не превратятся в файлы. Или, как вариант, пришлось бы дублировать каждое сообщение в виде файла и в виде записи базы данных Outlook.

Расширенные запросы

Некоторые из наших читателей выразили огорчение отсутствием возможности использования сложных запросов. В большинстве программных продуктов Microsoft присутствует интерфейс для составления сложных поисковых запросов, но, как правило, созданы они для специальных языков (SQL). В Vista мы хотели упростить проблему с поиском методами, знакомыми сегодняшнему поколению пользователей – однострочным полем для поиска. Тем не менее, наша реализация поддерживает расширенные запросы. Поэтому пользователи, знающие язык расширенных запросов и применяющие его для поиска в Интернете, могут с легкостью использовать его и в поле для поиска в Windows Vista.

На использование такого подхода нас натолкнули два наблюдения:

1. Наиболее важной частью поиска являются элементы поискового запроса. Как правило, одного элемента достаточно (согласно статистике, в Интернете в большинстве случаев поиск осуществляется по одному или двум словам). И для очистки результатов могут использоваться такие инструменты файловой системы как контрольные изображения, сортировка и опережающий ввод, которые позволяют сузить область поиска.

2. Было бы разумным предусмотреть интерфейс для расширенных запросов, покрывающий поиск по любым объектным свойствам, но для большинства пользователей он бы оказался слишком сложным и неповоротливым. Как было сказано выше, Windows Search может осуществлять поиск по 300 свойствам, поэтому представьте, каким мог быть интерфейс, позволяющий осуществлять поиск по ним всем. Если включить в интерфейс лишь наиболее распространенные свойства, то каким образом осуществлять поиск по оставшимся? Будут ли эти свойства сгруппированы по приложениям или таким аттрибутам, как время создания/редактирования, имя, права или иным? Некоторые из вас вспомнят функцию Advanced Find из Outlook, но следует понимать, что в Outlook группировку по связанным свойствам гораздо проще понять и реализовать, чем по всей ОС.

При разработке Vista мы учли ранее полученные отзывы, предлагающие обеспечить поддержку расширенных запросов. Благодаря этому в Vista появился язык расширенных запросов, предполагающий достаточно простой синтаксис запроса. Так, к примеру, ввод в строку поиска запроса «from:gerald sent:today» возвратит все письма от пользователя с именем «Gerald», отправленные в течение сегодняшнего дня. Проблемой является то, что большинство пользователей не знакомы с языком запросов. В Windows 7 мы намерены помочь пользователям в использовании языка запросов в зависимости от контекста. Ну а пока рекомендуем ознакомиться с синтаксисом запросов в Vista. Основная часть правил синтаксиса аналогична используемым в Интернете.

Несколько пользователей спросили о совпадениях фрагментов строк в именах файлов, которые мы на текущий момент не поддерживаем. Это является предметом жарких обсуждений по поводу расширенных запросов. С целью эффективно обрабатывать запросы индексатор строит индексы на базе отдельных слов. В Vista дебютировала система поиска по мере ввода информации, реализованная за счет совпадений префиксов проиндексированных слов. Поэтому когда вы вводите ‘foo’, система ищет совпадения, включая в результаты слова ‘food’ и ‘football’. Если ввести ‘foo net’, система возвратит результат со словами ‘food’ и ‘network’. Поэтому если вы хотели отыскать фразу “foo net”, тогда в поле для поиска необходимо взять поисковый запрос в кавычки – еще один пример синтаксиса запросов. Наша основная задача – обеспечить возможность поиска по всем возможным объектам, но имена файлов – это отдельный вопрос. По этой причине мы организовали поддержку запросов по суффиксам файловых имен. Если вы введете ‘*food’, поиск возвратит файлы, оканчивающиеся на ‘food’, например, ‘GoodFood’. Это достигается за счет реверсирования имени файла и его последующей индексации как нового слова. Например, реверсирование имени файла ‘GoodFood’ дает нам ‘DooFdooG’, которое мы индексируем как новое слово. Запрос по суффиксу ‘*food’ переводится в запрос по префиксу ‘doof*’ – логично, не так ли? Таким образом, наша реализация поддерживает все совпадения по префиксам для всех объектов поиска и совпадения по суффиксам для имен файлов, но не поддерживает подстрочные совпадения.

Производительность

Многие из читателей говорят об увеличении производительности и мы, безусловно, с ними согласны. Мы всегда стремимся, чтобы в каждом новом выпуске Windows пользователь смог делать больше с меньшими усилиями и с меньшим количеством ресурсов. Мы надеемся, что изменения в механизме поиска позволят всем тем, кто сегодня предпочел отключить службу индексации, пересмотреть свое решение. Даже если на вашем жестком диске царит порядок, а саму идею поиска файлов вы считаете бесполезной, возможно, что поиск в меню Start, поиск в почтовой программе или поиск с помощью Internet Explorer 8 окажется весьма полезным. Мы усердно работали над тем, чтобы увеличить производительность механизма поиска, сделав его неотъемлемой частью Windows. Достигнутые нами результаты заметны в WS4, а в скором времени вы увидите их и в Windows 7. Мы сократили нагрузку на процессор, увеличили время работы от батарей, улучшили интеграцию с системой и увеличили скорость обработки запроса. Кроме того, мы разработали несколько инструментов, которые помогают нам выявлять проблемы с производительностью. Если вы желаете помочь, пожалуйста, направляйте ваши отчеты на электронный ящик idx-help@microsoft.com и мы расскажем, каким образом необходимо проводить измерения производительности, чтобы их можно было анализировать и использовать для дальнейшего совершенствования механизма поиска.

Крис МакКоннелл (Chris McConnell)