La anatomía de una hipertextualidad de gran escala

Motor de búsqueda web

Sergey Brin y Lawrence Page

Departamento de Informática,

Stanford University, Stanford, CA 94305, EE.UU.

Sergey@cs.stanford.edu y page@cs.stanford.edu

Abstracto

En este artículo, presentamos Google, un prototipo de un motor de búsqueda a gran escala que
hace pesadas

Uso de la estructura presente en hipertexto. Google está diseñado para rastrear e indexar la Web
de manera eficiente

Y producir resultados de búsqueda mucho más satisfactorios que los sistemas existentes. El
prototipo con un

Texto y base de datos de hipervínculo de al menos 24 millones de páginas está disponible en

http://google.stanford.edu/

Ingeniería de un motor de búsqueda es una tarea difícil. Los motores de búsqueda indexan
decenas a cientos de

Millones de páginas web que implican un número comparable de términos distintos. Responden a
decenas de

Millones de consultas cada día. A pesar de la importancia de los motores de búsqueda a gran
escala en la web,

Muy poca investigación académica se ha hecho sobre ellos. Además, debido al rápido avance

La tecnología y la proliferación de la web, la creación de un motor de búsqueda web hoy en día es

muy diferente de tres

hace años que. Este documento proporciona una descripción en profundidad de nuestro motor de
búsqueda web a gran escala - el
Primera descripción pública tan detallada que sabemos de hasta la fecha. Aparte de los problemas
de escalado

Técnicas de búsqueda tradicionales a los datos de esta magnitud, hay nuevos retos técnicos

Con el uso de la información adicional presente en hipertexto para producir mejores resultados de
búsqueda. Esta

Este artículo aborda esta cuestión de cómo construir un sistema práctico a gran escala que

Información adicional presente en hipertexto. También miramos el problema de cómo tratar

efectivamente

Con colecciones de hipertexto incontroladas donde cualquiera puede publicar lo que quiera.

Palabras claves

World Wide Web, motores de búsqueda, recuperación de la información, PageRank, Google

1. Introducción

(Nota: Existen dos versiones de este documento: una versión completa más larga y una versión
impresa más corta.

Versión completa está disponible en la web y en el CD-ROM de la conferencia.)

La web crea nuevos retos para la recuperación de la información. La cantidad de información en la

web es

Creciendo rápidamente, así como el número de nuevos usuarios inexpertos en el arte de la

investigación en la web. La gente es

Es probable que navegue por la web utilizando su gráfico de enlaces, a menudo comenzando con
índices mantenidos humanos de alta calidad

Como Yahoo! o con motores de búsqueda. Las listas mantenidas por los humanos cubren los
temas populares

Subjetivo, caro de construir y mantener, lento para mejorar, y no puede cubrir todos los temas
esotéricos.

Los motores de búsqueda automatizados que dependen de la coincidencia de palabras clave

suelen devolver demasiados resultados de baja calidad.

Para empeorar las cosas, algunos anunciantes intentan llamar la atención de la gente tomando
medidas
Engañar a los motores de búsqueda automatizados. Hemos construido un motor de búsqueda 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 búsqueda de mayor calidad. Elegimos nuestro nombre
de sistema, Google, porque

Es una ortografía común de googol, o 10100 y encaja bien con nuestra meta de construir una
búsqueda a gran escala

Motores.

1.1 Motores de búsqueda web - Ampliación: 1994 - 2000

La tecnología de los motores de búsqueda ha tenido que escalar dramáticamente para

mantenerse al día con el crecimiento de la web. En 1994,

Uno de los primeros motores de búsqueda web, el World Wide Web Worm (WWWW) [McBryan
94] tenía un índice

De 110.000 páginas web y documentos web accesibles. A partir de noviembre de 1997, los
principales motores de búsqueda

Reclamar un índice de 2 millones (WebCrawler) a 100 millones de documentos web (de Search
Engine

Reloj). Es previsible que para el año 2000, un índice comprensivo de la Web contenga

Millones de documentos. Al mismo tiempo, el número de buscadores de motores de búsqueda de

manejar ha crecido increíblemente

también. En marzo y abril de 1994, el gusano de la World Wide Web recibió un promedio de
aproximadamente 1500 consultas

por día. En noviembre de 1997, Altavista afirmó que manejaba aproximadamente 20 millones de
consultas por día. Con el

Número creciente de usuarios en la web, y sistemas automatizados que consultan motores de

búsqueda, es probable

Que los principales motores de búsqueda manejarán cientos de millones de consultas por día para
el año 2000. El objetivo de

Nuestro sistema es abordar muchos de los problemas, tanto en calidad como en escalabilidad,
introducidos por escalamiento
Tecnología de motores de búsqueda a números tan extraordinarios.

1.2. Google: Escala con la Web

La creación de un motor de búsqueda que escalas incluso a la web de hoy presenta muchos
desafíos. Rastreo rápido

La tecnología 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

indexación debe procesar

Cientos de gigabytes de datos de manera eficiente. Las consultas deben ser manejadas
rápidamente, a un ritmo de cientos a

Miles por segundo.

Estas tareas son cada vez más difíciles a medida que crece la Web. Sin embargo, el rendimiento del

El costo ha mejorado dramáticamente para compensar parcialmente la dificultad. Hay, sin

embargo, varios

Excepciones a este progreso como tiempo de búsqueda de disco y robustez del sistema operativo.
Al diseñar Google,

Hemos considerado tanto la tasa de crecimiento de la Web como los cambios tecnológicos. Google
está diseñado 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 están optimizadas para un acceso rápido y eficiente (ver sección 4.2). Además,
esperamos que el costo

El índice y el texto del almacén o el HTML disminuirá eventual con respecto a la cantidad que
estará disponible (véase

Apéndice B). Esto resultará en propiedades de escala favorables para sistemas centralizados como
Google.

1.3 Objetivos del diseño

1.3.1 Calidad de búsqueda mejorada

Nuestro principal objetivo es mejorar la calidad de los motores de búsqueda web. En 1994,
algunas personas creían
Índice de búsqueda completo haría posible encontrar algo fácilmente. Según Best of the Web

1994 - Navigators, "El mejor servicio de navegación debería facilitar la búsqueda 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 búsqueda recientemente, pueden fácilmente demostrar que la integridad del índice
no es el único

La calidad de los resultados de la búsqueda. "Los resultados basura" suelen eliminar los resultados
que un usuario está interesado pulg De hecho,

A partir de noviembre de 1997, sólo uno de los cuatro principales motores de búsqueda comercial
se encuentra (devuelve su propia

Página de búsqueda en respuesta a su nombre en los diez primeros resultados). Una de las
principales causas de este problema es que

El número de documentos en los índices ha aumentado en muchos órdenes de magnitud, pero el

usuario

La capacidad de mirar los documentos no lo ha hecho. La gente todavía está dispuesta a mirar las
primeras decenas de resultados.

Debido a esto, a medida que crece el tamaño de la colección, necesitamos herramientas que
tengan una precisión muy alta (número de

Documentos relevantes devueltos, digamos en las decenas superiores de resultados). De hecho,

queremos que nuestra noción de "relevante"

Sólo incluyen los mejores documentos, ya que puede haber decenas de miles de ligeramente
relevante

documentos. Esta precisión muy alta es importante incluso a expensas del recuerdo (el número
total de

Documentos relevantes que el sistema pueda devolver). Hay un poco de optimismo reciente de
que el uso de

Más información hipertextual puede ayudar a mejorar la búsqueda 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
Información para hacer juicios de relevancia y filtrado de calidad. Google hace uso de ambos
enlaces

Estructura y texto de anclaje (ver Secciones 2.1 y 2.2).

1.3.2 Investigación académica de motores de búsqueda

Aparte de un tremendo crecimiento, la Web también se ha vuelto cada vez más comercial a través
del tiempo. En 1993,

El 1,5% de los servidores web estaban en dominios .com. Este número creció a más del 60% en
1997. Al mismo tiempo,

Los motores de búsqueda han migrado del dominio académico al comercial. Hasta ahora la
mayoría de las búsquedas

