Pgina 1

La anatoma de una hipertextualidad de gran escala

Motor de bsqueda web
Sergey Brin y Lawrence Page
Departamento de Informtica,
Stanford University, Stanford, CA 94305, EE.UU.
sergey@cs.stanford.edu y page@cs.stanford.edu
Abstracto
En este artculo, presentamos Google, un prototipo de un motor de bsqueda a gran escala
que hace pesadas uso de la estructura presente en el hipertexto. Google est diseado para
rastrear e indexar la Web de manera eficiente y producir resultados de bsqueda mucho
ms satisfactorios que los sistemas existentes. El prototipo con un texto y base de datos
de hipervnculo de al menos 24 millones de pginas est disponible en
http://google.stanford.edu/ Para disear un motor de bsqueda es una tarea difcil. Los
motores de bsqueda indexan decenas a cientos de millones de pginas web que implican
un nmero comparable de trminos distintos. Responden a decenas de millones de
consultas cada da. A pesar de la importancia de los motores de bsqueda a gran escala
en la web, muy poca investigacin acadmica se ha hecho sobre ellos. Adems, debido al
rpido avance la tecnologa y la proliferacin de la web, la creacin de un motor de
bsqueda web hoy en da es muy diferente de tres hace aos que. Este documento
proporciona una descripcin en profundidad de nuestro motor de bsqueda web a gran
escala el primera descripcin pblica tan detallada que sabemos de hasta la
fecha. Aparte de los problemas de escalamiento las tcnicas de bsqueda tradicionales a
los datos de esta magnitud, hay nuevos desafos tcnicos con el uso de la informacin
adicional presente en hipertexto para producir mejores resultados de bsqueda. Este
artculo aborda esta cuestin de cmo construir un sistema prctico a gran escala que
informacin adicional presente en hipertexto. Tambin miramos el problema de cmo
tratar efectivamente
con colecciones de hipertexto incontroladas donde cualquiera puede publicar lo que
quiera.
Palabras claves
World Wide Web, motores de bsqueda, recuperacin de informacin, PageRank, Google
1. Introduccin
(Nota: Existen dos versiones de este documento: una versin completa ms larga y una
versin impresa ms corta.
versin completa est disponible en la web y en el CD-ROM de la conferencia.)
La web crea nuevos retos para la recuperacin de la informacin. La cantidad de
informacin en la web es
creciendo rpidamente, as como el nmero de nuevos usuarios inexpertos en el arte de
la investigacin en la web. La gente es
es probable que navegue por la web utilizando su grfico de enlaces, a menudo
comenzando con ndices humanos de alta calidad
como Yahoo! o con los motores de bsqueda. Las listas mantenidas por el ser humano
cubren los temas populares
subjetivo, caro de construir y mantener, lento para mejorar, y no puede cubrir todos los
temas esotricos.
Los motores de bsqueda automatizados que dependen de la coincidencia de palabras
clave generalmente devuelven demasiados resultados de baja calidad.
Para empeorar las cosas, algunos anunciantes intentan llamar la atencin de la gente
tomando medidas
engaar a los motores de bsqueda automatizados. Hemos construido un motor de
bsqueda a gran escala que aborda muchas de las
los problemas de los sistemas existentes. Hace un uso especialmente intenso de la
estructura adicional presente en
hipertexto para proporcionar resultados de bsqueda de mayor calidad. Elegimos nuestro
nombre de sistema, Google, porque
es una ortografa comn de googol, o 10
100
y encaja bien con nuestra meta de construir una bsqueda a gran escala

Pgina 2

motores.
1.1 Motores de bsqueda web - Ampliacin: 1994 - 2000
La tecnologa de los motores de bsqueda ha tenido que escalar dramticamente para
mantenerse al da con el crecimiento de la web. En 1994,
uno de los primeros motores de bsqueda web, el World Wide Web Worm (WWWW)
[McBryan 94] tena un ndice
de 110.000 pginas web y documentos web accesibles. A partir de noviembre de 1997,
los principales motores de bsqueda
reclaman un ndice de 2 millones (WebCrawler) a 100 millones de documentos web
(desde Search Engine
Reloj). Es previsible que para el ao 2000, un ndice comprensivo de la Web contenga
millones de documentos. Al mismo tiempo, el nmero de buscadores de motores de
bsqueda de manejar ha crecido increblemente
tambin. En marzo y abril de 1994, el gusano de la World Wide Web recibi un promedio
de aproximadamente 1500 consultas
por da. En noviembre de 1997, Altavista afirm que manejaba aproximadamente 20
millones de consultas por da. Con el
nmero creciente de usuarios en la web, y sistemas automatizados que consultan los
motores de bsqueda, es probable
que los principales motores de bsqueda manejarn cientos de millones de consultas por
da para el ao 2000. El objetivo de
nuestro sistema es abordar muchos de los problemas, tanto en calidad como en
escalabilidad, introducidos por escalamiento
tecnologa de motores de bsqueda a estos nmeros extraordinarios.
1.2. Google: Escala con la Web
La creacin de un motor de bsqueda que escalas incluso a la web de hoy presenta muchos
desafos. Rastreo rpido
la tecnologa es necesaria para reunir los documentos web y mantenerlos actualizados. Se
debe utilizar espacio de almacenamiento
eficientemente para almacenar ndices y, opcionalmente, los propios documentos. El
sistema de indexacin debe procesar
cientos de gigabytes de datos de manera eficiente. Las consultas deben ser manejadas
rpidamente, a un ritmo de cientos a
miles por segundo.
Estas tareas son cada vez ms difciles a medida que crece la Web. Sin embargo, el
rendimiento del hardware y
los costos han mejorado dramticamente para compensar parcialmente la dificultad. Hay,
sin embargo, varios
excepciones a este progreso como tiempo de bsqueda de disco y robustez del sistema
operativo. Al disear Google,
hemos considerado tanto la tasa de crecimiento de la Web como los cambios
tecnolgicos. Google est diseado para
escala bien a conjuntos de datos extremadamente grandes. Hace un uso eficiente del
espacio de almacenamiento para almacenar el ndice. Sus datos
las estructuras estn optimizadas para un acceso rpido y eficiente (ver seccin
4.2). Adems, esperamos que el costo de
el ndice y el texto del almacn o el HTML disminuirn eventual con respecto a la
cantidad que estar disponible (vase
Apndice B). Esto resultar en propiedades de escala favorables para sistemas
centralizados como Google.
1.3 Objetivos del diseo
1.3.1 Calidad de bsqueda mejorada
Nuestro principal objetivo es mejorar la calidad de los motores de bsqueda web. En
1994, algunas personas crean que
ndice de bsqueda completo hara posible encontrar algo fcilmente. Segn Best of the
Web
1994 - Navigators, "El mejor servicio de navegacin debera facilitar la bsqueda de casi
cualquier
Web (una vez que se han introducido todos los datos). "Sin embargo, la web de 1997 es
bastante diferente.
un motor de bsqueda recientemente, puede fcilmente testificar que la integridad del
ndice no es el nico factor en
la calidad de los resultados de bsqueda. "Los resultados basura" suelen eliminar los
resultados que un usuario est interesado pulg De hecho,
a partir de noviembre de 1997, slo uno de los cuatro principales motores de bsqueda
comercial se encuentra (devuelve su propia
pgina de bsqueda en respuesta a su nombre en los diez primeros resultados). Una de las
principales causas de este problema es que
el nmero de documentos en los ndices ha aumentado en muchos rdenes de magnitud,
pero el usuario
la capacidad de mirar los documentos no. La gente todava est dispuesta a mirar las
primeras decenas de resultados.

Pgina 3

Debido a esto, a medida que crece el tamao de la coleccin, necesitamos herramientas

