Первый в мире поисковый движок: Исторический экскурс. Как рождался новый метод. Системы поиска бесплатных изображений

Иван Максимов

Возможности поискового движка DataparkSearch

Как организовать поиск информации на файловом сервере не только по названию и типу документа, но и по его контенту? Возможно ли создать подходящий инструмент, доступный и прозрачный для пользователей?

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

Локальные поисковые машины в большинстве своем распространяются бесплатно, тогда как корпоративные версии, позволяющие пользователям производить поиск информации на сервере, стоят достаточно дорого. Несомненно, покупая коммерческий продукт, мы получаем грамотную техническую поддержку и другие преимущества, но небольшие организации или владельцы частных сетей не всегда в состоянии заплатить тысячи долларов за подобные продукты. К счастью, в мире Open Source существуют свободные проекты, не уступающие по функциональности своим коммерческим конкурентам, с качественной поддержкой и обновлениями.

Сейчас мы рассмотрим один из вариантов по организации поиска документов на файловом сервере, который был реализован на конкретной задаче.

Начальные условия

Имеется файловый сервер под управлением ОС Linux. Для совместного использования файлов установлены популярные пакеты samba и pro-ftp. На диске используется файловая система reiserfs, как наиболее производительная для работы с большим количеством маленьких файлов (документы, около 3 тысяч, различных форматов: txt, html, doc, xls, rtf). Данные отсортированы, но их объем растет с каждым днем, удаление устаревшей информации не решает проблему. Как организовать поиск по именам и типам документов, а также по контенту? Как сделать его доступным для пользователей в локальной сети?

Для решения этих вопросов нам понадобится поисковый движок, сервер баз данных (MySQL, firebirg, ...), веб-сервер Apache и около гигабайта дискового пространства для работы комплекса.

Какой из поисковых движков выбрать?

Существуют локальные поисковые машины, такие как Google Desktop Search или Ask Jeeves Desktop Search . Возможно, для организации поиска в маленькой компании или на рабочей станции пользователя, под управлением ОС Windows, эти движки могут быть полезны, но не в данном случае. Поисковые «монстры» вроде Яндекса очень дороги, но если требуется качественная помощь разработчиков, то крупным компаниям, возможно, следует подумать об его аренде. Для *nix-семейства существует несколько проектов. Это движки:

• DataparkSearch
• Wordindex
• ASPseek
• Beagle
• MnogoSearch

Перечисленные движки позиционируются как свободно распространяемые поисковые машины для работы в локальной и/или глобальной сетях. Хочу заметить, что многие проекты не мультиплатформенные и не работают под операционными системами компании Microsoft. Для Windows-систем существуют серверные решения, такие как: MnogoSearch и «Ищейка» .

Итак, коротко рассмотрим поисковые машины под *nix-платформу:

Beagle – преемник в SUSE Linux движка Htdig . Последний дистрибутив SUSE, в который вошел движок Htdig, был за номером 9, в последующих версиях компания Novell заменила его на beagle. Htdig закончил свое развитие в 2004 году, последняя доступная версия – 3.2.0b6 от 31 мая 2004 года. Новый движок в SUSE позиционируется как локальный поисковик, но возможно использовать его и в корпоративной среде.

MnogoSearch (бывший UdmSearch) – известный многим и достаточно распространенный движок. Существуют версии как под Windows (30-дневная бесплатна версия), так и под *nix-платформы (лицензия GNU). Возможна работа практически со всеми распространенными версиями СУБД SQL под обе платформы. К сожалению, на данный движок достаточно много нареканий, поэтому я не остановил свой выбор на нём.

Wordindex – движок, находящийся в стадии разработки (на момент написания статьи последняя доступная версия 0.5 от 31 августа 2000 года). Работает в связке СУБД MySQL и веб-сервера Apache. Работоспособный проект представлен только на сайте разработчиков.

ASPseek – поисковая машина, получившая в прошлом достаточно большое распространение, но в 2002 году этот движок прекратил свое развитие (последняя доступная версия данной поисковой системы 1.2.10 от 22 июля 2002 года).

DataparkSearch – клон поискового движка MnogoSearch. Позволяет производить поиск как по именам файлов, так и по их контенту. Обработка txt-файлов, HTML-документов и тэгов mp3 встроена, для обработки содержимого документов иного типа необходимы дополнительные модули. Возможен поиск информации, как на локальном жестком диске, так и в локальной/глобальной сети (http, https, ftp, nntp и news).

Поисковая машина функционирует с самыми распространенными СУБД SQL, такими как MySQL , firebird , PostgreSQL и другими. По заявлению разработчиков, DataparkSearch стабильно работает на различных *nix-операционных системах: FreeBSD, Solaris, Red Hat, SUSE Linux и других. По сравнению с MnogoSearch в движке были исправлены некоторые ошибки, изменены в лучшую сторону некоторые функции. На сайте разработчиков приведены ссылки на рабочие версии движка в сети Интернет. Большой плюс – качественная документация на русском языке.

