Обзор архитектур подготовки данных для крупных поисковых систем В последний раз ты и я вспомнил , как стартовал Go.Mail.Ru в 2010 году и каким был Поиск до этого.
В этом посте мы попытаемся нарисовать общую картину — сосредоточимся на том, как работают другие, но сначала поговорим о поисковом распределении.
Как распространяются поисковые системы
По вашим просьбам мы решили подробнее рассмотреть основы стратегий распространения для самых популярных поисковых систем.Бытует мнение, что поиск в Интернете – это один из тех сервисов, который большинство пользователей выбирают самостоятельно, и в этой битве должен победить сильнейший.
Эта позиция для нас чрезвычайно привлекательна – именно по этой причине мы постоянно совершенствуем наши технологии поиска.
Но ситуация на рынке вносит свои коррективы, и в первую очередь сюда вмешиваются так называемые «браузерные войны».
Было время, когда поиск не был привязан к браузеру.
Тогда поисковая система была просто еще одним сайтом, который пользователь посещал по своему усмотрению.
Представьте себе — Internet Explorer до 7-й версии, появившейся в 2006 году, не имел панели поиска; В Firefox была строка поиска из первой версии, но сама она появилась только в 2004 году.
Откуда взялась строка поиска? Его не придумали авторы браузера — впервые он появился в составе Google Toolbar, выпущенного в 2001 году.
Google Toolbar добавил в браузер функционал «быстрого доступа к поиску Google», а именно — строку поиска в его панели: 
Почему Google выпустил свою панель инструментов? Вот как Дуглас Эдвардс, в то время бренд-менеджер Google, описывает ее цель в своей книге «Мне повезет: признания сотрудника Google под номером 59»:
«Панель инструментов была секретным оружием в нашей войне против Microsoft. Встроив панель инструментов в браузер, Google открыл еще один фронт в борьбе за нефильтрованный доступ для пользователей.
Билл Гейтс хотел получить полный контроль над работой ПК, и ходили слухи, что следующая версия Windows будет включать окно поиска прямо на рабочем столе.
Нам нужно было убедиться, что окно поиска Google не превратилось в устаревшую реликвию».
«Панель инструментов была секретным оружием в войне против Microsoft. Интегрировав Панель инструментов в браузер, Google открыла еще один фронт в борьбе за прямой доступ к пользователям.
Билл Гейтс хотел получить полный контроль над тем, как пользователи взаимодействуют со своими ПК: росли слухи, что в следующей версии Windows панель поиска будет установлена прямо на рабочем столе.
Необходимо было принять меры, чтобы панель поиска Google не стала пережитком прошлого».
Как распространялась панель инструментов? Да, всё то же самое, вместе с популярным софтом: Реальный игрок , Adobe Macromedia Shockwave Player и так далее.
Понятно, что свои панели инструментов стали распространять и другие поисковые системы (Yahoo Toolbar, например), а производители браузеров не преминули воспользоваться этой возможностью для получения дополнительного источника дохода от поисковых систем и встроили в себя поисковую строку.
введение понятия «поисковая система по умолчанию».
Бизнес-подразделения производителей браузеров выбрали очевидную стратегию: браузер является точкой входа пользователя в Интернет, настройки поиска по умолчанию с высокой вероятностью будут использоваться аудиторией браузера — так почему бы не продать эти настройки? И они были по-своему правы, ведь поиск в Интернете — продукт практически с нулевой «прилипчивостью».
На этом моменте стоит остановиться подробнее.
Многие возмутятся: «нет, человек привыкает искать и использует только ту систему, которой доверяет», но практика доказывает обратное.
Если, скажем, ваш почтовый ящик или аккаунт в соц.
сеть по каким-то причинам недоступна, вы не сразу переключаетесь на другой почтовый сервис или другую социальную сеть, потому что вы «приклеены» к своим аккаунтам: их знают ваши друзья, коллеги, родственники.
Смена аккаунта – долгий и болезненный процесс.
С поисковыми системами все совсем иначе: пользователь не привязан к той или иной системе.
Если поисковая система по каким-то причинам недоступна, пользователи не сидят и ждут, пока она наконец заработает, а просто переходят в другие системы (например, мы это наглядно видели в счетчиках LiveInternet год назад, во время сбоев у одного из наших конкурентов).
).
При этом пользователи от аварии особо не страдают, ведь все поисковые системы устроены примерно одинаково (поисковая строка, запрос, страница результатов) и даже неопытный пользователь не запутается при работе ни с одной из них.
При этом примерно в 90% случаев пользователь получит ответ на свой вопрос, в какой бы системе он его не искал.
Итак, поиск, с одной стороны, имеет практически нулевую «липкость» (в английском языке есть специальный термин «липкость»).
С другой стороны, какой-то вид поиска уже предустановлен в браузере по умолчанию, и достаточно большое количество людей будет им пользоваться только по той причине, что им оттуда удобно пользоваться.
И если поиск по строке поиска удовлетворяет потребности пользователя, то он может продолжать ею пользоваться.
К чему мы клоним? Ведущим поисковым системам ничего не остается, как бороться за поисковые строки браузера, распространяя свои десктопные поисковые продукты — панели инструментов, которые в процессе установки меняют поиск по умолчанию в браузере пользователя.
Зачинщиком этой драки был Google, остальным пришлось защищаться.
Можно, например, прочитать следующие слова Аркадия Воложа, создателя и владельца Яндекса: в его интервью : «Когда в 2006–2007 гг.
Доля Google на российском поисковом рынке начала расти, но мы сначала не могли понять, почему.
Тогда стало очевидно, что Google пиарит себя, встраивая его в браузеры (Opera, Firefox).
А с выпуском собственного браузера и мобильной операционной системы Google вообще начал уничтожать соответствующие рынки».
Поскольку Mail.Ru — это еще и поиск, он не может оставаться в стороне от «браузерных войн».
Просто мы вышли на рынок чуть позже других.
Теперь качество нашего Поиска заметно выросло, а наше распространение – это реакция на ту самую борьбу тулбаров, которая ведется на рынке.
В то же время для нас очень важно, чтобы все большее число людей, пытающихся использовать наш Поиск, оставались довольными результатами.
Кстати, наша дистрибьюторская политика в несколько раз менее активна, чем у ближайшего конкурента.
Мы видим это в счетчике top.mail.ru, который установлен на большинстве сайтов Рунета.
Если пользователь переходит на сайт по запросу через один из продуктов раздачи (панель инструментов, собственный браузер, поле поиска браузера-партнера), URL содержит параметр clid=.
Таким образом, мы можем оценить мощность запросов на раздачу: у конкурента почти в 4 раза больше, чем у нас.
Но перейдем от распространения к тому, как работают другие поисковые системы.
Ведь внутренние обсуждения архитектуры мы, естественно, начали с изучения архитектурных решений других поисковых систем.
Я не буду подробно описывать их архитектуры — вместо этого приведу ссылки на открытые материалы и выделю те особенности их решений, которые мне кажутся важными.
Подготовка данных для основных поисковых систем
Рамблер
У ныне закрытого поисковика Рамблер был ряд интересных архитектурных идей.Например, они знали о собственной системе хранения данных (NoSQL, как сейчас модно называть такие системы) и распределенных вычислениях HICS ( или HCS ), который использовался, в частности, для расчетов на графе связей.
HICS также позволил стандартизировать представление данных при поиске в едином универсальном формате.
Архитектура Рамблера сильно отличалась от нашей по организации пауков.
Наш паук был спроектирован как отдельный сервер, со своей самописной базой адресов загружаемых страниц.
Для загрузки каждого сайта запускался отдельный процесс, который одновременно скачивал страницы, парсил их, выделял новые ссылки и мог сразу переходить по ним.
Рамблер Паук был сделан намного проще.
На одном сервере находился большой текстовый файл со всеми известными Рамблеру адресами документов, по одному в строке, отсортированный в лексикографическом порядке.
Раз в сутки этот файл сканировался и формировались для скачивания другие текстовые файлы, которые выполнялись специальными программами, которые могли скачивать документы только из списка адресов.
Затем документы разбирались, ссылки извлекались и помещались рядом с этим большим файлом-списком всех известных документов, сортировались, после чего списки объединялись в новый большой файл, и цикл повторялся снова.
Плюсами такого подхода были простота и наличие единого реестра всех известных документов.
Недостатками была невозможность сразу перейти к вновь извлеченным адресам документов, поскольку загрузка новых документов могла произойти только на следующей итерации паука.
Кроме того, размер базы данных и скорость ее обработки были ограничены одним сервером.
Наш паук, наоборот, мог быстро переходить по всем новым ссылкам с сайта, но очень плохо управлялся извне.
«Залить» в адреса дополнительные данные (необходимые для ранжирования документов внутри сайта, определения приоритета скачивания), сложно было сбросить базу данных.
Яндекс
О внутренней структуре поиска Яндекса было известно немного, пока о ней не рассказал Ден Расковалов.Отсюда можно узнать, что поиск Яндекса состоит из двух разных кластеров:
- пакетная обработка
- обработка данных в режиме реального времени (это не совсем «реальное время» в том смысле, в котором этот термин используется в системах управления, где задержка во времени выполнения задачи может быть критичной.
Скорее, это способность документа попасть в индексирование максимально быстро и независимо от других документов или задач, своего рода «мягкая» версия реального времени;
Пока мы будем рассматривать только пакетную обработку, поскольку до обновления индекса в реальном времени мы были довольно далеки; мы хотели обновлять индекс раз в один или два дня.
При этом, несмотря на то, что внешне кластер пакетной обработки данных Яндекса был чем-то похож на нашу пару кластеров скачивания и индексирования, он имел и несколько серьезных отличий:
- Существует одна база данных адресов страниц, хранящаяся на узлах индексации.
В результате проблем с синхронизацией двух баз данных не возникает.
- Управление логикой прокачки передано узлам индексации, т.е.
узлы-пауки устроены очень просто, они скачивают то, что им говорят индексаторы.
Наш паук сам определял, что и когда скачивать.
- И, очень важное отличие: внутри все данные представлены в виде реляционных таблиц документов, сайтов и ссылок.
В нашем случае все данные были распределены по разным хостам и хранились в разных форматах.
Табличное представление данных существенно упрощает доступ к ним, позволяет делать различные выборки и получать самую разнообразную индексную аналитику.
Всего этого мы были лишены, и на тот момент только синхронизация двух наших баз документов (паука и индексатора) занимала неделю, и нам пришлось на это время остановить оба кластера.
И архитектура поиска Google, естественно, оказалась для нас наиболее интересной.
К сожалению, Google редко раскрывает свои архитектурные особенности; каждая статья является большим событием и практически мгновенно порождает параллельный OpenSource-проект (иногда более одного), реализующий описанные технологии.
Тем, кого интересуют возможности поиска Google, можно с уверенностью посоветовать изучить практически все презентации и выступления одного из важнейших специалистов компании по внутренней инфраструктуре — Джеффри Дин , Например:
- «Проблемы построения крупномасштабных информационно-поисковых систем» (слайды), благодаря которым можно узнать, как развивался Google, начиная с самой первой версии, которую еще делали студенты и аспиранты Стэнфордского университета, до 2008 года, до введения универсального поиска.
Есть видеозапись этого выступления и подобное выступление в Стэнфорде, «Создание программных систем в Google и извлеченные уроки»
- «MapReduce: упрощенная обработка данных в больших кластерах» .
В статье описана вычислительная модель, позволяющая легко распараллеливать вычисления на большом количестве серверов.
Сразу после этой публикации появилась платформа Hadoop с открытым исходным кодом.
- «BigTable: A Distributed Structured Storage System», рассказ о NoSQL базе данных BigTable, на базе которой были созданы HBase и Cassandra ( видео можно найти здесь , слайды - Здесь )
- «MapReduce, BigTable и другие абстракции распределенных систем для обработки больших наборов данных» - описание самых известных технологий Google.
- Табличная структура для подготовки данных.
Вся база поиска хранится в огромной таблице, где ключом является адрес документа, а метаинформация хранится в отдельных столбцах, сгруппированных в семейства.
Более того, таблица изначально проектировалась таким образом, чтобы эффективно работать с разреженными данными (то есть, когда не во всех документах есть значения в столбцах).
- Единая система распределенных вычислений MapReduce. Подготовка данных (включая создание поискового индекса) — это последовательность задач Mapreduce, выполняемых над BigTables или файлами в распределенной файловой системе GFS.
, поисковый паук заносит в нее содержимое загруженных страниц и, в конечном итоге, индекс построено на этом.
Есть еще одна интересная презентация другого специалиста Google Дэниела Пенга о нововведениях в BigTable, которые позволили быстро добавлять в индекс новые документы в течение нескольких минут. Эчто рекламировалась технология «вне» Google называется кофеин , а в публикациях его называли Percolator. Видео выступления на OSDI’2010 доступно посмотреть здесь .
Если очень грубо говоря, это тот же BigTable, но в котором есть так называемые триггеры — возможность загрузки собственных кусков кода, запускающих изменения внутри таблицы.
Если до сих пор я описывал пакетную обработку данных, т.е.
когда данные объединяются и обрабатываются вместе, если это возможно, то реализация того же самого на триггерах оказывается совсем другой.
Допустим, паук что-то скачал и добавил в таблицу новый контент; сработал триггер, сигнализирующий «появился новый контент, его нужно проиндексировать».
Процесс индексации начался немедленно.
Оказывается, все задачи поисковой системы в конечном итоге можно разделить на подзадачи, каждая из которых запускается своим кликом.
Имея большое количество оборудования, ресурсов и отлаженного кода, можно решить проблему добавления новых документов быстро, буквально за минуту — что и продемонстрировал Google. Отличие архитектуры Google от архитектуры Яндекса, где также была указана система обновления индекса в реальном времени, состоит в том, что в Google, как заявлено, вся процедура построения индекса выполняется с помощью триггеров, а в Яндексе она есть только на некоторое время.
небольшая часть лучших и наиболее ценных документов.
Лусене
Стоит упомянуть еще одну поисковую систему – Lucene. Это свободно доступная поисковая система, написанная на Java. В некотором смысле Lucene — это платформа для создания поисковых систем, например, она выделила поисковую систему под названием Nutch. По сути, Lucene — это поисковая система для создания индекса и поисковая система, а Nutch — это то же самое плюс паук, который сканирует страницы, потому что поисковая система не обязательно ищет документы, находящиеся в сети.Фактически, сама Lucene не реализует многих интересных решений, которые могла бы позаимствовать крупная поисковая система, рассчитанная на миллиарды документов.
С другой стороны, не следует забывать, что именно разработчики Lucene запустили проекты Hadoop и HBase (каждый раз, когда появлялась новая интересная статья от Google, авторы Lucene пытались сами применить анонсированные решения.
Например, возник HBase, который является клоном BigTable).
Однако эти проекты уже давно существуют сами по себе.
Что меня заинтересовало в Lucene/Nutch, так это то, как они использовали Hadoop. Например, в Nutch был написан специальный паук для сканирования веб-страниц, полностью выполненный в виде задач для Hadoop. Те.
весь паук — это просто процессы, которые выполняются в Hadoop в парадигме MapReduce. Это довольно необычное решение, выходящее за рамки использования Hadoop. Ведь это платформа для обработки больших объёмов данных, а это предполагает, что данные уже доступны.
Но здесь эта задача ничего не рассчитывает и не обрабатывает, а, наоборот, скачивает. С одной стороны, это решение подкупает своей простотой.
Ведь пауку необходимо получить все адреса одного сайта для скачивания, обходить их один за другим, сам паук также должен быть распределен и запущен на нескольких серверах.
Поэтому делаем маппер в виде разделителя адресов для сайтов, а каждый отдельный процесс прокачки реализуем как редьюсер.
С другой стороны, это довольно смелое решение, поскольку загружать сайты сложно — не каждый сайт отвечает за гарантированное время, и вычислительные ресурсы кластера тратятся просто на ожидание ответа от чужого веб-сервера.
Более того, проблема «медленных» сайтов существует всегда, если имеется достаточно большое количество адресов загрузки.
Паук скачивает 80% документов с быстрых сайтов за 20% времени, затем 80% времени тратит на загрузку медленных сайтов - и почти никогда не может скачать их целиком, всегда приходится что-то выбрасывать и оставлять "на след".
время".
Мы некоторое время анализировали это решение и в результате отказались от него.
Возможно, для нас архитектура этого паука была интересна как своего рода «отрицательный пример».
Подробнее о структуре нашей поисковой системы и о том, как мы ее строили, я расскажу в следующем посте.
Теги: #mail.ru #Поисковые технологии #поиск #панели инструментов #поисковая рассылка #GoMail.ru
-
Украсьте Свой Дом Хрустальными Люстрами
19 Oct, 24 -
S7 Airlines Купила «Морской Старт»
19 Oct, 24 -
Лисп — Экзотические Правила
19 Oct, 24 -
The Hit List — Еще Один Todo-Менеджер
19 Oct, 24 -
Uhf Rfid-Считыватель, Подключенный К Nodejs
19 Oct, 24 -
Веб-Справка, Веб-Документы. Еще Проще
19 Oct, 24
