La anatoma de una Bsqueda

Hipertextual Web Motor Scale-Large

Sergey Brin y Lawrence Page
@cs.stanford.edu
Informtica Departamento de Ciencias de la Universidad de Stanford, Stanford, CA 94305

Abstracto
En este trabajo, presentamos Google, un prototipo de un motor de bsqueda a gran escala
que hace un uso intensivo de la estructura presente en el hipertexto. Google est diseado
para rastrear e indexar la Web de manera eficiente y producir resultados mucho ms
satisfactorios que los sistemas existentes. El prototipo con una base de datos de texto
completo y 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. Decenas Buscar ndice motores a
cientos de millones de pginas web que involucran 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 de la tecnologa y la proliferacin de
Internet, la creacin de un motor de bsqueda en la web hoy en da es muy diferente a la de
hace tres aos. Este documento ofrece una descripcin en profundidad de nuestro motor de
bsqueda en Internet a gran escala - la primera descripcin pblica detallada que
conocemos hasta la fecha.
Aparte de los problemas de la ampliacin de las tcnicas de bsqueda tradicionales a los
datos de esta magnitud, hay nuevos retos tcnicos involucrados con el uso de la
informacin adicional presente en el hipertexto para producir mejores resultados de
bsqueda. En este trabajo se aborda la cuestin de cmo construir un sistema prctico a
gran escala que puede explotar la informacin presente en el hipertexto. Tambin nos
fijamos en el problema de cmo tratar eficazmente con colecciones de hipertexto no
controlados donde cualquiera puede publicar lo que quieran.
Palabras clave: World Wide Web, motores de bsqueda, recuperacin de informacin,
PageRank, Google

1. Introduccin
(Nota: Hay dos versiones de este trabajo - una versin ms larga completa y una versin
ms corta impresa La versin completa est disponible en la web y el CD-ROM de la
conferencia..)
La web crea nuevos retos para la recuperacin de informacin. La cantidad de informacin
en la web est creciendo rpidamente, as como el nmero de nuevos usuarios sin
experiencia en el arte de la investigacin de la tela. Las personas tienden a navegar por la
web utilizando su grfica enlace, a menudo a partir de los ndices humanos mantenido alta
calidad tales como Yahoo! o con motores de bsqueda. Humano mantiene listas abarcan

temas populares con eficacia pero son subjetivas, caros de construir y mantener, lento para
mejorar, y no puede cubrir todos los temas esotricos. Buscadores automticos que
dependen de concordancia de palabras clave por lo general vuelven demasiados partidos de
baja calidad. Para empeorar las cosas, algunos anunciantes tratan de llamar la atencin de
las personas mediante la adopcin de medidas destinadas a engaar a los motores de
bsqueda automatizados. Hemos construido un motor de bsqueda a gran escala que aborda
muchos de los problemas de los sistemas existentes. Se hace uso especialmente intensivo de
la estructura adicional presente en el hipertexto para proporcionar resultados de bsqueda
mucho ms altos de calidad. Elegimos nuestro nombre del sistema, Google, ya que es una
ortografa comn de googol, o 10 100 y encaja bien con nuestra meta de construir motores de
bsqueda muy gran escala.

1.1 Web Motores de bsqueda - Scaling Up: 1994 - 2000

Tecnologa de los motores de bsqueda se ha tenido que reducir drsticamente para
mantenerse al da con el crecimiento de la web. En 1994, uno de los primeros motores de
bsqueda web, el gusano de la World Wide Web (WWWW) [McBryan 94] tenan un ndice
de 110.000 pginas web y documentos accesibles web. A partir de noviembre de 1997, los
principales motores de bsqueda afirman ndice de 2 millones (WebCrawler) a 100
millones de documentos web (de Search Engine Watch). Es previsible que en el ao 2000,
un ndice completo del Web contendr ms de mil millones de documentos. Al mismo
tiempo, el nmero de consultas de bsqueda motores de mango ha crecido increblemente
tambin. En marzo y abril de 1994, la World Wide Web Worm recibi un promedio de
alrededor de 1.500 consultas por da. En noviembre de 1997, Altavista afirm que maneja
aproximadamente 20 millones de consultas por da. Con el creciente nmero de usuarios en
la web, y los sistemas automatizados que consulta los motores de bsqueda, es probable
que los principales motores de bsqueda se encargar de cientos de millones de consultas
por da para el ao 2000. El objetivo de nuestro sistema es hacer frente a muchos de los
problemas, tanto en calidad y capacidad de ampliacin, present al escalar la tecnologa de
motores de bsqueda para un nmero tan extraordinarias.

1.2. Google: Escala con la Web

La creacin de un motor de bsqueda que escala hasta la web de hoy presenta muchos
desafos. Se necesita la tecnologa de rastreo rpido para reunir los documentos web y
mantenerlos actualizados. El espacio de almacenamiento debe ser utilizado de manera
eficiente 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 manejado de manera rpida, a una velocidad de cientos a miles por segundo.
Estas tareas se estn convirtiendo cada vez ms difcil a medida que crece la Web. Sin
embargo, el rendimiento del hardware y el coste han mejorado dramticamente para
compensar parcialmente la dificultad. Hay, sin embargo, varias excepciones notables a este
progreso, tales como buscar disco tiempo y la robustez del sistema operativo. En el diseo
de Google, se ha considerado tanto la tasa de crecimiento de la Web y los cambios
tecnolgicos. Google est diseado para escalar bien a conjuntos de datos extremadamente

grandes. Se hace un uso eficiente de espacio de almacenamiento para almacenar el ndice.

Sus estructuras de datos estn optimizados para un acceso rpido y eficiente (ver seccin
4.2). Adems, se espera que el costo para indexar y almacenar texto o HTML
eventualmente disminuir respecto a la cantidad que estar disponible (ver Apndice B).
Esto dar lugar a propiedades de escala favorables para sistemas centralizados como
Google.

1.3 Objetivos de diseo

1.3.1 Mejora de la Calidad de Bsqueda
Nuestro principal objetivo es mejorar la calidad de los motores de bsqueda web. En 1994,
algunas personas crean que un ndice de bsqueda completa hara posible encontrar
cualquier cosa con facilidad. De acuerdo con Best of the Web 1994 - Navegantes, "El mejor
servicio de navegacin debera hacer ms fcil para encontrar casi cualquier cosa en la web
(una vez se introduce todos los datos)." Sin embargo, la web de 1997 es muy diferente.
Cualquiera que haya usado un motor de bsqueda recientemente, puede testificar
fcilmente que la integridad del ndice no es el nico factor en la calidad de los resultados
de bsqueda. "Los resultados de basura" a menudo se lavan a cabo ningn resultado que un
usuario est interesado en. De hecho, a partir de noviembre de 1997, slo una de las cuatro
principales motores de bsqueda comerciales se encuentra (devuelve su propia pgina de
bsqueda en respuesta a su nombre en el top ten Resultados). Una de las principales causas
de este problema es que el nmero de documentos en los ndices ha ido en aumento en
muchos rdenes de magnitud, pero la capacidad del usuario para ver los documentos no
tiene. La gente todava slo est dispuesto a mirar las primeras decenas de resultados.
Debido a esto, ya que el tamao de la coleccin crece, necesitamos herramientas que tienen
muy alta precisin (nmero de documentos relevantes devueltos, decimos en las primeras
decenas de resultados). De hecho, queremos que nuestra nocin de "relevante" para incluir
slo los mejores documentos ya que puede haber decenas de miles de documentos poco
relevantes. Esta muy alta precisin es importante, incluso a expensas de la recuperacin (el
nmero total de documentos relevantes que el sistema es capaz de volver). Hay un poco de
reciente optimismo 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 [Pgina 98] y el texto del enlace proporcionan una gran
cantidad de informacin para hacer juicios de relevancia y filtrado de calidad. Google hace
uso tanto de la estructura de enlace y el texto de anclaje (ver secciones 2.1 y 2.2).
1.3.2 Acadmico Investigacin Search Engine
Aparte de un gran crecimiento, la Web tambin se ha convertido cada vez ms comercial
con el 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
emigrado desde el dominio acadmico al comercial. Hasta ahora la mayor parte del
desarrollo de motores de bsqueda se ha encendido en las empresas con poco publicacin
de detalles tcnicos. Esto hace que la tecnologa de motores de bsqueda para seguir siendo
en gran medida un arte negro y ser la publicidad orientada (ver Apndice A). Con Google,