Итак, сравнив все «за» и «против», для реализации поиска на файловом сервере был выбран движок поисковой машины DataparkSearch.

Установка

Для работы нам понадобятся: веб-сервер Apache, сервер базы данных MySQL и исходные коды DataparkSearch. Устанавливаем сервер Apache и БД MySQL (со всеми необходимыми библиотеками). Если на вашем сервере установлена иная СУБД, то можно использовать и ее (см. документацию по движку). Далее распакуем архивы DataparkSearch и приступим к сборке нашего комплекса.

Запустим скрипт install.pl и ответим на необходимые вопросы: выбор папки установки движка, базы данных и другие относящиеся к параметрам работы движка. Рекомендуется оставит настройки по умолчанию. Опытные пользователи, прочитав документацию, расположенную в папке doc, могут вручную сконфигурировать движок (команда configure). Если при инсталляции скрипт не может найти mysql, возможно не установлены библиотеки для разработчиков (libmysql14 devil). Теперь скомпилируем и установим DataparkSearch командами make и make install.

Минимальное конфигурирование

Создадим базу данных:

sh$ mysqladmin create search

Командой mysqlshow просмотрим все таблицы в БД. Сразу хочу отметить, что удобнее работать с MySQL с помощью веб-консоли phpmyadmin, но можно обойтись и стандартным набором утилит. Необходимо создать нового пользователя в MySQL:

sh#mysql --user=root mysql

mysql> GRANT ALL PRIVILEGES ON *.* TO пользователь@localhost

IDENTIFIED BY "пароль" WITH GRANT OPTION;

exit

Перезагрузим MySQL.

Допустим, имя пользователя – searcher, пароль – qwerty.

Теперь создаём файл indexer.conf в папке /etc/ движка, примеры данного файла (для некоторых задач) можно найти в папке /doc/samples исходников DataparkSearch. Пример с минимальными настройками приведен на рис. 1.

Рассмотрим файл подробнее. Как упомянуто в комментарии, команда DBAddr указывает путь к SQL-серверу (в нашем случае это MySQL), способ хранения данных и другие параметры (если необходимо). Существуют несколько режимов хранения: если не указывать dpmode, то по умолчанию будет значение single – самый медленный. Рекомендуется использовать режим cache, но если с ним возникли проблемы, можно использовать менее эффективный, но более простой в конфигурировании режим multi. Подробное описание всех параметров dbmode находится в документации.

DoStore хранит сжатые копии проиндексированных документов. Sections – модуль, предоставляющий гибкие возможности индексирования. Допустим, можно создать ограничение по тэгу или настроить индексацию не только содержимого файлов, но и URL (хост, путь, имя). Langmap – специальные языковые карты для распознавания кодировок и языков, эффективны, если документы размером более 500 байт.

Второй необходимый конфигурационный файл – файл результатов поиска search.conf. Рекомендуется взять готовый шаблон (файл /etc/search.htm-dist) и отредактировать его под свои запросы. Нужно заметить, что основные параметры, указанные в файле indexer.conf, должны совпадать с параметрами в search.htm, иначе будут ошибки при работе движка. Search.htm состоит из нескольких блоков: первый – variables – содержит данные для работы движка (скрипт search.cgi), а все остальные блоки необходимы для формирования html-страницы результатов поиска. Пример блока variables в search.conf приведен на рис. 2.

Рассмотрим search.htm подробнее. Как видно, параметры DBAddr и LocalCharset совпадают с идентичными параметрами в indexer.conf. Если ваш веб-клиент поддерживает формат xml, то можно установить параметр ResultContentType text/xml. Ниже идут HTML-блоки, необходимые для дизайна страницы результатов, они здесь не представлены из-за большого объема. Рекомендуется пользоваться готовым шаблоном, расположенным в файле /etc/search.htm-dist. В сопроводительной документации полностью описан формат HTML-блоков (дизайна), желающие могут настроить его по своему вкусу.

Теперь можно запускать файл indexer из папки sbin движка DataparkSearch с параметром -Ecreate. Если все было сделано правильно, то будут созданы необходимы sql-таблицы в БД. Если появились ошибки, следует проверить имя пользователя mysql и пароль в файле indexer.conf, это наиболее распространенная ошибка.

Для тестирования рекомендуется проиндексировать небольшой участок ресурса, чтобы если возникнут ошибки, новая переиндексация не заняла много времени. Индексирование выполняется командой indexer без параметров, в итоге нам выведут результаты: затраченное время, количество документов и скорость работы.

