Термин Google Dance часто употребляется при описании механизма обновления индекса поисковой системы Google. Это обновление индекса Google происходит примерно раз в месяц. Во время обновления индекса происходили значительные изменения в результатах запросов, и в Google появлялись новые обратные ссылки на страницы. Начиная с середины 2003 года, Google стал обновлять свой индекс непрерывно. Однако, несмотря на это, время от времени индекс приходится полностью обновлять, в результате чего появляются новые обратные ссылки. Но благодаря постоянному процессу пересчета, воздействие этих полных обновлений на результаты запросов оказывается весьма незначительным.

Тем, кого интересует история Google Dance, предлагаем ознакомиться с материалами о Google Dances, подготовленными администратором WebmasterWorld Бреттом Табке (Brett Tabke).

Принципы функционирования Google Dance

Поисковая система Google получает свои результаты с более чем 10000 серверов, которые являются простыми персональными компьютерами с Linux -системами. Использование подобного оборудования в Google объясняют вопросами экономичности. Естественно, что обновление индекса не может происходить одновременно на всех серверах. Один за другим, серверы должны получать новый индекс.

Многие вебмастера полагают, что во время Google Dance система Google может проконтролировать, отвечает ли на запрос сервер со старым индексом, или сервер с обновленным индексом. Однако, принимая во внимание инверсность индексов Google, решение подобной задачи может быть весьма непростым. Из нижеследующего материала станет понятно, что подобного контроля в системе не существует. Фактически, основной причиной Google Dance является механизм использования системой Google Системы Доменных Имен (DNS).

Google Dance и DNS

Кроме того, что индекс Google расположен на более чем 10000 серверов, эти серверы, на сегодняшний день, расположены в двенадцати различных data-центрах. data-центры находятся, главным образом, в США (а именно, в Санта-Клара, штат Калифорния, и в Хендоне, штат Вирджиния). Справедливости ради надо отметить, что в июне 2002 года открылся первый европейский data-центр Google в швейцарском Цюрихе. За ним последовало открытие data-центров в Америке и двух в ирландском Дублине (запущенных в августе и сентябре 2003 года). Последний data-центр, в США, был сдан в эксплуатацию в октябре 2003 года.

Чтобы направлять траффик во все эти data-центры, Google теоретически может централизованно принимать все запросы и затем распределять их между data-центрами. Но подобная схема, очевидно, неэффективна. В реальности, каждый data-центр имеет свой собственный IP-адрес (цифровой адрес в сети Интернет), а способ доступа к этим IP-адресам управляется Системой Доменных Имен.

Схематически DNS функционирует следующим образом: в среде Интернет передача данных всегда происходит между IP-адресами. Информация о том, какой домен ставится в соответствие какому IP-адресу, предоставляется name-серверами системы DNS. Когда пользователь набирает адрес домена в своем браузере, его локальный name-сервер определяет IP-адрес этого домена, запрашивая name-сервер, ответственный за этот домен. (DNS имеет иерархическую структуру. Описание всего процесса функционирования DNS выходит за рамки данной статьи). Ip-адрес затем сохраняется в кэше локального name-сервера, поэтому нет необходимости запрашивать соответствующий домену name-сервер каждый раз, когда с доменом устанавливается связь.

Соответствующие записи в поддерживающем домен name-сервере определяют, как долго должны храниться данные в кэше принимающего name-сервера. Этот срок называется Временем Жизни (TTL) домена. По окончании срока TTL, кэширующий name-сервер должен опять получить данные о домене от соответствующего name-сервера. Очень часто TTL устанавливается равным одному или нескольким дням. В системе Google, напротив, Время Жизни домена www.Google.com составляет всего лишь пять минут. Таким образом, name-сервер может хранить IP-адрес Google в течение пяти минут, и затем должен запрашивать IP-адрес снова.

Каждый раз, когда name-сервер Google получает запрос, он отсылает обратно IP-адрес только одного data-центра. В реальности, запросы Google всегда направляются в разные data-центры, в соответствии с изменениями DNS-записей. С одной стороны, DNS-записи могут регулировать загрузку отдельных data-центров. В этом плане Google может осуществлять с помощью DNS элементарный баланс нагрузки на data-центры. С другой стороны, географическое расположение определенного кеширующего сервера может повлиять на частоту получения им IP-адресов отдельных data-центров. Таким образом можно уменьшить расстояние, необходимое для передачи данных от data-центра к кеширующему серверу. Чтобы продемонстрировать DNS-записи домена www.Google.com, мы разместили здесь пример одного кэширующего сервера.