tenemos un objetivo fuerte para empujar ms el desarrollo y la comprensin en el mbito

acadmico.
Otro de los objetivos de diseo importante era construir sistemas que un nmero razonable
de la gente puede utilizar realmente. Uso era importante para nosotros porque pensamos
que algunas de las investigaciones ms interesantes implicar aprovechar la gran cantidad
de datos de uso que est disponible en los sistemas modernos de Web. Por ejemplo, hay
muchas decenas de millones de bsquedas realizadas cada da. Sin embargo, es muy difcil
obtener estos datos, sobre todo porque se considera de gran valor comercial.
Nuestra meta diseo final fue la de construir una arquitectura que pueda apoyar las
actividades de investigacin novedosas en datos de la web a gran escala. Para apoyar a
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 la
creacin de un ambiente donde otros investigadores pueden venir en forma rpida, procesar
grandes trozos de la web, y producir resultados interesantes que habra sido muy difcil de
producir de otra manera. En el poco tiempo que el sistema ha estado haciendo, ya ha habido
varios trabajos utilizando las bases de datos generadas por Google, y muchos otros estn en
marcha. Otro de los objetivos que tenemos es la creacin de un entorno Spacelab-como
donde los investigadores o incluso los estudiantes pueden proponer y hacer experimentos
interesantes en nuestros datos de la web a gran escala.

2. Caractersticas del sistema

El motor de bsqueda Google tiene dos caractersticas importantes que le ayudan a producir
resultados de alta precisin. En primer lugar, se hace uso de la estructura de enlaces de la
web para calcular el ranking de cada pgina web de calidad. Esta clasificacin se llama
PageRank y se describe en detalle en [Pgina 98]. En segundo lugar, Google utiliza enlace
para mejorar los resultados de bsqueda.

2.1 PageRank: poner orden en la Web

La citacin (enlace) grfico de la web es un recurso importante que ha pasado gran parte no
utilizada en los motores de bsqueda web existentes. Hemos creado mapas que contienen
tantos como 518 millones de estos hipervnculos, una muestra significativa del total. Estos
mapas permiten un rpido clculo de de una pgina web "PageRank", una medida objetiva
de la importancia de la citacin que se corresponde bien con la idea subjetiva de la gente de
la importancia. Debido a esta correspondencia, PageRank es una excelente manera de dar
prioridad a los resultados de bsquedas de palabras clave web. Para temas ms populares,
una simple bsqueda en concordancia texto que se limita a la pgina web ttulos realiza
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 de Clculo PageRank

Literatura cita acadmica se ha aplicado a la web, en gran parte por contar las citas o los
vnculos de retroceso a una pgina determinada. Esto da una aproximacin de importancia
o calidad de una pgina. PageRank se extiende esta idea al 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 la pgina A tiene pginas T1 ... Tn que apuntan a ella (es decir, son las citas). El
parmetro d es un factor de amortiguacin que se puede establecer entre 0 y 1. Por lo
general, establecemos d a 0,85. Hay ms detalles acerca de d en la siguiente seccin.
Tambin C (A) se define como el nmero de enlaces que salen de la pgina A. El PageRank
de una pgina A se da como sigue:
PR (A) = (1-d) + d (PR (T1) / C (T1) + ... + PR (Tn) / C (Tn))
Tenga en cuenta que los PageRanks forman una distribucin de probabilidad sobre
pginas web, por lo que la suma de todas las pginas web PageRank 'ser uno.
PageRank o PR (A) se puede calcular utilizando un algoritmo iterativo simple, y
corresponde a el vector propio principal de la matriz de enlace normalizada de la web.
Adems, un PageRank de 26 millones de pginas web puede calcularse en unas pocas horas
en una estacin de trabajo de tamao medio. Hay muchos otros detalles que estn ms all
del alcance de este documento.
2.1.2 intuitiva Justificacin
PageRank se puede considerar como un modelo de comportamiento del usuario.
Suponemos que hay un "surfista aleatorio" que se le da una pgina web al azar y se
mantiene al hacer clic en los enlaces, no golpear "atrs", pero finalmente se aburre y
empieza en otra pgina al azar. La probabilidad de que el surfista aleatorio visita una pgina
es su PageRank. Y, el d factor de amortiguamiento es la probabilidad en cada pgina de la
"surfista aleatorio" se aburrir y solicite otra pgina al azar. Una variacin importante es
agregar slo el factor de amortiguamiento d para una sola pgina, o un grupo de pginas.
Esto permite la personalizacin y puede hacer que sea casi imposible de engaar
deliberadamente el sistema con el fin de conseguir una graduacin ms alta. Tenemos
varias otras extensiones al PageRank, de nuevo ver [Pgina 98].
Otra justificacin intuitiva es que una pgina puede tener un alto PageRank si hay muchas
pginas que apuntan a la misma, o si hay algunas pginas que apuntan a la misma y tener
un alto PageRank. Intuitivamente, las pginas que estn bien citan desde muchos lugares en
la web son vale la pena mirar. Adems, las pginas que tienen tal vez slo una cita de algo
as como el Yahoo! pgina de inicio son tambin generalmente vale la pena mirar. Si una
pgina no era de alta calidad, o era un vnculo roto, es muy probable que la pgina de inicio
de Yahoo no se unira a ella. PageRank maneja ambos casos y todo lo dems propagando
recursivamente pesos a travs de la estructura de enlaces de la web.

2.2 Anchor Text

El texto de los enlaces es tratado de una manera especial en nuestro motor de bsqueda. La
mayora de los motores de bsqueda asocian el texto de un enlace con la pgina que el
enlace est activado. Adems, lo asociamos con la pgina el enlace apunta. Esto tiene varias
ventajas. En primer lugar, las anclas a menudo proporcionan descripciones ms precisas de
las pginas web que los propios pginas. En segundo lugar, pueden existir anclajes para los
documentos que no pueden ser indexados por un motor de bsqueda basado en texto, como
imgenes, programas y bases de datos. Esto hace que sea posible para volver las pginas
web 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 comprueban para la validez antes de
ser devuelto al usuario. En este caso, el motor de bsqueda incluso puede devolver una
pgina que nunca ha existido en realidad, pero tena hipervnculos apuntando a la misma.
Sin embargo, es posible ordenar los resultados, por lo que este problema particular, rara vez
sucede.
Esta idea de propagar texto de anclaje a la pgina se refiere a se implement en el Worm
World Wide Web [McBryan 94] sobre todo porque ayuda a la bsqueda de informacin no
textual, y ampla la cobertura de bsqueda con un menor nmero de documentos
descargados. Utilizamos la propagacin de anclaje sobre todo porque el ancla de texto
puede ayudar a proporcionar mejores resultados de calidad. El uso de texto de anclaje es
eficiente tcnicamente difcil debido a las grandes cantidades de datos que deben ser
procesados. En nuestro rastreo actual de 24 millones de pginas, tuvimos ms de 259
millones de anclajes que hemos indexado.

2.3 Otras caractersticas

Aparte de PageRank y el uso de texto de anclaje, Google tiene varias otras caractersticas.
En primer lugar, se tiene informacin de la ubicacin de todos los xitos y por lo que hace
un uso extensivo de la proximidad en la bsqueda. En segundo lugar, Google realiza un
seguimiento de algunos detalles de la presentacin visual, como el tamao de fuente de las
palabras. Palabras en un tipo de letra ms grande o ms audaz se ponderan ms alto que
otras palabras. Tercer HTML puro, lleno de pginas est disponible en un repositorio.

