Кто не спрятался, я не виноват
АрхивПожалуй, скучно будет в очередной раз мусолить тот факт, что нынешние жесткие диски позволяют хранить море информации и что многие пользователи судорожно забивают их скачанными из Сети фильмами и музыкой, дабы мозг проще воспринимал необъятные просторы секторной степи.
Пожалуй, скучно будет в очередной раз мусолить тот факт, что нынешние жесткие диски позволяют хранить море информации и что многие пользователи судорожно забивают их скачанными из Сети фильмами и музыкой, дабы мозг проще воспринимал необъятные просторы секторной степи. Вот только в отношении поиска по этим самым файлам давным-давно ничего не менялось…
Полнотекстовый поиск среди документов по всему сетевому каталогу компании, где я работаю, занимает столько времени, что можно успеть переделать кучу дел и сходить пообедать. Так что эту процедуру приходится заранее планировать и порой оставлять на ночь. Знакомая ситуация?
А поиск бывает нужен не только по файлам, но и по адресной книге, по почте, по истории IM-клиента вроде Psi или Mirabilis ICQ. Попробуйте-ка одной командой найти все разговоры с тем или иным человеком за некоторый период на некоторую тему, если разговоры эти велись как по почте, так и через IM, — а заодно все файлы, имеющие отношение к теме разговора.
Да и доступ к файлу из приложения зачастую осложняется тем, что любая иерархическая файловая система предполагает либо сложную систему структурированных каталогов, либо несколько каталогов с файлопомойками на сотни и тысячи документов. Ситуация, когда файл может находиться в одном из десятка каталогов, к которым он теоретически имеет отношение, тоже наверняка многим знакома.
Разработки, упрощающие жизнь при таком поиске, существуют довольно давно. Во всяком случае, пользователи OS/2 и BeOS любят припомнить эти «фишки» своих любимиц. Только где сейчас эти операционные системы? Некоторое время назад гиганты мирового софтостроения обнаружили, что рынок поисковых умных механизмов по локальным файловым, локальным сетевым ресурсам и PIM-ресурсам практически не освоен. И вот что у нас есть на данный момент:
Кроме того, в корпоративной нише своей особой жизнью уже пару лет живут дорогие решения на основе EMC Centera и Avamar Axion. Однако эти продукты изначально спроектированы для работы с неизменяемыми данными, которые однажды и навсегда оседают в системе хранения и потом разве что дублируются в резервный центр хранения.
Упомянутые разработки по назначению и функциональности приравнивать друг к другу ни в коем случае нельзя. Однако все они в конечном счете предназначены для ускорения поиска информации. Обычно связка выглядит следующим образом: индексировщик проходит по файловой системе и создает базу данных документов, к которой затем обращаются при помощи отдельного поисковика или из самих приложений. Как только создается новый файл или изменяется существующий, индексировщик получает от ядра операционной системы команду добавить файл в индекс или обновить определенную часть существующего индекса.
Давайте взглянем на эти продукты поближе.
Системы индексации данных
Индексировщики данных играют ту же роль, что и поисковые системы в Интернете: они ходят по известным им ресурсам и создают базу данных (что где лежит), к которой пользователи затем обращаются с запросами. Индексировщик обязан не только понимать как можно больше разных типов файлов, но и работать как можно незаметнее, не отъедая много системных ресурсов и не оставляя дыр в безопасности системы. Сама идея индексации данных локальной файловой системы далеко не нова, но особого внимания никто ей раньше не уделял, иначе мы бы уже жили в более совершенном мире.
Medusa
www.members.cox.net/sinzui/medusa
Этот индексировщик (рис. 1) был создан несколько лет назад программистами из Eazel, писавшими универсальный файловый и интернет-браузер Nautilus на движке Gecko и рассчитывавшими зарабатывать на дополнительных информационных сервисах к нему. Выделенные на разработку Nau деньги программисты благополучно проели, после чего фирма схлопнулась, оставив после себя изрядное количество кода и интерфейсных наработок под свободной лицензией.
В коде Medusa в последний момент перед выходом GNOME 1.4 была найдена критическая ошибка, и индексировщик этот в релиз не попал. Впоследствии «Медуза» пережила даже пересмотр архитектуры, но пару лет активной разработки, по сути, не было. Затем Кертис Хови и Сет Никел портировали Medusa под GNOME 2.0, и сейчас Кертис в одиночку взялся доводить программу до ума.
Плюсом Medusa является очень шустрая обработка больших индексов и возможность создания виртуальных каталогов по результатам поиска, а, в некотором смысле, минусом — то, что различение типов файлов напрямую зависит от модуля графической оболочки gnome-vfs, отвечающего за работу с файловой системой.
Будущее Medusa Кертис видит в использовании на корпоративных файловых системах для распределенного индексирования. Поскольку даже два компьютера, индексирующие сетевые диски, создают ощутимый трафик, разнести индексирование по многим машинам — решение вполне разумное. Правда, это потребует изменений в архитектуре приложения.
Beagle
www.gnome.org/projects/beagle
Новый игрок на поисковом поле. В основе Beagle (рис. 2) лежат наработки Apache Jakarta’s Lucene (www.jakarta.apache.org/lucene/docs/index.html). Lucene изначально была ориентирована на хранение индексированных метаданных и быстрый поиск по большому их количеству. Но у нее нет индексировщиков для разных типов файлов — это скорее база данных для результатов индексации. А вот Beagle как раз содержит средства индексации, причем на момент подготовки статьи индексируется немало типов данных: документы Microsoft Word, PowerPoint и Excel, OpenOffice.org Writer, PDF, RTF, различные форматы изображений (JPG, PNG), музыкальные форматы (MP3, Ogg Vorbis, FLAC, MIDI, Musepack, Monkey Audio), файлы с исходным кодом (Java, C, C++, C# и Python), Texinfo и LyX. Более того, индексируется почта в groupware-клиенте Evolution, просмотренные в браузере сайты, содержание блогов, читаемых через RSS-аггрегатор BLAM!, и список предметов, которые можно купить на Amazon.com. У «Гончей» есть и собственный поисковик с графическим интерфейсом — BEST (Bleeding-Edge Search Tool). Главное отличие от «Медузы» в том, что Beagle ориентирован на индексацию скорее байтовых потоков, нежели файлов. Поэтому он может на лету закэшировать страницу, которую вы в тот момент просматриваете в браузере. Эта особенность работы с контекстной информацией, а не просто файлами на диске делает его очень полезным для Dashboard, о котором мы поговорим ниже.
Планы разработки Beagle досконально изложены в блоге разработчиков (www.planetbeagle.org). Программа развивается очень резво, не в последнюю очередь благодаря поддержке компании Novell, кормящей не только программистов, но и нескольких дизайнеров (www.primates.ximian.com/~glesage/wiki/doku.php?id=start), включая Якуба Штайнера (Jakub Steiner), известного популяризатора GIMP, автора серий замечательных пиктограмм и улучшателя практичности графических интерфейсов многих программ для GNOME.
Опасение, правда, вызывает то, что Beagle, как и все новые разработки GNOME и Novell, пишется на Mono (www.go-mono.org) — свободной реализации технологии Microsoft .NET. Более «безопасную» с точки зрения легальности систему поиска по метаданным с предварительным индексированием пишут сейчас и для KDE, но этим летом авторы честно заявили (www.conference2004.kde.org/cfp-devconf/scott.wheeler-search.metadata.interface.elements.php), что раньше чем через полтора года готового продукта ждать не стоит.
Spotlight
www.apple.com/macosx/tiger/spotlight.html
Подробностей о начинке «Прожектора» (рис. 3) известно не так уж много. Если судить по тому, что известно, то Spotlight — достаточно умно спроектированный «слой» метаданных над существующей файловой системой. Изменения файлов фиксируются на уровне ядра, после чего индексировщики быстро проходятся по системе еще раз и обновляют кэш метаданных. Факт весьма интересный: в число разработчиков Spotlight входят бывшие сотрудники BeOS Павел Сайслер (Pavel Cisler) и Доминик Джиампаоло (Dominic Giampaolo). Павел разрабатывал файловый менеджер BeOS — Tracker, а затем и вышеупомянутый Nautilus. Доминик тоже трудился в Be Inс., но занимался разработкой файловой системы, для которой в BeOS был очень умный индексировщик данных со схожим принципом действия. Впрочем, в случае со Spotlight речь идет не только об умном индексировщике, умеющем работать с файловой системой, календарем-планировщиком и почтовыми клиентами, но и об удобном пользовательском интерфейсе, возможности измерения релевантности результатов поиска запросу и многом другом. Больше того, язык запросов до известной степени приближен к естественному; правда, сколько поддерживается языков, пока неизвестно.
Google Desktop Search
Эта разработка, словно вражеская субмарина-невидимка, всплыла перед носом всего IT-мира. Земля давно полнилась слухами о том, что Google собирается в том или ином виде перебраться на локальные файловые системы. И вот неожиданно выходит бета-версия поисковика для локальных данных, работающего прямо из браузера.
Установившись, Google Desktop индексирует все доступные пользователю файлы в форматах MS Office, простые текстовые документы, историю сообщений в AOL Instant Messenger и почту Outlook. Затем индексация проводится по мере изменения данных на доступных пользователю локальных и LAN-ресурсах. Поисковая система интегрируется в браузер (IE или любой другой, основанный на Gecko) и при вызове из области уведомления открывает новое окно или вкладку дефолтного браузера (у меня это Firefox) со стандартной гугловой формой поиска, но добавленным разделом Desktop. Личные впечатления после двух недель использования программы таковы: если хватит терпения пережить неприлично долгую первоначальную индексацию данных, последующая работа вряд ли вас сильно разочарует. (Подробнее о GDS см. в статье Владимира Гуриева «Четыре Геркулеса», «КТ» #565. — Прим. ред.)
Системы хранения документов
GNOME Storage
В основе GNOME Storage (рис. 4) лежит технология D-BUS (www.freedesktop.org/Software/dbus), позволяющая различным приложениям обмениваться информацией. Storage состоит из нескольких компонентов.
Собственно хранилище данных содержит сервис D-BUS, через который получает объекты (документы) и их атрибуты, соотносит их друг с другом и позволяет инициировать поиск. Хранилище использует PostgreSQL для хранения структурированных данных и проведения поиска. Поскольку доступ к данным производится напрямую, а не через «буфер», изменения постоянно передаются по шине, поэтому разные пользователи могут работать над одним и тем же документом и сразу видеть все вносимые в него изменения. Если такой пользователь находится в контактном листе IM другого пользователя, то второй будет видеть в приложении пиктограмму со статусом первого и сможет быстро выйти с ним на связь.
Еще один компонент, libstorage-translators, обеспечивает инфраструктуру для преобразования структурированного объекта в поток байтов и наоборот. Например, если кто-то прислал вам почтой PDF-документ, вы просто перетаскиваете его мышкой на жесткий диск, а трансляторы автоматически «разбирают» его на части, извлекая для помещения в хранилище различные метаданные, такие как название альбома, EXIF-данные фотоснимка и т. п.
GNOME Storage понимает множество форматов: DocBook/XML, HTML, все форматы, поддерживающиеся библиотекой gdk-pixbuf (JPEG, PNG, BMP, GIF и др.), PDF, простой текст и все форматы, поддерживаемые Gstreamer [Платформа, позволяющая быстро создавать новые приложения для работы с мультимедийными данными при помощи «кирпичиков-модулей», тесно интегрирована с GNOME (www.gstreamer.net)] (MP3, OGG, AVI, MPEG2 и т. д.). В настоящее время реализован только разбор поступающих файлов и добавление их метаданных в хранилище.
Но это не самое интересное. Как вам понравится возможность поиска на языке запросов, близком к естественному? А ведь это уже реализованная и работающая функция. Притом реализация — хвала и честь разработчикам — модульная. Таким образом, вы можете очень просто добавить поддержку запросов на том или ином языке. Условие одно: для этого языка должна существовать грамматическая база данных HPSG (русской базы, увы, пока нет). У движка поиска есть ограничения по гибкости, но фразу вида «Найди все песни Стинга, которые я слушал в прошлую пятницу вечером» он поймет без проблем и выдаст список файлов, которые тут же можно будет прослушать.
Любопытный момент: основной разработчик GNOME Storage Сет Никел работает в RedHat, то есть в компании, конкурирующей с Novell.
DBFS
Пожалуй, самая молодая из рассматриваемых утилит. DBFS является надстройкой над обычной иерархической файловой системой, поэтому в ней хранятся не файлы, а своего рода ссылки на них. Реализация графической части DBFS потребовала внести ряд изменений в код KDE: по сути, изменен весь код, отвечающий за доступ к файлам. Например, вместо привычного диалога сохранения файлов в тот или иной каталог предлагается выбрать тип данных (изображение, музыка, видео и т. д.) и назначить файлу существующее или новое ключевое слово. Из ключевых слов можно создавать деревья.
У этой интересной идеи есть недостаток, который сразу бросается в глаза: в конечном счете мы все равно получаем сложную иерархическую систему, где ключевые слова заменяют названия каталогов. Другое дело, что ключевых слов можно задать несколько, а это позволяет увидеть один файл в нескольких местах в зависимости от того, по какому критерию вы его ищете. Например, фотография Эйфелевой башни может оказаться одновременно в «башнях» и «Париже», физически находясь в единственном экземпляре — что, согласитесь, удобно.
Недавно основной разработчик сменил приоритеты в пользу GNOME и теперь планирует вносить изменения не только в GNOME, но и в библиотеку Gtk+. На будущее запланирован и поисковик документов по их метаданным, а также автоматическое заполнение тегов метаданных.
DBFS (рис. 5) частично написана на Ocaml и в качестве БД использует упрощенную реализацию SQL под названием SQLite.
WinFS
www.msdn.microsoft.com/data/WinFS/default.aspx
Обещанная ранее как одна из главных инноваций Longhorn, WinFS (рис. 6) теперь уже точно не попадет туда и войдет, видимо, только в первый SP.
Самый распространенный слух про WinFS — что это принципиально новая файловая система — не соответствует действительности. WinFS — лишь надстройка над NTFS, реализованная при помощи Microsoft SQL Server с кодовым именем Yukon. Принцип работы всё тот же: доступ к данным производится при помощи запроса к БД по известным метаданным документов, хранящихся в иерархической файловой системе. Документы разных типов называются в терминологии MS объектами, и их количество пока ограничено, но впоследствии сможет быть расширено сторонними разработчиками.
Пока неясно, насколько обещанный офлайновый поисковик MSN коррелирует с планами на WinFS. Однако известно, что в июле этого года Microsoft для своего подразделения MSN купила компанию Lookout, разрабатывавшую одноименный поисковик, тоже использующий технологию предварительной индексации и работающий прямо из Outlook. Причем код Lookout основан на… все той же Lucene.
Контекстная сводка
Контекстная сводка — термин, как мне кажется, наиболее точно передающий суть технологии, которая в той или иной степени реализована в Windows/Mac OS X и десктопной оболочке GNOME. Во всяком случае, более адекватного описания на русском языке мне не попадалось. Так называемая Dashboard — это плавающая панель, «магнитящаяся» к краям экрана, при помощи которой можно быстро получить ту или иную информацию.
Dashboard в GNOME
www.nat.org/dashboard
Вот простой пример использования контекстной сводки при помощи Dashboard (рис. 7, 8) . В ходе обсуждения по ICQ/Jabber всплыло название некой программы, впечатлениями об использовании которой с вами неделю назад делился собеседник, чье имя вы не помните. Тогда вы выделяете название программы и нажимаете поиск в Dashboard. Затем в окне панели отображается список всех сообщений, где упоминалась программа, а также контактная информация всех людей, с которыми вы ее обсуждали. Если программа упоминалась в переписке по почте — то и заголовки этих писем. При желании — даже подборка первого десятка ссылок поиска по Интернету или ссылка на сайт этой программы, найденный через «I’m feeling lucky» Google.
В той же панели может висеть список текущих закачек, запланированных мероприятий, «тудусы» на сегодняшний день и т. д. И все это по желанию синхронизируется с той или иной задачей.
Как уже упоминалось, Dashboard для доступа к такого рода информации использует индекс, создаваемый Beagle. Занятно, что концепция Dashboard была вывешена основателем проекта Нэтом Фридманом еще пару лет назад, то есть до появления Sidebar.
В некотором роде конкурентом Dashboard является Slicker — новая альтернативная версия панели KDE.
«Sidebar» в Windows
Название разработки не зря поставлено в кавычки. Раскопать хотя бы кодовое название этой программы, основанной на технологиях Aero и Indigo, равно как и ее толковое описание, мне так и не удалось. С этой разработкой вышло смешно: сам продукт еще не выпущен, но уже есть программа от стороннего разработчика, которая с той или иной степенью успешности копирует идею.
Идея же полностью аналогична гномовскому Dashboard. Вообще говоря, если отследить хронологию появления реализаций концепции контекстной сводки, станет ясно, что Microsoft попросту скопипастила гномовский Dashboard.
Перспективы
Сообщение о выходе DBFS спровоцировало бурную дискуссию на одном российском форуме. Несмотря на изрядную долю, скажем так, неконструктива и обмен колкостями, она помогла мне посмотреть на поисковые системы ближайшего будущего под другим углом зрения. Перечислю основные недостатки, на возможное появление которых указывали участники форума:
Претензия №1 была быстро снята одним из участников обсуждения. Он установил предварительную версию DBFS и поделился впечатлениями, судя по которым беспокоиться особенно не о чем.
С претензией №2 нам еще предстоит разобраться на собственной шкуре, хотя опыт использования Google Desktop более чем ободряет. А вот справедливость претензии №3 в отношении многих, если не большинства пользователей у меня особых сомнений не вызывает. Скажем прямо: далеко не все заботятся о том, чтобы прописать теги очередному гигабайту музыки, залитому из eDonkey, если за них об этом уже не подумал выложивший файл человек. Многих устраивает, что название песни прописано в имени файла, а название альбома и имя исполнителя — в именах соответствующих каталогов.
То же самое касается и фотографий. Последнее, что вы захотите делать, вернувшись из отпуска с забитой под завязку 512-мегабайтовой флэшкой, — это ручками прописывать, какая фотография к чему относится. Разумеется, никто не отменяет базовых возможностей того же Nautilus по визуальной классификации путем добавления тех или иных значков-эмблем на пиктограмму файла. Но будет ли этого достаточно — неизвестно.
В принципе никто не мешает создать программу для массового редактирования метаданных тех же фотографий подобно уже существующим редакторам тегов MP3 и Ogg Vorbis. Другой вариант — указывать базовые метаданные (помимо существующих EXIF-данных) при автоматическом сбрасывании фотографий с флэшки на жесткий диск и параллельном выкладывании их на веб-сайт в виде новой галереи. Примерно так и будет работать другая интересная разработка на Mono — F-Spot (www.gnome.org/projects/f-spot).
Полноценного естественноязыкового поиска, боюсь, ждать еще долго. Вспомните: даже автоматические переводчики с одного языка на другой нам обещают уже лет сорок. А ведь корректный синтаксический разбор предложения — больная мозоль всех проектов, так или иначе связанных с искусственным интеллектом и прикладной лингвистикой. Причем вылечить эту мозоль пока никому толком не удалось.
Зато быстрый поиск по метаданным есть уже сейчас. Больше того, и по технологии, и по реализации продукты Novell и Apple практически равноценны. Разница лишь в открытости исходного кода. Зато Microsoft оказывается в догоняющих. Впрочем, кого, кроме самой Microsoft, в две тысячи надцатом году взволнует, что к выходу WinFS рынок вокруг офлайновых поисковых сервисов будет давно переделен?