El desarrollo del motor ha pasado en las empresas con poca publicación de detalles técnicos. Esto
causa

La tecnología de los motores de búsqueda para permanecer en gran medida un arte negro y
orientado a la publicidad (véase el Apéndice A).

Con Google, tenemos una fuerte meta de impulsar más desarrollo y comprensión en el mundo
académico.

reino.

Otra meta importante del diseño era construir los sistemas que un número razonable de gente
pueda utilizar realmente.

El uso era importante para nosotros porque creemos que algunas de las investigaciones más
interesantes involucrarán

Aprovechando la gran cantidad de datos de uso que están disponibles en los sistemas web
modernos. Por ejemplo, hay

Son muchas decenas de millones de búsquedas realizadas todos los días. Sin embargo, es muy
difícil obtener estos datos,

Principalmente porque se considera comercialmente valioso.

Nuestro objetivo final de diseño era construir una arquitectura que pudiera respaldar nuevas
actividades de

Datos web a gran escala. Para respaldar nuevos usos de investigación, Google almacena todos los
documentos reales que rastrea
En forma comprimida. Uno de nuestros principales objetivos en el diseño de Google fue establecer
un entorno donde

Otros investigadores pueden entrar rápidamente, procesar grandes trozos de la web y producir
resultados interesantes

Que habría sido muy difícil 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
están en marcha.

Otro objetivo que tenemos es crear un entorno similar al de Spacelab en el que investigadores o
incluso estudiantes puedan

Proponer y hacer experimentos interesantes en nuestros datos web a gran escala.

2. Características del sistema

El motor de búsqueda de Google tiene dos características importantes que le ayudan a producir
resultados de alta precisión. En primer lugar,

Hace uso de la estructura de enlaces de la Web para calcular una clasificación de calidad para cada
página web. Este ranking

Se llama PageRank y se describe en detalle en [Página 98]. En segundo lugar, Google utiliza el
enlace para mejorar

Resultados de la búsqueda.

2.1 PageRank: Traer orden a la Web

El gráfico de la cita (enlace) de la web es un recurso importante que en gran medida ha

Motores de búsqueda web. Hemos creado mapas que contienen hasta 518 millones de estos
hipervínculos, un

Muestra significativa del total. Estos mapas permiten un cálculo rápido del "PageRank" de una
página web, un

Medida objetiva de su importancia de citación que corresponde bien con la idea subjetiva

importancia. Debido a esta correspondencia, PageRank es una excelente manera de priorizar los
resultados de

Búsquedas de palabras clave web. Para la mayoría de los temas populares, una búsqueda simple
de concordancia de texto que está restringida a la web
Los títulos de página se desempeñan admirablemente cuando PageRank prioriza los resultados
(demo disponible en

Google.stanford.edu). Para el tipo de búsqueda de texto completo en el sistema principal de

Google, PageRank también ayuda

mucho.

2.1.1 Descripción del cálculo del PageRank

La literatura de citas académicas se ha aplicado a la web, en gran medida contando citas o vínculos
de retroceso a un

Página dada. Esto da una aproximación de la importancia o calidad de una página. PageRank
amplía este

Idea por no contar los enlaces de todas las páginas por igual, y por la normalización por el número
de enlaces en una página.

PageRank se define como sigue:

Asumimos que la página A tiene las páginas T1 ... Tn que apuntan a ella (es decir, son citas). El
parámetro d

Es un factor de amortiguación que se puede establecer entre 0 y 1. Normalmente fijamos d a 0.85.

Existen

Más detalles acerca de d en la siguiente sección. También C (A) se define como el número de
enlaces que van

Fuera de página A. El PageRank de una página A se da como sigue:

PR (T _ {1}) + ... + PR (T _ {n}) / C (T _ {n}))

Tenga en cuenta que los PageRanks forman una distribución de probabilidad sobre páginas web,
por lo que la suma de todos

Páginas web 'PageRank será uno.

PageRank o PR (A) se puede calcular utilizando un simple algoritmo iterativo, y corresponde al

Vector propio principal de la matriz de enlace normalizada de la banda. Además, un PageRank

para 26 millones de web

Páginas se pueden calcular en pocas horas en una estación de trabajo de tamaño medio. Hay
muchos otros detalles

Que están fuera del alcance de este documento.

2.1.2 Justificación Intuitiva

PageRank puede ser pensado como un modelo de comportamiento del usuario. Asumimos que
hay un "surfista aleatorio" que es

Dado una página web al azar y sigue haciendo clic en los enlaces, nunca golpear "atrás", pero
finalmente se aburre

Y comienza en otra página aleatoria. La probabilidad de que la persona que practica surf al azar
visite una página es su PageRank.

Y, el d factor de amortiguación es la probabilidad de que en cada página el "surfista aleatorio" se

aburrirá y solicitar

Otra página aleatoria. Una variación importante es agregar solamente el factor de amortiguación d
a una sola página, o un

Grupo de páginas. Esto permite la personalización y puede hacer casi imposible deliberar

Engañar al sistema para obtener una clasificación más alta. Tenemos varias otras extensiones a
PageRank,

Ver de nuevo [Página 98].

Otra justificación intuitiva es que una página puede tener un PageRank alto si hay muchas páginas
que apuntan

A él, o si hay algunas páginas que apuntan a ella y tienen un PageRank alto. Intuitivamente, las
páginas que están bien

Citados de muchos lugares alrededor de la web vale la pena mirar. También, las páginas que
quizás sólo tienen una

Citación de algo así como la página de inicio de Yahoo! también son generalmente vale la pena
mirar. Si una página no fue

Alta calidad, o era un acoplamiento quebrado, él es muy probable que la página inicial de Yahoo
no enlazaría a ella.

PageRank maneja estos dos casos y todo lo demás mediante la propagación recursiva de pesos

A través de la estructura de enlace de la red.

2.2 Texto de anclaje

El texto de los enlaces se trata de una manera especial en nuestro buscador. La mayoría de los
motores de búsqueda asocian el texto
De un enlace con la página en la que se encuentra el enlace. Además, lo asociamos con la página a
la que apunta el enlace.

Esto tiene varias ventajas. En primer lugar, las anclas a menudo proporcionan descripciones más
precisas de las páginas web que

Las propias páginas. En segundo lugar, pueden existir anclas para documentos que no pueden ser

Motor de búsqueda basado en texto, como imágenes, programas y bases de datos. Esto hace
posible volver a la red

Páginas que en realidad no se han rastreado. Tenga en cuenta que las páginas que no se han
rastreado pueden causar

Problemas, ya que nunca se verifican su validez antes de ser devueltos al usuario. En este caso, el

Motor de búsqueda puede incluso devolver una página que nunca existió realmente, pero tenía
hipervínculos apuntando a ella.

Sin embargo, es posible ordenar los resultados, de modo que este problema particular rara vez
ocurre.

Esta idea de propagar el texto ancla a la página a la que se refiere se implementó en la World Wide
Web

Worm [McBryan 94], especialmente porque ayuda a buscar información no textual y amplía la
búsqueda

Cobertura con menos descargaUtilizamos la propagación del ancla principalmente porque el texto
del ancla

Puede ayudar a proporcionar resultados de mejor calidad. El uso eficiente del texto de anclaje es
técnicamente difícil debido a

Las grandes cantidades de datos que deben ser procesados. En nuestro rastreo actual de 24
millones de páginas,

Más de 259 millones de anclas que indexamos.

2.3 Otras características

Aparte de PageRank y el uso de texto de anclaje, Google tiene varias otras características. En
primer lugar, tiene ubicación

Información para todos los golpes y por lo que hace un uso extensivo de la proximidad en la
búsqueda. En segundo lugar, Google mantiene la pista
De algunos detalles visuales de la presentación tales como tamaño de fuente de palabras. Las
palabras en una fuente más grande o más audaz son

Ponderado más alto que otras palabras. En tercer lugar, el HTML completo de páginas está
disponible en un repositorio.

3 Trabajo relacionado