Скопируем файл bin/search.cgi из директории DataparkSearch в папку cgi-bin нашего веб-сервера и отредактируем файл index.shtml нашего веб-сервера Apache (расположенный в папке html), добавив в него код формы поиска:

Теперь можно зайти на ресурс localhost, используя любой доступный браузер. В появившейся форме ввести искомое слово, допустим «процессор» (см. рис. 3). В итоге мы должны получить страницу с результатами поиска, если, конечно, такие документы существуют (см. рис. 4). Если вместо страницы с результатами поиска появится документ с ошибками, то следует проверить работу скрипта. Зайдя в директорию cgi-bin веб-сервера, выполним скрипт «seach.cgi test >> test.htm». Если страница результатов сформирована правильно, следует проверить конфигурацию сервера Apache: правильно ли указан путь до cgi-скрипта, выполняется ли тестовый скрипт test.cgi в директории веб-сервера.

Если test.htm пуст или также содержит ошибки, рекомендуется проверить, существуют ли данные в базе, делается это командой «indexer -S». Возможно, следует переиндексировать сервер командой «indexer – v 5» – максимальный уровень выдачи отладочной информации. Выставив в файле search.htm команду LogLevel 5 и внимательно просмотрев логи веб-сервера, можно выяснить, как выполняется обработка данных в SQL-сервере.

Добавление дополнительных модулей (парсетов)

По умолчанию движок работает только с файлами html и txt, но возможно установить дополнительные модули (парсеты), которые преобразуют иные типы документов в html или txt (plain text). Возможна работа с xls (Excel), doc (Word), rtf (Word), ppt (Power Point), pdf (Acrobat Reader) и даже rpm (RedHar Package Manager)-файлами, в последнем будут отображаться только метаданные. В нашем случае понадобится обработка офисных форматов. Для xls и doc существует несколько парсетов: catdoc преобразует документы в txt-формат, XLHTML и vwHtml конвертируют файлы в HTML-формат.

Я рекомендую использовать пакет catdoc, так как скорость преобразования в txt-формат намного выше преобразования в HTML-формат, к тому же программа XLHTML иногда «подвисала» при конвертировании документов. Хотя разработчики предвидели данную проблему и рекомендуют во избежание «зависания» парсета установить в indexer.conf параметр ParserTimeOut 300 (число указывается в секундах), но время индексирования тогда еще более возрастет.

Также нам понадобится еще один парсет – unrtf – для работы с rtf-файлами, он конвертирует документы в html-код или text/plain-формат на выбор пользователя.

Скачаем и установим нужные пакеты, для подключения парсета нужно добавить строки в indexer.conf:

Для формата xls (программа xls2csv входит в пакет catdoc):

Mime application/vnd.ms-excel text/plain "xls2csv $1"

AddType application/vnd.ms-excel *.xls *.XLS

для документов doc параметры выглядят так:

Mime application/msword text/plain "catdoc $1"

AddType application/vnd.ms-excel *.doc *.DOC

обработка RTF-документов:

AddType text/rtf* *.rtf *.RTF

AddType application/rtf *.rtf *.RTF

Mime text/rtf* text/html "/usr/local/bin/unrtf --text $1"

Mime application/rtf text/html "/usr/local/bin/unrtf --text $1"

Cтоит напомнить, что некоторые Windows-приложения иногда создают файлы с тем же расширением в верхнем регистре, поэтому добавим в список AddType те же расширения, но с иными названиями.

Для индексации можно добавлять любые типы документов, но движок будет показывать только ссылки на имена файлов.

Допустим, если необходимо проиндексировать rpm или iso-файлы и получить из них метаданные, вам понадобится сначала найти соответствующую программу (парсет) и добавить нужные параметры в index.conf. Список поддерживаемых типов документов можно посмотреть, например, в файле mime.types сервера Apache. Готовые решения для конвертации файлов или получения из них метаданных можно найти среди настроек пакета Midnight Commander, в файле mc.ext.

Режим хранения cache

Существует несколько способов ускорить работу движка, один из них – использовать метод хранения данных cache. Для работы в этом режиме нам потребуются утилиты cached и run-splitter, находящиеся в директории sbin относительно движка. Если у вас уже создана SQL-база данных в другом режиме (dpmode), не забудьте сначала ее удалить и только потом изменить режим хранения. Очистим базу данных командами: «indexer -С» (очистка SQL-таблиц) и «indexer Edrop» (удаление таблиц). Далее создайте из файла шаблона cached.conf-dist, расположенного в папке etc нашего движка, файл cached.conf. Не забудем изменить в нем параметры доступа к SQL БД:

Теперь можно отредактировать файлы index.conf и search.conf, изменив в них параметры:

indexer.conf

DBAddr mysql://searcher:qwerty@localhost/search/?dbmode=cache&cached=localhost:7000

