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


Ваши комментарии и электронные сообщения в очередной раз представили шанс рассказать о особенностях разработки 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)

Comments (5)
  1. Greg001 says:

    В данный момент я пишу из Windows 7 build 6801. На мой взгляд это маленький шедевр програмной архитектуры. Интерфейс пользователя буквально набит всяческими полезными штучкам, а это радует. Aero Shake – замечательная идея создать такой быстрый и лёгкий переключатель свёртыванияразвёртывания. Супербар достоин похвалы, наконец-то исцезли эти кучи кнопок сьедающих пространство панели (а мне как программисту это было очень не удобно). Прилипание к краям экрана – просто чудо, подвёл к краю и готово, окно приняло нужную форму и прилипло к краю, что в ХР нужно было долго метится курсором. UAC – (даже слов не хватает), доведён почти до совершенства всего лишь  8 раз Windows 7 спросила моё разрешение  за время настройки ситемы (неплохое решение сделать уровень чувствительности UAC). Что касается WordPad и  Paint они напоминаю профисиональные редакторы текста и изображений. Windows Solution Center пришедший на смену Security center не надоедает своими вопросами и предупреждениями. Удобное и быстрое подключение к интернету, функция Media Home group всё это упрощает работу в сети. Проводник наконец то стал многоинформационым (некий человек 2-умя статьями ниже возмущался тем что папки расположены по умолчанию в виде списка) именно в виде списка файлы и папки предоставляют пользователю всю информацию о содержимом (не могу не отметить хорошую работу с тегами). Поиск – может гордо нести своё название потому что теперь он стал настоящим поиском, а не многочасовой рутиной просматривания файлов вручную. Стабильность – её я пока не у одной ОС не видел , она стойко выносит все эксперементы с драйверами и пока даже не было не одного синего экрана или потери данных (надеюсь не будет!). Ну и наконец скорость  – в действительности эта Windows 7 быстрая в отличии от её старшей сестры Vista. Однако стоит отметить и мелкие шероховатости и недоделки в интерфейсе и кое-где ещё которые (надеюсь!) будут исправлены, однако в целом эта ОС в действительности создана на качество и совесть и достойна Вашего внимания.

  2. user_17 says:

    Абсолютно согласен с вами, Greg001! Тестовая сборка Windows 7 ver. 6801 – действительно шедевр, образец инженерной мысли, блистание алмазных граней отточенного технического совершенства. Она – логическое продолжение своей старшей сестры – WINDOWS VISTA!

    Но вы совершенно забыли упомянуть про новейший Windows-firewall, оснащённый уникальными функциями, это идеальное средство для защиты от хакерских атак и утечек информации.

    Так же, вы ничего не сказали про самый безопасный и надёжный браузер IE8 beta, который, к сожалению и, по всей видимости, до сих пор не оснащён профессиональной проверкой правописания.

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

  3. volk1234 says:

    скачал WindowsSearch-KB940157-XP-x86-enu.exe

    установил. Ос Windows XP SP2. Компьютер:

    AMD 4400 x2Ram 2048MB…

    Включил папки для индексации.

    Ищу некий документ. Нашло несколько документов

    по моему слов(причем не все названия содержат это слово), mht-файл(сохранненый в Opera из русского блога М.Руссиновича) WindowsSearch открыл в виде крякозябр, несмотря на то что в IE и Opera открывается нормально. Кодировки менял. непомогает.

    Второй документ кыся.txt размером 1.3 мб. После открытия его в виде крякозябр и щелчку по открытому тексту – зависает или перезагружается

    Explorer.exe !!!

  4. volk1234 says:

    установка на виртуальной машине(XP) показала:

    кодировка отображается правильно, desctop serch

    виснет на файле кыся.тхт закрытие приводит к перезагрузке explorer.

    Дальнейшие попытки посмотреть что делает процесс с помощью ProcMon привели к синему экрану: код ошибки 0x000000050 второй и четвертый параметр с нулями.

    После перезагрузки компьютера  WindowsSearch

    намертво отказалась загружатся, служба тоже.

    Код ошибки службы(специфический): -2147221164

    Переустановил WindowsSearch всеравно виснет на этом файле.

  5. volk1234 says:

    к чему это я написал, возможно ваш WS 4.0 плохо работает с отображением текстовых файлов большого размера?

Comments are closed.

Skip to main content