Búsqueda de la investigación 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 búsqueda web. Posteriormente fue seguido por
otros

Motores de búsqueda académicos, muchos de los cuales son ahora empresas públicas.
Comparado con el crecimiento del

Web y la importancia de los motores de búsqueda hay muy pocos documentos sobre los motores
de búsqueda recientes

[Pinkerton 94]. Según Michael Mauldin (científico en jefe, Lycos Inc) [Mauldin], "los diversos

(Incluyendo a Lycos) vigilan de cerca los detalles de estas bases de datos. "Sin embargo, ha habido
una feria

Cantidad de trabajo sobre las características específicas de los motores de búsqueda.

Especialmente bien representado es el trabajo que puede

Obtener resultados mediante el post-procesamiento de los resultados de los motores de

búsqueda comerciales existentes o producir

Motores de búsqueda "individualizados". Por último, ha habido un montón de investigación sobre

la recuperación de la información

Especialmente en colecciones bien controladas. En las dos secciones siguientes, se analizan

algunas

Esta investigación necesita ser extendida para trabajar mejor en la web.

3.1 Recuperación de información

El trabajo en sistemas de recuperación de información se remonta a muchos años y está bien

desarrollado [Witten 94].

Sin embargo, la mayor parte de la investigación sobre los sistemas de recuperación de información
está en pequeñas empresas bien controladas
Colecciones homogéneas tales como colecciones de artículos científicos o noticias sobre un tema
relacionado.

De hecho, el punto de referencia primario para la recuperación de información, la Conferencia de

Recuperación de Texto [TREC 96]

Utiliza una colección bastante pequeña y bien controlada para sus puntos de referencia. El
"Corpus muy grande"

Benchmark es sólo 20 GB en comparación con los 147 GB de nuestro rastreo de 24 millones de

páginas web. Cosas que

Trabajar bien en TREC a menudo no producen buenos resultados en la web. Por ejemplo, el vector
estándar

El modelo de espacio intenta devolver el documento que más 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 más algunas palabras. Por ejemplo, hemos visto un motor
de búsqueda principal

Devolver una página que contiene sólo "Bill Clinton Sucks" y la imagen de una "Bill Clinton"
consulta. Algunos sostienen

Que en la web, los usuarios deben especificar más exactamente lo que quieren y añadir más
palabras a sus

consulta. Discordamos vehementemente de esta posición. Si un usuario emite una consulta como
"Bill Clinton"

Obtener resultados razonables ya que hay una enorme cantidad de información de alta calidad
disponible en este

tema. Dado ejemplos como estos, creemos que el trabajo estándar de recuperación de
información debe ser

Ampliado para tratar eficazmente con la web.

3.2 Diferencias entre la Web y colecciones bien controladas

La web es una vasta colección de documentos heterogéneos completamente incontrolados.

Documentos sobre la
Tienen variaciones extremas internas a los documentos, y también en la meta información externa
que

Podría estar disponible. Por ejemplo, los documentos difieren internamente en su idioma (tanto
humano como

Programación), vocabulario (direcciones de correo electrónico, enlaces, códigos postales, números

de teléfono, números de producto), tipo o

(Texto, HTML, PDF, imágenes, sonidos), e incluso puede ser generado por la máquina (archivos de
registro o salida

De una base de datos). Por otro lado, definimos meta información externa como información que
puede ser

Inferido sobre un documento, pero no está contenido en él. Ejemplos de meta información
externa incluyen

Cosas como reputación de la fuente, frecuencia de actualización, calidad, popularidad o uso, y

citas. No

Sólo son las posibles fuentes de meta información externa variada, pero las cosas que se están
midiendo

Varían muchos órdenes de magnitud también. Por ejemplo, compare la información de uso de una

Homepage, como Yahoo que actualmente recibe millones de páginas vistas todos los días con un
oscuro

Artículo histórico que podría recibir una visión cada diez años. Claramente, estos dos elementos
deben ser tratados

Muy diferente por un motor de búsqueda.

Otra gran diferencia entre la web y las colecciones tradicionales bien controladas es que hay

Prácticamente ningún 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 búsqueda para encaminar el tráfico y las empresas que
deliberadamente

La manipulación de los motores de búsqueda para obtener beneficios se convierten en un

problema grave. Este problema que no ha sido

En sistemas tradicionales de recuperación de información cerrada. Además, es interesante

observar que los metadatos
Los esfuerzos han fracasado en gran parte con los motores de búsqueda web, porque cualquier
texto en la página que no es directamente

Representado al usuario es abusado para manipular los motores de búsqueda. Incluso hay
numerosas empresas

Que se especializan en la manipulación de los motores de búsqueda con fines de lucro.

4 Anatomía del sistema

En primer lugar, proporcionaremos un debate de alto nivel sobre la arquitectura. Luego, hay
algunas

Descripciones de estructuras de datos importantes. Por último, las principales aplicaciones:

rastreo, indexación y

La búsqueda será examinada en profundidad.

4.1 Descripción general de la arquitectura de Google

En esta sección, daremos una visión general de alto nivel de cómo

Todo el sistema funciona como se ilustra en la Figura 1.

Las secciones discutirán las aplicaciones y las estructuras de datos

No mencionado en esta sección. 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 páginas web)

Es realizado por varios rastreadores distribuidos. Hay un

URLserver que envía listas de URLs a buscar en el

Rastreadores Las páginas web que se obtienen se envían a

El almacén. El almacén entonces comprime y almacena

Las páginas web en un repositorio. Cada página web tiene un

Número de identificación asociado llamado docID que se asigna

Siempre que se analiza una nueva URL de una página web. los

Función de indexación es realizada por el indexador y

clasificador. El indizador realiza un número de funciones. Se lee

El repositorio, descomprime los documentos y los analiza. Cada documento se convierte en un

conjunto de

Ocurrencias de palabras llamadas hits. Los resultados registran la palabra, la posición en el

documento, una aproximación de la fuente

Tamaño y mayúsculas. El indexador distribuye estos golpes en un conjunto de "barriles", creando

una

Índice ordenado adelante. El indizador realiza otra función importante. Analiza todos los enlaces
en

Cada página web y almacena información importante sobre ellos en un archivo de anclas. Este
archivo contiene

Suficiente información para determinar a dónde 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. También 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 simplificación, vea la
Sección 4.2.5), y

Recurre a ellos por wordID para generar el índice invertido. Esto se hace en su lugar para que poco
temporal

Se necesita espacio para esta operación. El clasificador también produce una lista de ID de palabra
y desplazamientos en el

Índice invertido. Un programa llamado DumpLexicon toma esta lista junto con el léxico producido
por el
Indexador y genera un nuevo léxico para ser usado por el buscador. El buscador es ejecutado por
un servidor web y

Utiliza el léxico 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 están optimizadas para que una gran colección de documentos
pueda rastrearse, indexarse y

Buscado con poco costo. Aunque, las CPUs y las tasas de producción de entrada a granel han
mejorado dramáticamente

Los años, una búsqueda de disco todavía requiere unos 10 ms para completar. Google está
diseñado para evitar que el disco busque

Siempre que sea posible, y esto ha tenido una influencia considerable en el diseño de las
estructuras de datos.

Figura 1. Arquitectura de alto nivel de Google

4.2.1 BigFiles

BigFiles son archivos virtuales que abarcan múltiples sistemas de archivos y son direccionables por
enteros de 64 bits. los

La asignación entre múltiples sistemas de archivos se maneja automáticamente. El paquete

BigFiles también maneja

Asignación y desasignación de descriptores de archivos, ya que los sistemas operativos no

proporcionan suficiente

necesariamente. BigFiles también soportan opciones de compresión rudimentarias.

4.2.2 Repositorio

El repositorio contiene el HTML completo de cada página web.

Cada página se comprime usando zlib (véase RFC1950). los

La elección de la técnica de compresión es una compensación entre la velocidad

Y la relación de compresión. Elegimos la velocidad de zlib

Mejora significativa en la compresión ofrecida por bzip. los

La velocidad de compresión de bzip fue de aproximadamente 4 a 1 en el