que tengan una precisin muy alta (nmero de
documentos relevantes devueltos, digamos en las decenas superiores de resultados). De
hecho, queremos que nuestra nocin de "relevante"
slo incluir los mejores documentos, ya que puede haber decenas de miles de ligeramente
relevante
documentos. Esta alta precisin es importante incluso a costa de la memoria (el nmero
total de
documentos relevantes que el sistema pueda devolver). Hay un poco de optimismo
reciente de que el uso de
ms informacin hipertextual puede ayudar a mejorar la bsqueda y otras aplicaciones
[Marchiori 97] [Spertus
97] [Weiss 96] [Kleinberg 98]. En particular, la estructura de enlace [Page 98] y el texto
de enlace proporcionan una gran cantidad de
informacin para hacer juicios de relevancia y filtrado de calidad. Google hace uso de
ambos vnculos
estructura y texto de anclaje (ver Secciones 2.1 y 2.2).
1.3.2 Investigacin acadmica de motores de bsqueda
Aparte de un tremendo crecimiento, la Web tambin se ha vuelto cada vez ms comercial
a travs del tiempo. En 1993,
El 1,5% de los servidores web estaban en dominios .com. Este nmero creci a ms del
60% en 1997. Al mismo tiempo,
los motores de bsqueda han migrado del dominio acadmico al comercial. Hasta ahora,
la mayora de las bsquedas
el desarrollo del motor ha ido encendido en las compaas con poca publicacin de
detalles tcnicos. Esto causa
la tecnologa de los motores de bsqueda para permanecer en gran parte un arte negro y
para ser orientado a la publicidad (vase el Apndice A).
Con Google, tenemos una fuerte meta de impulsar ms desarrollo y comprensin en la
reino.
Otra meta importante del diseo era construir los sistemas que un nmero razonable de
gente puede utilizar realmente.
El uso era importante para nosotros porque pensamos que algunas de las investigaciones
ms interesantes involucrarn
aprovechando la gran cantidad de datos de uso que est disponible en los sistemas web
modernos. Por ejemplo, hay
son muchas decenas de millones de bsquedas realizadas todos los das. Sin embargo, es
muy difcil obtener estos datos,
principalmente porque se considera comercialmente valioso.
Nuestro objetivo final de diseo fue construir una arquitectura que pueda apoyar
actividades de investigacin novedosas sobre
datos en red a gran escala. Para apoyar nuevos usos de investigacin, Google almacena
todos los documentos reales que rastrea
en forma comprimida. Uno de nuestros principales objetivos en el diseo de Google fue
establecer un entorno en el que
otros investigadores pueden entrar rpidamente, procesar grandes trozos de la web y
producir resultados interesantes
que habra sido muy difcil de producir de otra manera. En el corto tiempo que el sistema
ha
ya han sido varios documentos utilizando bases de datos generadas por Google, y muchos
otros estn en marcha.
Otro objetivo que tenemos es establecer un entorno similar al de Spacelab, donde los
investigadores o incluso los estudiantes pueden
proponer y hacer experimentos interesantes en nuestros datos web a gran escala.
2. Caractersticas del sistema
El motor de bsqueda de Google tiene dos caractersticas importantes que le ayudan a
producir resultados de alta precisin. En primer lugar,
hace uso de la estructura de enlaces de la Web para calcular una clasificacin de calidad
para cada pgina web. Este ranking
se llama PageRank y se describe en detalle en [Pgina 98]. En segundo lugar, Google
utiliza el enlace para mejorar
Resultados de la bsqueda.
2.1 PageRank: Traer orden a la Web
El grfico de la cita (enlace) de la red es un recurso importante que en gran parte ha
motores de bsqueda web. Hemos creado mapas que contienen hasta 518 millones de
estos hipervnculos, un
muestra significativa del total. Estos mapas permiten un clculo rpido del "PageRank"
de una pgina web, un

Pgina 4

medida objetiva de su importancia de citacin que corresponde bien con la idea subjetiva
importancia. Debido a esta correspondencia, PageRank es una excelente manera de
priorizar los resultados de
bsquedas de palabras clave web. Para la mayora de los temas populares, una simple
bsqueda de concordancia de texto que est restringida a la web
ttulos de pgina se desempea admirablemente cuando PageRank prioriza los resultados
(demo disponible en
google.stanford.edu). Para el tipo de bsquedas de texto completo en el sistema principal
de Google, PageRank tambin ayuda
mucho.
2.1.1 Descripcin del clculo del PageRank
La literatura de citas acadmicas se ha aplicado a la web, en gran medida contando citas
o vnculos de retroceso a un
pgina dada. Esto da alguna aproximacin de la importancia o calidad de una
pgina. PageRank extiende esto
idea de no contar los enlaces de todas las pginas por igual, y por la normalizacin por el
nmero de enlaces en una pgina.
PageRank se define como sigue:
Asumimos que la pgina A tiene pginas T1 ... Tn que apuntan a ella (es decir, son
citas). El parmetro d
es un factor de amortiguacin que se puede establecer entre 0 y 1. Normalmente fijamos
d a 0,85. Existen
ms detalles acerca de d en la siguiente seccin. Tambin C (A) se define como el nmero
de enlaces que van
fuera de la pgina A. El PageRank de una pgina A se da como sigue:
PR (T _ {1}) + ... + PR (T _ {n}) / C (T _ {n}))
Tenga en cuenta que los PageRanks forman una distribucin de probabilidad sobre
pginas web, por lo que la suma de todos
pginas web 'PageRank ser uno.
PageRank o PR (A) pueden calcularse usando un simple algoritmo iterativo, y
corresponde a la
vector propio principal de la matriz de enlace normalizada de la banda. Adems, un
PageRank para 26 millones de web
pginas se pueden calcular en pocas horas en una estacin de trabajo de tamao
medio. Hay muchos otros detalles
que estn fuera del alcance de este documento.
2.1.2 Justificacin Intuitiva
PageRank puede ser pensado como un modelo de comportamiento del
usuario. Asumimos que hay un "surfista aleatorio" que es
dado una pgina web al azar y sigue haciendo clic en los enlaces, nunca golpear "atrs",
pero finalmente se aburre
y comienza en otra pgina aleatoria. La probabilidad de que la persona que practica surf
al azar visite una pgina es su PageRank.
Y, el factor de amortiguamiento D es la probabilidad en cada pgina del "navegante
aleatorio" se aburrir y la solicitud
otra pgina aleatoria. Una variacin importante es slo para agregar el factor de
amortiguamiento d para una sola pgina, o una
grupo de pginas. Esto permite la personalizacin y puede hacer casi imposible deliberar
engaar al sistema para obtener una clasificacin ms alta. Tenemos varias otras
extensiones a PageRank,
ver de nuevo [Pgina 98].
Otra justificacin intuitiva es que una pgina puede tener un PageRank alto si hay muchas
pginas que apuntan
a l, o si hay algunas pginas que apuntan a ella y tienen un PageRank
alto. Intuitivamente, las pginas que estn bien
citados de muchos lugares alrededor de la web vale la pena mirar. Tambin, las pginas
que quizs slo tienen una
citacin de algo como el Yahoo! pgina principal tambin son generalmente vale la pena
mirar. Si una pgina no fue
alta calidad, o era un acoplamiento quebrado, es muy probable que la pgina inicial de
Yahoo no enlazara a ella.
PageRank maneja estos dos casos y todo lo dems mediante la propagacin recursiva de
pesos
a travs de la estructura de enlace de la red.

Pgina 5

2.2 Texto de anclaje

El texto de los enlaces se trata de una manera especial en nuestro buscador. La mayora
de los motores de bsqueda asocian el texto
de un enlace con la pgina en la que se encuentra el enlace. Adems, lo asociamos con la
pgina a la que apunta el enlace.
Esto tiene varias ventajas. En primer lugar, los anclajes a menudo proporcionan
descripciones ms precisas de las pginas web que
las propias pginas. En segundo lugar, pueden existir anclas para documentos que no
puedan ser
motor de bsqueda basado en texto, como imgenes, programas y bases de datos. Esto
hace posible volver a la red
pginas que en realidad no se han rastreado. Tenga en cuenta que las pginas que no se
han rastreado pueden causar
problemas, ya que nunca se verifica su validez antes de ser devueltos al usuario. En este
caso, el
motor de bsqueda puede incluso devolver una pgina que nunca existi realmente, pero
tena hipervnculos apuntando a ella.
Sin embargo, es posible ordenar los resultados, de modo que este problema particular rara
vez ocurre.
Esta idea de propagacin de texto ancla a la pgina a la que se refiere se implement en
la World Wide Web
Worm [McBryan 94], especialmente porque ayuda a buscar informacin no textual y
ampla la bsqueda
con menos documentos descargados. Utilizamos la propagacin de anclaje
principalmente porque el texto de anclaje
puede ayudar a proporcionar resultados de mejor calidad. El uso eficiente del texto de
anclaje es tcnicamente difcil debido a
las grandes cantidades de datos que deben procesarse. En nuestro rastreo actual de 24
millones de pginas,
ms de 259 millones de anclas que indexamos.
2.3 Otras caractersticas
Aparte de PageRank y el uso de texto de anclaje, Google tiene varias otras
caractersticas. En primer lugar, tiene ubicacin
informacin para todos los golpes y por lo que hace un uso extensivo de la proximidad
en la bsqueda. En segundo lugar, Google mantiene la pista
de algunos detalles visuales de la presentacin tales como tamao de la fuente de
palabras. Las palabras en una fuente ms grande o ms audaz son
ponderado ms alto que otras palabras. En tercer lugar, el HTML completo de pginas
est disponible en un repositorio.
3 Trabajo relacionado
Bsqueda de la investigacin en la web tiene una historia corta y concisa. El Gusano de
la World Wide Web (WWWW)
[McBryan 94] fue uno de los primeros motores de bsqueda web. Posteriormente fue
seguido por varios otros
motores de bsqueda acadmicos, muchos de los cuales son ahora empresas
pblicas. Comparado con el crecimiento del
Web y la importancia de los motores de bsqueda hay muy pocos documentos sobre los
motores de bsqueda recientes
[Pinkerton 94]. Segn Michael Mauldin (cientfico en jefe, Lycos Inc) [Mauldin], "los
diversos
(incluyendo a Lycos) vigilan de cerca los detalles de estas bases de datos. "Sin embargo,
ha habido un
cantidad de trabajo sobre las caractersticas especficas de los motores de
bsqueda. Especialmente bien representado es el trabajo que puede
obtener resultados mediante el post-procesamiento de los resultados de los motores de
bsqueda comerciales existentes o producir
motores de bsqueda "individualizados". Por ltimo, ha habido un montn de
investigacin sobre la recuperacin de la informacin
sistemas, especialmente en colecciones bien controladas. En las dos secciones siguientes,
debatimos algunas
esta investigacin necesita ser extendida para trabajar mejor en la web.
3.1 Recuperacin de informacin
El trabajo en sistemas de recuperacin de informacin se remonta a muchos aos y est
bien desarrollado [Witten 94].
Sin embargo, la mayor parte de la investigacin sobre los sistemas de recuperacin de
informacin est en pequeos pozos bien controlados
colecciones homogneas tales como colecciones de artculos cientficos o noticias sobre
un tema relacionado.
De hecho, el punto de referencia primario para la recuperacin de informacin, la
Conferencia de Recuperacin de Texto [TREC 96],
utiliza una coleccin bastante pequea y bien controlada para sus puntos de referencia. El
"Corpus muy grande"