3 Trabajo relacionado
Investigacin Bsqueda en la web tiene una historia breve y conciso. El gusano de la World
Wide Web (WWWW) [McBryan 94] fue uno de los primeros motores de bsqueda web.
Fue seguido posteriormente por otros buscadores acadmicos, muchos de los cuales son
ahora las empresas pblicas. En comparacin con el crecimiento de la Web y la importancia
de los motores de bsqueda, hay muy pocos documentos sobre los ltimos motores de
bsqueda [Pinkerton 94]. Segn Michael Mauldin (jefe cientfico, Lycos Inc) [Mauldin],
"los diferentes servicios (incluyendo Lycos) vigilan de cerca los detalles de estas bases de
datos". Sin embargo, ha habido una buena cantidad de trabajo en las caractersticas
especficas de los motores de bsqueda. Especialmente bien representado es un trabajo que
puede obtener resultados por el post-procesamiento de los resultados de los motores de
bsqueda comerciales existentes o producir pequeos motores de bsqueda escala
"individualizados". Por ltimo, ha habido un montn de investigacin en sistemas de

recuperacin de informacin, en especial sobre las colecciones bien controladas. En las

siguientes dos secciones, se discuten algunas reas en las que esta investigacin debe
ampliarse para trabajar mejor en la web.

3.1 Recuperacin de Informacin

El trabajo en los 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 pequeas colecciones homogneas bien
controlados, tales como colecciones de artculos cientficos o noticias sobre un tema
relacionado. De hecho, el punto de referencia principal para la recuperacin de la
informacin, el texto de recuperacin Conferencia [TREC 96], utiliza una coleccin
bastante pequeo y bien controlado por sus puntos de referencia. El punto de referencia
"Muy Grande Corpus" slo se compara con la de 20 GB 147 GB de nuestro rastreo de 24
millones de pginas web. Las cosas que funcionan bien en TREC menudo no producen
buenos resultados en la web. Por ejemplo, el modelo de espacio vectorial norma intenta
devolver el documento que ms se aproxima la consulta, dado que tanto la consulta y el
documento son vectores definidos por su ocurrencia palabra. En la web, esta estrategia a
menudo retorna documentos muy cortos que son la consulta adems de algunas palabras.
Por ejemplo, hemos visto un importante motor de bsqueda me devuelve 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 su consulta. No estamos de acuerdo con vehemencia con esta
posicin. Si un usuario enva una consulta como "Bill Clinton" que debe obtener resultados
razonables ya que hay una enorme cantidad de informacin de alta calidad disponibles en
este tema. Ejemplos dados como estos, que creen que el trabajo de recuperacin de
informacin estndar debe ampliarse para abordar con eficacia la web.

3.2 Diferencias entre la Web y Colecciones bien controlados

La web es una vasta coleccin de documentos heterogneos totalmente incontrolados.
Documentos en la web tienen extrema variacin interna de los documentos, y tambin en la
meta informacin externa que pueda estar disponible. Por ejemplo, los documentos difieren
internamente en su idioma (tanto humanos como de programacin), vocabulario
(direcciones de correo electrnico, enlaces, cdigos postales, nmeros de telfono, nmeros
de productos), forma o formato (texto, HTML, PDF, imgenes, sonidos), y puede incluso a
mquina generado (archivos o salida de una base de datos de registro). Por otro lado,
definimos meta informacin externa como informacin que se puede deducir sobre un
documento, pero no est contenido dentro de ella. Ejemplos de informacin externa meta
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 informacin externa meta
variaron, pero las cosas que se estn midiendo varan muchos rdenes de magnitud
tambin. Por ejemplo, comparar la informacin de uso de una pgina importante, al igual
que Yahoo de los que recibe actualmente a millones de pginas vistas cada da con un
artculo histrico oscura que podra recibir un punto de vista cada diez aos. Es evidente
que estos dos temas deben ser tratados de manera muy diferente por un motor de bsqueda.

Otra gran diferencia entre la web y colecciones bien controlados tradicionales es que no hay
prcticamente ningn control sobre lo que la gente puede poner en la web. Si unimos esto
flexibilidad para publicar cualquier cosa con la enorme influencia de los motores de
bsqueda para enrutar el trfico y las empresas que la manipulacin deliberada los motores
de bsqueda con fines de lucro convertido en un problema grave. Este problema que no ha
sido abordado en los sistemas de recuperacin de informacin cerrada tradicionales.
Adems, es interesante observar que los metadatos esfuerzos han fracasado en gran medida
con los motores de bsqueda web, ya que cualquier texto en la pgina que no est
directamente representado al usuario se abusa de manipular los motores de bsqueda.
Incluso hay numerosas empresas que se
especializan en la manipulacin de los
motores de bsqueda con fines de lucro.

Anatoma 4 Sistema
En primer lugar, vamos a ofrecer un debate
de alto nivel de la arquitectura. Entonces,
hay algunas descripciones en profundidad
de las estructuras de datos importantes. Por
ltimo, las principales aplicaciones: rastreo,
indexacin y bsqueda sern examinadas
en profundidad.

4.1 Google Arquitectura general

En esta seccin, vamos a dar una visin
general de alto nivel de cmo funciona todo
el sistema como se muestra en la Figura 1.
Figura 1. Arquitectura de Alto Nivel de Google
Otras secciones discutirn las aplicaciones
y estructuras de datos que no se mencionan en esta seccin. La mayor parte de Google se
implementa en C o C ++ para la eficiencia y puede ejecutarse en Solaris o Linux.
En Google, la web de rastreo (la descarga de pginas web) se lleva a cabo por varios
rastreadores distribuidos. Hay una URLserver que enva listas de URLs para ser exagerado
los rastreadores. Las pginas web que son descabellada se envan a la storeserver. El
storeserver luego comprime y almacena las pginas web en un repositorio. Cada pgina
web tiene un nmero de identificacin asociado llamado docID que se asigna cada vez que
una nueva URL se analiza de una pgina web. La funcin de indexacin se realiza por el
indexador y el clasificador. El indizador realiza una serie de funciones. Se lee el repositorio,
descomprime los documentos, y las analiza. Cada documento se convierte en un conjunto
de ocurrencias de palabras llamado hits. Los xitos grabar la palabra, la posicin en el
documento, una aproximacin del tamao de fuente, y la capitalizacin. El indexador
distribuye estos xitos en un conjunto de "barriles", la creacin de un ndice de avance
parcialmente ordenados. El indexador realiza otra funcin importante. Analiza todos los
enlaces en cada pgina web y almacenes de informacin importante acerca de ellos en un

archivo de anclajes. Este archivo contiene informacin suficiente para determinar donde
cada enlace apunta desde y hacia, y el texto del enlace.
El URLresolver lee el archivo de anclas y convierte las direcciones URL relativas en URLs
absolutas y a su vez en docIDs. Se pone el texto de anclaje en el ndice hacia adelante,
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 enlaces se utiliza para calcular
PageRanks para todos los documentos.
El clasificador toma los barriles, que se ordenan por docID (esto es una simplificacin,
vase la Seccin 4.2.5), y les recurre por wordID para generar el ndice invertido. Esto se
hace en lugar de modo que se necesita poco espacio temporal para esta operacin. El
clasificador tambin produce una lista de wordIDs 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 utilizado por el buscador. El buscador est
dirigido por un servidor web y utiliza el lxico construido por DumpLexicon junto con el
ndice invertido y los PageRanks para responder consultas.

4.2 Estructuras de datos Mayor

