Le nom "Google Dance" est souvent utilis� pour d�crire la mise � jour de l'index du Search Engine de Google. La mise � jour de l'index de Google se produit en moyenne une fois par mois. Elle peut �tre identifi�e par des mouvements significatifs dans les r�sultats lors d'une recherche et particuli�rement dans le cache de Google sur toutes les pages index�es qui refl�tent votre statut lors du dernier spidering de Google. En fait, cela prend plusieurs jours pour compl�ter la mise � jour de l'index. Pendant cette p�riode, le vieux et le nouvel index alterne sur www.google.com. Dans un premier temps, les r�sultats du nouvel index se produisent sporadiquement. Mais plus tard, ils apparaissent plus fr�quemment. Le Search Engine de Google tire ses r�sultats de plus de 10 000 serveurs qui sont de simples PC sur Linux qui sont employ�s par Google pour des raisons de co�t. Naturellement, une mise � jour d'index ne peut pas �tre proc�d�e sur tous ces serveurs en m�me temps. Un serveur apr�s l'autre doit �tre mis � jour avec le nouvel index. Beaucoup de webmasters pensent que, pendant la Google Dance, Google peut d'une mani�re quelconque commander si un serveur avec le nouvel index ou un serveur avec un vieil index r�pond � une requ�te de recherche. Mais, depuis que l'index de Google est invers�, ce serait tr�s compliqu�. Car il n'y a aucune commande dans le syst�me qui permet de le faire. En fait, la raison de la Google Dance est la mani�re de Google d'employer le Domain Name Syst�me (DNS). Non seulement l'index de Google est r�parti sur plus de 10 000 serveurs, mais ces serveurs sont �galement, � partir de maintenant, plac�s sur 8 diff�rents centres de calculs (data centers). Ces centres de calculs, sont principalement situ�s aux Etats-Unis (cad. Santa Clara, Californie et Herndon, Virginie), et le premier centre de calculs europ�en de Google � Zurich a �t� cr�� en juin 2002. Il y aura tr�s probablement, maintenant, plus de centres de calculs qui sont peut�tre r�partis dans le monde entier. Afin de diriger le trafic vers tous ces centres de calculs, Google pourrait th�oriquement centraliser toutes les requ�tes et alors les envoyer aux centres de calculs. Mais ce serait �videmment inefficace. En fait, chaque centre de calculs a sa propre adresse IP (adresse num�rique sur l'Internet) et la mani�re dont ces adresses IP sont consult�es est contr�l�e par le Domain Name System (DNS). Fondamentalement, le DNS fonctionne comme ceci : sur l'Internet, les transferts de donn�es ont lieu toujours entre des adresses IP. L'information � propos de chaque Domaine est r�solue par son adresse IP qui est fournie par les serveurs de nom du DNS. Quand un utilisateur �crit une requ�te sur un domaine dans son navigateur, un serveur de nom localement configur� lui obtient l'adresse IP pour ce domaine en entrant en contact avec le serveur de nom qui est responsable de ce domaine. Le DNS est structur� hi�rarchiquement. L'illustration du processus entier d�passerait la port�e de cet article. L'adresse IP est alors mise en cache par le serveur de nom local, de sorte qu'il ne soit pas n�cessaire d'entrer en contact avec le serveur de nom responsable chaque fois qu'une requ�te remonte jusqu'au domaine. Les enregistrements pour un domaine au serveur de nom responsable constituent pour combien de temps l'enregistrement peut �tre cach� par le serveur de nom. C'est le Time to Live (TTL) d'un domaine. D�s que TTL expirera, le cache du serveur de nom doit de nouveau rechercher l'enregistrement du domaine sur le serveur de nom responsable. Tr�s souvent, le TTL est plac� � un ou plusieurs jours. En revanche, le Time to Live du domaine www.google.com est seulement de cinq minutes. Ainsi, un serveur de nom peut seulement mettre en cache l'adresse IP de Google pendant cinq minutes puis il devra la rechercher. Chaque fois que le serveur de nom de Google re�oit une requ�te, il renvoie l'adresse IP de seulement un centre de donn�es. De cette fa�on, les requ�tes de Google sont toujours dirig�es vers les diff�rents centres de donn�es en changeant des enregistrements de DNS. D'une part, les enregistrements des DNS peuvent �tre bas�s sur le chargement d'un simple centre de donn�es. De cette fa�on, Google conduirait � une simple forme de chargement �quilibr� par son utilisation du DNS. D'autre part, l'endroit g�ographique du cache d'un serveur de nom peut influencer sur le nombre de fois o� il re�oit les adresses simples de l'IP des centres de donn�es. Ainsi, la distance pour des transmissions de donn�es peut �tre r�duite. La fa�on dont les centres de donn�es, le DNS et la Google Dance sont connexes, est facile. Pendant la Google Dance, les centres de donn�es ne re�oivent pas tous le nouvel index en m�me temps. En fait, le nouvel index est transf�r� au centre de donn�es l'un apr�s l'autre. Quand les requ�tes des utilisateurs Google sont faites pendant la Google Dance, elles peuvent obtenir les r�sultats d'un centre de donn�es qui a toujours le vieil index puis, quelques minutes plus tard, avec la m�me requ�te ceux d'un centre de donn�es qui a le nouvel index. Pour les utilisateurs, la mise � jour de l'index a eu lieu en quelques minutes. Mais naturellement ce proc�d� peut s'inverser, de sorte que Google commute apparemment entre le vieux et nouvel index. Le commencement d'une Google Dance peut toujours �tre observ� sur les domaines test www2.google.com et www3.google.com. Ces domaines ont normalement des enregistrements de DNS stables qui font la r�solution de domaines de seulement une (souvent la m�me) adresse IP. Avant que la Google Dance commence, au moins un des domaines test � son adresse IP assign�e par le centre de donn�es qui re�oit le nouvel index en premier. L'accumulation d'un index compl�tement nouveau une fois par mois peut causer un ennui certain. Apr�s tout, Google doit spider quelques milliard de documents puis traiter de nombreux Terabyte de donn�es. Par cons�quent, l'essai du nouvel index est in�vitable. Naturellement, le personnel de Google n'a pas besoin des domaines d'essais eux-m�mes. Certainement, qu'ils ont beaucoup d'options pour v�rifier int�rieurement un nouvel index, mais ils n'ont pas beaucoup de temps pour effectuer les essais. Ainsi, la raison d'avoir www2 et www3 doit plut�t montrer le nouvel index aux webmasters qui sont int�ress�es par leurs futurs rangs.