Pgina 6

benchmark es slo 20GB en comparacin con los 147GB de nuestro rastreo de 24

millones de pginas web. Cosas que
trabajar bien en TREC a menudo no producen buenos resultados en la web. Por ejemplo,
el vector estndar
el modelo de espacio intenta devolver el documento que ms se aproxima a la consulta,
dado que tanto la consulta
y el documento son vectores definidos por su ocurrencia de palabra. En la web, esta
estrategia a menudo
documentos cortos que son la consulta ms algunas palabras. Por ejemplo, hemos visto
un motor de bsqueda principal
devolver una pgina que contiene slo "Bill Clinton Sucks" y la imagen de una "Bill
Clinton" consulta. Algunos sostienen
que en la web, los usuarios deben especificar con mayor precisin lo que quieren y aadir
ms palabras a sus
consulta. Discordamos vehementemente de esta posicin. Si un usuario emite una
consulta como "Bill Clinton"
obtener resultados razonables ya que hay una enorme cantidad de informacin de alta
calidad disponible en este
tema. Dado ejemplos como estos, creemos que el trabajo estndar de recuperacin de
informacin debe ser
ampliado para tratar eficazmente con la web.
3.2 Diferencias entre la Web y colecciones bien controladas
La web es una vasta coleccin de documentos heterogneos completamente
incontrolados. Documentos sobre la
web tienen una variacin extrema interna a los documentos, y tambin en la meta
informacin externa que
podra estar disponible. Por ejemplo, los documentos difieren internamente en su idioma
(tanto humano como
programacin), vocabulario (direcciones de correo electrnico, enlaces, cdigos postales,
nmeros de telfono, nmeros de producto), tipo o
(texto, HTML, PDF, imgenes, sonidos), e incluso pueden ser generados por la mquina
(archivos de registro o salida
de una base de datos). Por otro lado, definimos meta informacin externa como
informacin que puede ser
inferido sobre un documento, pero no est contenido en l. Ejemplos de meta informacin
externa incluyen
cosas como la reputacin de la fuente, frecuencia de actualizacin, calidad, popularidad
o uso, y las citas. No
slo son las posibles fuentes de meta informacin externa variada, pero las cosas que se
estn midiendo
varan muchos rdenes de magnitud tambin. Por ejemplo, compare la informacin de
uso de una
homepage, como Yahoo que actualmente recibe millones de pginas vistas cada da con
un oscuro
artculo histrico que podra recibir una visin cada diez aos. Claramente, estos dos
elementos deben ser tratados
muy diferente por un motor de bsqueda.
Otra gran diferencia entre la web y las colecciones tradicionales bien controladas es que
hay
virtualmente ningn control sobre lo que la gente puede poner en la web. Acople esta
flexibilidad para publicar cualquier cosa con
la enorme influencia de los motores de bsqueda para encaminar el trfico y las empresas
que deliberadamente
manipular los motores de bsqueda para obtener beneficios se convierte en un problema
serio. Este problema que no ha sido
en sistemas tradicionales de recuperacin de informacin cerrada. Adems, es interesante
observar que los metadatos
los esfuerzos han fracasado en gran medida con los motores de bsqueda web, ya que
cualquier texto en la pgina que no es directamente
representado al usuario es abusado para manipular los motores de bsqueda. Incluso hay
numerosas empresas
que se especializan en la manipulacin de los motores de bsqueda con fines de lucro.
4 Anatoma del sistema
En primer lugar, proporcionaremos una discusin de alto nivel de la
arquitectura. Entonces, hay algunos en profundidad
descripciones de estructuras de datos importantes. Finalmente, las principales
aplicaciones: rastreo, indexacin y
la bsqueda se examinar en profundidad.

Pgina 7

4.1 Descripcin general de la arquitectura de Google

En esta seccin, daremos una visin general de alto nivel de cmo
todo el sistema funciona como se ilustra en la Figura 1.
las secciones discutirn las aplicaciones y las estructuras de datos
no mencionado en esta seccin. La mayor parte de Google es
implementado en C o C ++ para la eficiencia y puede
ya sea Solaris o Linux.
En Google, el rastreo web (descarga de pginas web)
se realiza por varios rastreadores distribuidos. Hay un
URLserver que enva listas de URLs a buscar en el
rastreadores Las pginas web que se obtienen se envan a
el almacn. El almacn entonces comprime y almacena
las pginas web en un repositorio. Cada pgina web tiene un
nmero de identificacin asociado llamado docID que se asigna
siempre que se analiza una nueva URL de una pgina web. los
funcin de indexacin es realizada por el indexador y
clasificador. El indizador realiza una serie de funciones. Se lee
el repositorio, descomprime los documentos y los analiza. Cada documento se convierte
en un conjunto de
las ocurrencias de palabras llamadas hits. Los resultados registran la palabra, la posicin
en el documento, una aproximacin de la fuente
tamao y maysculas. El indexador distribuye estos golpes en un conjunto de "barriles",
creando una
ndice ordenado adelante. El indizador realiza otra funcin importante. Analiza todos los
enlaces en
cada pgina web y almacena informacin importante sobre ellos en un archivo de
anclas. Este archivo contiene
suficiente informacin para determinar a dnde va cada enlace desde y hacia, y el texto
del enlace.
El URLresolver lee el archivo de anclajes y convierte las URL relativas en URLs
absolutas y, a su vez, en
docIDs. Coloca el texto de anclaje en el ndice directo, asociado con el docID que los
puntos de anclaje
a. Tambin genera una base de datos de enlaces que son pares de docIDs. La base de datos
de enlaces se utiliza para calcular
PageRanks para todos los documentos.
El clasificador toma los barriles, que son ordenados por docID (esto es una simplificacin,
ver Seccin 4.2.5), y
los utiliza por wordID para generar el ndice invertido. Esto se hace en su lugar para que
poco temporal
se necesita espacio para esta operacin. El clasificador tambin produce una lista de ID
de palabra y desplazamientos en el
ndice invertido. Un programa llamado DumpLexicon toma esta lista junto con el lxico
producido por el
indexador y genera un nuevo lxico para ser usado por el buscador. El buscador es
ejecutado por un servidor web y
utiliza el lxico construido por DumpLexicon junto con el ndice invertido y los
PageRanks para responder
consultas.
4.2 Principales estructuras de datos
Las estructuras de datos de Google se optimizan para que una coleccin de documentos
grande se pueda rastrear, indexar y
buscado con poco costo. Aunque, las CPUs y las tasas de produccin de entrada a granel
han mejorado drsticamente
los aos, una bsqueda de disco todava requiere unos 10 ms para completar. Google est
diseado para evitar las busquedas de disco
siempre que sea posible, y esto ha tenido una influencia considerable en el diseo de las
estructuras de datos.
Figura 1. Arquitectura de alto nivel de Google

Pgina 8

4.2.1 BigFiles
BigFiles son archivos virtuales que abarcan mltiples sistemas de archivos y son
direccionables por enteros de 64 bits. los
la asignacin entre mltiples sistemas de archivos se maneja automticamente. El paquete
BigFiles tambin maneja
asignacin y desasignacin de descriptores de archivo, ya que los sistemas operativos no
proporcionan suficiente
necesariamente. BigFiles tambin soportan opciones de compresin rudimentarias.
4.2.2 Repositorio
El repositorio contiene el HTML completo de cada pgina web.
Cada pgina se comprime con zlib (vase RFC1950). los
la eleccin de la tcnica de compresin es una compensacin entre la velocidad
y la relacin de compresin. Elegimos la velocidad de zlib
mejora significativa en la compresin ofrecida por bzip. los
la tasa de compresin de bzip fue de aproximadamente 4 a 1 en la
repositorio en comparacin con la compresin de 3 a 1 de zlib. En el
repositorio, los documentos se almacenan uno tras otro y
son prefijados por docID, longitud y URL como se puede ver en
Figura 2. El repositorio no requiere ninguna otra estructura de datos para ser utilizada
para acceder a ella. Esto ayuda con
la coherencia de los datos y facilita mucho el desarrollo; podemos reconstruir todas las
otras estructuras de datos de
slo el repositorio y un archivo que lista los errores del rastreador.
4.2.3 ndice de documentos
El ndice de documentos mantiene informacin sobre cada documento. Es un ancho fijo
ISAM (ndice secuencial
modo de acceso), ordenado por docID. La informacin almacenada en cada entrada
incluye la
el estado del documento, un puntero en el repositorio, una suma de comprobacin del
documento y varias estadsticas. Si el
documento se ha rastreado, tambin contiene un puntero en un archivo de anchura
variable llamado docinfo que
contiene su URL y ttulo. De lo contrario, el puntero apunta a la URLlist que contiene
slo la URL.
Esta decisin de diseo fue impulsada por el deseo de tener una estructura de datos
razonablemente compacta, y la
capacidad de buscar un registro en una bsqueda de disco durante una bsqueda
Adems, hay un archivo que se utiliza para convertir URLs en docIDs. Es una lista de
sumas de comprobacin de URL
con sus docIDs correspondientes y se clasifica por checksum. Con el fin de encontrar el
docID de un particular
URL, se calcula la suma de comprobacin de la URL y se realiza una bsqueda binaria
en el archivo de sumas de comprobacin para encontrar
su docID. Las URL pueden convertirse en docIDs en lote haciendo una combinacin con
este archivo. Este es el
tcnica que el URLresolver utiliza para convertir URLs en docIDs. Este modo de
actualizacin por lotes es crucial porque
de lo contrario debemos realizar una bsqueda por cada enlace que asumiendo que un
disco llevara ms de un
mes para nuestro conjunto de datos de enlaces de 322 millones.
4.2.4 Lxico
El lxico tiene varias formas diferentes. Un cambio importante de los sistemas anteriores
es que el lxico
puede caber en la memoria por un precio razonable. En la implementacin actual
podemos mantener el lxico en
memoria en una mquina con 256 MB de memoria principal. El lxico actual contiene 14
millones de palabras
(aunque algunas palabras raras no fueron agregadas al lxico). Se implementa en dos
partes: una lista de las
palabras (concatenadas juntas pero separadas por nulos) y una tabla hash de
punteros. Para diversas funciones,
Figura 2. Estructura de datos del repositorio