search.htm

DBAddr mysql://searcher:qwerty/search/?dbmode=cache

Этого изменения в целом достаточно, но если вы желаете достичь еще большей гибкости движка, то рекомендуется ознакомиться с дополнительными параметрами режима cache и внести необходимые изменения в конфигурационные файлы.

cached & 2> cached.out

Демон запустится и будет записывать отладочную информацию в файл cached.out. Порт работы cached по умолчанию – 7000, но если необходимо, его можно изменить (в cached.conf).

Заново создадим SQL-таблицы для нового режима хранения данных командой «indexer -Ecreate» и проиндексируем сервер – indexer. После завершения выполним команду:

run-splitter -k

Должен сказать, что данный метод ускоряет не только скорость поиска по базе, а также скорость индексирования. Теперь можно попробовать произвести поиск по БД, если все было сделано правильно, то мы получим результаты поиска.

Дополнительные функции

В приведенной конфигурации использовались минимальные параметры настройки, с помощью дополнительных можно добиться большей функциональности и гибкости движка, все зависит от поставленных задач. Для повышения скорости работы поиска движка можно использовать модуль mod_dpsearch для сервера Apache. Потребность в данном модуле возникает, если индексируются сотни тысяч документов и необходимо повысить скорость работы движка до максимума. Также в документации можно найти и другие методы ускорения работы движка, например: оптимизация SQL БД или использование виртуальной памяти в качестве кэша.

Достаточно часто возникает необходимость в поиске грамматических форм слов. Допустим, нам нужны все формы слова «процессор» (процессоры, процессоров, ...), для этого можно настроить модули ispell или aspell. Более подробно о них написано в документации.

В DataparkSearch имеется возможность индексировать сегменты сетей, за это отвечает параметр: subnet 192.168.0.0/24 в indexer.conf.