Repositorio en comparación con la compresión de 3 a 1 de zlib. En el

Depositario, 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

Sólo el repositorio y un archivo que lista los errores del rastreador.

4.2.3 Índice de documentos

El índice de documentos mantiene información sobre cada documento. Es un ISAM de ancho fijo
(Índice secuencial

Modo de acceso), ordenado por docID. La información almacenada en cada entrada incluye la

El estado del documento, un puntero en el repositorio, una suma de comprobación del

documento y varias estadísticas. Si el

Documento se ha rastreado, también contiene un puntero en un archivo de anchura variable

llamado docinfo que

Contiene su URL y título. De lo contrario, el puntero apunta a la URLlist que contiene sólo la URL.

Esta decisión de diseño fue impulsada por el deseo de tener una estructura de datos
razonablemente compacta, y la

Capacidad de buscar un registro en una búsqueda de disco durante una búsqueda

Además, hay un archivo que se utiliza para convertir URLs en docIDs. Es una lista de sumas de
comprobación 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 verificación de la URL y se realiza una búsqueda binaria en el archivo de
sumas de comprobación para encontrar
Su docID. Las URL pueden convertirse en docIDs en lote haciendo una combinación con este
archivo. Este es el

Técnica que el URLresolver utiliza para convertir URLs en docIDs. Este modo de actualización por
lotes es crucial porque

De lo contrario debemos realizar una búsqueda para cada enlace que suponiendo que un disco
llevaría más de un

Mes para nuestro conjunto de datos de enlace de 322 millones.

4.2.4 Léxico

El léxico tiene varias formas diferentes. Un cambio importante de los sistemas anteriores es que el
léxico

Puede caber en la memoria por un precio razonable. En la implementación actual podemos

mantener el léxico en

Memoria en una máquina con 256 MB de memoria principal. El léxico actual contiene 14 millones
de palabras

(Aunque algunas palabras raras no fueron agregadas al léxico). 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

La lista de palabras tiene alguna información auxiliar que está más allá del alcance de este artículo
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

Información de posición, fuente y mayúsculas. Las listas de visitas representan la mayor parte del
espacio

Adelante y los índices invertidos. Debido a esto, es importante representarlos tan eficientemente
como

posible. Se consideraron varias alternativas para codificar la posición, fuente y mayúsculas - simple

Codificación (un triple de enteros), una codificación compacta (una asignación optimizada mano
de bits), y Huffman
codificación. Al final elegimos una codificación compacta optimizada manualmente ya que
requería mucho menos espacio que el

Codificación simple y mucho menos manipulación de bits que Huffman codificación. Los detalles
de los golpes se muestran en

Figura 3.

Nuestra codificación 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, título, texto de anclaje o
metaetiqueta. Los éxitos sencillos incluyen todo

más. Un golpe simple consiste en un bit de capitalización, tamaño de fuente y 12 bits de posición
de palabra en un documento (todos

Las posiciones superiores a 4095 están marcadas como 4096). El tamaño de la fuente se
representa con relación al resto del documento

Utilizando tres bits (sólo 7 valores se utilizan realmente porque 111 es el indicador que señala un
golpe de fantasía). Un elegante

Hit consiste en un bit de mayúsculas, el tamaño de fuente establecido en 7 para indicar que es un
golpe de fantasía, 4 bits para codificar el

Tipo de golpe de fantasía, y 8 bits de posición. Para los golpes de anclaje, los 8 bits de posición se
dividen en 4 bits para

Posición en el ancla y 4 bits para un hash de la docID el ancla se produce pulg Esto nos da algunos
limitados

Mientras no hay muchas anclas para una palabra en particular. Esperamos actualizar

La forma en que se almacenan los resultados de anclaje para permitir una mayor resolución en los
campos de posición y docIDhash.

Utilizamos el tamaño de fuente en relación con el resto del documento porque al buscar, no desea
clasificar

De lo contrario documentos idénticos de manera diferente sólo porque uno de los documentos
está en una fuente más grande.

La longitud de una lista de resultados se almacena antes de los golpes ellos mismos.

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 más larga de lo que cabría en

Bits, se usa un código 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 número de barriles (utilizamos 64). Cada barril

Tiene un rango de wordID. Si un documento contiene palabras

Que caen en un determinado barril, el docID se registra en

El barril, seguido por una lista de wordID con listas de

Corresponden a esas palabras. Este esquema requiere un ligero

Más de almacenamiento debido a duplicados docIDs, pero el

La diferencia es muy pequeña para un número razonable de cubos y ahorra tiempo considerable y
la codificación

Complejidad en la fase de indexación final realizada por el clasificador. Además, en lugar de

almacenar

WordID, almacenamos cada ID de palabra como una diferencia relativa con respecto al ID de
palabra mínimo que cae en la

Figura 3. Índices hacia delante y hacia atrás

Y el Léxico

Barrel el wordID es pulg De esta manera, podemos utilizar sólo 24 bits para el wordID en los
barriles sin clasificar,

Dejando 8 bits para la longitud de la lista de resultados.

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 válido, el léxico contiene un puntero en el barril
que

WordID cae en. Señala 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 cuestión importante es en qué orden deben aparecer los docID en el doclist. Una solución
simple es

Almacénelos ordenados por docID. Esto permite la rápida fusión de diferentes doclists para
múltiples palabras

Consultas. Otra opción es almacenarlos ordenados por un ranking de la ocurrencia de la palabra en

cada

documento. Esto hace que responder a una palabra de consultas trivial y hace probable que las
respuestas a

Las consultas de palabras múltiples están cerca del comienzo. Sin embargo, la fusión es mucho
más difícil. Además, esto hace que

Desarrollo mucho más difícil en que un cambio a la función de clasificación requiere una
reconstrucción del índice.

Elegimos un compromiso entre estas opciones, manteniendo dos conjuntos de barriles invertidos -
un conjunto para el éxito

Listas que incluyen hits de título 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 fósforos dentro de esos barriles comprobamos los más
grandes.

4.3 Rastreo de la Web

Ejecutar un rastreador web es una tarea difícil. Hay problemas difíciles de rendimiento y
confiabilidad y

Aún más importante, hay asuntos sociales. El rastreo es la aplicación más frágil ya que implica

Interactuando con cientos de miles de servidores web y varios servidores de nombres que están
más allá

El control del sistema.

Con el fin de escalar a cientos de millones de páginas web, Google tiene un sistema de rastreo
distribuido rápido. UN

Un solo servidor de URL sirve listas de direcciones URL a un número de rastreadores

(normalmente ejecutamos aproximadamente 3). Ambos

URLserver y los rastreadores se implementan en Python. Cada rastreador mantiene

aproximadamente 300 conexiones

Abierto a la vez. Esto es necesario para recuperar las páginas web a un ritmo lo suficientemente
rápido. A velocidades máximas, el sistema

Puede rastrear más de 100 páginas web por segundo utilizando cuatro rastreadores. Esto equivale
a aproximadamente 600 K por segundo

de datos. Un mayor estrés de rendimiento es la búsqueda de DNS. Cada rastreador mantiene una
caché DNS propia

No necesita hacer una búsqueda de DNS antes de rastrear cada documento. Cada uno de los
cientos de conexiones

Puede estar en varios estados diferentes: buscar DNS, conectarse al host, enviar solicitud y

Respuesta de recepción. Estos factores hacen que el rastreador sea un componente complejo del
sistema. Usa

E / S asíncrona para administrar eventos y una serie de colas para mover la búsqueda de páginas
de estado a estado.

Resulta que la ejecución de un rastreador que se conecta a más de medio millón de servidores, y
genera decenas

De millones de entradas de registro genera una cantidad justa de correo electrónico y llamadas
telefónicas. Debido al gran número de

De personas que vienen en línea, siempre hay quienes no saben lo que es un rastreador, porque
este es el

Primera que han visto. Casi todos los días, recibimos un mensaje de correo electrónico como,
"Wow, se miró a un montón de

Páginas de mi sitio web. ¿Cómo te gustó? "También hay algunas personas que no saben