Pgina 9

la lista de palabras tiene alguna informacin auxiliar que est ms all del alcance de este
artculo para explicarlo completamente.
4.2.5 Listas de aciertos
Una lista de resultados corresponde a una lista de ocurrencias de una palabra en particular
en un documento particular incluyendo
informacin de posicin, fuente y maysculas. Las listas de visitas representan la mayor
parte del espacio
adelante y los ndices invertidos. Por ello, es importante representarlos tan eficientemente
como
posible. Consideramos varias alternativas para codificar la posicin, la fuente y la
mayscula - simple
codificacin (un triple de enteros), una codificacin compacta (una asignacin optimizada
a mano de bits), y Huffman
codificacin. Al final elegimos una codificacin compacta optimizada manualmente ya
que requera mucho menos espacio que el
codificacin simple y mucho menos manipulacin de bits que Huffman codificacin. Los
detalles de los golpes se muestran en
Figura 3.
Nuestra codificacin compacta utiliza dos bytes para cada golpe. Hay dos tipos de xitos:
golpes de lujo y golpes sencillos.
Los impactos de lujo incluyen los impactos que ocurren en una URL, ttulo, texto de
anclaje o metaetiqueta. Los xitos sencillos incluyen todo
ms. Un golpe simple consiste en un bit de maysculas, tamao de fuente y 12 bits de
posicin de palabra en un documento (todos
las posiciones superiores a 4095 estn marcadas como 4096). El tamao de la fuente se
representa con relacin al resto del documento
utilizando tres bits (slo 7 valores se utilizan realmente porque 111 es la bandera que
seala un golpe de fantasa). Un elegante
hit consiste en un bit de maysculas, el tamao de fuente establecido en 7 para indicar
que es un golpe de fantasa, 4 bits para codificar el
tipo de golpe de fantasa, y 8 bits de posicin. Para los golpes de anclaje, los 8 bits de
posicin se dividen en 4 bits para
posicin en ancla y 4 bits para un hash del docID en el que se produce el ancla. Esto nos
da algunas limitaciones
mientras no hay muchas anclas para una palabra en particular. Esperamos actualizar
la forma en que los golpes de anclaje se almacenan para permitir una mayor resolucin
en los campos de posicin y docIDhash.
Utilizamos el tamao de fuente en relacin con el resto del documento porque al buscar,
no desea clasificar
de lo contrario documentos idnticos de manera diferente slo porque uno de los
documentos est en una fuente ms grande.
La longitud de una lista de resultados se almacena antes de los golpes.
Para ahorrar espacio, la longitud de la lista de resultados se combina con la
wordID en el ndice directo y el docID en el invertido
ndice. Esto limita a 8 y 5 bits respectivamente (hay
algunos trucos que permiten obtener 8 bits de la
wordID). Si la longitud es ms larga de lo que cabra en
bits, se utiliza un cdigo de escape en esos bits, y los siguientes dos
bytes contienen la longitud real.
4.2.6 Forward Index
El ndice forward est en realidad ya parcialmente ordenado. Es
almacenado en un nmero de barriles (utilizamos 64). Cada barril
contiene un rango de ID de palabra. Si un documento contiene palabras
que caen en un determinado barril, el docID se registra en
el barril, seguido por una lista de ID de palabra con listas de
corresponden a esas palabras. Este esquema requiere
ms de almacenamiento debido a duplicados docIDs, pero el
la diferencia es muy pequea para un nmero razonable de cubos y ahorra tiempo
considerable y la codificacin
complejidad en la fase de indexacin final realizada por el clasificador. Adems, en lugar
de almacenar
wordID, almacenamos cada ID de palabra como una diferencia relativa con respecto al
ID de palabra mnimo que cae en la
Figura 3. ndices hacia delante y hacia atrs
y el Lxico

Pgina 10

barrel el wordID es pulg De esta manera, podemos utilizar slo 24 bits para el wordID en
los barriles sin clasificar,
dejando 8 bits para la longitud de la lista de aciertos.
4.2.7 ndice invertido
El ndice invertido consiste en los mismos barriles que el ndice forward, excepto que han
sido
procesado por el clasificador. Para cada wordID vlido, el lxico contiene un puntero en
el barril que
wordID cae en. Seala a un doclist de docID junto con sus listas de golpe
correspondientes. Este doclist
representa todas las ocurrencias de esa palabra en todos los documentos.
Una cuestin importante es en qu orden deben aparecer los docID en el doclist. Una
solucin sencilla es
almacnelos ordenados por docID. Esto permite la rpida fusin de diferentes doclists
para mltiples palabras
consultas. Otra opcin es almacenarlos ordenados por una clasificacin de la ocurrencia
de la palabra en cada
documento. Esto hace que responder a una palabra consultas trivial y hace probable que
las respuestas a
las consultas de palabras mltiples estn cerca del comienzo. Sin embargo, la fusin es
mucho ms difcil. Adems, esto hace que
desarrollo mucho ms difcil en que un cambio a la funcin de clasificacin requiere una
reconstruccin del ndice.
Elegimos un compromiso entre estas opciones, manteniendo dos conjuntos de barriles
invertidos - un conjunto para el xito
listas que incluyen golpes de ttulo o de anclaje y otro conjunto para todas las listas de
aciertos. De esta manera, verificamos el primer conjunto de
barriles primero y si no hay suficientes fsforos dentro de esos barriles comprobamos los
ms grandes.
4.3 Rastreo de la Web
Ejecutar un rastreador web es una tarea difcil. Hay problemas difciles de rendimiento y
confiabilidad y
an ms importante, hay asuntos sociales. El rastreo es la aplicacin ms frgil ya que
implica
interactuando con cientos de miles de servidores web y varios servidores de nombres que
estn ms all
el control del sistema.
Con el fin de escalar a cientos de millones de pginas web, Google tiene un sistema de
rastreo distribuido rpido. UN
servidor URL nico sirve listas de direcciones URL a un nmero de rastreadores
(normalmente se ejecuta alrededor de 3). Ambos
URLserver y los rastreadores son implementados en Python. Cada rastreador mantiene
alrededor de 300 conexiones
abrir a la vez. Esto es necesario para recuperar las pginas web a un ritmo lo
suficientemente rpido. A velocidades de pico, el sistema de
puede rastrear ms de 100 pginas web por segundo utilizando cuatro rastreadores. Esto
equivale a aproximadamente 600 K por segundo
de datos. Un gran estrs rendimiento es la bsqueda de DNS. Cada rastreador mantiene
una su propia cach DNS por lo que
no necesita hacer una bsqueda de DNS antes de meterse cada documento. Cada uno de
los cientos de conexiones
puede ser en un nmero de diferentes estados: mirando hacia arriba DNS, conectar con el
equipo, el envo de la solicitud, y
recibir la respuesta. Estos factores hacen que el rastreador de un componente complejo
del sistema. Usa
S asncrona para gestionar eventos, y un nmero de colas para mover la pgina obtiene a
partir de un estado a otro.
Resulta que la ejecucin de un rastreador que conecta a ms de medio milln de
servidores, y genera decenas
de millones de entradas de registro genera una buena cantidad de correo electrnico y las
llamadas telefnicas. Debido a la gran cantidad
de personas que vienen en lnea, no siempre son los que no saben lo que es un rastreador
es, porque este es el
primero que han visto. Casi todos los das, recibimos un correo electrnico algo como,
"Wow, se vea a una gran cantidad de
pginas de mi sitio web. Cmo te gusta?" Tambin hay algunas personas que no saben
acerca de la
robots de protocolo de exclusin, y piensan que su pgina debe ser protegido de la
indexacin de una declaracin como,
"Esta pgina tiene derechos de autor y no debe ser indexado", lo que no hace falta decir
es difcil para los rastreadores web
comprender. Adems, debido a la enorme cantidad de datos implicados, las cosas van a
suceder inesperados. por
ejemplo, nuestro sistema trat de arrastrarse un juego en lnea. Esto dio lugar a una gran
cantidad de mensajes basura en la
medio de su juego! Resulta que este era un problema fcil de solucionar. Sin embargo,
este problema no se haba acercado