Estructuras de datos de Google estn optimizadas para que una coleccin de documentos de
gran tamao puede ser rastreado, indexados, y buscaron con poco costo. Aunque, CPUs y
las tasas de salida de entrada a granel han mejorado dramticamente en los ltimos aos, un
disco buscan an requiere unos 10 ms para completar. Google est diseada para evitar
bsquedas en disco siempre que sea posible, y esto ha tenido una influencia considerable en
el diseo de las estructuras de datos.
4.2.1 BigFiles
BigFiles son archivos virtuales que abarcan mltiples sistemas de archivos y son
direccionables por 64 bits enteros. El reparto entre los mltiples sistemas de archivos se
maneja automticamente. El paquete BigFiles tambin se encarga de la asignacin y
cancelacin de asignacin de descriptores de archivos, ya que los sistemas operativos no
proporcionan suficiente para nuestras necesidades. BigFiles tambin admite opciones de
compresin rudimentarias.
4.2.2 Repositorio
El repositorio contiene el HTML de cada
pgina web. Cada pgina se comprime usando
zlib (ver RFC1950). La eleccin de la tcnica
de compresin es un compromiso entre la
velocidad y la relacin de compresin.
Elegimos la velocidad de zlib sobre una
mejora significativa en la compresin ofrecida Figura 2. Estructura de datos del repositorio
por bzip. La tasa de compresin de bzip era

aproximadamente de 4 a 1 en el repositorio en comparacin con el 3 a 1 de compresin de

zlib. En el repositorio, los documentos se almacenan uno tras otro y estn prefijados por
docID, longitud y URL como puede verse en la Figura 2. El repositorio no requiere otras
estructuras de datos para ser utilizados con el fin de acceder a l. Esto ayuda a la
consistencia de los datos y hace el desarrollo mucho ms fcil; podemos reconstruir todas
las otras estructuras de datos de slo el repositorio y un archivo que lista los errores de
orugas.
4.2.3 ndice de documentos
El ndice de documento mantiene la informacin sobre cada documento. Es un ISAM ancho
fijo (modo de acceso secuencial Index) ndice, ordenado por docID. La informacin
almacenada en cada entrada incluye el estado actual del documento, un puntero en el
repositorio, una suma de comprobacin de documentos y diversas estadsticas. Si el
documento se ha rastreado, tambin contiene un puntero a un archivo de ancho variable
llamada DOCINFO que contiene su URL y el ttulo. De lo contrario, el puntero en la urllist
que contiene slo la URL. Esta decisin de diseo fue impulsado por el deseo de tener una
estructura de datos razonablemente compacto, y la posibilidad de buscar un registro en un
disco seek durante una bsqueda
Adems, hay un archivo que se utiliza para convertir las URL en docIDs. Es una lista de
sumas de comprobacin de URL con sus correspondientes docIDs y est ordenada por la
suma de comprobacin. Con el fin de encontrar el docID de un URL en particular, la suma
de comprobacin de la URL se calcula y una bsqueda binaria se realiza en el archivo de
sumas de comprobacin para encontrar su docID. URLs se pueden convertir en docIDs en
el lote haciendo una fusin con este archivo. Esta es la tcnica del URLresolver utiliza para
convertir las URL en docIDs. Este modo lote de actualizacin es crucial, ya que de lo
contrario hay que realizar un solo buscan por todos los eslabones que asumir un disco
tomara ms de un mes para nuestro conjunto de datos de 322 millones de enlace.
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 la memoria en una mquina con 256 MB de memoria
principal. El lxico actual contiene 14 millones de palabras (aunque algunas palabras raras
no se aadieron al lxico). Se lleva a cabo en dos partes - una lista de las palabras
(concatenados juntos pero separados por nulos) y una tabla hash de punteros. Para las
diversas funciones, la lista de las palabras tiene alguna informacin auxiliar que est ms
all del alcance de este documento para explicar plenamente.
4.2.5 Listas de ataque
Una lista de resultados corresponde a una lista de ocurrencias de una palabra en particular
en un documento particular, incluyendo la posicin, la fuente, y la informacin de la
capitalizacin. Hit listas representan la mayor parte del espacio utilizado tanto en el avance
y los ndices invertidos. Debido a esto, es importante que los represente tan eficientemente

como sea posible. Se consideraron varias alternativas para la posicin de codificacin, la

fuente, y la capitalizacin - codificacin simple (un triple de nmeros enteros), una
codificacin compacta (una asignacin optimizada mano de bits), y la codificacin de
Huffman. Al final se opt por una mano optimizado codificacin compacta ya que requiere
mucho menos espacio que la simple codificacin y mucho menos manipulacin de bits de
codificacin de Huffman. Los detalles de los accesos se muestran en la Figura 3.
Nuestra codificacin compacta utiliza dos bytes para cada golpe. Hay dos tipos de
resultados: xitos de lujo y xitos de civil. xitos de lujo incluyen xitos que ocurren en
una URL, ttulo, texto de anclaje o etiqueta meta. Accesos Plain incluyen todo lo dems. Un
golpe normal consiste en un poco de capitalizacin, tamao de fuente y 12 bits de posicin
de la palabra en un documento (todas las posiciones superiores a 4095 se etiquetan 4096).
Tamao de la fuente se representa en relacin con el resto del documento usando tres bits
(slo 7 valores se utilizan en realidad, porque 111 es la bandera que seala un golpe de
fantasa). Un golpe de lujo consta de un poco de capitalizacin, el tamao de fuente se
establece en 7 para indicar que es un golpe de lujo, 4 bits para codificar el tipo de golpe de
fantasa, y 8 bits de posicin. Para visitas de anclaje, los 8 bits de posicin se dividen en 4
bits para la posicin de anclaje y 4 bits para un hash de la docID el ancla se produce. Esto
nos da alguna frase limita la bsqueda, siempre y cuando no hay que muchos anclajes para
un palabra en particular. Esperamos
actualizar la forma en que los accesos de
anclaje se almacenan para permitir una
mayor resolucin en la posicin y campos
docIDhash. Utilizamos tamao de la fuente
en relacin con el resto del documento, ya
que en la bsqueda, usted no desea clasificar
los documentos por lo dems idnticas de
manera diferente slo porque uno de los
documentos est en un tipo de letra ms
grande.
La longitud de una lista de resultados se
almacena antes de los propios xitos. Para
ahorrar espacio, la longitud de la lista de
resultados se combina con la wordID en el
Figura 3. avance y retroceso ndices y el
ndice hacia adelante y el docID en el ndice
Lxico
invertido. Esto limita a 8 y 5 bits
respectivamente (hay algunos trucos que
permiten a 8 bits para ser prestados desde el wordID). Si la duracin es ms larga que
cabra en que muchos bits, se utiliza un cdigo de escape en esos bits, y los siguientes dos
bytes contienen la longitud real.
4.2.6 ndice Adelante
El ndice de avance es en realidad ya parcialmente ordenadas. Se almacena en un nmero
de barriles (utilizamos 64). Cada barril tiene una gama de wordID de. Si un documento
contiene palabras que caen dentro de un barril particular, la docID se registra en el barril,