Robots protocolo de exclusión, y creo que su página debe estar protegido de la indexación por una
declaración como,
"Esta página está protegida por derechos de autor y no debe ser indexada", lo que no es necesario
decir que es difícil para los rastreadores web

comprender. Además, debido a la enorme cantidad de datos involucrados, cosas inesperadas

sucederán. por

Por ejemplo, nuestro sistema intentó rastrear un juego en línea. Esto resultó en un montón de
mensajes de basura en el

Medio de su juego! Resulta que este fue un problema fácil de arreglar. Pero este problema no
había surgido

Hasta que habíamos descargado decenas de millones de páginas. Debido a la inmensa variación en
las páginas web y

Servidores, es prácticamente imposible probar un rastreador sin ejecutarlo en gran parte de

Internet.

Invariablemente, hay cientos de problemas oscuros que pueden ocurrir solamente en una página
fuera del conjunto

Web y hacer que el rastreador se bloquee, o peor, causar un comportamiento impredecible o

incorrecto. Sistemas que

Acceso a grandes partes de la Internet debe ser diseñado para ser muy robusto y cuidadosamente
probado. Desde grande

Sistemas complejos tales como rastreadores causarán invariablemente problemas, es necesario

que haya recursos significativos

Dedicado a leer el correo electrónico y resolver estos problemas a medida que vienen.

4.4 Indexación de la Web

Parsing - Cualquier analizador que está diseñado para ejecutarse en toda la Web debe manejar
una gran variedad de

Posibles errores. Estos van desde errores tipográficos en las etiquetas HTML a kilobytes de ceros
en el medio de una etiqueta,

Caracteres no ASCII, etiquetas HTML anidadas de cientos de profundidad, y una gran variedad de
otros errores que

Desafiar a la imaginación de nadie para llegar a otros igualmente creativos. Para una velocidad
máxima,
En lugar de utilizar YACC para generar un parser CFG, utilizamos flex para generar un analizador
léxico que

Nos equipamos con su propia pila. Desarrollando este analizador que funciona a una velocidad
razonable y es muy

Robusto implicó una cantidad justa de trabajo.

Documentos de indexación en barriles - Después de analizar cada documento, se codifica en un

número

De barriles. Cada palabra se convierte en un wordID mediante el uso de una tabla hash en
memoria - el léxico.

Las nuevas adiciones a la tabla de hash de léxico se registran en un archivo. Una vez que las
palabras se convierten en

WordID, sus ocurrencias en el documento actual se traducen en listas de visitas y se escriben en

Los barriles delanteros. La principal dificultad con la paralelización de la fase de indexación es que
la

El léxico debe ser compartido. En lugar de compartir el léxico, tomamos el enfoque de escribir un
registro de

Todas las palabras extra que no estaban en un léxico de base, que fijamos en 14 millones de
palabras. De esa manera

Varios indexadores pueden ejecutarse en paralelo y, a continuación, el pequeño archivo de

registro de palabras adicionales puede ser procesado por

Un indexador final.

Clasificación - Para generar el índice invertido, el clasificador toma cada uno de los barriles
delanteros y

Ordena por wordID para producir un barril invertido para los golpes de título y de anclaje y un
texto completo invertido

barril. Este proceso sucede un barril a la vez, requiriendo así poco almacenamiento temporal.
También nosotros

Paralelizar la fase de clasificación para utilizar tantas máquinas como las que tenemos
simplemente ejecutando múltiples Clasificadores, que pueden procesar diferentes cubetas al
mismo tiempo. Dado que los barriles no encajan en

Memoria, el clasificador los subdivide en cestas que encajan en la memoria basada en

WordID y docID. Entonces el clasificador, carga cada cesta en la memoria, la clasifica y escribe su
contenido

En el barril invertido corto y el barril invertido lleno.

4.5 Búsqueda

El objetivo de la búsqueda es proporcionar resultados de búsqueda de calidad de manera

eficiente. Muchos de los grandes

Los motores de búsqueda parecían haber hecho grandes progresos en términos de eficiencia. Por
lo tanto, nos hemos centrado

Más en calidad de búsqueda en nuestra investigación, aunque creemos que nuestras soluciones
son escalables a

Volúmenes con un poco más de esfuerzo. El proceso de evaluación de consultas de google se

muestra en la Figura 4.

Poner un límite en el tiempo de respuesta, una vez que un cierto número

(Actualmente 40.000) de documentos coincidentes,

El buscador pasa automáticamente al paso 8 de la figura 4. Esto

Significa que es posible que los resultados subóptimos sean

Devuelto Actualmente estamos investigando otras maneras de resolver

este problema. En el pasado, clasificamos los accesos según

PageRank, que parecía mejorar la situación.

4.5.1 El sistema de clasificación

Google mantiene mucha más información sobre la web

Documentos que los motores de búsqueda típicos. Todos los hitlist

Incluye información de posición, fuente y mayúsculas.

Adicionalmente, factorizamos los impactos del texto de anclaje y

PageRank del documento. Combinando todo esto

Información en un rango es difícil. Hemos diseñado nuestro ranking

Función de modo que ningún factor particular pueda tener

influencia. Primero, considere el caso más simple: una sola palabra

consulta. Para clasificar un documento con una sola palabra

Consulta, Google mira la lista de resultados de ese documento para esa palabra.

Google considera que cada golpe es uno de varios tipos diferentes (título, ancla, URL, fuente de
texto sin formato,

Texto en letra pequeña, ...), cada uno de los cuales tiene su propio peso-tipo. Los pesos de tipo
constituyen un vector

Indexados por tipo. Google cuenta el número de visitas de cada tipo en la lista de resultados.
Entonces cada cuenta es

Convertido en una cuenta-peso. Los pesos de conteo aumentan linealmente con los conteos al
principio, pero rápidamente disminuyen

De modo que más de un cierto conteo no ayudará. Tomamos el producto punto del vector de
contadores-pesos

Con el vector de pesos de tipo para calcular una puntuación de IR para el documento. Por último,
la puntuación IR es

Combinado con PageRank para dar un rango final al documento.

Para una búsqueda de múltiples palabras, la situación es más complicada. Ahora se deben
escanear múltiples listas de aciertos

A través de una vez para que los éxitos que ocurren cerca juntos en un documento se ponderan
más alto que los éxitos

Ocurriendo muy lejos. Los éxitos de las listas de múltiples aciertos se combinan para que los éxitos
cercanos sean igualados

juntos. Para cada conjunto de coincidencias, se calcula una proximidad. La proximidad se basa en
la

Aparte los golpes están en el documento (o el ancla) pero se clasifican en 10 "compartimientos"

diferentes del valor que se extienden de

Una frase coincidente con "ni siquiera cerca". Los conteos se calculan no sólo para cada tipo de
golpe sino para cada tipo

Y proximidad. Cada tipo y par de proximidad tiene un tipo-prox-peso. Los conteos se convierten en
Cuenta-pesos y tomamos el producto punto de los pesos de cuenta y los pesos de tipo-prox para
computar

Una puntuación de IR. Todos estos números y matrices se pueden mostrar con los resultados de la
búsqueda usando un

Modo de depuración especial. Estas pantallas han sido muy útiles en el desarrollo del sistema de
clasificación.

4.5.2 Comentarios

La función de clasificación tiene muchos parámetros como los pesos de tipo y los pesos de tipo-
prox. Averiguar

Los valores correctos para estos parámetros es algo de un arte negro. Para ello, tenemos un
usuario

Mecanismo de retroalimentación en el motor de búsqueda. Un usuario de confianza puede

evaluar opcionalmente todos los resultados que

Se devuelven. Esta retroalimentación se guarda. Entonces cuando modificamos la función de

clasificación, podemos ver el impacto

De este cambio en todas las búsquedas anteriores que fueron clasificados. Aunque lejos de ser
perfecto, esto nos da

1. Analizar la consulta.

2. Convierte palabras en wordIDs.

3. Busque el inicio del doclist en

El barril corto para cada palabra.

4. Escanear a través de los doclistas hasta