Pgina 11

hasta que haba descargado decenas de millones de pginas. Debido a la gran variacin
en las pginas web y
servidores, es prcticamente imposible probar una oruga sin ejecutarlo en gran parte de
la Internet.
Invariablemente, hay cientos de problemas oscuros que slo pueden ocurrir en una pgina
fuera de la totalidad
web y hacer que el rastreador se bloquee, o peor, provocar un comportamiento
impredecible o incorrecta. Los sistemas que
de acceso a una gran parte de la necesidad de Internet a ser diseados para ser muy robusto
y probado cuidadosamente. Desde grandes
sistemas complejos tales como rastreadores destinada a causar problemas, es necesario
que haya recursos significativos
dedicado a la lectura del correo electrnico y la solucin de estos problemas a medida que
surgen.
4.4 Indexacin de la Web
Anlisis sintctico - Cualquier programa de anlisis que est diseado para funcionar en
toda la Web debe manejar una enorme variedad de
posibles errores. Estos van desde errores tipogrficos en las etiquetas HTML de kilobytes
de ceros en el medio de una etiqueta,
caracteres no ASCII, etiquetas HTML anidadas cientos de profundidad, y una gran
variedad de otros errores que se
desafiar la imaginacin de cualquiera de llegar a los igualmente creativas. Para una
velocidad mxima,
en lugar de utilizar YACC para generar un analizador CFG, utilizamos flex que genere
un analizador lxico, que
equipamos con su propia pila. El desarrollo de este analizador, que funciona a una
velocidad razonable y es muy
robusta implic una buena cantidad de trabajo.
Documentos de indexacin en Barriles - Despus se analiza cada documento, se
codifica en un nmero
de barriles. Cada palabra se convierte en un wordID mediante el uso de una tabla hash en
memoria - el lxico.
Las nuevas adiciones a la tabla hash de lxico se registran en un archivo. Una vez que las
palabras se convierten en
wordID de, sus ocurrencias en el documento actual se traducen en listas negras y estn
escritos en
los barriles hacia adelante. La principal dificultad con la paralelizacin de la fase de
indexacin es que el
lxico tiene que ser compartida. En lugar de compartir el lxico, tomamos el enfoque de
escribir un registro de
todas las palabras adicionales que no estaban en un lxico de base, que fija en 14 millones
de palabras. De esa manera
varios indizadores pueden ejecutarse en paralelo y luego el archivo de registro pequea
de palabras adicionales pueden ser procesados por
un ltimo paso a paso.
Ordenando - Con el fin de generar el ndice invertido, la clasificadora toma cada uno de
los barriles hacia adelante y hacia
la ordena por wordID para producir un barril invertido en el ttulo y anclaje hits y un texto
completo invertidas
barril. Este proceso se produce un barril a la vez, por lo que requiere poco de
almacenamiento temporal. Tambin nosotros
paralelizar la fase de clasificacin para usar tantas mquinas como lo hemos hecho,
simplemente mediante la ejecucin de mltiples
clasificadores, que pueden procesar diferentes cubos al mismo tiempo. Dado que los
barriles no encajan en principal
la memoria, el clasificador de las subdivide adems en cestas que hacen encajar en la
memoria sobre la base de
wordID y docID. A continuacin, el clasificador, se carga cada canasta en la memoria, la
ordena y escribe su contenido
en el can corto invertida y el can invertido completo.
4.5 Bsqueda
El objetivo de la bsqueda es para proporcionar resultados de bsqueda de calidad de
manera eficiente. Muchas de las grandes superficies comerciales
motores de bsqueda parecen haber hecho grandes progresos en trminos de
eficiencia. Por lo tanto, nos hemos centrado
ms en la calidad de la bsqueda en nuestra investigacin, aunque creemos que nuestras
soluciones son escalables a comerciales
volmenes con un esfuerzo poco ms. El proceso de evaluacin consulta Google es
muestra en la Figura 4.

Pgina 12

Para poner un lmite en el tiempo de respuesta, una vez que un cierto nmero de
(Actualmente 40.000) de los documentos que coincidan se encuentran, la
buscador pasa automticamente al paso 8 en la Figura 4. Este
significa que es posible que los resultados sub-ptimos seran
devuelto. Actualmente estamos investigando otras maneras de resolver
este problema. En el pasado, hemos solucionado los accesos de acuerdo con
PageRank, que pareca mejorar la situacin.
4.5.1 El sistema de clasificacin
Google mantiene mucha ms informacin sobre Web
documentos que los motores de bsqueda tpicos. cada lista negra
incluye la posicin, la fuente y la informacin de capitalizacin.
Adems, tenemos en cuenta los xitos de texto de anclaje y la
PageRank del documento. Combinando todo esto
informacin en un rango es difcil. Hemos diseado nuestro ranking
funcin de manera que ningn factor en particular puede tener demasiado
influencia. En primer lugar, consideremos el caso ms simple - una sola palabra
consulta. Con el fin de clasificar un documento con una sola palabra
consulta, Google mira a la lista negra de ese documento para esa palabra.
Google considera cada golpe al ser uno de varios tipos diferentes (ttulo, ancla, URL,
texto plano fuente grande,
texto sin formato de fuente pequeo, ...), cada uno de los cuales tiene su propio tipo de
peso. El tipo-pesos componen un vector
indexadas por tipo. Google cuenta el nmero de visitas de cada tipo en la lista de
resultados. A continuacin, cada cuenta es
convertido en un recuento de peso. Count-pesos aumentan linealmente con recuentos al
principio, pero rpidamente disminuir
de manera que ms de un cierto nmero de no ayudar. Tomamos el producto escalar del
vector de recuento de pesos
con el vector de tipo-pesos para calcular una puntuacin de IR para el documento. Por
ltimo, la puntuacin es de IR
combinado con PageRank para dar un rango final al documento.
Para realizar una bsqueda de varias palabras, la situacin es ms complicada. Ahora
mltiples listas de resultados deben ser escaneados
a travs de una sola vez para que golpea ocurren juntos en un documento son ponderados
superiores a golpes
que ocurre muy separados. Los xitos de las mltiples listas de resultados se corresponden
de manera que se hacen coincidir xitos cercanas
juntos. Para cada conjunto combinado de xitos, una proximidad se calcula. La
proximidad se basa en qu tan lejos
Aparte de los xitos estn en el documento (o ancla), pero se clasifica en 10
"contenedores" diferentes valores que van desde
un partido de la frase a "ni de lejos". Los recuentos se calculan no slo para cada tipo de
golpe, sino para todos los tipos
y la proximidad. Cada tipo y la proximidad par tiene una prox-peso tipo. Los recuentos
se convierten en
Contamos-pesos y tomamos el producto escalar de los recuentos de pesos y los pesos-
PROX-tipo para calcular
una puntuacin de IR. Todos estos nmeros y matrices posible que todos aparezcan los
resultados de bsqueda utilizando una
el modo de depuracin especial. Estas pantallas han sido muy tiles en el desarrollo del
sistema de clasificacin.
4.5.2 Evaluacin
La funcin de clasificacin tiene muchos parmetros como el tipo-pesos y los-PROX-
pesos de tipo. averiguar
los valores correctos de estos parmetros es algo de un arte negro. Con el fin de hacer
esto, tenemos un usuario
mecanismo de retroalimentacin en el motor de bsqueda. Un usuario de confianza puede
evaluar opcionalmente todos los resultados que
son devueltos. Esta retroalimentacin se guarda. Luego, cuando modificamos la funcin
de clasificacin, podemos ver el impacto
de este cambio en todas las bsquedas anteriores que fueron clasificados. Aunque lejos
de ser perfecto, esto nos da una cierta
1. analizar la consulta.
2. Convertir las palabras en wordIDs.
3. Se desplaza hasta el inicio de la Lista de documentos de de
el can corto para cada palabra.
4. Scan a travs de los doclists hasta
hay un documento que coincida
todos los trminos de bsqueda.
5. Calcular el rango de ese
documento para la consulta.
6. Si estamos en los caones cortos y por lo
al final de cualquier Lista de documentos de, buscar la
comenzar de la Lista de documentos de en el barril lleno
por cada palabra y vaya al paso 4.
7. Si no estamos al final de cualquier
Lista de documentos de ir al paso 4.
Clasificar los documentos que tienen
emparejado por rango y devolver la parte superior
k.
Figura 4. Evaluacin de consulta Google
Pgina 13

idea de cmo un cambio en la funcin de clasificacin afecta a los resultados de bsqueda.