Также возможно запрещать индексировать определенные типы файлов или конкретные папки на серверах: Disallow *.avi или Disallow */cgi-bin/*.

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

Выводы

Поисковый движок DataparkSearch – мощное средство для работы c веб-ресурсами, расположенными как в локальной сети, так и в глобальной. Проект постоянно развивается и дорабатывается, на момент написания статьи последняя стабильная версия движка 4.38 (от 13.03.2006) и снапшота 4.39 (от 19.04.2006). Должен заметить, что обновления последней версии происходят почти через день.

Мы не рассматривали вопрос о создании публичного поискового сервиса в Интернете, если же вам это требуется, ознакомтесь с соответствующей документацией по СУБД, веб-серверу и другим моментам, касающимся защиты информации от несанкционированного доступа.

Приложение

Работа

Сервер был установлен на машине: AMD Athlon 2500 Barton, 512 Мб DDR 3200 (Dual), HDD WD 200 Гб SATA (8 Мб кэш, 7200 оборотов). Конфигурация движка: движок DataparkSearch (v4.38), СУБД MySQL (v4.1.11), веб-сервер Apache (v1.3.33), производится индексация doc, xls, rtf (конвертация в text/plain), html, txt-файлов. Используется режим хранения данных multi. Обработка примерно 2 тыс. файлов, расположенных на данной машине (размер на диске ~1 Гб), и индексация их контента требует 40 мин, размер БД после работы примерно равен 1 Гб. Должен заметить, что скорость работы движка с нелокальными ресурсами будет зависеть от скорости канала. Также скорость индексирования зависит от используемых парсетов. Использование режима хранения cache улучшает скорость работы примерно на 15-20%. В качестве клиентского ПО используются веб-браузеры, проверялась работа на: Firefox, Opera, Konqueror, Microsoft Internet Explorer и даже Lynx – проблем не возникло. Всю работу серверной части движка можно автоматизировать с помощью всем известного демона cron, поместив в него нужные параметры для индексации данных.

С самого появления цифровых фотоаппаратов у нас, конечно, нет недостатка в фотографиях. На самом деле, Yahoo ! оценивает, что в 2014 году мы получим 880 миллионов цифровых фотографий.

У нас никогда не было недостатка в фотографиях — наоборот, намного сложнее найти именно то изображение, что нам нужно, в этом безбрежном океане.

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

В то же время, попробуйте задать на поиск какой-то менее распространенный объект или, например, абстрактное понятие — возможно, солнечный день или конкретный тип цветка. Это может оказаться гораздо сложнее. Часть трудностей связана с тем, что даже если существует идеальное изображение, оно не может быть помечено таким образом, чтобы его можно было найти.

В этих случаях вы можете потратить много времени на поиски на различных сайтах с бесплатными изображениями и все равно остаться ни с чем. Ох. Это объясняет, почему так много коммерческих хранилищ рекламируются на бесплатных сайтах изображений — их поисковые средства часто стоят того, чтобы заплатить за рекламу.

Итак, для того, чтобы избежать этого, вы можете попробовать сервис поиска бесплатных изображений.

Системы поиска бесплатных изображений

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

Довольно трудно сравнивать качество 7 поисковых систем, о которых я расскажу в этой статье. Сначала я хотела запустить на поиск те же самые запросы в каждой из них и сравнить результаты.

Тем не менее, после того как я попробовала некоторые очень популярные термины (в частности, «компьютеры» ) и получила тысячи результатов в некоторых системах, а по другим, менее популярным, я в то же время не получила ничего (возможно, потому что я просто использовала неправильные ключевые слова ), я решила, что такой тест может дать ошибочные результаты.

Более того, эти поисковые системы индексируют новые изображения ежедневно, так что даже если сегодня в какой-то системе нет ни единого изображения для запроса «солнечный день «, то завтра может случиться, что система добавит десятки таких изображений.

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

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

Вполне возможно, что изображения, которые когда-то были лицензированы как свободные, позже изменили лицензию, так как их автор передумал. Поэтому всегда проверяйте лицензию, прежде чем использовать изображение.

1. Google Images

Для многих из нас, Google Images является первым (и часто единственным ) выбором для поиска бесплатных изображений, которые также разрешены для коммерческого использования. Для поиска бесплатных изображений через Google Images введите ключевые слова в поле поиска и нажмите Enter , затем выберите вкладку Картинки (1):

Google Images

Затем нажмите на кнопку «Инструменты поиска » (2), чтобы открыть список параметров поиска и выберите пункт «Права использования » (3). Из выпадающего меню выберите лицензию, которая подходит именно Вам.

Выбор Google для поиска, как правило, хорош. Для действительно популярных терминов вы найдете огромное количество изображений. К счастью, они часто предлагают суб-результаты. Например, для компьютеров они предлагают такие категории, как Apple , ноутбуки, картинки, обои, запчасти, PNG и т.д., чтобы конкретизировать поиск.

Для менее популярных терминов и менее ограничительных прав использования, выбор не так широк. Очень часто вы не найдете ничего подходящего, особенно если ищете материал, который является бесплатным для повторного использования с возможностью или без возможности вносить изменения. В этом случае вам стоит попробовать другой сервис для поиска изображений, из тех, что я опишу ниже. Это не займет много времени.

2. CC Search

CC Search , (сокращенно от Creative Commons Search ), это еще один крупный поисковик изображений, лицензированных в соответствии с лицензиями Creative Commons .

Хотя, как они сами утверждают, технически это не поисковая система, но они явно предлагают результаты поиска по нескольким другим сайтам, таким как Europeans , Flickr , Google Images , Wikimedia Commons , Fotopedia , Open Clipart Gallery , Pixabay :

Проблема состоит в том, что CC Search не ищет по всем этим сайтам сразу. Вместо этого, вы вводите поисковый запрос и выбираете место, где хотите искать. Это не очень удобно, но все же быстрее, чем искать непосредственно на всех этих сайтах.

Кроме изображений CC Search предлагает результаты по музыке, видео и другим медиа.

Вы можете указать, что вы ищете: либо материал, который является бесплатным для коммерческого использования, либо вещи, которые вы можете изменять, адаптировать и использовать, как основу, либо и то, и другое.

Если вам понравился CC Search , и вы планируете использовать его постоянно, они предлагают браузерное дополнение (по крайней мере, для Firefox ), которое помогает ускорить доступ к сайту.

Имейте в виду, что Creative Commons не означает «бесплатно для всех ». Вы должны понимать, что использование данной лицензии подразумевает размещение всех ссылок, аккредитацию и другие условия.

3. Photo Pin

Flickr — это, пожалуй, крупнейшее хранилище бесплатных картинок в Интернете, поэтому не удивительно, что несколько сервисов поиска изображений концентрируются исключительно на нем. Photo Pin — один из них. Когда вы открываете сайт и вводите запрос, вы видите что-то вроде этого:

На левой стороне вы можете выбрать тип нужной вам лицензии (например, коммерческая или некоммерческая ), а также каким образом сортировать результаты (новые сначала, актуальность, интересность ).

Конечно, нет никаких причин, почему бы вам не поискать Creative Commons контент непосредственно на Flickr через расширенный поиск. Однако Photo Pin обеспечивает вам два преимущества.

Во-первых, это проще, если вы акцентируете внимание только на лицензируемом контенте. Во-вторых, Photo Pin обеспечивает простую загрузку в нужном размере, а также предоставляет простую возможность скопировать и вставить лицензионные ссылки.

Действительно удобный сервис.

4. PicFindr

В отличие от многих других сервисов, называющих себя «поисковиками», даже если они ищут только по Flickr , PicFindr более амбициозен. Он производит поиск более чем по десяти сайтам бесплатных изображений в широком диапазоне лицензий (Creative Commons, GNU и другие ).

Список сайтов включает в себя бесплатные подразделы некоторых сайтов изображений, например, DreamsTime , что делает эту поисковую систему особенно полезной. Когда вы вводите поисковый запрос, вы увидите что-то вроде этого:

Кроме того, PicFindr имеет некоторые дополнительные опции поиска, которые делают его еще более полезным:

Некоторые из сайтов, включенных в поиск, не слишком известны, в то же время некоторые из популярных сайтов почему-то отсутствуют, но в целом, это очень хорошая поисковая система.

5. Veezzle

Если вы готовы попробовать еще один поисковик, который ищет как по Flickr , так и по Wikimedia Commons , познакомьтесь с Veezzle . Когда вы заходите на сайт и вводите поисковый запрос, вы можете конкретизировать его, как это показано на следующем скриншоте:

Когда вы нажимаете кнопку «Поиск «, результаты из Flickr и Wikimedia Commons отображаются отдельно. Вы можете выбрать, как вы хотите выводить результаты — по релевантности, по популярности или по дате загрузки.

Несмотря на то, Veezzle является еще одной поисковой системой, работающей с Flickr , не отвергайте этот вариант, прежде чем попробуете в его в действии. Flickr настолько огромен и разнообразен, что различные поисковые системы могут выдавать вам различные результаты. Так что, возможно, с помощью Veezzle вы найдете как раз самые подходящие вам изображения.

6. Every Stock Photo

С возможностью выбирать из почти 23 миллионов бесплатных фотографий Every Stock Photo является действительно прекрасным местом для поиска. Данный сервис производит поиск по нескольким сайтам. В дополнение к Flickr и Wikimedia Commons , которые охвачены в других поисковиках, Every Stock Photo ищет и в других местах: MorgueFile , SXU , НАСА и Photi :

Расширенные опции позволяют оптимизировать поиск. Они позволяют выбрать тип лицензии, источник и что отображать (разрешение, лицензия, источник ). Для меня лично, Every Stock Photo является вторым после Google Images предпочтительным поисковиком изображений. Но, так как вкусы у всех разные, не обязательно, что он подойдет для остальных:

7. Behold

Вполне возможно, что уже приведенных поисковых систем вам окажется более чем достаточно, но вот последний. По сравнению с некоторыми другими поисковыми системами Behold кажется бедным родственником, так как он выводит результаты только с Flickr . Тем не менее, в отличие от тех же поисковых систем Behold очень, очень быстрый, что является огромным преимуществом.

Привет хабр.
Пару месяцев назад мне поступил заказ на разработку сайта. Сайт представлял собой сборник статей добавляемых пользователем. Одним из пунктов технического задания было создание поиска. Т.к. я большой любитель изобретать велосипеды, было решено не использовать поиск от Яндекса или гугла.

Обычный поиск

Самым тривиальным решением было разбивать статьи на слова, разбивать запрос на слова и искать совпадения.
Плюсы:

• Высокая скорость. Можно было для этого использовать сразу mysql таблицу со словами
• Простота. Скрипт для такого алгоритма занимал бы всего несколько десятков строк.

• низкая точность, отсутствие возможности исправления ошибок

Нечёткий поиск

Итак, было решено сделать все как у «взрослых». Т.е. авто исправление ошибок и поиск не только по точному соответствию слов но и по формам слова. Т.к. хотелось большей производительности, поиск писался не на php, а на Яве постоянно висящей в памяти и хранящей индекс статей.

Стеммер

Для начала надо было определиться, как обобщать разные формы одного слова. Будем считать, что одинаковые слова это слова с одинаковым корнем. Но вот извлечение корня это не лёгкая задача. Решая эту проблему, я быстро нагуглил так называемый «стеммер Поттера» (Сайт автора). Стеммер Поттера выделяет корень слова, который, однако, не всегда совпадает с лексическим. К тому же он написан для разных языков, в том числе и для русского. Однако пример русского написан на пхп и, переписав его один в один на яву, я получил очень слабую производительность. Проблема решилась использованием регулярных выражений. Из-за нелюбви к регулярным выражениям я взял готовый пример www.algorithmist.ru/2010/12/porter-stemmer-russian.html (Спасибо автору).
В результате производительность получилась на уровне 1 млн. слов в секунду.

Исправление опечаток

Часто бывает так, что пользователь ошибается при вводе запроса. Поэтому нам необходим алгоритм определения похожести слов. Для этого существует много методов, но самым быстрым из них является метод 3-грамм. Суть его такова: Разбиваем слово на тройки последовательно идущих букв. Со вторым поступаем аналогично. Пример:
Конституция => КОН ОНС НСТ СТИ ТИТ ИТУ ТУЦ УЦИ ЦИЯ
Консттуция=> КОН ОНС НСТ СТТ ТТУ ТУЦ УЦИ ЦИЯ

Потом сравниваем эти тройки и чем больше одинаковых троек мы получили, тем выше похожесть слов.
Итого у нас совпадает 6 троек из 8 или 75%.
Этот метод хорош, когда в запросе пропущена или добавлена лишняя буква. Но вот когда человек заменяет одну букву на другую, у нас сразу попадает 3 тройки. Однако обычно лишняя или пропущенная буква это опечатка. А вот заменённая - это орфографическая ошибка. Какие же это ошибки:

• Замена а – о и о-а: мАлоко, пАбеда, рОдон
• Е-и, и-е. бИда, пЕрог
• неправильно употребление мягкого и твёрдого знака.

Поэтому приведём все к одному виду:

Private String replace(String word) { word=word.replace("а","о"); word=word.replace("е","и"); word=word.replace("б","п"); word=word.replace("д","т"); word=word.replace("г","к"); word=word.replace("щ","ш"); word=word.replace("ъ","ь"); word=word.replace("ж","ш"); return word; }

Таким образом, нам надо перебрать все имеющиеся слова и найти самое похожее. При 1 млн. слов это около 1 с, что не приемлемо. Оптимизируем. Для начала, положим, что нас интересуют слова, отличающиеся в длине максимум на 2 буквы. Потом заметим, что из трёх букв существует всего 30 000 вариаций.(33*33*33).Поэтому прохешируем ещё на этапе индексации итого алгоритм будет такой:

String gramms=get3gram(word); int i=0; for (String gram:gramms) { if (this.tgram_abc[i]==null) this.tgram_abc[i]=new ArrayList(); this.tgram_abc[i].add(id); i++; }

Далее сделаем аналогичное для слова с «приведёнными» буквами, потом заменим нн на н и добавим в третий массив, и напоследок удалим все мягкие знаки.
Теперь можно искать похожие слова. Разбиваем слова на граммы, находим хеш кажой тройки и получаем списко слов в которых одни есть на похожих позициях.

HashMap GramBalls=new HashMap(); int StartG=(i-2>=0)?i-2:0; int EndG=(i+2); for (int l=len-2;l<=len+2;l++) for (int j=StartG;j<=EndG;j++) if (this.tgram_abc[l][j]!=null) for (int id:this.tgram_abc[l][j]) if (!GramBalls.containsKey(id)) GramBalls.put(id, (1-(double)Math.abs(len-l)/3) /(word.length()-2));

В последней строке выведенная методом «тыка» формула, которая означает, что триграмм в конце будет приносить слову 0.7 очков/кол-во триграмма. А первая будет приносить 1 очко/кол-во грамм.
Дальше аналогично ищем для «приведённого» слова из запроса и для слова с заменёнными нн и мягкими знаками. Правда там вместо 1 будет 0.7 и 0.3 соответственно.
После сортируем слова по очкам и выбираем слово с наибольшим кол-вом очков. Однако если у «чемпиона» меньше 0.1 очка то возвращаем null. Это нужно чтобы не учитывать совсем непохожие слова. Т.к. приведённый выше алгоритм определяет что «космонавт» «астма» имеют похожесть 0.05.

Механизм индексации

У «взрослых» индексацией занимаются специальные программы пауки, которые периодически обходят сайты, индексируют содержимое, ищут ссылки на странице и идут по ним дальше. У нас же все просто. При добавлении страницы php скрипт посылает запрос нашем поисковику индексировать страницу. Далее страница очищается от тегов. После разбивается на слова. После этого определяется язык слова. Мы проходим по слову и для каждой буквы добавляем балл языкам, которые поддерживают это символ. Для русского это а-я и дефис «-».Для английского это a-z, дефис и апостроф(‘). Все символы и цифры вынесены в отдельный «символьный язык».
Для хранения и быстрого поиска у нас существует массив списка слов.

ArrayList WordIndex[язык текста][служебный индекс текста][язык слова]

Этот список хранит позицию слова в статье и id статьи.
Аналогично заводим массив для хранения корней слова.
Далее берем заголовок и индексируем его как ещё один текст.

Механизм поиска и ранжирования

Это самый главный механизм любой поисковой системы. Именно от того насколько правильно он создаёт выдачу зависит мнение пользователей.
Когда пользователь нажимает на кнопку поиск php скрипт пересылает запрос поисковику. Тот его разбивает на слова. Только тут есть одно отличие от индексации. Если при добавленной статьи при встрече незнакомого слова мы добавляем его в список слов, то при встрече в запросе незнакомого слова мы ищем наиболее похожее используя метод 3 грамм.
После разбиения для каждого слова мы получаем список из пар id текста – вхождение слова.
Определим, насколько статья подходит запросу:

1. Посчитаем, сколько всего слов из запросов есть в статье.(a)
2. Посчитаем, сколько всего корней из запросов есть в статье.(b)
3. Посчитаем сколько существует словосочетаний слов аналогичных словосочетаниям в запросе(c)
4. Посчитаем, сколько существует словосочетаний корней аналогичных словосочетаниям в запросе(d)
5. Определим сколько слов из запроса встречаются в статье(e)
6. Определим сколько корней из запроса(f)

После чего каждой статье добавим баллы по след формуле:

Math.log(2*a+1)+ Math.log(2+1)+2+Math.log(c*5+1))+ Math.log(d*3+1)))*(f+2*e));

Формула создана по след принципам:

1. Слова приоритетнее корней
2. Словосочетания приоритетнее обычных слов
3. Чем более полно статья описывает поисковый запрос, тем выше её рейтинг. Причём полнота является ключевым

Далее пройдёмся по заголовкам, только там будем умножать баллы на 10, т.к. заголовок отражает суть статьи.
Сортируем и выводим.
Приведённый алгоритм обрабатывает 100 запросов в секунду при индексе в 1000 статей на VPS с процессором 1Ггц.
P.S. Эта статья лишь служит лишь для ознакомления с некоторыми алгоритмами и идеями нечёткого поиска.

На тысячах анонимных FTP-сайтов. В этом многообразии пользователям было достаточно сложно обнаружить программу, подходящую для решения их задачи.

Более того, они заранее не знали, существует ли искомый инструмент. Поэтому приходилось вручную просматривать FTP-хранилища, структура которых значительно отличалась. Именно эта проблема и привела к появлению одного из ключевых аспектов современного мира - интернет-поиска.

История создания

«Вместо того чтобы тратить свое время на брожение по FTP-сайтам и пытаться понять, что на них есть, я написал скрипты, которые делали это за меня, - рассказывает Алан, - и делали быстро».

<поле>:<необязательный пробел><значение><необязательный пробел>
Запись <поле> могла принимать два значения: User-agent или Disallow. User-agent конкретизировала имя робота, для которого описывалась политика, а Disallow определял разделы, к которым закрывался доступ.

Например, файл с такой информацией запрещает всем роботам доступ к любым URL с /cyberworld/map/ или /tmp/, или /foo.html:

# robots.txt for http://www.example.com/ User-agent: * Disallow: /cyberworld/map/ # This is an infinite virtual URL space Disallow: /tmp/ # these will soon disappear Disallow: /foo.html
В этом примере закрывается доступ к /cyberworld/map для всех роботов, кроме cybermapper:

# robots.txt for http://www.example.com/ User-agent: * Disallow: /cyberworld/map/ # This is an infinite virtual URL space # Cybermapper knows where to go. User-agent: cybermapper Disallow:
Этот файл «развернет» всех роботов, которые попробуют получить доступ к информации на сайте:

# go away User-agent: * Disallow: /

Бессмертный Archie

Хотя Archie очень старый поисковый движок, он все же предоставляет довольно мощную функциональность при поиске нужного файла. Однако по сравнению с современными поисковыми системами, он крайне примитивен. «Поисковики» ушли далеко вперед - достаточно лишь начать вводить желаемый запрос, как система уже предлагает варианты поиска. Не говоря уже об используемых алгоритмах машинного обучения.

Сегодня машинное обучение представляет собой одну из главных частей поисковых систем, таких как Google или «Яндекс». Примером использования этой технологии может быть ранжирование поиска: контекстуальное ранжирование, персонализированное ранжирование и др. При этом очень часто применяются системы Learning to Rank (LTR).

Машинное обучение также позволяет «понимать» запросы, вводимые пользователем. Сайт самостоятельно корректирует написание, обрабатывает синонимы, разрешает вопросы многозначности (что хотел найти пользователь, информацию о группе Eagles или же об орлах). Поисковые системы самостоятельно учатся классифицировать сайты по URL - блог, новостной ресурс, форум и т. д., а также самих пользователей для составления персонализированного поиска.

Прапрадедушка поисковых движков

Что касается Алана Эмтейджа, то когда его спрашивают об упущенной возможности разбогатеть, он отвечает с долей скромности. «Разумеется, я бы хотел разбогатеть, - говорит он. - Однако даже с оформленными патентами я мог бы и не стать миллиардером. Слишком легко допустить неточности в описании. Иногда выигрывает не тот, кто был первым, а тот, кто стал лучшим».

Google и другие компании не были первыми, но они превзошли своих конкурентов, что позволило основать многомиллиардную индустрию.