Hay un documento que coincide

Todos los términos de búsqueda.

5. Calcular el rango de ese

Documento para la consulta.

6. Si estamos en barricas cortas y en

El final de cualquier doclist, busque al

Inicio del doclist en el barril completo

Para cada palabra y vaya al paso 4.

7. Si no estamos al final de cualquier

Doclist vaya al paso 4.

Ordena los documentos que

Igualado por rango y devolver la parte superior

Figura 4. Evaluación de Google Query

Idea de cómo un cambio en la función de clasificación afecta a los resultados de búsqueda.

5 Resultados y Rendimiento

La medida más importante de una búsqueda

Motor es la calidad de sus resultados de búsqueda.

Mientras que una evaluación completa del usuario es

Más allá del alcance de este documento, nuestro

Experiencia con Google ha demostrado que

Mejores resultados que los principales

Motores de búsqueda comerciales para

Búsquedas. Como un ejemplo que ilustra

El uso de PageRank, el texto de anclaje, y

Proximidad, la Figura 4 muestra la

Resultados para una búsqueda en "bill clinton".

Estos resultados demuestran

Características de Google. Los resultados son

Agrupado por el servidor. Esto ayuda

Considerablemente al tamizar a través del resultado

Conjuntos Una serie de resultados provienen de la

Dominio whitehouse.gov que es lo que

Uno puede razonablemente esperar de tal

buscar. Actualmente, la mayoría de los

Los motores de búsqueda no devuelven ningún resultado

De whitehouse.gov, mucho menos el derecho

Otros. Observe que no hay título para el

Primer resultado. Esto es porque no fue

Rastreado En su lugar, Google se basó en el ancla

Texto para determinar esto fue una buena respuesta

A la consulta. Del mismo modo, el quinto resultado es

Una dirección de correo electrónico que, por supuesto, no es

Rastreable También es un resultado del texto de anclaje.

Todos los resultados son razonablemente altos

Páginas de calidad y, al finalizar, ninguno

Eran enlaces rotos. Esto se debe

Todos ellos tienen alto PageRank. los

Los rangos de página son los porcentajes en rojo

Junto con gráficos de barras. Por último, no hay resultados sobre un Bill que no sea Clinton o sobre
un Clinton

Que no sea Bill. Esto se debe a que ponemos una gran importancia en la proximidad de las
ocurrencias de palabras. De

Por supuesto, una verdadera prueba de la calidad de un motor de búsqueda implicaría un extenso
estudio de usuario o resultados

Análisis que no tenemos espacio para aquí. En su lugar, invitamos al lector a probar Google por sí
mismos

En http://google.stanford.edu.

5.1 Requisitos de almacenamiento

Consulta: bill clinton

Http://www.whitehouse.gov/

100.00% (sin fecha) (0K)

Http://www.whitehouse.gov/

La oficina del presidente

99,67% (23 de diciembre de 1996) (2K)

Http://www.whitehouse.gov/WH/EOP/OP/html/OP_Home.html

Bienvenido a la Casa Blanca

99,98% (Nov 09 1997) (5K)

Http://www.whitehouse.gov/WH/Welcome.html

Enviar correo electrónico al presidente