5 Resultados y Rendimiento
La medida ms importante de una bsqueda
motor es la calidad de sus resultados de bsqueda.
Mientras que una evaluacin completa de usuario es
ms all del alcance de este trabajo, nuestra propia
experiencia con Google ha demostrado que es
producir mejores resultados que la mayor
motores de bsqueda comerciales para la mayora
bsquedas. Como un ejemplo que ilustra
el uso de PageRank, el ancla de texto, y
proximidad, la figura 4 muestra Google de
resultados de una bsqueda en "bill clinton".
Estos resultados demuestran algunos de
caractersticas de Google. Los resultados son
agrupados por el servidor. Esto ayuda
considerablemente cuando tamizado a travs de resultado
conjuntos. Un nmero de resultados son de la
whitehouse.gov de dominio que es lo
uno puede esperar razonablemente como una
buscar. Actualmente, comercial ms importante
motores de bsqueda no arroj ningn resultado
de whitehouse.gov, y mucho menos la derecha
otros. Observe que no hay ttulo para el
primer resultado. Esto se debe a que no era
rastreado. En su lugar, Google se bas en el ancla
texto para determinar esto era una buena respuesta
a la consulta. Del mismo modo, el resultado es el quinto
una direccin de correo electrnico que, por supuesto, no es
rastreable. Tambin es el resultado de texto de anclaje.
Todos los resultados son razonablemente alto
pginas de calidad y, en ltima comprobacin, ninguno
eran enlaces rotos. Esto es as porque
todos ellos tienen alto PageRank. los
PageRanks son los porcentajes en rojo
junto con grficos de barras. Por ltimo, no hay resultados sobre un proyecto de ley que
no sean Clinton o sobre un Clinton
aparte de Bill. Esto se debe a que ponemos pesados importancia de la proximidad de las
apariciones de palabras. De
Por supuesto una verdadera prueba de la calidad de un motor de bsqueda implicara un
extenso estudio usuario o resultados
anlisis que no tenemos espacio para aqu. En lugar de ello, invitamos al lector a probar
Google por s mismos
en http://google.stanford.edu.
5.1 Requisitos de almacenamiento
Pregunta: bill clinton
http://www.whitehouse.gov/
100,00%
(Sin fecha) (0K)
http://www.whitehouse.gov/
La oficina del presidente
99,67%
(Diciembre 23 de 1996) (2K)
http://www.whitehouse.gov/WH/EOP/OP/html/OP_Home.html
Bienvenido a la Casa Blanca
99,98%
(Noviembre 09, 1997) (5K)
http://www.whitehouse.gov/WH/Welcome.html
Escribir mensaje de correo electrnico al Presidente
99,86%
(Jul 14 1997) (5K)
http://www.whitehouse.gov/WH/Mail/html/Mail_President.html
mailto: president@whitehouse.gov
99,98%
mailto: President@whitehouse.gov
99.27%
El "no oficial" Bill Clinton
94.06%
(Noviembre 11, 1997) (14K)
http://zpub.com/un/un-bc.html
Bill Clinton se rene los psi
86.27%
(Jun 29 1997) (63K)
http://zpub.com/un/un-bc9.html
Presidente Bill Clinton - The Dark Side
97.27%
(Nov 10 1997) (15K)
http://www.realchange.org/clinton.htm
$ 3 Bill Clinton
94.73%
(Sin fecha) (4K)
http://www.gatewy.net/~tjohnson/clinton1.html
Figura 4. Ejemplos de Resultados de Google

Pgina 14

Aparte de la calidad de bsqueda, Google est diseado para escalar de forma rentable
con el tamao de la web, ya que
crece. Un aspecto de esto es utilizar el almacenamiento de manera eficiente. La Tabla 1
presenta un desglose de algunas estadsticas y
los requisitos de almacenamiento de Google. Debido a la compresin del tamao total del
depsito es de aproximadamente 53 GB, simplemente
ms de un tercio del total de la almacena datos. A los precios actuales de disco esto hace
que el depsito de un tiempo relativamente
fuente barata de datos tiles. Ms importante an, el total de todos los datos que utiliza el
motor de bsqueda requiere
una cantidad comparable de almacenamiento, alrededor de 55 GB. Por otra parte, la
mayora de las preguntas pueden ser contestadas utilizando slo el
ndice invertido corto. Con una mejor codificacin y compresin del ndice de
documentos, una tela de alta calidad
motor de bsqueda puede caber en una unidad de 7 GB de un nuevo PC.
Rendimiento 5.2 Sistema
Es importante para un motor de bsqueda para rastrear e indexar
eficientemente. Esta informacin forma se puede mantener hasta la fecha y
cambios importantes en el sistema pueden probarse con relativa rapidez.
Para Google, los grandes trabajos de rastreo, la indexacin,
y la clasificacin. Es difcil medir el tiempo de rastreo
tom global porque los discos se llenaron, los servidores de nombres chocaron,
o cualquier nmero de otros problemas que detuvo el sistema.
En total se tom aproximadamente 9 das para descargar los 26 millones
pginas (incluidos los errores). Sin embargo, una vez que el sistema era
funcionando sin problemas, que corri mucho ms rpido, la descarga de la ltima
11 millones de pginas en tan slo 63 horas, con un promedio de poco ms de 4
milln de pginas por da o 48,5 pginas por segundo. Nos encontramos con la
indexador y el rastreador simultneamente. El indexador corri solo
ms rpido que los rastreadores. Esto es en gran parte porque pasamos justo
tiempo suficiente optimizar el indexador de modo que no sera una
embotellamiento. Estas optimizaciones incluyen actualizaciones masivas a la
ndice de documento y la colocacin de estructuras de datos crticos en
el disco local. El indexador funciona a aproximadamente 54 pginas por
segundo. Los clasificadores pueden ejecutarse completamente en paralelo; utilizando
cuatro mquinas, todo el proceso de clasificacin toma alrededor de 24
horas.
Rendimiento 5.3 Buscar
Mejorar el rendimiento de la bsqueda no era el principal objetivo de nuestra
investigacin hasta este punto. los
versin actual de Google responde a la mayora de las consultas de entre 1 y 10
segundos. Esta vez es en su mayora
dominado por S de disco a travs de NFS (ya que los discos se extienden por un nmero
de mquinas). Adems,
Google no tiene ningn optimizaciones tales como el almacenamiento en cach de
consultas, subndices en trminos comunes, y otra
optimizaciones comunes. Tenemos la intencin de acelerar considerablemente Google a
travs de la distribucin y el hardware,
software y mejoras algortmicas. Nuestro objetivo es ser capaz de manejar varios cientos
de consultas por
segundo. Tabla 2 tiene algunos tiempos de consulta de la muestra a partir de la versin
actual de Google. Se repiten a
mostrar las aceleraciones resultantes de IO en cach.
Estadsticas de almacenamiento
Tamao total de 147,8 GB descabellada Pginas
Repositorio comprimido
53.5 GB
ndice invertida corta
4,1 GB
ndice de Inversin total
37.2 GB
Lxico
293 MB
Datos de anclaje temporal
(No en total)
6,6 GB
ndice de documentos Incl.
Ancho de datos variables
9,7 GB
enlaces Base de Datos
3.9 GB
Total sin Repositorio de 55.2 GB
Total con Repositorio 108,7 GB
Pgina Web Estadsticas
Nmero de pginas Web
descabellada
24 millones
Visto nmero de URLs
76,5 millones
Nmero de correo electrnico
direcciones
1,7 millones
Nmero de de 404
1.6 millones
Tabla 1. Estadsticas

Pgina 15