seguido por una lista de de wordID con hitlists que corresponden a esas palabras. Este
esquema requiere un poco ms de almacenamiento debido a docIDs duplicados pero la
diferencia es muy pequea para un nmero razonable de cubos y ahorra considerable
tiempo y la complejidad de codificacin en la fase final de la indexacin realizada por el
clasificador. Por otra parte, en lugar de almacenar de wordID reales, almacenamos cada
wordID como una diferencia relativa del wordID mnimo que cae en el can del wordID
es. De esta manera, podemos utilizar slo 24 bits para los aos wordID en los barriles sin
ordenar, dejando 8 bits para la longitud lista de resultados.
4.2.7 ndice invertido
El ndice invertido se compone de las mismas barricas como el ndice hacia adelante,
excepto que han sido procesados por el clasificador. Por cada wordID vlida, el lxico
contiene un puntero en el barril que wordID cae en. Apunta a una doclist de docID de junto
con sus correspondientes listas de xitos. Este doclist representa todas las ocurrencias de
esa palabra en todos los documentos.
Una cuestin importante es en qu orden los docID de deben aparecer en el doclist. Una
solucin simple es almacenarlos ordenados por docID. Esto permite una rpida fusin de
diferentes doclists para varias consultas de palabras. Otra opcin es almacenarlos segn un
ranking de la aparicin de la palabra en cada documento. Esto hace que responder una
consulta de palabras triviales y hace probable que las respuestas a varias consultas de
palabras son cerca del inicio. Sin embargo, la fusin es mucho ms difcil. Adems, esto
hace que el desarrollo mucho ms difcil en que un cambio en la funcin de clasificacin
requiere una reconstruccin del ndice. Elegimos un compromiso entre estas opciones,
mantener dos conjuntos de barriles invertidas - un conjunto de listas de resultados que
incluyen xitos de ttulo o de anclaje y otro conjunto de todas las listas de xitos. De esta
manera, se comprueba la primera serie de barriles primero y si no hay suficientes resultados
dentro de esos barriles comprobamos los ms grandes.

4.3 Rastreo de la Web

Ejecucin de un rastreador web es una tarea difcil. Hay problemas de rendimiento y
fiabilidad difciles y an ms importante, hay cuestiones sociales. El gateo es la aplicacin
ms frgil, ya que implica la interaccin con cientos de miles de servidores web y varios
servidores de nombres que son todos ms all del control del sistema.
Con el fin de escalar a cientos de millones de pginas web, Google tiene un sistema de
rastreo distribuido rpido. Una sola URLserver sirve listas de direcciones URL a una serie
de rastreadores (que normalmente encontramos aproximadamente 3). Tanto el URLserver y
los rastreadores son implementados en Python. Cada rastreador mantiene aproximadamente
300 conexiones abiertas a la vez. Esto es necesario para recuperar pginas web a un ritmo
suficientemente rpido. A velocidades mximas, el sistema puede rastrear ms de 100
pginas web por segundo utilizando cuatro rastreadores. Esto equivale a aproximadamente
600K por segundo de datos. Un gran estrs rendimiento es bsqueda de DNS. Cada
rastreador mantiene una su propia cach de DNS para que no se tiene que hacer una

bsqueda de DNS antes de meterse cada documento. Cada uno de los cientos de conexiones
puede estar en un nmero de diferentes estados: mirando hacia arriba DNS, conectando con
el anfitrin, el envo de la solicitud, y la recepcin de la respuesta. Estos factores hacen que
el rastreador un componente complejo del sistema. Utiliza asncrono IO para gestionar
eventos, y un nmero de colas para pasar la pgina obtiene de estado a estado.
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 llamadas telefnicas. Debido a la gran cantidad de personas que vienen en la
lnea, siempre hay aquellos que no saben lo que es un rastreador es, porque este es el
primero que han visto. Casi a diario, recibimos un correo electrnico algo como, "Wow, te
veas a una gran cantidad de pginas de mi sitio web. Cmo te gusta?" Tambin hay
algunas personas que no conocen el protocolo de exclusin de robots, 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 indexados", que no hace falta decir que es difcil para los
rastreadores web entender. Tambin, debido a la enorme cantidad de datos involucrados,
cosas inesperadas sucedern. Por ejemplo, nuestro sistema intent arrastrarse un juego en
lnea. Esto dio lugar a un montn de mensajes de basura en el centro de su juego! Resulta
que este era un problema fcil de solucionar. Pero este problema no se haba acercado hasta
que habamos descargado decenas de millones de pginas. Debido a la inmensa variacin
en las pginas web y servidores, es prcticamente imposible probar un rastreador sin
ejecutar en gran parte de la Internet. Invariablemente, hay cientos de problemas oscuros que
slo pueden ocurrir en una pgina de toda la web y hacer que el rastreador se bloquee, o
peor, provocar un comportamiento impredecible o incorrecta. Los sistemas que acceden a
grandes partes de la Internet deben ser diseados para ser muy robusta y cuidadosamente
probado. Desde los grandes sistemas complejos como rastreadores invariablemente causar
problemas, es necesario que sean importantes recursos dedicados a la lectura del correo
electrnico y la solucin de estos problemas a medida que surgen.

4.4 Indexacin de la Web

De anlisis - Cualquier programa de anlisis que est diseado para ejecutarse en

toda la Web debe manejar una gran cantidad de errores posibles. Estos van desde
errores tipogrficos en las etiquetas HTML para kilobytes de ceros en el medio de
una etiqueta, los caracteres no ASCII, etiquetas HTML anidado cientos de
profundidad, y una gran variedad de otros errores que desafan la imaginacin de
nadie para llegar a los igualmente creativas. Para obtener la mxima velocidad, en
lugar de utilizar YACC para generar un analizador CFG, usamos flex para generar
un analizador lxico que atuendo con su propia pila. El desarrollo de este programa
de anlisis que funciona a una velocidad razonable y es muy robusto implic una
buena cantidad de trabajo.
Para poner un lmite en el tiempo de respuesta, una vez que un cierto nmero
(actualmente 40000) de los documentos se encuentran a juego, el buscador pasa
automticamente al paso 8 en la Figura 4. Esto significa que es posible que los
resultados subptimos seran devueltos. Actualmente estamos investigando otras

maneras de resolver este problema. En el pasado, nos lo solucionaron los accesos de

acuerdo con PageRank, que pareca mejorar la situacin.
4.5.1 El sistema de clasificacin
Google mantiene mucha ms informacin sobre los documentos web que los
motores de bsqueda tpicos. Cada lista negra incluye la posicin, la fuente, y la
informacin de la capitalizacin. Adems, tenemos en cuenta los xitos de texto de
anclaje y el PageRank del documento. La combinacin de toda esta informacin en
un rango es difcil. Hemos diseado nuestra funcin de clasificacin para que
ningn factor en particular puede tener demasiada influencia. En primer lugar,
consideremos el caso ms simple - una sola consulta de textos. Con el fin de
clasificar un documento con una sola consulta de textos, Google mira a la lista
negra de ese documento para esa palabra. Google considera que cada golpe sea uno
de varios tipos diferentes (ttulo, ancla, URL, llanura fuente grande de texto, sin
formato de fuente pequeo texto, ...), cada uno de los cuales tiene su propio peso
tipo. El tipo-pesos constituyen un vector indexado por tipo. Google cuenta el
nmero de accesos de cada tipo en la lista de resultados. Entonces, cada recuento se
convierte en un peso recuento. Conde-pesos aumentan linealmente con recuentos al
principio, pero rpidamente disminuir de manera que ms de un cierto conde no le
ayudar. Tomamos el producto escalar del vector de recuento-pesos con el vector de
tipo-pesos para calcular una puntuacin de IR para el documento. Por ltimo, la
puntuacin IR se combina con PageRank para dar un rango final al documento.
Para una bsqueda de varias palabras, la situacin es ms complicada. Ahora varias
listas de xitos deben ser escaneados a travs de una sola vez para que golpea
ocurren juntos en un documento se ponderan ms alto que golpea ocurren lejos. Los
xitos de las mltiples listas de resultados se corresponden de modo que los accesos
cercanos coinciden juntos. Para cada conjunto combinado de hits, una proximidad
se calcula. La proximidad se basa en lo lejos los xitos estn en el documento (o
ancla), pero se clasifica en 10 de valor "contenedores" diferentes que van desde una
concordancia de frase de "ni de lejos". Los recuentos se calculan no slo para cada
tipo de golpe, sino para todo tipo y de proximidad. Cada par de tipo y la proximidad
tiene una prox peso tipo. Los recuentos se convierten en conteo-pesos y nos toman
el producto escalar del Conde-pesos y el tipo-PROX-pesos para calcular una
puntuacin de IR. Todos estos nmeros y matrices posible que todos aparezcan con
los resultados de bsqueda utilizando un modo de depuracin especial. Estas
pantallas han sido de gran ayuda en el desarrollo del sistema de clasificacin.
4.5.2 Evaluacin
La funcin de la clasificacin tiene muchos parmetros como el tipo-pesos y el tipoPROX-pesos. Averiguar los valores correctos para estos parmetros es algo de un
arte negro. Para ello, contamos con un mecanismo de retroalimentacin de los
usuarios en el motor de bsqueda. Un usuario de confianza puede opcionalmente
evaluar todos los resultados que se devuelven. Se guarda Esta retroalimentacin.
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 idea de cmo un cambio Pregunta: bill clinton
en la funcin de clasificacin http://www.whitehouse.gov/
100,00%
(sin fecha) (0K)
afecta a los resultados de
http://www.whitehouse.gov/
bsqueda.