Несложно разобраться, каким образом связаны data-центры, DNS и Google Dance. В течение Google Dance data-центры не получают новый индекс одновременно. Фактически, новый индекс передается по очереди от одного data-центра следующему. Когда пользователь делает Google-запрос в течение Google Dance, он может получить результаты от data-центра, который содержит старый индекс, и тот же запрос через несколько минут может быть обработан data-центром с обновленным индексом. С точки зрения пользователя, обновление индекса занимает несколько минут. Но, на самом деле, подобный процесс может повториться, как будто Google переключается между старым и новым индексом.

Нужно отметить, что компания Google самостоятельно занималась вопросом балансирования нагрузки на DNS, пока в сентябре 2003 года она не начала пользоваться услугами, а затем и name-серверами компании Akamai Technologies.

IP-адреса и домены data-центров Google.

Процесс выполнения Google Dance можно, в основных чертах, наблюдать, запрашивая IP-адреса data-центров Google. Хотя запросы на IP-адреса обычно редиректятся на www.Google.com, Google имеет домены, которые соответствуют IP-адресам отдельных data-центров. Эти домены, равно как и их IP-адреса, представлены в следующем списке.

Domain IP Address
www-ex.Google.com 216.239.33.100
www-sj.Google.com 216.239.35.100
www-va.Google.com 216.239.37.100
www-dc.Google.com 216.239.39.100
www-ab.Google.com 216.239.51.100
www-in.Google.com 216.239.53.100
www-zu.Google.com 216.239.55.100
www-cw.Google.com 216.239.57.100
www-fi.Google.com 216.239.41.100
www-gv.Google.com 216.239.59.100
www-kr.Google.com 66.102.11.100
www-mc.Google.com 66.102.7.100
www-lm.Google.com 66.102.9.100

Примечание: Запросы на www-zu и www-sj в настоящее время перенаправляются на другие data-центры. В добавок к тому, что результаты запросов на эти IP-адреса сильно различаются в процессе Google Dance, эти запросы, похоже, перенаправляются внутри системы на другие data-центры. Если посмотреть на статистику DNS-записей Google, в настоящее время www.Google.com не перенаправляет запросы на www-zu и www-sj . Из этого можно сделать вывод, что данные data-центры находятся в режиме оффлайн.

Те, кто следит за обновлениями индекса Google, зачастую полагают, что Google Dance завершен, когда они видят новый индекс на www.Google.com, или когда они не находят на www.Google.com старого индекса в течение какого-то времени. На самом деле, обновление не закончено до того момента, пока все домены из приведенного выше списка не станут выдавать результаты из нового индекса.

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

Нужно отметить, также, что доступ к отдельным data-центрам обычно контролируется только DNS, но иногда запросы переадресуются. Определить подобные случаи несложно: если при запросе на один из вышеперечисленных доменов ссылки в кэше на Google-сервер не совпадают с IP-адресом, принадлежащим домену, тогда имеет место переадресация запроса. Такие случаи свидетельствуют о том, что Google ограничивает (по разным причинам) доступ к определенному data-центру.

Google Dance и тестовые домены www2 и www3

Начало Google Dance всегда можно наблюдать на тестовых доменах www2.Google.com и www3.Google.com . Эти домены обычно имеют неизменные записи DNS, следовательно домены привязаны к определенному (зачастую одинаковому для обоих адресов) IP-адресу. Перед началом Google Dance, по крайней мере один из тестовых доменов приписывается к IP-адресу того data-центра, который первым получит новый индекс.

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

Поэтому домены www2 и www3 предназначены, скорее, для того, чтобы показать новый индекс вебмастерам, которые интересуются своими будущими рейтингами. Многие из этих вебмастеров обсуждают вопросы, связанные с новым индексом на сетевых форумах Google. Эти обсуждения доступны работникам Google. Причем основная масса пользователей еще не может наблюдать новый индекс, потому что DNS записи для www.Google.com обычно не указывают на IP-адрес data-центра, обновляемого первым при начале очередного обновления.