6. Conclusiones
Google est diseado para ser un motor de bsqueda escalable.
El objetivo principal es proporcionar alta calidad de bsqueda
Resultados Durante un mundo en rpido crecimiento Wide Web.
Google emplea una serie de tcnicas para mejorar
incluyendo la calidad de bsqueda fila de la pgina, el texto de anclaje, y
informacin de proximidad. Por otra parte, Google es una
arquitectura completa para la recopilacin de pginas web,
indexacin de ellos, y la realizacin de consultas de bsqueda ms
ellos.
6.1 Trabajo Futuro
Un motor de bsqueda web a gran escala es un sistema complejo y queda mucho por
hacer. nuestro inmediata
objetivos son mejorar la eficiencia de bsqueda y escalar a aproximadamente 100
millones de pginas web. Algunos
simples mejoras en la eficiencia incluyen el almacenamiento en cach de consultas,
asignacin de disco inteligente y subndices.
Otra rea que requiere mucha investigacin es actualizaciones. Debemos tener algoritmos
inteligentes para decidir qu
pginas web de edad deben volver a rastrear y qu otros nuevos deben ser
rastreadas. Trabajar hacia este objetivo tiene
ha hecho en [Cho 98]. Un rea prometedora de la investigacin est utilizando cachs de
proxy para construir las bases de datos de bsqueda,
ya que son impulsado la demanda. Estamos planeando aadir caractersticas simples con
el apoyo de bsqueda comercial
los motores como los operadores booleanos, negacin, y frenar. Sin embargo, otras
caractersticas estn empezando a ser
explorado tales como la pertinencia de retroalimentacin y la agrupacin (Google es
compatible actualmente con un nombre de host simple basado
clustering). Tambin tenemos la intencin de apoyar el contexto del usuario (como la
ubicacin del usuario), y resumen de resultados. Nosotros
Tambin estamos trabajando para extender el uso de la estructura de enlaces y enlaces de
texto. sencillos experimentos indican PageRank
se puede personalizar mediante el aumento del peso de la pgina de inicio del usuario o
marcadores. En cuanto a los enlaces de texto, nos
estn experimentando con el uso de texto enlaces, adems de la propia texto del enlace
circundante. Una bsqueda en la Web
el motor es un entorno muy rico para las ideas de investigacin. Tenemos demasiados
para enumerar aqu, as que no lo hacemos
esperamos que esta seccin de trabajo futuro para convertirse en mucho ms corto en un
futuro prximo.
6.2 Bsqueda de alta calidad
El mayor problema que enfrentan los usuarios de los buscadores web hoy en da es la
calidad de los resultados que obtienen espalda.
Si bien los resultados son a menudo divertido y se expanden los horizontes de los
usuarios, que a menudo son frustrantes y consumen
tiempo precioso. Por ejemplo, el primer resultado de una bsqueda de "Bill Clinton" en
uno de los ms populares
Los motores de bsqueda comerciales fue el Bill Clinton Broma del Da: 14 de abril de
1997. Google est diseado para
proporcionar la bsqueda de mayor calidad as como la Web contina creciendo
rpidamente, la informacin se puede encontrar fcilmente.
Con el fin de lograr esto Google hace un uso intensivo de la informacin hipertextual que
consiste en enlace
estructura y el texto del enlace (ancla). Google tambin utiliza la proximidad y la fuente
de informacin. Mientras que la evaluacin de un
motor de bsqueda es difcil, hemos encontrado que subjetivamente Google devuelve
resultados de bsqueda de mayor calidad
que los motores de bsqueda comerciales actuales. El anlisis de la estructura de enlaces
a travs de PageRank permite a Google
Evaluar la calidad de las pginas web. El uso de enlaces de texto como una descripcin
de qu puntos del enlace de ayuda a
el retorno del motor de bsqueda relevantes (y hasta cierto punto de alta calidad)
resultados. Por ltimo, el uso de la proximidad
informacin ayuda a aumentar la relevancia de un gran negocio para muchas consultas.
consulta inicial
misma consulta
Repetida (IO
sobre todo en cach)
Consulta
UPC
Veces)
Total
Veces)
UPC
Veces)
Total
Veces)
al gore
0,09
2.13
0,06
0,06
vicio
presidente
1,77
3,84
1,66
1,80
difcil
discos
0,25
4,86
0,20
0,24
buscar
motores
1,31
9,63
1,16
1,16
Tabla 2. Los tiempos de bsqueda

Pgina 16

6.3 Arquitectura escalable

Aparte de la calidad de la bsqueda, Google est diseado para escalar. Debe ser eficiente
en espacio y tiempo,
y los factores constantes son muy importantes cuando se trata de toda la Web. En la
aplicacin de Google,
han visto los cuellos de botella en la CPU, acceso a la memoria, la capacidad de memoria,
disco busca, el rendimiento del disco, disco
la capacidad y la red de IO. Google ha evolucionado para superar una serie de estos
cuellos de botella durante
diversas operaciones. principales estructuras de datos de Google hacen uso eficiente del
espacio de almacenamiento disponible.
Por otra parte, el rastreo, indexacin y operaciones de clasificacin son lo suficientemente
eficientes para ser capaces de construir una
ndice de una parte sustancial de la web - 24 millones de pginas, en menos de una
semana. Esperamos ser capaces
para construir un ndice de 100 millones de pginas en menos de un mes.
6.4 Una herramienta de investigacin
Adems de ser un motor de bsqueda de alta calidad, Google es una herramienta de
investigacin. Los datos de Google tiene
recogido ya ha dado lugar a muchos otros documentos presentados en conferencias y
muchos ms en el
camino. La investigacin reciente, tal como [Abiteboul 97] ha demostrado una serie de
limitaciones a las preguntas sobre el
Web que puede ser respondida sin tener la web disponibles a nivel local. Esto significa
que Google (o una
sistema similar) no slo es una valiosa herramienta de investigacin pero necesaria para
una amplia gama de aplicaciones.
Esperamos que Google va a ser un recurso para los investigadores e investigadores de
todo el mundo y provocar la
prxima generacin de tecnologa de los motores de bsqueda.
7 Agradecimientos
Scott Hassan y Alan Steremberg han sido fundamentales para el desarrollo de Google. su
talento
contribuciones son insustituibles, y los autores les deben mucho
agradecimiento. Tambin nos gustara dar las gracias
Hctor Garca Molina, Rajeev Motwani, Jeff Ullman, y Terry Winograd y todo el
WebBase
grupo por su apoyo y discusiones interesantes. Finalmente, nos gustara reconocer el
generoso
apoyo de nuestros donantes de equipos IBM, Intel y Sun y nuestros proveedores de
fondos. La investigacin descrita aqu fue
llevado a cabo como parte del Proyecto Integrado de Stanford Digital Library, apoyada
por el Consejo Nacional de Ciencia
Fundacin bajo el Acuerdo de Cooperacin IRI-9411306. Los fondos para este acuerdo
de cooperacin es tambin
proporcionado por DARPA y la NASA, y por Interval Research, y los socios industriales
del Stanford
Proyecto de Bibliotecas Digitales.
Referencias
Mejor de la Web 1994 - Navegantes http://botw.org/1994/awards/navigators.html
Bill Clinton Broma del Da: 14 de abril de 1997.
http://www.io.com/~cjburke/clinton/970414.html.
Bzip2 Pgina http://www.muraroa.demon.co.uk/
Google motor de bsqueda http://google.stanford.edu/
cosecha http://harvest.transarc.com/
Mauldin, Michael L. Lycos Diseo opciones en un Servicio de Bsqueda en Internet,
IEEE Entrevista Experto
http://www.computer.org/pubs/expert/1997/trends/x1008/mauldin.htm
El efecto de Telfono Celular uso a la atencin del conductor
http://www.webfirst.com/aaa/text/cell/cell0toc.htm
Search Engine Watch http://www.searchenginewatch.com/
RFC 1950 (zlib) ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html
Los robots Protocolo de Exclusin:
http://info.webcrawler.com/mak/projects/robots/exclusion.htm

Pgina 17

Crecimiento Web Resumen: http://www.mit.edu/people/mkgray/net/web-growth-

summary.html
Yahoo! http://www.yahoo.com/
[Abiteboul 97] Serge Abiteboul y Victor Vianu, consultas y Computacin en la Web .
Actas de la Conferencia Internacional sobre Teora de la base de datos. Delphi, Grecia
1997.
[Bagdikian 97] Ben H. Bagdikian. El monopolio de los medios . 5 Edicin. Editorial:
Beacon, ISBN:
0807061557
[Cho 98] Junghoo Cho, Hctor Garca Molina, Lawrence Page. Rastreo eficiente a travs
de la URL
Pedido. Sptima Conferencia Internacional Web (WWW 98). Brisbane, Australia, Abril
14-18,
1998.
[Gravano 94] Luis Gravano, Hctor Garca Molina, y A. Tomasic. La eficacia de brillo
para el problema de deteccin de texto-base de datos. Proc. 1994 de la ACM SIGMOD
Internacional
Conferencia sobre la gestin de los datos de 1994.
[Kleinberg 98] Jon Kleinberg, autorizadas Fuentes en un entorno de Hyperlinked , Proc.
ACM-SIAM Simposio sobre discreto Algoritmos de 1998.
[Marchiori 97] Massimo Marchiori. La bsqueda de la informacin correcta en la Web:
Hyper Buscar
Motores. La Sexta Conferencia Internacional WWW (WWW 97). Santa Clara, EE.UU.,
Abril 7-11,
1997.
[McBryan 94] Oliver A. McBryan. GENVL y WWWW: Herramientas para la doma de
la Web. primero
Conferencia Internacional de la World Wide Web. CERN, Ginebra (Suiza), mayo 25-26-
27
1994. http://www.cs.colorado.edu/home/mcbryan/mypapers/www94.ps
[Pgina 98] Lawrence Page, Sergey Brin, Rajeev Motwani, Terry Winograd. El
PageRank Cita
Clasificacin: poner orden en la Web. Manuscrito en curso.
http://google.stanford.edu/~backrub/pageranksub.ps
[Pinkerton 94] Brian Pinkerton, encontrar lo que se quiere: Las experiencias con el
Webcrawler.
La Segunda Internacional WWW Conferencia de Chicago, EE.UU., 17-20 de de octubre
de., 1994
http://info.webcrawler.com/bp/WWW94.html
[Spertus 97] Ellen Spertus. Parsito: Minera de informacin estructural en la Web. El
sexto
Conferencia Internacional WWW (WWW 97). Santa Clara, EE.UU., 7-11 de abril 1997.
[TREC 96] Actas de la quinta texto de la Conferencia de retirada (TREC-
5). Gaithersburg, Maryland,
De noviembre de 20-22, 1996. Editorial: Departamento de Comercio, Instituto Nacional
de Estndares y
Tecnologa. Editores: DK Harman y EM Voorhees. texto completo en:
http://trec.nist.gov/
[Witten 94] Ian H Witten, Alistair Moffat, y Timothy C. Bell. Managing Gigabytes:
La compresin y la indexacin de documentos e imgenes. Nueva York: Van Nostrand
Reinhold, 1994.
[Weiss 96] Ron Weiss, Bienvenido Velez, Mark A. Sheldon, Chanathip Manprempre,
Peter
Szilagyi, Andrzej Duda, y David K. Gifford. HyPursuit: Una red jerrquica motor de
bsqueda
que explota contenido-Enlace de hipertexto La agrupacin. Actas de la 7 Conferencia
ACM sobre
Hipertexto. Nueva York, 1996.
vitae