5 Resultados y
Rendimiento

Oficina del Presidente

99,67% (23 de diciembre 1996) (2K)
http://www.whitehouse.gov/WH/EOP/OP/html/OP_Home.html
Bienvenido a La Casa Blanca
99,98% (09 de noviembre 1997) (5K)
http: // www.whitehouse.gov/WH/Welcome.html~~MD~~aux
Enviar correo electrnico al Presidente
99.86% (14 de julio 1997)

La medida ms importante
de un motor de bsqueda es
la calidad de sus resultados
de bsqueda. Si bien una
evaluacin de usuario
completa est ms all del
"No oficial" de Bill Clinton
alcance de este trabajo,
94,06% (11 de noviembre 1997) (14K)
nuestra propia experiencia
http://zpub.com/un/un-bc.html
con Google ha demostrado
Bill Clinton se rene La encoge
que para producir mejores
86,27%
(29 de junio 1997) (63K)
http://zpub.com/un/un-bc9.html
resultados que los principales
presidente Bill Clinton - El lado oscuro
motores de bsqueda
97,27% (10 de noviembre 1997) (15K)
comerciales para la mayora http://www.realchange.org/ clinton.htm
de las bsquedas. Como un $ 3 Bill Clinton
ejemplo que ilustra el uso de 94,73% (sin fecha) (4K)
PageRank, el ancla de texto, http://www.gatewy.net/~tjohnson/clinton1.html
Figura 4. Resultados de ejemplo de Google
y la proximidad, la figura 4
muestra los resultados de
Google para una bsqueda en "bill clinton". Estos resultados demuestran algunas de
las caractersticas de Google. Los resultados se agrupan por servidor. Esto ayuda
considerablemente cuando tamizado a travs de conjuntos de resultados. Una serie
de resultados son de dominio whitehouse.gov que es lo que uno puede esperar
razonablemente de tal bsqueda. En la actualidad, la mayora de los principales
motores de bsqueda comercial no devuelven ningn resultado de whitehouse.gov,
mucho menos los ms adecuados. Observe que no hay ningn ttulo para el primer
resultado. Esto se debe a que no se ha rastreado. En su lugar, Google se bas en el
texto de anclaje para determinar esto era una buena respuesta a la consulta. Del
mismo modo, el quinto resultado es una direccin de correo electrnico que, por
supuesto, no es rastreable. Tambin es un resultado de texto de anclaje.
Todos los resultados son razonablemente pginas de alta calidad y, en ltima
comprobacin, ninguno era enlaces rotos. Esto es en gran parte porque todos 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 sea Clinton o
sobre un Clinton aparte de Bill. Esto se debe a que le damos pesada importancia de
la proximidad de las ocurrencias de palabras. Por supuesto una verdadera prueba de

Tamao total de descabellada

Pginas
la calidad de un motor de bsqueda implicara
un extenso estudio de usuario o resultados de
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

Aparte de la calidad de bsqueda, Google est
diseado para escalar de forma rentable para el
tamao de la Web a medida que crece. Un
aspecto de esto es utilizar el almacenamiento
de manera eficiente. 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, poco ms de un
tercio del total de datos que almacena. A los
precios actuales de disco esto hace que el
depsito de una fuente relativamente barata de
datos tiles. Ms importante an, el total de
todos los datos utilizados por 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 corta
invertida. Con una mejor codificacin y
compresin del ndice de documentos, un
motor de bsqueda web de alta calidad puede
caber en una unidad de 7GB de un nuevo PC.

147.8 GB Repositorio
Comprimido

53.5 GB

ndice invertido Corto

4.1 GB

ndice completo Invertido 37.2 GB

Lxico

293 MB

Datos de anclaje
temporal
(no en total)

6.6 GB

ndice de documentos
Incl.
9.7 GB
Ancho de datos variables
Enlaces Base de datos

3.9 GB

Total sin Repositorio

55.2 GB

Con total Repositorio

108.7
GB

Estadsticas de Almacenamiento

Rendimiento 5.2 Sistema

Es importante para un motor de bsqueda para
rastrear e indexar de manera eficiente. De esta
manera la informacin puede mantenerse al da
y los principales cambios en el sistema se
puede probar con relativa rapidez. Para Google,
las principales operaciones estn rastreo, la
indexacin y clasificacin. Es difcil medir
cunto tiempo tom el rastreo global porque los
discos se llenaron, los servidores de nombres se
estrell, o cualquier nmero de otros problemas
Pgina web Estadsticas
que dejaron el sistema. En total tard
aproximadamente 9 das para descargar los 26 Nmero de pginas
24000000
Web recuperados de
Nmero de Urls Seen 76500000
Nmero de
1,7
direcciones de correo
millones
electrnico

Nmero de de 404

millones

millones de pginas (incluyendo errores). Sin embargo, una vez que el sistema
estaba funcionando sin problemas, se corra mucho ms rpido, la descarga de los
ltimos 11 millones de pginas en slo 63 horas, con un promedio de poco ms de 4
millones de pginas al da o 48,5 pginas por segundo. Corrimos el indexador y el
rastreador de forma simultnea. El indexador corri solo ms rpido que los
rastreadores. Esto es en gran parte porque pasamos el tiempo justo optimizar el
indexador de modo que no sera un cuello de botella. Estas optimizaciones incluyen
actualizaciones masivas al ndice de documentos y 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.

5.3 Bsqueda Rendimiento

Mejorar el rendimiento de bsqueda no fue el foco principal de nuestra
investigacin hasta este punto. La versin actual de Google responde a la mayora
de las consultas de entre 1 y 10 segundos. Esta vez est dominado en su mayora por
el disco IO a travs de NFS (ya que los discos estn distribuidas en un nmero de
mquinas). Por otra parte, Google no tiene ningn optimizaciones tales como el
almacenamiento en cach de
Misma consulta
consultas, subndices en
Consulta
repetida (IO
trminos comunes, y otras
Inicial
mayormente en
optimizaciones comunes.
cach)
Tenemos la intencin de
CPU
CPU
acelerar Google
Tiempo
Tiempo
Consulta
Tiempo
Tiempo
considerablemente a travs de
total (s)
total (s)
(s)
(s)
la distribucin y el hardware,
el software y mejoras
al gore
0.09
2.13
0.06
0.06
algortmicas. Nuestro
vicepresidente 1.77
3.84
1.66
1.80
objetivo es ser capaz de
discos duros 0.25
4.86
0.20
0.24
manejar varios cientos de
consultas por segundo. Tabla los motores de
1.31
9.63
1.16
1.16
2 tiene unos tiempos de
bsqueda
consulta de la muestra de la
Tabla 2. Tiempos de bsqueda
versin actual de Google. Se
repiten para mostrar las aceleraciones resultantes de cach IO.

6. Conclusiones
Google est diseado para ser un motor de bsqueda escalable. El objetivo principal
es proporcionar resultados de bsqueda de alta calidad sobre un mundo en rpido
crecimiento Wide Web. Google emplea una serie de tcnicas para mejorar la calidad
de bsqueda incluyendo fila de la pgina, el texto de anclaje, y la informacin de
proximidad. Adems, Google es una arquitectura completa para la recopilacin de