К моменту, когда тестовое сообщество участников форумов Google не находит каких-либо серьезных нарушений, вызванных новым индексом, DNS записи Google готовы приписать к www.Google.com тот data-центр, который будет обновляться первым. Именно в этот момент начинается Google Dance. Но если серьезные нарушения обнаружатся на этой тестовой стадии, еще остается возможность отменить обновления на других data-центрах. Домен www.Google.com не будет направлять запросы на data-центр с “испорченным” индексом, и широкая общественность ничего не заметит. В этом случае индекс должен быть пересчитан, либо сеть будет сканироваться заново.

Итак, результаты поиска, видимые на www2.Google.com и www3.Google.com, появляются на www.Google.com позднее, в процессе планового обновления индекса. Однако, возможны небольшие вариации. С одной стороны, индекс на одном data-центре никогда не совпадает полностью с индексом на другом data-центре. Это можно легко проверить, посмотрев количественные показатели результатов одного и того же запроса, сделанного на разных доменах, указанных выше. Зачастую они будут различаться. С другой стороны, часто предполагается, что иттеративный расчет значений PageRank еще не закончен к моменту начала Google Dance, поэтому предварительные значения оказывают влияние на рейтинги.

Новые значения PageRank в течение Google Dance

Многих вебмастеров интересуют изменения рейтингов их вебсайтов в течение Google Dance. Но, кроме этого, многим также хочется узнать их новые значения PageRank. Обычно Тулбар Google берет значения PageRank из того data-центра, который определен IP-адресом в актуальной записи DNS для www.Google.com. Поэтому, когда начинается Google Dance, Тулбар обычно показывает старые значения PageRank.

Google передает на Тулбар значения PageRank в виде обычных текстовых файлов. Ранее для этого использовался XML, а на текстовые файлы перешли в августе 2002 года. Файлы PageRank можно запросить непосредственно с домена www.Google.com . Обычно URL подобных файлов имеют следующий вид:

http://www.Google.com/search?client=navclient-auto&ch=0123456789&features=Rank&q=info:http://www.domain.com/

Файлы PageRank содержат только одну текстовую строку. Завершает эту строку аббревиатура “PageRank”.

Параметры, включенные в приведенный здесь URL необходимы для того, чтобы отобразить файлы PageRank в браузере. Значение “navclient-auto” для параметра “client” идентифицирует Тулбар. URL передается через параметр q. Значение “Rank” для параметра “features” определяет, что запрашиваются файлы PageRank. Если его опустить, серверы Google будут передавать файлы XML. Параметр “ch” передает Google контрольную сумму для данного URL, причем эта контрольная сумма может изменяться только тогда, когда Google обновляет версию своего Тулбара.

Файлы PageRank, запрашиваемые Тулбаром Google, сохраняются в кэше Internet Explorer. Поэтому их URL и контрольные суммы можно легко узнать, заглянув в папку Temporary Internet Files. Зная контрольные суммы ваших URL, вы можете просматривать файлы PageRank в вашем браузере. Поскольку файлы PageRank хранятся в кэше браузера и явно доступны для просмотра, и пока запросы не производятся автоматически, просмотр файлов PageRank в браузере не будет нарушением Правил Google. Однако будьте осторожны. Тулбар передает Google свой собственный User-Agent, в виде:

Mozilla/4.0 (compatible; GoogleToolbar 1.1.60-deleon; OS SE 4/10)

1.1.60-deleon - это версия Тулбара, которая, естественно, может изменяться. OS - операционная система, которая у вас установлена. Таким образом, Google способен определять запросы от браузеров, если они не поступают через прокси, и если User-Agent не изменен соответствующим образом.

Сейчас давайте посмотрим, как мы можем получить новые значения PageRank. Посмотрев на кэш Internet Explorer, вы заметите, что файлы PageRank запрашиваются не с домена www.Google.com, а с IP-адресов, подобных 216.239.33.102 . К тому же, URL файлов PageRank часто содержат параметр “failedip”, который имеет значение типа “216.239.35.102;1111″ (назначение этого параметра пока что не совсем ясно). Однако получить новые значения PageRank довольно просто. Нужно изменить IP-адреса в URL таким образом, чтобы запрос посылался на те data-центры, которые уже содержат обновленный индекс. Необходимая для этого информация у вас уже есть.