Как создать поисковую систему в интернете
Опубликовано в Бизнес в интернете, Обо всем 
Теги: Бизнес в интернете, Стартап
Создаем свой поисковик
Как создать свой поисковик? — спрашивает Коля К. из Киева.
Создать поисковик несложно — отвечаю я
Идея создания своей поисковой системы может кому-то показаться бредовой, хотя на самом деле это очень удобно.
Критиканы сразу же начинают возражать вот есть ведь яндекс, рамблер, тот же google. Зачем еще один?
Ответ лежит на поверхности.
— Во первых свою поисковую систему имеет смысл строить на ограниченом объеме выдачи. Допустим у вас есть 400 компаний поставщиков и 300 компаний партнеров. + на вашем рынке фигурирует еще 1000 тематических сайтов содержащих полезную информацию. Использование обычных ПС даст горы мусора в выдаче. Обработка в ручную для таких объемов в принципе невозможна. Вывод?
Нужна поисковая система проводящая поиск по ограниченному набору строго определенных сайтов
— Во вторых такой самостоятельно созданый поисковик является хорошей рекламной площадкой, которая может монетизироваться.
— В третьих вы определенно можете предоставить своим клиентам удобный и очень полезный сервис тематического поиска.
Ну и наконец в четвертых это вопрос брендинга. Компания способная создать поисковик всегда круче компании на это неспособной. А при учете того что большинство людей считает создание своей поисковой системы сложной, если не сказать неподъемной задачей, то ваш престиж растет до небес.
-Нужно сказать что благодаря современным технологиям достаточно нетривиальная задача разработки системы поиска вылилась в простое и лаконичное решение от команды Ашманова.
Система Flexum — cервис для создания поиска по группе сайтов.
Все гениальное просто. Пользуйтесь!
Как не надо делать сервисы и организовывать стартапы
Что русскому хорошо, то немцу похмелье. Новая биржа Индек убейся ап стену.
Тема продолжения сегодняшнего поста — что такое хороший сервис.
1. Простая регистрация. Не беспокойте меня активацией, не просите ввести 10 капч, не нужно генерить 20 полей данных, мне все равно на вашу безопасность, я хочу получить решение проблемы и если вы сделаете все красиво и быстро Вы останетесь с баблом, а я довольный
2. Чем проще — тем лучше. Хороший сервис позволяет делать 1-2 действия, но при этом офигенно. Я давно не пользуюсь ACDSee потому что она дрочь. Она умеет жарить яишницу и запускать ракеты, а я мечтаю о удобном просмотре картинок, тоже самое касается Nero. Из всего пакета 90% пользователей использует 2 программы, повторяю 2. остальное нафиг не надо.
3. Простота изменений интерфейса, самого интерфейса и интеграции системы с другими вот залог успеха. Я не хочу изучать ваш апи я хочу поставить на сайт одну строчку и получить полный автомат.
4. Не задавайте глупых вопросов. В ходе работы по косвенным данным о пользователе можно собрать достаточно информации чтобы снять тонну ненужных вопросов. Дайте человеку работать а не настраивать вашу офигенную систему.
Как и зачем я создал свой поисковик Pick: история создания и примеры кода
Поскольку Яндекс не захотел парсить мои сайты сославшись на то, что они не умеют обрабатывать контент в формате deflate мне захотелось разобраться в чем дело и попробовать написать свой поисковый сервис. Вообще служба техподдержки Яндекс оказалась для меня бесполезной, поскольку два дня Платоны доказывали мне, что сайты на Revolver CMF отдают битую кодировку. В то же время это был просто сжатый в deflate HTML. В итоге я решил написать свой индексатор, который умеет индексировать сжатый HTML и не только.
Создавать было решено антибюрократический Open Source поисковик, ранжирующий результаты в выдаче на основе голосов зарегистрированных пользователей без участия модерации.
Название мы с друзьями выбрали созвучно всем известной Picus Networks из мира компьютерной игры DeusEx. Осталось создать два алгоритма Pick для выполнения запросов и Picker для индексации контента.
Как создавался Pick
Можно было реализовать поисковую систему отдельно, но я использовал framework RevolveR, который предоставляет доступ к API работы с базой данных и ее кэширование, обработку POST и GET запросов с защитой, а также fetch API для динамических запросов.
А после интеграции Pick стал частью ядра. Скачать RevolveR CMF можно со страницы проекта GitHub.
Создаем индекс в базе данных
Очевидно, что нам нужен свой поисковый индекс, который будет храниться в базе данных. Для этого сформируем структуру на SBQ (structure based queries), которая хранится в файле /Kernel/Structures/DataBase.php:
Мы создали структуру будущей таблицы revolver_index, которую будут использовать модели для записи и хранения данных. Полям content , description и title назначаем полнотекстовый индекс для ускорения запросов SELECT, а для поля host укажем тип индекса simple (это поможет сделать быстрый поиск по всем индексированным ссылкам определённого ресурса).
Также у нас есть поля date и hash . Дата хранит последний момент индексации ресурса, а hash указывает на актуальность данных (если хэш заново полученной страницы не отличается от хранимого в БД значения, то обновление не выполняется).
Поле uri будет содержать полную ссылку страницы.
Теперь нам понадобится таблица в БД которая будет хранить рейтинги материалов в формате 5 звезд на основе голосов зарегистрированных пользователей (API для рейтингов есть и о том как оно работает чуть ниже).
Создадим еще одну структуру:
Таблица очень простая. Она хранит ID ресурса, ID пользователя и оценку.
Давайте зарегистрируем структуры в схеме базы данных:
Таблицы сформированы и описаны и нам осталось выполнить SBQ через API RevolveR CMF для создания этих таблиц в базе данных:
После выполнения этого кода в базе данных появится таблицы revolver__index и revolver__index_ratings, а мы сможем использовать API моделей для работы с ними.
Регистрируем сервис индексации и страницу поиска
В RevolveR CMF есть такое понятие как сервисы. Они используются для выполнения каких-то задач при обращении к ним с аргументами, но не имеют кэширования и не обрабатываются шаблоном.
Чтобы зарегистрировать сервис индексации просто пропишем параметры в файл /private/config.php:
Здесь все предельно просто. Type service указывает на то, что URL /picker/ будет служить обработчиком запросов, которые избегают систему кэширования фреймворка и игнорируют формирование шаблона.
Теперь сразу же зарегистрируем путь, который будет отображать страницу выполнения поисковых запросов к базе данных. Для этого в этом же файле добавим строки:
Параметр menu указывает на то, что мы отображаем пункт в главном меню, а type равное node указывает на то, что регистрируемый путь является узлом, который подвергается кэшированию по умолчанию и может быть подключен к шаблону.
Мы зарегистрировали 2 URI и теперь нужно подключить обработчики сервиса и узла. Поскольку было решено сделать Pick компонентом ядра, мы модернизируем файл /Kernel/Modules/Switch.php:
Этими строками мы создали подключение NodePick и RoutePicker, которые будут содержать основные исходные коды алгоритмов поискового движка. Нам достаточно всего 2 файла.
Индексатор URL Picker
Чтобы проиндексировать какой либо сайт мы должны иметь доступ по сети и уметь парсить сайты. Для этого была использована стандартная библиотека cURL для PHP.
Вот исходный код функции, которая открывает URL и достает содержимое страницы:
Работает алгоритм очень просто. При передаче URL происходит открытие web-страницы и обработчик проверяет корректность SSL соединения. Далее мы смотрим что тип документа характеризует ценные для нас данные HTML или Application xHTML, а также проверяем код ответа сервера. Все, что препятствует получению данных приводит к возврату значения null .
Дополнительно проверяем, что отдаваемый сервером контент может быть сжатым в gzip, deflate или compress.
Теперь нам нужна функция для работы с самим полученным документом. Мы должны извлечь текстовое содержимое без тегов и получит все ссылки на странице:
Здесь вы могли заметить еще две вспомогательные функции. Одна из них, getMetaTags() , извлекает из HTML содержимого все мета теги, а другая, getHost() , распаковывает URL и возвращает host .
Исходный код функций получения meta тегов и хоста:
При этом алгоритм рассчитан таким образом, что превращает все относительные ссылки документа в абсолютные и фильтрует бесполезные ссылки содержащие хэш фрагменты.
Мы собираем только ссылки на этот же ресурс для того, чтобы crawler не убежал слишком далеко, а корректно закончил индексацию всего ресурса.
Поддержка Robots.txt
Не все ссылки бывают полезны и не все страницы несут какую либо смысловую нагрузку. Чтобы профильтровать информацию добавим поддержку подгрузки файла robots.txt:
Загружаем мы robots.txt только единожды за проход и сохраняем полученный массив правил в переменную:
Далее нам понадобится обработчик правил robots.txt. Для этого используем функцию:
При передаче аргумента $xurl происходит сверка с правилами robots.txt и функция возвращает либо true либо null , что символизирует разрешение на добавление в базу данных.
Обработка индекса
Чтобы базу индекса могли индексировать только администраторы и писатели ресурса мы обернем код в проверку роли и добавим фильтр запроса. Черпать аргумент будем из контроллера переменных SV[‘g’] .
Таким образом мы получаем значение host из GET запроса и можем приступить к созданию поискового индекса.
Обработчик индекса поисковой базы
Изначально мы делаем запрос с проверкой наличия искомого URL в базе данных. Если индекс уже существует — просто выясняем свежий ли он, а если его нет, то запишем результат в базу данных. Попутно мы делаем запрос к robots.txt, распаковываем ссылки и метаданные из документов.
Отвечает за это следующая функция:
После записи основной страницы, с которой начинается индексация, происходит обработка всех URL, которые она содержит. Здесь работают две модели:
Модель GET проверяет наличие адреса в индексе.
Модель SET использует автоматическое чтение схемы БД из SBQ и выполняет запрос записи или обновления автоматически.
Алгоритм использует timeout .5 секунды между запросами по ссылкам и не нагружает ресурсы, когда происходит сканирование.
Стоит обратить внимание на hash . В данном случае мы сначала распаковываем тело документа, а затем избавляемся от всех тегов. MD5 полученного текста мы будем использовать для проверки актуальности данных.
Если страницы изменялись, то алгоритм подметит это при проверке:
Для того, чтобы не загружать заново обработанные в процессе прохода ссылки мы передаем аргумент &$indexed по ссылке и на каждую итерацию заполняет глобальный массив ссылками при этом проверяя, что url нет в списке.
Выполняем поисковые запросы
Обладая собственным индексом мы можем приступить к созданию самого сервиса поиска. Для этого мы применим экспертную модель работающую на основе SBQ:
Здесь мы не используем классический LIKE MySQL запрос, а применяем RegExp поиска по базе данных.
Также не забудем, что нам нужно реализовать сортировку по рейтингу, а для этого мы получаем все рейтинги связанного url.
Сам аргумент qs мы будем брать из контроллера переменных SV[‘p’] (стек POST запросов):
Также в этом коде происходит сверка значения captcha, которая усиливает надёжность и предотвращает спам запросы с удаленных серверов.
Сама форма строится с использованием Form API и ее структура (FS) выглядит следующим образом:
К форме подключен автоматический перевод заголовков полей и меток, а сама структура формы должна быть передана в CLASS:
Теперь наша форма работает и умеет передавать пост параметр динамически используя fetch запрос, а каптча предотвращает перегрузку и генерацию запросов ботами.
Алгоритм ранжирования
Сначала мы отсортируем результаты по рейтингу, а дальше перетасуем их в пределах своей цифры рейтинга:
Пишем обработку сниппета
Нам осталось передать поля выбранные предварительным регулярным выражением из базы данных и генерировать сниппет поисковой выдачи.
Мы будем выбирать фрагмент из текста и помечать совпадение запросу:
Здесь пришлось повозиться. Простой подход совсем не подразумевал, что PHP начнет обрабатывать UTF-8 корректно, но я смог добиться работы с русским и английским языками.
Это обычный список возможностью выбора одного из 5ти вариантов голосования по шкале звезд. Голосовать мы предоставим возможность только зарегистрированным пользователям не более одно раза за ссыку, что исключит факт накрутки.
Сам JavaScript для обработки голоса находится в файле /Interface/interface.js и он также подключен к другим материалам подвергаемым голосованию(новости, страницы блога, страницы форума, комментарии и так далее).
Отдельно обратим внимание на обработку голосования. В Revolver CMF уже есть функциональность для голосования и она располагается в сервисе в файле /Kernel/Routes/RouteRating.php.
Нам нужно просто добавить HTML разметку хэндлера для, которая будет инициализировать по клику функцию голосования:
Это обычный список возможностью выбора одного из 5ти вариантов голосования по шкале звезд. Голосовать мы предоставим возможность только зарегистрированным пользователям не более одно раза за ссыку, что исключит факт накрутки.
Сам JavaScript для обработки голоса находится в файле /Interface/interface.js и он также подключен к другим материалам подвергаемым голосованию (новости, страницы блога, страницы форума, комментарии и так далее).
Отдельно обратим внимание на обработку голосования. В Revolver CMF уже есть функциональность для голосования и она располагается в сервисе в файле /Kernel/Routes/RouteRating.php.
Handler голосования автоматически подключается к fetch , а нам осталось только добавить параметр $tpe и прописать таблицу для которой устанавливаются голоса:
Будущее Pick
В будущем, в Revolver CMF будет интегрирована опция связывания индексов и поисковая база расшириться результатами других инсталляций.
Это мне кажется идеально. Во первых, пользователи сами решают какие сайты индексировать, а во вторых положение в поисковой выдаче — это продукт оценки живых людей, которые выполняют поисковые запросы.
Выдачи с разных сайтов могут отличаться и выдача будет формироваться на основе рейтингов разных включенных в индекс ресурсов.
Здесь найдется и место для нейронной сети, чтобы было интереснее и круче.
Запросы будут монетизироваться. Стоимость использования внешнего индекса будет определяться мощностью поисковой базы (размером тематического индекса) и частотой запросов. Также есть мысли о создании собственной валюты (не крипто), которую можно будет приобретать и выводить через основной сайт проекта Pick.
Скачать дистрибутив RevolveR CMF с поисковой системой Pick можно со страницы проекта GitHub.
Сейчас индекс поиска официального сайта почти пустой, но протестировать поисковую систему можно здесь.
Поисковые технологии или в чем загвоздка написать свой поисковик
Когда-то давно взбрела мне в голову идея: написать свой собственный поисковик. Было это очень давно, тогда я еще учился в ВУЗе, мало чего знал про технологии разработки больших проектов, зато отлично владел парой десятков языков программирования и протоколов, да и сайтов своих к тому времени было понаделано много.
Ну есть у меня тяга к монструозным проектам, да…
В то время про то, как они работают было известно мало. Статьи на английском и очень скудные. Некоторые мои знакомые, которые были тогда в курсе моих поисков, на основе нарытых и мной и ими документов и идей, в том числе тех, которые родились в процессе наших споров, сейчас делают неплохие курсы, придумывают новые технологии поиска, в общем, эта тема дала развитие довольно интересным работам. Эти работы привели в том числе к новым разработкам разных крупных компаний, в том числе Google, но я лично прямого отношения к этому не имею.
На данный момент у меня есть собственный, обучающийся поисковик от и до, со многими нюансами – подсчетом PR, сбором статистик-тематик, обучающейся функцией ранжирования, ноу хау в виде отрезания несущественного контента страницы типа меню и рекламы. Скорость индексации примерно полмиллиона страниц в сутки. Все это крутится на двух моих домашних серверах, и в данный момент я занимаюсь масштабированием системы на примерно 5 свободных серверов, к которым у меня есть доступ.
Здесь я в первый раз, публично, опишу то, что было сделано лично мной. Думаю, многим будет интересно как же работают Яндекс, Google и почти все мне известные поисковики изнутри.
Есть много задач при построении таких систем, которые почти нереально решить в общем случае, однако с помощью некоторых ухищрений, придумок и хорошего понимания как работает железячная часть Вашего компьютера можно серьезно упростить. Как пример – пересчет PR, который в случае нескольких десятков миллионов страниц уже невозможно поместить в самой большой оперативной памяти, особенно если Вы, как и я, жадны до информации, и хотите кроме 1 цифры хранить еще много полезностей. Другая задача – хранение и обновление индекса, как минимум двумерной базы данных, в которой конкретному слову сопоставляется список документов, на которых оно встречается.
Просто вдумайтесь, Google хранит, по одной из оценок, более 500 миллиардов страниц в индексе. Если бы каждое слово встречалось на 1 странице только 1 раз, и на хранение этого надо было 1 байт – что невозможно, т.к. надо хранить хотя бы id страницы – уже от 4 байт, так вот тогда объем индекса бы был 500гб. В реальности одно слово встречается на странице в среднем до 10 раз, объем информации на вхождение редко когда меньше 30-50 байт, весь индекс увеличивается в тысячи раз… Ну и как прикажите это хранить? А обновлять?
Ну вот, как это все устроено и работает, я буду рассказывать планомерно, так же как и про то как считать PR быстро и инкрементально, про то как хранить миллионы и миллиарды текстов страниц, их адреса и быстро искать по адресам, как организованы разные части моей базы данных, как инкрементально обновлять индекс на много сотен гигов, ну и наверное расскажу как сделать обучающийся алгоритм ранжирования.
На сегодня объем только индекса, по которому происходит поиск — 57Gb, увеличивается каждый день примерно на 1Gb. Объем сжатых текстов – 25Gb, ну и я храню кучу другой полезной инфы, объем которой очень трудно посчитать из-за ее обилия.