99,86% (14 de julio de 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% (11 de noviembre de 1997) (14K)

Http://zpub.com/un/un-bc.html

Bill Clinton se encuentra con los encogimientos

86,27% (29 de junio de 1997) (63K)

Http://zpub.com/un/un-bc9.html

Presidente Bill Clinton - El Lado Oscuro

97,27% (10 de noviembre de 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. Resultados de la muestra de Google

Aparte de la calidad de la búsqueda, Google está diseñado para escalar de forma rentable el
tamaño de la Web, ya que

Crece Un aspecto de esto es usar el almacenamiento eficientemente. El cuadro 1 presenta un

desglose de algunas estadísticas y

Requisitos de almacenamiento de Google. Debido a la compresión, el tamaño total del repositorio

es de unos 53 GB,

Más de un tercio del total de datos que almacena. A los precios actuales del disco esto hace que el
repositorio sea relativamente

Fuente barata de datos útiles. Más importante aún, el total de todos los datos utilizados por el
motor de búsqueda requiere

Una cantidad comparable de almacenamiento, unos 55 GB. Además, la mayoría de las consultas se
pueden contestar

Índice invertido corto. Con una mejor codificación y compresión del índice de documentos, una
web de alta calidad

Motor de búsqueda puede encajar en una unidad de 7 GB de un nuevo PC.

5.2 Rendimiento del sistema

Es importante que un motor de búsqueda rastree e indexe

eficientemente. De esta forma, la información puede mantenerse actualizada y

Los cambios importantes en el sistema se pueden probar con relativa rapidez.

Para Google, las principales operaciones son rastreo, indexación,

Y Clasificación. Es difícil medir cuánto tiempo se arrastran

Tomó en general porque los discos se llenaron, servidores de nombres se estrelló,

O cualquier número de otros problemas que pararon el sistema.

En total tardaron aproximadamente 9 días en descargar los 26 millones

Páginas (incluyendo errores). Sin embargo, una vez

Funcionando sin problemas, se ejecutó mucho más rápido, la descarga de la última

11 millones de páginas en sólo 63 horas, promediando un poco más de 4

Millones de páginas por día o 48,5 páginas por segundo. Dirigimos el

Indexador y el rastreador simultáneamente. El indexador funcionó sólo

Más rápido que los rastreadores. Esto se debe en gran medida a que

Suficiente tiempo optimizando el indexador para que no sea

embotellamiento. Estas optimizaciones incluyeron actualizaciones masivas

El índice de documentos y la colocación de estructuras de

El disco local. El indexador se ejecuta en aproximadamente 54 páginas por

segundo. Los clasificadores se pueden ejecutar completamente en paralelo; utilizando

Cuatro máquinas, todo el proceso de selección toma alrededor de 24

Horas.

5.3 Desempeño de la búsqueda

Mejorar el desempeño de la búsqueda no fue el foco principal de nuestra investigación hasta este
punto. los

La versión actual de Google responde a la mayoría de las consultas entre 1 y 10 segundos. Esta vez
es mayormente

Dominado por el disco IO sobre NFS (ya que los discos están distribuidos en varias máquinas).
Además,

Google no tiene ninguna optimización como el almacenamiento en caché de consultas, subíndices

en términos comunes y otros

Optimizaciones comunes. Tenemos la intención de acelerar Google considerablemente a través de

la distribución y el hardware,

Software y mejoras algorítmicas. Nuestro objetivo es ser capaz de manejar cientos de consultas
por

segundo. La Tabla 2 tiene algunos tiempos de consulta de ejemplo de la versión actual de Google.
Se repiten para

Mostrar las aceleraciones resultantes de E / S en caché.

Estadísticas de Almacenamiento

Tamaño total de páginas recuperadas 147.8 GB

Depósito comprimido 53.5 GB

Índice invertido corto 4,1 GB

Índice completo invertido 37.2 GB

Léxico 293 MB

Datos de anclaje temporales

(No en total) 6.6 GB

Índice de documentos Incl.

Datos de ancho variable 9.7 GB

Base de datos de enlaces 3.9 GB

Total sin repositorio 55,2 GB

Total Con repositorio 108,7 GB

Estadísticas de la página web

Número de Páginas Web

Se recaudaron 24 millones

Número de urls vistos 76,5 millones

Número de correo electrónico

Direcciones 1,7 millones

Número de 404's 1,6 millones

Cuadro 1. Estadísticas

6. Conclusiones

Google está diseñado para ser un motor de búsqueda escalable.

El objetivo principal es proporcionar una búsqueda de alta calidad

Resultados sobre un World Wide Web cada vez más rápido.

Google emplea una serie de técnicas para mejorar

La calidad de búsqueda incluyendo el rango de página, el texto de anclaje y

Información de proximidad. Además, Google es un

Arquitectura completa para reunir páginas web,

Indexarlos y realizar consultas de búsqueda sobre

ellos.

6.1 Trabajo futuro

Un motor de búsqueda web a gran escala es un sistema complejo y aún queda mucho por hacer.
Nuestro inmediato

Los objetivos son mejorar la eficiencia de búsqueda y escalar a aproximadamente 100 millones de
páginas web. Algunos

Las mejoras simples de la eficiencia incluyen el almacenamiento en caché de consultas, la

asignación de discos inteligentes y los subíndices.

Otra área que requiere mucha investigación es las actualizaciones. Debemos tener algoritmos
inteligentes para decidir qué

Las páginas web viejas deben ser rastreadas y qué nuevas deben ser rastreadas. El trabajo hacia
esta meta

Hecho en [Cho 98]. Un área prometedora de investigación está utilizando escondrijos proxy para
construir bases de datos de búsqueda,

Ya que son impulsados por la demanda. Estamos planeando agregar funciones sencillas
compatibles con la búsqueda comercial

Motores como operadores booleanos, negación y derivación. Sin embargo, otras características
están empezando a ser

Como la retroalimentación de relevancia y la agrupación en clúster (Google actualmente admite

un nombre de

Agrupación). También planeamos apoyar el contexto del usuario (como la ubicación del usuario) y
el resumen de resultados. Nosotros

También están trabajando para ampliar el uso de la estructura del enlace y el texto del enlace.
Experimentos simples indican PageRank
Puede personalizarse aumentando el peso de la página principal o de los marcadores de un
usuario. En cuanto al texto del enlace,

Están experimentando con el uso de texto alrededor de los enlaces, además del texto del enlace
en sí. Una búsqueda en la Web

Motor es un entorno muy rico para las ideas de investigación. Tenemos demasiados para
enumerar aquí así que no

Esperamos que esta sección de Trabajo Futuro sea mucho más corta en un futuro próximo.

6.2 Búsqueda de alta calidad

El mayor problema que enfrentan los usuarios de los motores de búsqueda web hoy en día es la
calidad de los resultados que reciben de vuelta.

Si bien los resultados son a menudo divertidos y ampliar los horizontes de los usuarios, a menudo
son frustrantes y consumen

tiempo precioso. Por ejemplo, el resultado superior para una búsqueda de "Bill Clinton" en uno de
los

Los motores de búsqueda comerciales era la broma de Bill Clinton del día: 14 de abril, 1997.
Google se diseña para

Proporcionar una búsqueda de mayor calidad para que la Web siga creciendo rápidamente, la
información se puede encontrar fácilmente.

Con el fin de lograr esto Google hace un gran uso de la información hipertextual que consiste en el
enlace

Estructura y enlace (ancla) del texto. Google también utiliza información de proximidad y fuente.
Si bien la evaluación de un

Motor de búsqueda es difícil, hemos encontrado subjetivamente que Google devuelve resultados
de búsqueda de mayor calidad

Que los motores de búsqueda comerciales actuales. El análisis de la estructura de enlaces a través
de PageRank permite a Google

Evaluar la calidad de las páginas web. El uso de texto de enlace como una descripción de lo que el
vínculo apunta a ayuda

Los resultados del motor de búsqueda pertinentes (y en cierto grado de alta calidad). Por último,
el uso de la proximidad

Información ayuda a aumentar la relevancia mucho para muchas consultas.

Consulta inicial

Misma consulta

Repetido (IO

En su mayoría en caché)

Consulta de la CPU

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

difícil

Discos 0,25 4,86 0,20 0,24

buscar

Motores 1,31 9,63 1,16 1,16

Tabla 2. Tiempos de búsqueda

6.3 Arquitectura escalable

Aparte de la calidad de la búsqueda, Google está diseñado para escalar. Debe ser eficiente tanto
en el espacio como en el tiempo,

Y los factores constantes son muy importantes cuando se trata con toda la Web. En la
implementación de Google,

Han visto cuellos de botella en la CPU, el acceso a la memoria, la capacidad de memoria, el disco
busca, el rendimiento del disco, el disco
Capacidad y IO de red. Google ha evolucionado para superar una serie de cuellos de botella
durante

Varias operaciones. Las principales estructuras de datos de Google hacen un uso eficiente del
espacio de almacenamiento disponible.

Además, las operaciones de rastreo, indexación y clasificación son lo suficientemente eficaces para
poder

Índice de una parte sustancial de la web - 24 millones de páginas, en menos de una semana.
Esperamos poder

Para construir un índice de 100 millones de páginas en menos de un mes.

6.4 Una herramienta de investigación

Además de ser un motor de búsqueda de alta calidad, Google es una herramienta de investigación.
Los datos que Google

Recogido ya ha dado lugar a muchos otros trabajos presentados a conferencias y muchos más
sobre la

camino. Investigaciones recientes como [Abiteboul 97] han mostrado una serie de limitaciones a
las

Web que puede ser contestada sin tener la Web disponible localmente. Esto significa que Google
(o un

Sistema similar) no es sólo una valiosa herramienta de investigación sino necesaria para una
amplia gama de aplicaciones.

Esperamos que Google sea un recurso para buscadores e investigadores de todo el mundo y

Próxima generación de tecnología de motores de búsqueda.

7 Agradecimientos

Scott Hassan y Alan Steremberg han sido críticos para el desarrollo de Google. Su talento

Las contribuciones son insustituibles, y los autores les deben mucha gratitud. También queremos
agradecer

Héctor García-Molina, Rajeev Motwani, Jeff Ullman y Terry Winograd y toda la WebBase

Grupo por su apoyo y discusiones perspicaces. Por último, queremos reconocer la generosidad

Apoyo de nuestros proveedores de equipos IBM, Intel, y Sun y nuestros financiadores. La

investigación descrita aquí fue
Realizado como parte del Proyecto de Biblioteca Digital Integrada de Stanford, apoyado por el
National Science

Fundación en virtud del Acuerdo de Cooperación IRI-9411306. La financiación de este acuerdo de

cooperación

Proporcionados por DARPA y NASA, y por Interval Research, y los socios industriales de Stanford

Proyecto de Bibliotecas Digitales.

Referencias

Lo Mejor de la Web 1994 - Navegadores http://botw.org/1994/awards/navigators.html

Bill Clinton Broma del día: 14 de abril de 1997. http://www.io.com/~cjburke/clinton/970414.html.

Página de inicio de Bzip2 http://www.muraroa.demon.co.uk/

Motor de búsqueda de Google http://google.stanford.edu/

Cosecha http://harvest.transarc.com/

Mauldin, Michael L. Lycos Opciones de Diseño en un Servicio de Búsqueda en Internet, Entrevista

de Expertos del IEEE

Http://www.computer.org/pubs/expert/1997/trends/x1008/mauldin.htm

El efecto del uso del teléfono celular sobre la atención del conductor

Http://www.webfirst.com/aaa/text/cell/cell0toc.htm

Reloj del Search Engine http://www.searchenginewatch.com/

RFC 1950 (zlib) ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html

Protocolo de exclusión de robots: http://info.webcrawler.com/mak/projects/robots/exclusion.htm

Crecimiento del Web: http://www.mit.edu/people/mkgray/net/web-growth-summary.html

Yahoo! http://www.yahoo.com/

[Abiteboul 97] Serge Abiteboul y Víctor Vianu, Consultas y Cómputo en la Web.

Actas de la Conferencia Internacional sobre la Teoría de Bases de Datos. Delphi, Grecia 1997.

[Bagdikian 97] Ben H. Bagdikian. El Monopolio de los Medios. 5ª Edición. Editorial: Beacon, ISBN:

0807061557

[Cho 98] Junghoo Cho,

Vitae

Sergey Brin recibió su B.S. Licenciatura en matemáticas e informática

De la Universidad de Maryland en College Park en 1993. Actualmente, es un

Doctor en Filosofía. Candidato en informática en la Universidad de Stanford, donde recibió

Su M.S. En 1995. Él es un recipiente de un graduado de la fundación nacional de la ciencia

Compañerismo. Sus intereses de investigación incluyen motores de búsqueda, información

Extracción de fuentes no estructuradas y minería de datos de grandes colecciones de texto

Y datos científicos.

Lawrence Page nació en East Lansing, Michigan, y recibió un B.S.E.

En Ingeniería Informática en la Universidad de Michigan Ann Arbor en 1995.

Actualmente es Ph.D. Candidato en Ciencias de la Computación en la Universidad de Stanford.

Algunos de sus intereses de investigación incluyen la estructura de enlace de la web,

Interacción por ordenador, motores de búsqueda, escalabilidad del acceso a la información

Interfaces y minería de datos personales.

8 Apéndice A: Publicidad y motivos mixtos

Actualmente, el modelo de negocio predominante para los motores de búsqueda comerciales es la

publicidad. Los objetivos de

El modelo de negocio publicitario no siempre corresponde a la búsqueda de calidad a los usuarios.

por

Por ejemplo, en nuestro prototipo de motor de búsqueda uno de los mejores resultados para el
teléfono celular es "The Effect of

Uso del teléfono celular con la atención del conductor ", un estudio que explica con gran detalle
las distracciones y

Riesgo asociado con la conversación en un teléfono celular mientras se conduce. Este resultado de
búsqueda surgió primero porque

De su alta importancia como juzgado por el PageRank algoritmo, una aproximación de la

importancia de la cita en
La web [Página, 98]. Está claro que un motor de búsqueda que estaba tomando dinero para
mostrar el teléfono celular

Los anuncios tendrían dificultad para justificar la página que nuestro sistema devolvió a sus
anunciantes pagadores. Para esto

Tipo de razón y experiencia histórica con otros medios [Bagdikian 83], esperamos que la
publicidad

Los motores de búsqueda financiados serán inherentemente sesgados hacia los anunciantes y
lejos de las necesidades del

Consumidores.

Puesto que es muy difícil incluso para los expertos evaluar los motores de búsqueda, el sesgo del
motor de búsqueda es particularmente

insidioso. Un buen ejemplo fue OpenText, que se informó que vendía a las empresas el derecho a
ser

Enumerados en la parte superior de los resultados de búsqueda para consultas particulares

[Marchiori 97]. Este tipo de sesgo es

Más insidioso que la publicidad, porque no está claro quién "merece" estar allí, y quién está
dispuesto a

Pagar dinero para ser incluido. Este modelo de negocio resultó en un alboroto, y OpenText ha
dejado de ser un

Motor de búsqueda viable. Pero es menos probable que el mercado tolere un sesgo menos
evidente. Por ejemplo, una búsqueda

Motor podría añadir un pequeño factor a los resultados de búsqueda de las empresas "amigables",
y restar un factor de

Resultados de los competidores. Este tipo de sesgo es muy difícil de detectar, pero podría

Efecto en el mercado. Además, los ingresos publicitarios suelen ser un incentivo para

Resultados de búsqueda de calidad. Por ejemplo, nos dimos cuenta de que un motor de búsqueda
importante no devolvería una gran compañía aérea

Cuando el nombre de la aerolínea fue dado como una consulta. Ocurrió que la aerolínea había

Caro, vinculado a la consulta que era su nombre. Un mejor motor de búsqueda no lo habría
requerido
Anuncio, y posiblemente resultó en la pérdida de los ingresos de la compañía aérea para el motor
de búsqueda. En general,

Se podría argumentar desde el punto de vista del consumidor que cuanto mejor sea el buscador,
menos

Los anuncios serán necesarios para que el consumidor encuentre lo que quiere. Por supuesto, esto

Publicidad apoyado modelo de negocio de los motores de búsqueda existentes. Sin embargo,
siempre habrá

Dinero de los anunciantes que quieren que un cliente cambie productos, o que tengan algo que
sea genuinamente

nuevo. Pero creemos que la cuestión de la publicidad causa suficientes incentivos mixtos que es
crucial tener un

Competitivo motor de búsqueda que es transparente y en el ámbito académico.

9 Apéndice B: Escalabilidad

9. 1 Escalabilidad de Google

Hemos diseñado Google para ser escalable en el corto plazo a una meta de 100 millones de
páginas web. Tenemos

Acaba de recibir el disco y las máquinas para manejar aproximadamente esa cantidad. Todas las
partes que consumen mucho tiempo del

Sistema son paralelos y aproximadamente tiempo lineal. Estos incluyen cosas como los
rastreadores, indexadores y

Clasificadores También pensamos que la mayoría de las estructuras de datos tratarán con gracia la
expansión. Sin embargo,

En 100 millones de páginas web estaremos muy cerca de todo tipo de límites del sistema
operativo en la

Sistemas operativos comunes (actualmente se ejecutan en Solaris y Linux). Estos incluyen cosas
como

Memoria direccionable, número de descriptores de archivos abiertos, tomas de red y ancho de

banda, y muchos otros.

Creemos que la expansión a más de 100 millones de páginas aumentaría enormemente la

complejidad de nuestras

sistema.
9.2 Escalabilidad de las arquitecturas de indexación centralizadas

A medida que aumentan las capacidades de los ordenadores, es posible indexar una gran cantidad
de texto para

costo razonable. Por supuesto, es probable que otros medios de mayor uso de ancho de banda,
como el video, se conviertan en

Más penetrante. Pero, como el costo de producción del texto es bajo comparado con los medios
como el video, el texto es

Es probable que siga siendo muy penetrante. También, es probable que pronto tendremos
reconocimiento del habla que haga un

Trabajo razonable que convierte el discurso en texto, ampliando la cantidad de texto disponible.
Todo esto proporciona

Increíbles posibilidades de indexación centralizada. He aquí un ejemplo ilustrativo. Suponemos

que queremos

Índice que todo el mundo en los EE.UU. ha escrito durante un año. Asumimos que hay 250
millones de personas

En los Estados Unidos y escriben un promedio de 10k por día. Eso supone unos 850 terabytes.
también

Suponer que la indexación de un terabyte se puede hacer ahora por un costo razonable. También
suponemos que la

Los métodos de indexación utilizados sobre el texto son lineales o casi lineales en su complejidad.
Dado todo esto

Podemos calcular cuánto tiempo nos llevaría antes de poder indexar nuestros 850 terabytes

Costo razonable asumiendo ciertos factores de crecimiento. La Ley de Moore se definió en 1965
como una duplicación

18 meses en potencia del procesador. Ha sido notablemente cierto, no sólo para los procesadores,
sino para otros

Parámetros importantes del sistema, como el disco también. Si asumimos que la ley de Moore es
válida para el futuro,

Solo necesitamos 10 duplicaciones más, o 15 años para alcanzar nuestro objetivo de indexar todo
lo que
EE.UU. ha escrito durante un año por un precio que una pequeña empresa podía permitirse. Por
supuesto, los expertos en hardware son

La Ley de Moore no puede seguir manteniéndose durante los próximos 15 años, pero

Ciertamente un montón de interesantes aplicaciones centralizadas, incluso si sólo recibimos parte

del camino a nuestro

Ejemplo hipotético.

Por supuesto, sistemas distribuidos como Gloss [Gravano 94] o Harvest serán a menudo los
sistemas más eficientes y

Elegante solución técnica para la indexación, pero parece difícil convencer al mundo de utilizar
estos sistemas

Debido a los altos costos de administración de la instalación de un gran número de instalaciones.

Por supuesto que es

Es muy probable que la reducción drástica del costo de administración sea posible. Si eso sucede, y
todo el mundo

Comienza a ejecutar un sistema de indexación distribuida, la búsqueda sin duda mejorará

drásticamente.

Debido a que los seres humanos sólo pueden escribir o hablar una cantidad finita, y como las
computadoras continúan mejorando, el texto

La indexación se escalará aún mejor de lo que lo hace ahora. Por supuesto, podría haber una
cantidad infinita de máquina

Generado contenido, pero sólo la indexación de grandes cantidades de contenido humano

generado parece tremendamente

útil. Así que estamos optimistas de que nuestra arquitectura centralizada de motores de búsqueda
web mejorará en su

Capacidad de cubrir la información de texto pertinente en el tiempo y que hay un futuro brillante
para la búsqueda.