pginas web, la indexacin de ellos, y la realizacin de consultas de bsqueda por

encima de ellos.

6.1 Trabajo Futuro

Un motor de bsqueda en Internet a gran escala es un sistema complejo y mucho
queda por hacer. Nuestros objetivos inmediatos son mejorar la eficiencia de
bsqueda y escalar a aproximadamente 100 millones de pginas web. Algunas
mejoras simples a la eficiencia incluyen el almacenamiento en cach de consultas,
la asignacin de disco inteligente, y subndices. Otra rea que requiere mucha
investigacin es actualizaciones. Debemos tener algoritmos inteligentes para decidir
qu pginas web antiguas deben recrawled y qu otros nuevos deben ser rastreadas.
Trabajar hacia esta meta se ha hecho en [Cho 98]. Una prometedora rea de
investigacin est utilizando memorias cach de proxy para construir las bases de
datos de bsqueda, ya que son impulsados demanda. Estamos planeando aadir
caractersticas simples apoyados por motores de bsqueda comerciales como
operadores booleanos, la negacin, y frenar. Sin embargo, otras caractersticas estn
empezando a ser explorado como retroalimentacin relevancia y la agrupacin
(Actualmente Google es compatible con una sencilla basada en la agrupacin
nombre de host). Tambin planeamos apoyar contexto de usuario (como la
ubicacin del usuario), y el resultado de resumen. Tambin estamos trabajando para
extender el uso de la estructura de enlace y el texto del vnculo. Experimentos
sencillos indican PageRank se puede personalizar mediante el aumento del peso de
la pgina o marcadores de inicio del usuario. En cuanto a texto del enlace, estamos
experimentando con el uso de texto enlaces, adems del texto del enlace en s
circundante. Un motor de bsqueda Web es un ambiente muy rico para las ideas de
investigacin. Tenemos demasiados para enumerar aqu, as que no esperamos que
esta seccin de trabajo futuro para convertirse en mucho ms corto en un futuro
prximo.

6.2 de alta calidad de Bsqueda

El mayor problema que enfrentan los usuarios de motores de bsqueda web hoy en
da es la calidad de los resultados que obtienen espalda. Si bien los resultados son a
menudo divertido y expanden los horizontes de los usuarios, son a menudo
frustrante y consume un tiempo precioso. Por ejemplo, el primer resultado de
bsqueda para "Bill Clinton" en uno de los motores de bsqueda comerciales ms
populares fue la de Bill Clinton Broma del Da: 14 de abril 1997 Google est
diseado para proporcionar la bsqueda de mayor calidad con el fin de la Web
sigue. creciendo rpidamente, la informacin se puede encontrar fcilmente. Con el
fin de lograr esto Google hace un uso intensivo de la informacin hipertextual que
consta de estructura de enlace y enlace (ancla) texto. Google tambin utiliza la
informacin de proximidad y la fuente. Si bien es difcil la evaluacin de un motor
de bsqueda, hemos encontrado subjetivamente que Google devuelve resultados de
bsqueda de calidad ms altos que los actuales motores de bsqueda comerciales. 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 lo
que el enlace apunta a ayuda al retorno de motores de bsqueda relevantes (y hasta
cierto punto de alta calidad) resultados. Por ltimo, el uso de la informacin de
proximidad ayuda a aumentar la relevancia de un gran negocio para muchas
consultas.

6.3 Arquitectura escalable

Aparte de la calidad de la bsqueda, Google est diseado para escalar. Debe ser
eficiente tanto en el espacio y el tiempo, y los factores constantes son muy
importantes cuando se trata de toda la Web. En la aplicacin de Google, hemos visto
los cuellos de botella en la CPU, acceso a la memoria, la capacidad de memoria,
disco busca, rendimiento del disco, capacidad de disco, y la red de IO. Google ha
evolucionado para superar una serie de estos cuellos de botella durante las diversas
operaciones. Principales estructuras de datos de Google hacen uso eficiente del
espacio de almacenamiento disponible. Por otra parte, las rastrear, indexar y
operaciones de clasificacin son lo suficientemente eficientes para poder construir
un ndice de una parte sustancial de la web - 24 millones de pginas, en menos de
una semana. Esperamos ser capaces de 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 ha recogido ya ha dado lugar a muchos otros
documentos presentados a congresos y muchos ms en camino. Investigaciones
recientes como [Abiteboul 97] ha demostrado una serie de limitaciones a las
preguntas acerca de la Web que pueden ser contestadas sin tener la Web disponibles
localmente. Esto significa que Google (o un sistema similar) no es slo una valiosa
herramienta de investigacin pero necesario 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
De Scott Hassan y Alan Steremberg han sido fundamentales para el desarrollo de
Google. Sus contribuciones talentosos son insustituibles, y los autores les debemos
mucha gratitud. Tambin nos gustara dar las gracias a Hctor Garca-Molina,
Rajeev Motwani, Jeff Ullman, y Terry Winograd y todo el grupo WebBase por su
apoyo y discusiones interesantes. Por ltimo, nos gustara reconocer el generoso
apoyo de nuestros donantes de equipos IBM, Intel y Sun y nuestros financiadores.
La investigacin descrita aqu se llev a cabo como parte del Proyecto de Biblioteca
Digital Integrado de Stanford, con el apoyo de la National Science Foundation bajo
el Acuerdo Cooperativo IRI-9411306. La financiacin de este acuerdo de
cooperacin tambin es proporcionada por DARPA y la NASA, y por Interval

Research, y los socios industriales del Proyecto de Bibliotecas Digitales de

Stanford.

Referencias
o
o

[Marchiori 97] Massimo Marchiori. La bsqueda de la informacin correcta

en la Web:. Hyper motores de bsqueda La Sexta Conferencia Internacional
WWW (WWW 97). Santa Clara, EE.UU., 7 a 11 abril 1997.

[McBryan 94] Oliver A. McBryan. GENVL y WWWW: Herramientas para

Taming the Web. Primera Conferencia Internacional sobre la. World Wide
Web CERN, Ginebra (Suiza), mayo de 1994. 25-26-27
http://www.cs.colorado.edu/home/mcbryan/mypapers/www94.ps

. [Pgina 98] Lawrence Pgina, Sergey Brin, Rajeev Motwani, Terry

Winograd Clasificacin La Cita PageRank: poner orden en la Web.
Manuscrito en curso. Http://google.stanford.edu/~backrub/pageranksub.ps

[Pinkerton 94] Brian Pinkerton, encontrar lo que se quiere:. Experiencias

con el WebCrawler La Segunda Internacional WWW Conferencia de
Chicago, EE.UU., 17-20 de octubre de 1994.
http://info.webcrawler.com/bp/WWW94.html

. [Spertus 97] Ellen Spertus parsito: Minera informacin estructural en la

Web. La Sexta Conferencia Internacional WWW (WWW 97). Santa Clara,
EE.UU., 7 a 11 abril 1997.

[TREC 96] Actas de la quinta Conferencia texto REcuperacin (TREC-5).

Gaithersburg, Maryland, Noviembre 20-22, 1996. Editorial: Departamento
de Comercio, el 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. Gigabytes

Administracin: La compresin y la indexacin de documentos e imgenes.
Nueva York: Van Nostrand Reinhold, 1994.

[Weiss 96] Ron Weiss, Bienvenido Vlez, Mark A. Sheldon, Chanathip

Manprempre, Peter Szilagyi, Andrzej Duda, y David K. Gifford. HyPursuit:
Un motor de bsqueda jerrquica de la red que explota Content-Enlace
hipertexto Clustering. Actas de la sptima ACM Conferencia sobre
hipertexto. Nueva York, 1.996.

Vitae
Sergey Brin recibi su licenciatura en

matemticas y ciencias de la computacin de la Universidad de Maryland en