Pgina 18

Sergey Brin recibi su licenciatura en matemticas y ciencias de la computacin

de la Universidad de Maryland en College Park, en 1993. Actualmente, es una
Doctor en Filosofa. candidato en ciencias de la computacin en la Universidad de
Stanford, donde recibi
su MS en 1995. l es un receptor de una Fundacin Nacional de Ciencia de Graduados
Compaerismo. Sus intereses de investigacin incluyen los motores de bsqueda, la
informacin
extraccin de fuentes no estructuradas, y minera de datos de grandes colecciones de
textos
y datos cientficos.
Lawrence Page naci en East Lansing, Michigan, y recibi una EEB
en Ingeniera Informtica de la Universidad de Michigan, Ann Arbor en 1995.
En la actualidad es un Ph.D. candidato en Ciencias de la Computacin de la Universidad
de Stanford.
Algunos de sus intereses de investigacin incluyen la estructura de enlaces de la web,
humana
interaccin con el ordenador, motores de bsqueda, la escalabilidad de acceso a la
informacin
interfaces y datos personales minera.
8 Apndice A: Publicidad y motivos mezclados
Actualmente, el modelo de negocio predominante para los motores de bsqueda
comerciales es la publicidad. Los objetivos de
el modelo de negocio de la publicidad no siempre corresponden a proporcionar a los
usuarios la bsqueda de la calidad. por
ejemplo, en nuestro motor de bsqueda prototipo de uno de los mejores resultados para
el telfono celular es "El efecto de
Telfono celular de su uso a la atencin del conductor", un estudio que explica en gran
detalle las distracciones y
el riesgo asociado con la conversacin en un telfono celular mientras se conduce. Este
resultado de la bsqueda se acerc en primer lugar porque
de su gran importancia como se juzga por el algoritmo PageRank, una aproximacin de
importancia citacin en
la web [Pgina 98]. Est claro que un motor de bsqueda que se llevaba dinero para
muestra el telfono celular
anuncios tendran dificultades para justificar la pgina que nuestro sistema volvi a sus
anunciantes pagan. Para esto
Tipo de la razn y la experiencia histrica con otros medios de comunicacin [83]
Bagdikian, esperamos que la publicidad
motores de bsqueda sern financiados inherentemente sesgados hacia los anunciantes y
lejos de las necesidades de la
consumidores.
Dado que es muy difcil incluso para los expertos para evaluar los motores de bsqueda,
el sesgo de motor de bsqueda es especialmente
insidioso. Un buen ejemplo fue OpenText, que fue informado de que la venta de las
empresas el derecho de estar
que aparece en la parte superior de los resultados de bsqueda para determinadas
consultas [97] Marchiori. Este tipo de sesgo es mucho
ms insidiosa que la publicidad, ya que no est claro que "merece" estar all, y que est
dispuesto a
pagar dinero para ser enumeradas. Este modelo de negocio se tradujo en un alboroto, y
OpenText ha dejado de ser una
motor de bsqueda viable. Pero sesgo menos flagrante son susceptibles de ser tolerado
por el mercado. Por ejemplo, una bsqueda
motor podra aadir un pequeo factor de resultados procedentes de sociedades
"amistosos" buscar, y restar un factor de
Los resultados de los competidores. Este tipo de sesgo es muy difcil de detectar, pero
todava podra tener un efecto significativo
efecto en el mercado. Por otra parte, los ingresos por publicidad a menudo proporciona
un incentivo para proporcionar pobres
Pgina 19

resultados de la bsqueda de la calidad. Por ejemplo, nos dimos cuenta de un motor de

bsqueda ms importantes no volvera un gran de la aerolnea
pgina de inicio cuando el nombre de la compaa area se dio como una consulta. Dio
la casualidad de que la aerolnea haba colocado una
ad caro, vinculado a la consulta que era su nombre. Una mejor motor de bsqueda no
habra requerido este
anuncio, y posiblemente como resultado la prdida de los ingresos de la compaa area
para el motor de bsqueda. En general,
Podra argumentarse desde el punto de vista del consumidor que el mejor es el motor de
bsqueda es, al menos
sern necesarios anuncios para el consumidor para encontrar lo que quieren. Por supuesto,
esto erosiona la
la publicidad apoyada modelo de negocio de los motores de bsqueda existentes. Sin
embargo, siempre habr
dinero de los anunciantes que desean un cliente para cambiar productos, o tiene algo que
es genuinamente
nuevo. Sin embargo, creemos que la cuestin de la publicidad hace que los incentivos
suficientes mixtos que es crucial tener una
motor de bsqueda competitivo que es transparente y en el mbito acadmico.
9 Apndice B: Escalabilidad
9. 1 escalabilidad de Google
Hemos diseado Google para ser escalable en el corto plazo a una meta de 100 millones
de pginas web. Tenemos
acaba de recibir el disco y mquinas para manejar ms o menos de esa cantidad. Todo el
tiempo que consumen partes del
sistema se paralelizar y hora ms o menos lineal. Estos incluyen cosas como los
rastreadores, los indexadores, y
clasificadores. Tambin creemos que la mayora de las estructuras de datos se ocupar
con gracia con la expansin. Sin embargo,
en 100 millones de pginas web que estaremos muy cerca contra todo tipo de lmites del
sistema operativo en el
sistemas operativos comunes (actualmente se ejecutan en Solaris y Linux). Estos incluyen
cosas como
memoria direccionable, el nmero de descriptores de archivos abiertos, conexiones de red
y ancho de banda, y muchos otros.
Creemos que la ampliacin a mucho ms de 100 millones de pginas aumentaran en gran
medida la complejidad de nuestro
sistema.
9.2 Escalabilidad de arquitecturas centralizadas de indexacin
A medida que las capacidades de las computadoras aumentan, se hace posible indexar
una cantidad muy grande de texto para una
costo razonable. Por supuesto, otros medios ms ancho de banda intensivo, como el vdeo
es probable que se convierta
ms penetrante. Pero, debido a que el costo de produccin del texto es bajo comparado
con los medios de comunicacin como el vdeo, texto es
probable que siga siendo muy generalizado. Adems, es probable que pronto vamos a
tener reconocimiento de voz que hace una
trabajo razonable convertir la voz en texto, ampliando la cantidad de texto
disponible. Todo esto proporciona
posibilidades asombrosas para la indexacin centralizada. Aqu es un ejemplo
ilustrativo. Suponemos que queremos
ndice todo todo el mundo en los EE.UU. ha escrito durante un ao. Suponemos que hay
250 millones de personas
en los EE.UU. y escriben un promedio de 10k por da. Eso equivale a ser de unos 850
terabytes. tambin
asumir que la indexacin de un terabyte puede hacerse ahora por un costo
razonable. Tambin suponemos que la
mtodos de indexacin utilizados sobre el texto son lineales o casi lineales en su
complejidad. Teniendo en cuenta todos estos
supuestos que se pueden calcular cunto tiempo se tardara antes de que pudiramos
ndice de nuestros 850 terabytes para una
costo razonable asumir ciertos factores de crecimiento. La Ley de Moore se defini en
1965 como se duplica cada
18 meses en la potencia del procesador. Se ha celebrado notablemente cierto, no slo para
los procesadores, pero por otra
importantes parmetros del sistema, tales como el disco as. Si asumimos que la ley de
Moore se mantiene para el futuro,
slo necesitamos 10 ms duplicaciones, o 15 aos para alcanzar nuestro objetivo de
indexacin de todo a todos en el
Estados Unidos ha escrito durante un ao por un precio que una pequea empresa podra
permitirse. Por supuesto, los expertos estn de hardware
Ley de Moore algo preocupado no puede continuar manteniendo durante los prximos 15
aos, pero hay
sin duda una gran cantidad de interesantes aplicaciones centralizadas, incluso si slo
tenemos una parte del camino a nuestra
ejemplo hipottico.

Pgina 20

Por supuesto, un sistemas distribuidos como G l oss [Gravano 94] o de la cosecha a

menudo ser el ms eficiente y
solucin tcnica elegante para la indexacin, pero parece difcil convencer al mundo en
utilizar estos sistemas
debido a los altos costos de administracin de la creacin de un gran nmero de
instalaciones. Por supuesto que es
bastante probable que la reduccin del costo de administracin drsticamente es
posible. Si eso sucede, y todo el mundo
se pone en marcha un sistema de indexacin distribuida, la bsqueda ciertamente
mejorara drsticamente.
Debido a que los seres humanos slo pueden escribir o hablar una cantidad finita, y como
computadoras seguir mejorando, texto
indexacin escalar an mejor que lo hace ahora. Por supuesto que podra haber una
cantidad infinita de la mquina
contenido generado, pero slo la indexacin de grandes cantidades de contenido generado
por el ser humano parece tremendamente
til. As que somos optimistas de que nuestra arquitectura de motor de bsqueda web
centralizado mejorar en su
capacidad para cubrir la informacin de texto pertinente en el tiempo y que hay un futuro
brillante para la bsqueda