College Park en 1993. Actualmente es un Ph.D. candidato en ciencias de la
computacin en la Universidad de Stanford, donde recibi su maestra en 1995. l
es un receptor de una Fundacin Nacional de Ciencia de Becas de Postgrado. Sus
intereses de investigacin incluyen los motores de bsqueda, extraccin de
informacin de fuentes no estructuradas, y la minera de datos de grandes
colecciones de textos y datos cientficos.
Lawrence Pgina naci en East Lansing, Michigan, y recibi una EEB en
Ingeniera Informtica en la Universidad de Michigan, Ann Arbor en 1995. En la
actualidad es un Ph.D. candidato en Ciencias de la Computacin en la Universidad
de Stanford. Algunos de sus intereses de investigacin incluyen la estructura de
enlaces de la web, la interaccin persona-ordenador, motores de bsqueda, la
escalabilidad de las interfaces de acceso a la informacin, y la minera de datos
personales.

8 Apndice A: Publicidad y Motivos mixtos

En la actualidad, el modelo de negocio predominante para los motores de bsqueda
comerciales es la publicidad. Los objetivos del modelo de negocio de la publicidad
no siempre corresponden a la prestacin de bsqueda de calidad a los usuarios. Por
ejemplo, en nuestra bsqueda prototipo de motor de uno de los mejores resultados
para el telfono celular es "El Efecto de Cellular Phone Uso Al conductor
Atencin", un estudio que explica con gran detalle las distracciones y los riesgos
asociados con la conversacin en un telfono celular mientras se conduce. Este
resultado de la bsqueda se acerc primero a causa de su gran importancia, a juzgar
por el algoritmo de PageRank, una aproximacin de la citacin importancia en la
web [Pgina 98]. Est claro que un motor de bsqueda que fue tomando el dinero
por mostrar anuncios de telfonos celulares tendra dificultades para justificar la
pgina que nuestro sistema regres a sus anunciantes que pagan. Para este tipo de
razn y la experiencia histrica con otros medios de comunicacin [Bagdikian 83],
esperamos que la publicidad financiada motores de bsqueda se har con
preferencia inherente hacia los anunciantes y lejos de las necesidades de los
consumidores.
Dado que es muy difcil incluso para los expertos para evaluar los motores de
bsqueda, el sesgo de motor de bsqueda es particularmente insidioso. Un buen
ejemplo fue OpenText, que fue informado de que la venta de las empresas el
derecho a ser incluido en la parte superior de los resultados de bsqueda para
determinadas consultas [Marchiori 97]. Este tipo de sesgo es mucho ms insidioso
que la publicidad, ya que no est claro que "merece" estar ah, 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 un motor de bsqueda viable. Pero sesgo
menos flagrante son susceptibles de ser tolerado por el mercado. Por ejemplo, un
motor de bsqueda podra aadir un pequeo factor de los resultados de bsqueda
de las empresas "amigables", 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 en el mercado. Por otra parte, los ingresos de
publicidad a menudo proporciona un incentivo para proporcionar resultados de
bsqueda de mala calidad. Por ejemplo, hemos observado un importante motor de
bsqueda no volvera pgina de inicio de una gran compaa area cuando el
nombre de la compaa area se le dio como una consulta. Dio la casualidad de que
la aerolnea haba colocado un anuncio costoso, 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 al
motor de bsqueda. En general, se podra argumentar desde el punto de vista del
consumidor que la mejor es, se necesitar el motor de bsqueda de los menos
anuncios para el consumidor para encontrar lo que quieren. Por supuesto, esto
erosiona la publicidad apoyada modelo de negocio de los motores de bsqueda
existentes. Sin embargo, siempre habr dinero de los anunciantes que quieren un
cliente para cambiar los productos, o que tienen algo que es realmente nuevo. Pero
creemos que la cuestin de la publicidad hace que suficientes incentivos mixtos que
es fundamental contar con un motor de bsqueda competitiva 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. Acabamos de recibir el disco y mquinas para manejar
ms o menos de esa cantidad. Todas las piezas que requieren mucho tiempo del
sistema son paralelizar y hora ms o menos lineal. Estos incluyen cosas como los
rastreadores, indexadores y clasificadores. Tambin pensamos 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 los sistemas operativos ms comunes (actualmente corremos
tanto en Solaris y Linux). Estos incluyen cosas como la memoria direccionable, el
nmero de descriptores de archivos abiertos, tomas de corriente de red y ancho de
banda, y muchos otros. Creemos que la ampliacin a un montn ms de 100
millones de pginas que aumentara considerablemente la complejidad de nuestro
sistema.

9.2 Escalabilidad de arquitecturas centralizadas de indexacin

Como las capacidades de las computadoras aumentan, se hace posible indexar una
cantidad muy grande de texto para un costo razonable. Por supuesto, otros medios
de comunicacin ms intensivas en ancho de banda, como el vdeo es probable que
se convierta ms penetrante. Pero, debido a que el costo de produccin de un texto
es bajo comparado con los medios de comunicacin como el vdeo, el texto es
probable que siga siendo muy generalizada. Adems, es probable que pronto vamos
a tener reconocimiento de voz que hace un trabajo razonable convertir voz en texto,

la ampliacin de la cantidad de texto disponible. Todo esto ofrece posibilidades

increbles para la indexacin centralizada. Aqu est un ejemplo ilustrativo.
Suponemos que queremos indexar todo a todos en los EE.UU. ha escrito durante un
ao. Suponemos que hay 250 millones de personas en los EE.UU. y escribimos un
promedio de 10k por da. Eso se resuelve en alrededor de 850 terabytes. Tambin
suponen que la indexacin de un terabyte puede hacerse ahora por un costo
razonable. Tambin suponemos que los mtodos de indexacin utilizados sobre el
texto son lineales o casi lineales en su complejidad. Teniendo en cuenta todos estos
supuestos podemos calcular cunto tiempo le tomara antes de que pudiramos
ndice nuestros 850 terabytes por un costo razonable asumir ciertos factores de
crecimiento. La Ley de Moore se defini en 1965 como se duplica cada 18 meses en
el poder del procesador. Se ha mantenido notablemente cierto, no slo para los
procesadores, pero para otros parmetros importantes del sistema, como disco
tambin. Si asumimos que la ley de Moore se mantiene para el futuro, necesitamos
slo 10 ms duplicaciones, o 15 aos para llegar a nuestra meta de la indexacin de
todo a todos en los EE.UU. ha escrito durante un ao por un precio que una
compaa pequea podra permitirse. Por supuesto, los expertos de hardware son
algo preocupados Ley de Moore no puede continuar manteniendo durante los
prximos 15 aos, pero sin duda hay una gran cantidad de aplicaciones
centralizadas interesantes, incluso si slo tenemos una parte del camino a nuestro
ejemplo hipottico.
Por supuesto a los sistemas distribuidos como G l oss [Gravano 94] o la cosecha a
menudo ser la solucin tcnica ms eficiente y elegante para la indexacin, pero
parece difcil de convencer al mundo de utilizar estos sistemas, debido a los altos
costos de la administracin de la creacin de grandes nmero de instalaciones. Por
supuesto, es muy probable que la reduccin del costo de la administracin
drsticamente es posible. Si eso ocurre, y todo el mundo comienza la ejecucin de
un sistema de indexacin distribuida, la bsqueda sin duda mejorar drsticamente.
Debido a que los seres humanos slo pueden escribir o hablar una cantidad finita, y
como computadoras continan mejorando, la indexacin de texto escalarn incluso
mejor que lo hace ahora. Por supuesto que podra haber una cantidad infinita de
mquina de contenido generado, pero slo indexacin enormes cantidades de
contenido generado humana parece tremendamente til. As que somos optimistas
de que nuestra bsqueda en la web arquitectura centralizada motor mejorar en su
capacidad para cubrir la informacin de texto pertinente en el tiempo y que hay un
futuro brillante para la bsqueda.