La anatomía de un hipertextual a gran escala

Buscador web
Sergey Brin y Lawrence Page
Departamento de Informática,
Universidad de Stanford, Stanford, CA 94305, EE.UU.
sergey@cs.stanford.edu y page@cs.stanford.edu

Resumen
En este artículo, presentamos Google, un prototipo de un motor de búsqueda a gran
escala que hace pesado Uso de la estructura presente en el 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 completo. La base de datos de texto e hipervínculos de al menos 24 millones de
páginas está disponible en http://google.stanford.edu/ Diseñar un motor de
búsqueda es una tarea desafiante. Los buscadores indexan decenas a cientos de
Millones de páginas web que involucran un número comparable de términos
distintos. Responden decenas de Millones de consultas todos los días. A pesar de
la importancia de los motores de búsqueda a gran escala en la web, Se ha hecho
muy poca investigación académica sobre ellos. Además, debido al rápido avance
en
La tecnología y la proliferación web, crear 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
detallada de nuestro motor de búsqueda web a gran escala:
La primera descripción pública detallada que conocemos hasta la fecha. Aparte de
los problemas de escalado. Técnicas de búsqueda tradicionales a datos de esta
magnitud, hay nuevos desafíos técnicos involucrados con el uso de la información
adicional presente en el hipertexto para producir mejores resultados de
búsqueda. Esta El documento aborda esta cuestión de cómo construir un sistema
práctico a gran escala que pueda explotar el Información adicional presente en
hipertexto. También nos fijamos en el problema de cómo tratar con eficacia con
colecciones de hipertexto no controladas donde cualquier persona puede publicar
lo que quiera.

Palabras clave

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

Google

1. Introducción
(Nota: hay dos versiones de este documento: una versión completa más larga y una
versión impresa más corta. La 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
información. La cantidad de información en la web es creciendo rápidamente, así
como la cantidad de usuarios nuevos sin experiencia en el arte de la investigación
web. La gente es probable que navegue por la web usando su gráfico de enlace, a
menudo comenzando con índices humanos de alta calidad mantenidos como
Yahoo! o con motores de búsqueda. Las listas mantenidas por humanos cubren
temas populares de manera efectiva pero subjetivo, costoso 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 concordancia de palabras
clave generalmente devuelven demasiadas coincidencias de baja calidad. Para
empeorar las cosas, algunos anunciantes intentan llamar la atención de las
personas tomando medidas destinadas a engañar a los motores de búsqueda
automatizados. Hemos construido un motor de búsqueda a gran escala que aborda
muchos de los problemas de los sistemas existentes. Hace un uso especialmente
pesado de la estructura adicional presente en hipertexto para proporcionar
resultados de búsqueda de calidad mucho más alta. Elegimos el nombre de nuestro
sistema, Google, porque Es una ortografía común de googol, o 10100 y encaja bien
con nuestro objetivo de construir búsquedas a gran escala los motores.

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

La tecnología de 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 accesibles en la web. A partir de
noviembre de 1997, los principales buscadores reclama 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 completo de la Web contendrá
más de un mil millones de documentos al mismo tiempo, el número de consultas
que manejan los motores de búsqueda ha crecido increíblemente también, en marzo
y abril de 1994, el World Wide Web Worm 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 un 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
mediante escalado tecnología de motores de búsqueda a números tan
extraordinarios.

1.2. Google: escalado con la web

Crear un motor de búsqueda que se adapte incluso a la web actual presenta muchos
desafíos:
-Rastreo rápido se necesita tecnología para reunir los documentos web y
mantenerlos actualizados.
-Espacio de almacenamiento debe ser utilizado.
-Eficacia para almacenar índices y, opcionalmente, los propios documentos.
El sistema de indexación debe ser procesado, cientos de gigabytes de datos
eficientemente, las consultas deben ser manejadas rápidamente, a una tasa de
cientos de miles por segundo Estas tareas son cada vez más difíciles a medida que
la Web crece. Sin embargo, el rendimiento del hardware y los costos han mejorado
dramáticamente para compensar parcialmente la dificultad. Hay, sin embargo,
varias notables, excepciones a este progreso, como el tiempo de búsqueda del
disco y la solidez del sistema operativo. En el diseño de Google, hemos considerado
tanto la tasa de crecimiento de la web como los cambios tecnológicos, google está
diseñado para escalar 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 de, el índice y el texto de la tienda o HTML
finalmente declinarán en relación con la cantidad que estará disponible (ver
apéndice B). Esto dará como resultado propiedades de escalamiento favorables
para sistemas centralizados como Google.

1.3 Objetivos de diseño

1.3.1 Calidad de búsqueda mejorada

Nuestro principal objetivo es mejorar la calidad de los buscadores web. En 1994,
algunas personas creían que una el índice de búsqueda completo permitiría
encontrar cualquier cosa fácilmente, según lo mejor de la web 1994 -navegadores,
"El mejor servicio de navegación debería hacer que sea fácil encontrar casi
cualquier cosa en el web (una vez que se ingresan todos los datos). "Sin embargo,
la Web de 1997 es bastante diferente. Cualquiera que haya usado un motor de
búsqueda recientemente, puede testificar fácilmente que la integridad del índice no
es el único factor en la calidad de los resultados de búsqueda. Los "resultados no
deseados" a menudo eliminan cualquier resultado que le interese a un usuario. De
hecho, a partir de noviembre de 1997, solo uno de los cuatro motores de búsqueda
comerciales principales se encuentra (devuelve su propio 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 la capacidad de mirar
documentos no lo ha hecho, la gente todavía está dispuesta a ver las primeras
decenas de resultados debido a esto, a medida que crece el tamaño de la colección,
necesitamos herramientas que tienen una precisión muy alta (número de
documentos relevantes devueltos, digamos en los diez primeros resultados). De
hecho, queremos que nuestra noción de "relevante" solo incluye los mejores
documentos, ya que puede haber decenas de miles de documentos ligeramente
relevantes, esta precisión tan alta es importante incluso a expensas de la
recuperación (el número total de documentos relevantes que el sistema puede
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] [Klineberg 98]. En particular, la estructura del enlace [Página
98] y el texto del 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 de motores de búsqueda académicos
Aparte del tremendo crecimiento, la Web también se ha vuelto cada vez más
comercial con el tiempo, en 1993, 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
buscadores han migrado del dominio académico al comercial, hasta ahora más
búsqueda, el desarrollo de motores ha continuado en compañías con poca
publicación de detalles técnicos, esto causa la tecnología de motores de búsqueda
seguirá siendo en gran medida un arte negro y estará orientada a la publicidad (ver
Apéndice A). Con Google, tenemos un gran objetivo de impulsar un mayor
desarrollo y comprensión en el ámbito académico. Otro objetivo importante del
diseño era construir sistemas que un número razonable de personas pudieran usar.
El uso fue importante para nosotros porque creemos que algunas de las
investigaciones más interesantes implicarán aprovechando la gran cantidad de
datos de uso disponibles en los sistemas web modernos. Por ejemplo, hoy son
muchas las decenas de millones de búsquedas que se realizan 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 apoyar nuevas actividades de investigación en datos web
a gran escala. Para respaldar los 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 era crear un entorno donde otros
investigadores pueden ingresar rápidamente, procesar grandes porciones de la web
y producir resultados interesantes, eso hubiera sido muy difícil de producir de otra
manera. En el corto tiempo que el sistema ha estado funcionando, ya se han
publicado varios artículos utilizando bases de datos generadas por Google, y
muchos otros están en curso. Otro objetivo que tenemos es establecer un entorno
similar a Spacelab donde los investigadores o incluso los 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 lo
ayudan a producir resultados de alta precisión. Primero, hace uso de la estructura
de enlaces de la Web para calcular un ranking 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 los resultados de la búsqueda.

2.1 PageRank: Llevar el orden a la Web

El gráfico de citas (enlaces) de la web es un recurso importante que en gran medida
no se ha utilizado en las redes existentes buscadores web Hemos creado mapas
que contienen hasta 518 millones de estos hipervínculos, un muestra significativa
del total. Estos mapas permiten el cálculo rápido del "PageRank" de una página
web, una medida objetiva de su importancia de la cita que se corresponde bien con
la idea subjetiva de las personas importancia. Debido a esta correspondencia,
PageRank es una excelente manera de priorizar los resultados de búsquedas de
palabras clave en la web. Para los temas más populares, una búsqueda de
coincidencia de texto simple que está restringida a la web los títulos de las páginas
funcionan de manera admirable cuando PageRank prioriza los resultados (la
demostración está disponible en google.stanford.edu). Para el tipo de búsquedas
de texto completo en el sistema principal de Google, PageRank también ayuda
mucho.

2.1.1 Descripción del cálculo de PageRank

La bibliografía de citas académicas se ha aplicado a la web, en gran parte contando
citas o vínculos de retroceso a una página dada esto da una aproximación de la
importancia o calidad de una página. PageRank extiende esto idea al no contar los
enlaces de todas las páginas por igual, y al normalizar la cantidad de enlaces en
una página. PageRank se define de la siguiente manera:
Asumimos que la página A tiene páginas T1. Tn que apuntan a ella (es decir, son
citas). El parámetro d es un factor de amortiguamiento que se puede establecer
entre 0 y 1. Por lo general, establecemos d en 0,85. Existen más detalles sobre d
en la siguiente sección. También C (A) se define como el número de enlaces que
van fuera de la página A. El PageRank de una página 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 distribución de probabilidad en las
páginas web, por lo que la suma de todas las páginas web de PageRanks será una
el PageRank o PR (A) se puede calcular utilizando un algoritmo iterativo simple, y
corresponde al vector propio principal de la matriz de enlaces normalizados de la
web. Además, un PageRank por 26 millones de web. Las páginas se pueden
calcular en unas pocas horas en una estación de trabajo de tamaño medio. Hay
muchos otros detalles que están más allá del alcance de este documento.

2.1.2 Justificación intuitiva

El PageRank se puede considerar como un modelo de comportamiento del
usuario. Suponemos que hay un "surfista aleatorio" que se le da una página web al
azar y sigue haciendo clic en los enlaces, nunca pulsando "atrás" pero finalmente
se aburre y comienza en otra página al azar. La probabilidad de que el internauta
aleatorio visite una página es su PageRank, y, el factor de amortiguamiento D es la
probabilidad en cada página del "navegante aleatorio" se aburrirá y la solicitud otra
página al azar. Una variación importante es agregar solo el factor de
amortiguamiento d a una sola página, o un grupo de páginas, esto permite la
personalización y puede hacer casi imposible deliberadamente engañar al sistema
con el fin de obtener una clasificación más alta. Tenemos varias otras extensiones
para PageRank, nuevamente vea [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 lo señalan y tienen un alto PageRank. Intuitivamente, las
páginas que están bien. Vale la pena mirar los lugares citados en muchos lugares
de la red. Además, las páginas que quizás tengan una sola cita de algo como el
Yahoo! La página de inicio también vale la pena mirar. Si una página no estuviera
de alta calidad, o era un enlace roto, es muy probable que la página de inicio de
Yahoo! no lo haga. PageRank maneja estos casos y todo lo que hay entre ellos
mediante la propagación recursiva de pesos a través de la estructura de enlaces de
la web.
2.2 texto de anclaje
El texto de los enlaces se trata de una manera especial en nuestro motor de
búsqueda, la mayoría de los buscadores 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. Primero, los anclajes a menudo
proporcionan descripciones más precisas de las páginas web que las páginas
mismas Segundo, pueden existir anclajes para documentos que no pueden ser
indexados por un motor de búsqueda basado en texto, como imágenes, programas
y bases de datos. Esto hace posible devolver web, páginas que en realidad no han
sido rastreadas. Tenga en cuenta que las páginas que no se han rastreado pueden
causar problemas, ya que nunca se comprueban la validez antes de devolverse 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 que la apuntaban, sin embargo,
es posible ordenar los resultados, por lo que este problema en particular rara vez
ocurre, esta idea de propagar el texto de anclaje a la página a la que hace referencia
se implementó en la World Wide Web. Worm [McBryan 94] especialmente porque
ayuda a buscar información no textual y expande la búsqueda cobertura con menos
documentos descargados. Utilizamos la propagación de anclaje principalmente
porque el texto de anclaje puede ayudar a proporcionar mejores resultados de
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 actual rastreo
de 24 millones de páginas, tuvimos más de 259 millones de anclajes que
indexamos.

2.3 Otras características

Aparte de PageRank y el uso de texto de anclaje, Google tiene varias otras
características. Primero, tiene ubicación de información para todos los hits y por lo
tanto hace un uso extensivo de la proximidad en la búsqueda. En segundo lugar,
Google realiza un seguimiento de algunos detalles de presentación visual como el
tamaño de letra de las palabras. Las palabras en una fuente más grande o más
audaz son ponderadas más alto que otras palabras. En tercer lugar, el HTML
completo en bruto de las páginas está disponible en un repositorio.

3 trabajos relacionados
Búsqueda de investigación en la web tiene una historia corta y concisa. El gusano
de la red mundial (WWWW) [McBryan 94] fue uno de los primeros motores de
búsqueda web. Posteriormente fue seguido por varios otros buscadores
académicos, muchos de los cuales son ahora empresas públicas, comparado con
el crecimiento de la web y la importancia de los motores de búsqueda son muy
pocos documentos sobre los motores de búsqueda recientes [Pinkerton 94]. Según
Michael Mauldin (científico jefe, Lycos Inc.) [Mauldin], "los diversos servicios
(incluyendo Lycos) guardan de cerca los detalles de estas bases de datos”. Sin
embargo, ha habido una feria cantidad de trabajo en características específicas de
los motores de búsqueda. Especialmente bien representado es el trabajo que puede
obtenga resultados post-procesando los resultados de los motores de búsqueda
comerciales existentes, o produzca a pequeña escala buscadores
"individualizados". Finalmente, ha habido mucha investigación sobre recuperación
de información. Sistemas, especialmente en colecciones bien controladas en las
siguientes dos secciones, discutimos algunas áreas donde esta investigación debe
ampliarse para funcionar 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 sistemas de recuperación de información se realiza en pequeños bien
controlados, colecciones homogéneas como colecciones de artículos científicos o
noticias sobre un tema relacionado. De hecho, el punto de referencia principal 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", el punto de referencia es de solo 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 produce buenos resultados en la
web. Por ejemplo, el vector estándar, el modelo espacial intenta devolver el
documento que más se aproxima a la consulta, dado que ambas consultas y
documento son vectores definidos por su palabra de ocurrencia. En la web, esta
estrategia a menudo vuelve muy cortos los documentos que son la consulta más
unas pocas palabras. Por ejemplo, hemos visto un motor de búsqueda importante
devuelva una página que contenga solo "Bill Clinton Sucks" y una imagen de una
consulta de "Bill Clinton". Algunos sostienen que en la web, los usuarios deben
especificar con mayor precisión lo que desean y agregar más palabras a su
consulta, estamos en desacuerdo con esta posición, si un usuario hace una consulta
como "Bill Clinton", debería obtener resultados razonables ya que hay una enorme
cantidad de información de alta calidad disponible en este tema. Dados ejemplos
como estos, creemos que el trabajo de recuperación de información estándar debe
ser ampliado para tratar con eficacia la web.

3.2 Diferencias entre la web y colecciones bien controladas

La web es una vasta colección de documentos heterogéneos completamente
descontrolados. Documentos sobre la web tiene una variación extrema interna a los
documentos, y también en la metainformación externa que podría estar
disponible. Por ejemplo, los documentos difieren internamente en su idioma (tanto
humanos como programación), vocabulario (direcciones de correo electrónico,
enlaces, códigos postales, números de teléfono, números de producto), tipo o
formato (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 la metainformación externa como información que puede ser inferido
sobre un documento, pero no está contenido dentro de él. Ejemplos de
metainformación externa incluyen cosas como la reputación de la fuente, la
frecuencia de actualización, la calidad, la popularidad o el uso, y las citas. No solo
se varían las posibles fuentes de metainformación externa, pero las cosas que se
están midiendo también varían muchos órdenes de magnitud. Por ejemplo,
comparar la información de uso de una importante página de inicio, como la de
Yahoo! que actualmente recibe millones de visitas a la página todos los días con un
oscuro artículo histórico que podría recibir una vista 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 no hay control sobre lo que las personas pueden poner en
la web. Combina esta flexibilidad para publicar cualquier cosa con la enorme
influencia de los motores de búsqueda para enrutar el tráfico y las empresas que
deliberadamente manipulan los motores de búsqueda con fines de lucro se
convierte en un grave problema. Este problema que no ha sido abordado en los
sistemas de recuperación de información cerrados tradicionales. Además, es
interesante observar que los metadatos los esfuerzos han fallado en gran medida
con los motores de búsqueda web, porque cualquier texto en la página que no está
directamente representado al usuario se abusa para manipular los motores de
búsqueda. Incluso hay numerosas empresas. Que se especializan en la
manipulación de motores de búsqueda con fines de lucro.

4. Anatomía del sistema

Primero, proporcionaremos una discusión de alto nivel sobre la
arquitectura. Entonces, hay algunos en profundidad descripciones de estructuras de
datos importantes. Finalmente, las aplicaciones principales: rastreo, indexación y
La búsqueda será examinada en profundidad.

4.1 Visió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 muestra en la Figura 1. Más adelante en las secciones se
discutirán las aplicaciones y estructuras de datos no se menciona en esta
sección. La mayor parte de google es implementado en C o C ++ por eficiencia y
puede ejecutarse en 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 URL para ser recuperadas a los rastreadores de las
páginas web que se recuperan se envían a el storeerver. El storeerver luego
comprime y almacena as páginas web en un repositorio cada página web tiene un
número de identificación asociado llamado un ID de documento que se asigna cada
vez que se analiza una nueva URL de una página web la función de indexación es
realizada por el indexador y clasificador. El indexador realiza una serie de funciones
y se lee el repositorio, descomprime los documentos y los analiza. Cada documento
se convierte en un conjunto de palabra ocurrencias llamadas hits. Los hits registran
la palabra, la posición en el documento, una aproximación de la fuente tamaño y
capitalización, el indexador distribuye estos hits en un conjunto de "barriles",
creando un índice adelantado ordenado, el indexador 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 anclajes. Este archivo contiene suficiente
información para determinar dónde apunta cada enlace desde y hacia, y el texto del
enlace. URLresolver lee el archivo de anclajes y convierte las URL relativas en URL
absolutas y, a su vez, en docIDs pone el texto de anclaje en el índice hacia adelante,
asociado con el ID de documento que señala el punto de anclaje, también genera
una base de datos de enlaces que son pares de docIDs, la base de datos de enlaces
se utiliza para calcular PageRank para todos los documentos.
El clasificador toma los barriles, que están ordenados por docIDs (esto es una
simplificación, consulte la Sección 4.2.5), y los recurre por Word ID 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 compensaciones en el índice invertido en un programa llamado
DumpLexicon toma esta lista junto con el léxico producido por el Indexador y genera
un nuevo léxico para ser utilizado 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 el 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 se pueda rastrear, indexar y buscó con poco costo, aunque, las CPU
y las tasas de salida de entrada masiva han mejorado dramáticamente a lo largo de
los años, una búsqueda de disco aún requiere aproximadamente 10 ms para
completarse, Google está diseñado para evitar búsquedas de disco 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 la asignación entre múltiples sistemas de
archivos se maneja automáticamente. El paquete BigFiles también maneja
asignación y des asignación de descriptores de archivos, ya que los sistemas
operativos no proporcionan suficiente para nuestros necesariamente. BigFiles
también soporta 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 utilizando zlib (ver RFC1950). 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 sobre una mejora significativa en la compresión ofrecida por
bzip. La tasa de compresión de bzip fue de aproximadamente 4 a 1 en el repositorio
en comparación con la compresión 3 a 1 de zlib. En el repositorio, los documentos
se almacenan uno tras otro y tienen el prefijo docID, la longitud y la URL como se
puede ver en Figura 2. El repositorio no requiere que se utilicen otras estructuras de
datos para acceder a él. Esto ayuda con la consistencia de los datos y facilita mucho
el desarrollo; Podemos reconstruir todas las otras estructuras de datos de solo el
repositorio y un archivo que enumera 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) índice de modo de acceso, ordenado por docID. La
información almacenada en cada entrada incluye la información actual, estado del
documento, un puntero al repositorio, una suma de comprobación del documento y
varias estadísticas. Si el documento ha sido rastreado, también contiene un puntero
en un archivo de ancho variable llamado docinfo que contiene su URL y su título. De
lo contrario, el puntero apunta a la lista de URL que contiene solo 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 obtener un registro en una búsqueda
de disco durante una búsqueda, además, hay un archivo que se utiliza para convertir
direcciones URL en ID de documento, es una lista de sumas de comprobación de
URL, con sus correspondientes docIDs y se ordena por suma de comprobación con
el fin de encontrar el docID de un determinado URL, se calcula la suma de
comprobació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 se pueden convertir en docIDs
en lote haciendo una combinación con este archivo. Este es la técnica que usa la
herramienta de resolución de URL para convertir las URL en ID de doc. Este modo
de actualización por lotes es crucial porque de lo contrario, debemos realizar una
búsqueda por cada enlace que suponiendo que un disco llevaría más de un mes
para nuestro conjunto de datos de 322 millones de enlaces.

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 añadidas 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 información auxiliar que está más
allá del alcance de este documento para explicarlo en su totalidad.

4.2.5 Listas de resultados

Una lista de resultados corresponde a una lista de apariciones de una palabra en
particular en un documento en particular, incluyendo posición, fuente, e información
de mayúsculas, las listas de visitas representan la mayor parte del espacio utilizado
tanto en el adelante y los índices invertidos debido a esto, es importante
representarlos tan eficientemente como sea posible. Consideramos varias
alternativas para codificar la posición, la fuente y el uso de mayúsculas: simple
codificación (un triple de enteros), una codificación compacta (una asignación de
bits optimizada a mano) y Huffman codificación. Al final, elegimos una codificación
compacta optimizada a mano, ya que requería mucho menos espacio que la
codificación simple y mucho menos manipulación de bits que la codificación de
Huffman. Los detalles de los hits se muestran en Figura 3. Nuestra codificación
compacta utiliza dos bytes para cada golpe. Hay dos tipos de hits: hits de lujo e hits
simples. Los éxitos de lujo incluyen los que se producen en una URL, título, texto
de anclaje o metaetiqueta. Los éxitos simples 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 etiquetadas
como 4096). El tamaño de fuente se representa en relación con el resto del
documento usando tres bits (en realidad solo se usan 7 valores porque 111 es la
bandera que señala un golpe elegante). Un elegante, el golpe consiste en un bit de
capitalización, el tamaño de fuente establecido en 7 para indicar que es un golpe
elegante, 4 bits para codificar el Tipo de golpe de lujo, 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 ancla
y 4 bits para un hash de la ID de documento en la que se produce el ancla, esto nos
da un poco limitada la búsqueda de frases siempre que no haya tantos anclajes
para una palabra en particular. Esperamos actualizar la forma en que se almacenan
los aciertos de anclaje para permitir una mayor resolución en los campos de posición
y docIDhash. Usamos 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 solo porque uno de los documentos tiene una fuente más grande.
La longitud de una lista de aciertos se almacena antes de los aciertos, para ahorrar
espacio, la longitud de la lista de resultados se combina con el Word ID en el índice
de avance y el ID de documento en el invertido índice. Esto lo limita a 8 y 5 bits
respectivamente (hay algunos trucos que permiten tomar prestados 8 bits de la
Word ID). Si la longitud es más larga de lo que cabría en tantos bits, se utiliza un
código de escape en esos bits, y los dos siguientes Los bytes contienen la longitud
real.

4.2.6 Índice hacia adelante

El índice directo ya está parcialmente ordenado. Es almacenado en un número de
barriles (utilizamos 64). Cada barril tiene un rango de wordID's. Si un documento
contiene palabras que caen en un barril particular, el docID se registra en el barril,
seguido de una lista de ID de palabra con listas de resultados que corresponden a
esas palabras. Este esquema requiere ligeramente más almacenamiento debido a
docIDs duplicados pero la diferencia es muy pequeña para un número razonable de
depósitos y ahorra tiempo y codificación considerables, complejidad en la fase de
indexación final realizada por el clasificador. Además, en lugar de almacenar reales
WordID’s, almacenamos cada wordID como una diferencia relativa del wordID
mínimo que cae en el Figura 3. Índices de avance y retroceso y el léxico barril en el
que está el ID de palabra. De esta manera, podemos usar solo 24 bits para los ID
de palabra en los barriles sin clasificar, dejando 8 bits para la longitud de la lista de
aciertos.

4.2.7 Índice invertido

El índice invertido consiste en los mismos barriles que el índice delantero, excepto
que han sido procesados por el clasificador. Por cada ID de palabra válido, el léxico
contiene un puntero en el barril que wordID cae en Apunta a una lista de
documentos de ID de documento junto con sus listas de resultados
correspondientes. Esta lista de documentos representa todas las apariciones de esa
palabra en todos los documentos un tema importante es en qué orden deben
aparecer los ID de documento en la lista de documentos. Una solución simple es
almacenarlos ordenados por docID. Esto permite la fusión rápida de diferentes listas
de documentos para varias palabras consultas otra opción es almacenarlos
ordenados por una clasificación de la aparición de la palabra en cada
documento. Esto hace que responder las consultas de una palabra sea trivial y hace
que sea probable que las respuestas a las consultas de varias palabras están cerca
del comienzo. Sin embargo, la fusión es mucho más difícil. Además, esto hace el
desarrollo es mucho más difícil porque un cambio en la función de clasificación
requiere una reconstrucción del índice. Elegimos un compromiso entre estas
opciones, manteniendo dos juegos de barriles invertidos: uno para golpear listas
que incluyen éxitos de título o ancla y otro conjunto para todas las listas de
aciertos. De esta manera, comprobamos el primer conjunto de primero barriles y si
no hay suficientes partidos dentro de esos barriles revisamos los más grandes.

4.3 Rastreando la Web

Ejecutar un rastreador web es una tarea desafiante. Hay problemas difíciles de
rendimiento y fiabilidad y aún más importante, hay problemas sociales, el rastreo es
la aplicación más frágil ya que implica estar interactuando con cientos de miles de
servidores web y varios servidores de nombres que están más allá del control del
sistema para escalar a cientos de millones de páginas web, Google tiene un sistema
de rastreo distribuido rápido. El único servidor URL sirve listas de URL a varios
rastreadores (generalmente ejecutamos alrededor de 3). Ambos URLserver y los
rastreadores están implementados en Python. Cada rastreador mantiene
aproximadamente 300 conexiones abiertas a la vez., esto es necesario para
recuperar 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 usando cuatro
rastreadores, esto equivale a aproximadamente 600K por segundo de datos. Un
estrés importante en el rendimiento es la búsqueda de DNS. Cada rastreador
mantiene su propio caché de DNS por lo que no es necesario realizar una búsqueda
de DNS antes de rastrear cada documento. Cada uno de los cientos de conexiones
pueden estar en varios estados diferentes: buscar DNS, conectarse al host, enviar
una solicitud y recibiendo respuesta. 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 las recuperaciones de página de estado a estado.
Resulta que ejecutar 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 a la gran
cantidad de personas que vienen en línea, siempre hay quienes no saben lo que es
un rastreador, porque este son los primeros que han visto. Casi todos los días,
recibimos un correo electrónico algo así como "Wow, miraste un montón de páginas
de mi sitio web. ¿Cómo le gustó? "También hay algunas personas que no saben
sobre el protocolo de exclusión de robots, y cree que su página debe estar protegida
de la indexación mediante una declaración como, "Esta página tiene derechos de
autor y no debe ser indexada", lo que no hace falta decir que es difícil para los
rastreadores web comprender. Además, debido a la gran cantidad de datos
involucrados, sucederán cosas inesperadas por ejemplo, nuestro sistema intentó
rastrear un juego en línea, esto dio lugar a muchos mensajes de basura en el medio
de su juego! Resulta que este fue un problema fácil de solucionar, 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 en los servidores,
es prácticamente imposible probar un rastreador sin ejecutarlo en gran parte de
Internet. Invariablemente, hay cientos de problemas oscuros que solo pueden
ocurrir en una página de la totalidad web y hacer que el rastreador se bloquee, o
peor aún, cause un comportamiento impredecible o incorrecto. Sistemas que el
acceso a grandes partes de Internet debe estar diseñado para ser muy robusto y
cuidadosamente probado desde lo grande los sistemas complejos como los
rastreadores siempre causarán problemas, es necesario que haya recursos
significativos dedicados a leer el correo electrónico y resolver estos problemas a
medida que surjan.

4.4 Indexando la web

Análisis: cualquier analizador diseñado para ejecutarse en toda la Web debe
manejar una gran variedad de posibles errores estos van desde errores tipográficos
en etiquetas HTML a kilobytes de ceros en medio de una etiqueta caracteres no
ASCII, etiquetas HTML anidadas a cientos de profundidades, y una gran variedad
de otros errores que desafía la imaginación de cualquier persona para que presente
ideas igualmente creativas. Para la velocidad máxima, en lugar de utilizar YACC
para generar un analizador CFG, usamos flex para generar un analizador léxico que
nos vestimos con su propia pila. El desarrollo de este analizador que se ejecuta a
una velocidad razonable y es muy robusto e involucró una buena cantidad de
trabajo.

Indexación de documentos en barriles: Después de analizar cada documento, se

codifica en un número de barriles cada palabra se convierte en una ID de palabra
utilizando una tabla hash en memoria: el léxico las nuevas adiciones a la tabla hash
de léxico se registran en un archivo una vez que las palabras se convierten en
WordID, sus incidencias en el documento actual se traducen en listas de resultados
y se escriben en los barriles delanteros. La principal dificultad con la paralelización
de la fase de indexación es que el léxico necesita ser compartido. En lugar de
compartir el léxico, tomamos el enfoque de escribir un registro de todas las palabras
adicionales que no estaban en un léxico base, que fijamos en 14 millones de
palabras. De esa manera se pueden ejecutar múltiples indexadores en paralelo y
luego 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 lo ordena por wordID para producir un barril invertido para los
títulos y los resultados de ancla y un texto completo invertido barril. Este proceso
ocurre un barril a la vez, por lo que requiere poco almacenamiento
temporal. También nosotros paralelicen la fase de clasificación para usar tantas
máquinas como tengamos simplemente ejecutando múltiples clasificadores, que
pueden procesar diferentes cubos al mismo tiempo. Dado que los barriles no
encajan en principal memoria, el clasificador los subdivide en canastas que encajan
en la memoria en función de ID de palabra e ID de documento. Luego el clasificador,
carga cada canasta en la memoria, la ordena y escribe su contenido en el corto
barril invertido y el barril invertido completo.

4.5 buscando
El objetivo de la búsqueda es proporcionar resultados de búsqueda de calidad de
manera eficiente muchos de los grandes comerciales. Los motores de búsqueda
parecían haber hecho grandes progresos en términos de eficiencia, por lo tanto, nos
hemos centrado más sobre la calidad de la búsqueda en nuestra investigación,
aunque creemos que nuestras soluciones son escalables a volúmenes comerciales
con un poco más de esfuerzo. El proceso de evaluación de la consulta de Google
se muestra en la Figura 4. Para poner un límite en el tiempo de respuesta, una vez
que un cierto número (actualmente 40,000) de documentos coincidentes se
encuentran, el buscador pasa automáticamente al paso 8 en la Figura 4. Este
significa que es posible que los resultados subóptimos sean devuelto Actualmente
estamos investigando otras formas de resolver este problema en el pasado,
ordenamos los éxitos de acuerdo a 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 cada hitlist incluye información de posición, fuente y
mayúsculas, además, tomamos en cuenta los éxitos del texto de anclaje y la
PageRank del documento. Combinando todo esto la información en un rango es
difícil diseñamos nuestro ranking. Funciona de manera que ningún factor particular
pueda tener demasiada 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 hit es uno de varios tipos diferentes (título, ancla, URL, fuente
grande de texto sin formato, fuente pequeña de texto sin formato,...), cada una de
las cuales tiene su propio peso de tipo. Los tipos-pesos forman un vector indexado
por tipo Google cuenta el número de hits de cada tipo en la lista de hits. Entonces
cada cuenta es convertida en una cuenta de peso. Los pesos de conteo aumentan
linealmente con los conteos al principio pero disminuyen rápidamente por lo que
más de un cierto recuento no ayudará. Tomamos el producto punto del vector de
conteo-pesos con el vector de tipo-pesos para calcular una puntuación de IR para
el documento. Finalmente, la puntuación IR es combinado con PageRank para dar
una clasificación 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
resultados de una vez para que las coincidencias que se producen juntas en un
documento se ponderen más que las coincidencias ocurriendo muy separados. Los
hits de las múltiples listas de hits se combinan para que coincidan los hits cercanos
juntos. Para cada conjunto de aciertos coincidentes, se calcula una proximidad. La
proximidad se basa en qué tan lejos aparte, los aciertos están en el documento (o
ancla) pero se clasifican en 10 "bandejas" de diferentes valores que van desde una
frase coincide con "ni siquiera cerca". Los conteos se calculan no solo para cada
tipo de golpe sino para cada tipo y la proximidad. Cada tipo y par de proximidad
tiene un peso de tipo prox. Las cuentas se convierten en contar-pesos y tomamos
el producto de puntos de los recuentos-pesos y el tipo-prox-pesos para calcular una
puntuación de IR. Todos estos números y matrices se pueden mostrar con los
resultados de búsqueda utilizando un modo de depuración especial. Estas pantallas
han sido muy útiles para desarrollar el sistema de clasificación.

4.5.2 Feedback
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 son una
especie de arte negro. Para ello, tenemos un usuario mecanismo de
retroalimentación en el buscador. Un usuario confiable puede evaluar
opcionalmente todos los resultados que son devueltos. Esta retroalimentación se
guarda; luego cuando modifiquemos la función de clasificación, podemos ver el
impacto de este cambio en todas las búsquedas anteriores que fueron
clasificadas. Aunque lejos de ser perfecto, esto nos da cierta idea de cómo un
cambio en la función de clasificación afecta a los resultados de búsqueda.

1. Analizar la consulta.
2. Convertir palabras en wordIDs.
3. Buscar el inicio de la lista de documentos en el barril corto para cada palabra.
4. Escanear a través de las listas de documentos hasta hay un documento que
coincide todos los términos de búsqueda.
5. Calcula el rango de eso documento para la consulta.
6. Si estamos en los barriles cortos y en al final de cualquier lista documental, busca
al inicio de la lista de documentos en el barril lleno para cada palabra e ir al paso 4.
7. Si no estamos al final de alguna doclist ir al paso 4. ordenar los documentos que
tienen emparejado por rango y devolver la parte superior k.

Figura 4. Evaluación de Google Query

5 Resultados y Rendimiento
La medida más importante de una búsqueda el 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, nuestra propia experiencia con Google lo ha
demostrado para producir mejores resultados que los principales, buscadores
comerciales para la mayoría búsquedas Como un ejemplo que ilustra el uso de
PageRank, texto de anclaje, y proximidad, la figura 4 muestra la de Google
resultados para una búsqueda en "Bill Clinton". Estos resultados demuestran
algunos de las características de Google. Los resultados son agrupados por
servidor esto ayuda considerablemente al tamizar el resultado conjunto, una serie
de resultados son del dominio whitehouse.gov que es lo que uno puede
razonablemente esperar de tal buscar. Actualmente, la mayoría de los grandes
comerciales los buscadores no devuelven ningún resultado de whitehouse.gov,
mucho menos el derecho unos observe que no hay título para el primer
resultado esto es porque no era arrastrado En cambio, Google confió en el ancla
texto para determinar esta 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 de texto de anclaje. Todos los resultados son
razonablemente altos, páginas de calidad y, en última instancia, ninguna eran
enlaces rotos, esto es en gran parte porque todos ellos tienen alto PageRank. Los
PageRanks son los porcentajes en rojo junto con gráficos de barras. Finalmente, no
hay resultados sobre un proyecto de ley que no sea Clinton o sobre un Clinton aparte
de Bill. Esto se debe a que damos mucha importancia a la proximidad de las
ocurrencias de palabras. De por supuesto, una verdadera prueba de la calidad de
un motor de búsqueda involucraría un extenso estudio o resultados del usuario.
Análisis para el que no tenemos espacio 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

Aparte de la calidad de búsqueda, Google está diseñado para escalar de manera

rentable al tamaño de la Web, ya que crece Un aspecto de esto es usar el
almacenamiento de manera eficiente. La tabla 1 tiene 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 aproximadamente 53 GB, solo 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, alrededor de 55 GB. Además, la mayoría de las
consultas se pueden responder con solo el índice corto invertido. Con una mejor
codificación y compresión del Índice de Documentos, una web de alta calidad.
El motor de búsqueda puede caber en una unidad de 7 GB de una PC nueva.

5.2 Rendimiento del sistema

Es importante para un motor de búsqueda rastrear e indexar eficientemente de esta
manera la información se puede mantener actualizada y los cambios importantes
en el sistema se pueden probar con relativa rapidez para Google, las principales
operaciones son de rastreo, indexación, y la clasificación. Es difícil medir el tiempo
de rastreo en general porque los discos se llenaron, los servidores de nombres
fallaron, o cualquier número de otros problemas que detuvieron el sistema. En total
tardaron aproximadamente 9 días en descargar los 26 millones páginas (incluyendo
errores). Sin embargo, una vez que el sistema estaba funcionando sin problemas,
corrió mucho más rápido, descargando el último 11 millones de páginas en solo 63
horas, con un promedio de poco más de 4 millones de páginas por día o 48.5
páginas por segundo. Corrimos el indexador y el rastreador a la vez. El indexador
corrió solo más rápido que los rastreadores. Esto es en gran parte porque gastamos
solo suficiente tiempo optimizando el indexador para que no sea un
embotellamiento. Estas optimizaciones incluyeron actualizaciones masivas a Índice
de documentos y colocación de estructuras de datos críticos en 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 clasificación lleva alrededor de 24 horas.

5.3 Rendimiento de búsqueda

Mejorar el rendimiento de la búsqueda no fue el objetivo principal de nuestra
investigación hasta este momento. 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 la E / S de disco sobre NFS (ya que los discos se distribuyen en varias
máquinas). Además, Google no tiene optimizaciones, como el almacenamiento en
caché de consultas, los 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 varios cientos de consultas por segundo. La Tabla 2 tiene
algunos tiempos de consulta de muestra de la versión actual de Google. Se repiten
a mostrar las aceleraciones resultantes de la IO en caché.

Estadísticas de almacenamiento
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 rápido
crecimiento de la World Wide Web. Google emplea una serie de técnicas para
mejorar la calidad de búsqueda que incluye rango de página, texto de anclaje y
Información de proximidad. Además, Google es una arquitectura completa para la
recopilación de páginas web, indexándolos, y realizando consultas de búsqueda
sobre ellos.

6.1 Trabajo futuro

Un motor de búsqueda web a gran escala es un sistema complejo y 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. Algunas de las mejoras
simples a 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 actualizaciones. Debemos tener algoritmos inteligentes para
decidir qué las páginas web antiguas se deben volver a rastrear y las nuevas se
deben rastrear. El trabajo hacia esta meta tiene hecho en [Cho 98]. Un área de
investigación prometedora es el uso de cachés de proxy para construir bases de
datos de búsqueda, ya que son impulsados por la demanda. Estamos planeando
agregar características simples compatibles con la búsqueda comercial motores
como los operadores booleanos, la negación y la derivación. Sin embargo, otras
características están empezando a ser explorado, como comentarios de relevancia
y agrupación en clústeres (actualmente, Google admite un nombre de host simple
basado en agrupamiento). También planeamos apoyar el contexto del usuario
(como la ubicación del usuario) y el resumen de resultados. Nosotros también
estamos trabajando para extender el uso de la estructura de enlaces y el texto de
enlaces. Experimentos simples indican el PageRank se puede personalizar
aumentando el peso de la página de inicio o los marcadores de un usuario. En
cuanto al texto de enlace, nosotros están experimentando con el uso de texto que
rodea los enlaces, además del propio texto del enlace. Una búsqueda web el motor
es un entorno muy rico para ideas de investigación. Tenemos demasiados para
enumerarlos aquí, así que no espere que esta sección de trabajo futuro sea mucho
más corta en el futuro cercano.

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 obtienen, si bien los resultados suelen ser
divertidos y expanden los horizontes de los usuarios, a menudo son frustrantes y
consumen tiempo precioso. Por ejemplo, el resultado principal para una búsqueda
de "Bill Clinton" en uno de los más populares los motores de búsqueda comerciales
fue la broma del día de Bill Clinton: 14 de abril de 1997. Google está diseñado para
proporcione una búsqueda de mayor calidad para que la Web siga creciendo
rápidamente, la información se puede encontrar fácilmente para lograr esto, Google
hace un uso intensivo de información hipertextual que consiste en un enlace texto
de estructura y enlace (ancla). Google también utiliza la proximidad y la información
de la fuente. Mientras que la evaluación de un el 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 del texto del enlace como una descripción de a qué
apunta el enlace ayuda el motor de búsqueda devuelve resultados relevantes (y
hasta cierto punto de alta calidad). Finalmente, el uso de la proximidad. La
información ayuda a aumentar la relevancia de muchas consultas.

6.3 Arquitectura escalable

Aparte de la calidad de 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 de toda la Web. En la implementación de Google,
nosotros he visto cuellos de botella en la CPU, el acceso a la memoria, la capacidad
de la memoria, las búsquedas del disco, el rendimiento del disco, el disco capacidad,
y red IO. Google ha evolucionado para superar varios de estos 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 eficientes
como para poder construir un Í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 tiene Google recopilado ya ha dado lugar a muchos
otros documentos presentados a conferencias y muchos más sobre
camino. Investigaciones recientes como [Abiteboul 97] han mostrado una serie de
limitaciones a las consultas sobre la Web que puede responderse sin tener la Web
disponible localmente. Esto significa que Google (o un sistema similar) no solo es
una herramienta de investigación valiosa sino que es necesaria para una amplia
gama de aplicaciones. Esperamos que Google sea un recurso para buscadores e
investigadores de todo el mundo y que encienda la 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 nos gustaría agradecer Héctor García-Molina, Rajeev Motwani,
Jeff Ullman, y Terry Winograd y toda la WebBase grupo por su apoyo y discusiones
perspicaces. Finalmente nos gustaría reconocer el generoso soporte de nuestros
donantes de equipos IBM, Intel y Sun y nuestros patrocinadores. La investigación
descrita aquí fue realizado como parte del Proyecto de la Biblioteca Digital Integrada
de Stanford, apoyado por el National Science Fundación bajo Acuerdo de
Cooperación IRI-9411306. La financiación de este acuerdo de cooperación es
también proporcionada por DARPA y NASA, y por Interval Research, y los socios
industriales de Stanford Proyecto de bibliotecas digitales.

Referencias
Vitae

Sergey Brin obtuvo su licenciatura en matemáticas e informática de la Universidad

de Maryland en College Park en 1993. Actualmente, él es un Doctor en
Filosofía. Candidato a la informática en la Universidad de Stanford, donde recibió
su maestría en 1995. Recibió un graduado de la National Science Foundation
compañerismo. Sus intereses de investigación incluyen motores de búsqueda de
información, extracción de fuentes no estructuradas y extracción de datos de
grandes colecciones de texto y datos científicos.

Lawrence Page nació en East Lansing, Michigan, y recibió un BSE 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 enlaces de la
web, humanos Interacción informática, buscadores, escalabilidad de 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 del modelo de negocio publicitario no
siempre corresponde a proporcionar una búsqueda de calidad a los usuarios, por
ejemplo, en nuestro motor de búsqueda de prototipos, uno de los mejores resultados
para teléfonos celulares es "El efecto de uso del teléfono celular a la atención del
conductor ", un estudio que explica con gran detalle las distracciones y riesgo
asociado con conversar en un teléfono celular mientras se conduce. Este resultado
de búsqueda apareció primero porque de su alta importancia según lo juzgado por
el algoritmo PageRank, 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 dificultades para justificar la página
que nuestro sistema devolvió a sus anunciantes de pago 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 estarán inherentemente sesgados hacia los
anunciantes y lejos de las necesidades de los anunciantes los consumidores dado
que es muy difícil incluso para los expertos evaluar motores de búsqueda, el sesgo
de los motores de búsqueda es particularmente insidioso. Un buen ejemplo fue
OpenText, que según se informó, estaba vendiendo 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 mucho 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 listado. Este modelo de negocio resultó en un alboroto, y
OpenText ha dejado de ser un motor de búsqueda viable. Pero es probable que el
mercado tolere un sesgo menos evidente. Por ejemplo, una búsqueda. El motor
podría agregar un pequeño factor a los resultados de búsqueda de compañías
"amigables" y restar un factor de resultados de los competidores. Este tipo de sesgo
es muy difícil de detectar pero aún podría tener una diferencia significativa. Efecto
en el mercado. Además, los ingresos por publicidad a menudo proporcionan un
incentivo para proporcionar resultados de búsqueda de calidad. Por ejemplo,
notamos que un motor de búsqueda importante no devolvería una aerolínea grande
página de inicio cuando el nombre de la aerolínea fue dado como una
consulta. Ocurrió que la aerolínea había colocado un anuncio caro, vinculado a la
consulta que tenía su nombre. Un mejor motor de búsqueda no habría requerido
esto anuncio, y posiblemente resultó en la pérdida de los ingresos de la aerolínea
al motor de búsqueda. En general, se podría argumentar desde el punto de vista del
consumidor que cuanto mejor es el motor de búsqueda, menos se necesitarán
anuncios para que el consumidor encuentre lo que quiere. Esto por supuesto
erosiona la publicidad apoyada en el modelo de negocio de los motores de
búsqueda existentes. Sin embargo, siempre habrá dinero de los anunciantes que
quieren que un cliente cambie de producto o que tenga algo que sea genuino
nuevo. Pero creemos que el tema de la publicidad causa suficientes incentivos
mixtos que es crucial tener un buscador competitivo, transparente y en el ámbito
académico.

9 Apéndice B: Escalabilidad

9. 1 Escalabilidad de Google
Hemos diseñado Google para que sea escalable en el corto plazo a un objetivo de
100 millones de páginas web. Tenemos acabo de recibir el disco y las máquinas
para manejar aproximadamente esa cantidad. Todo el tiempo consume partes de la
Los sistemas son paralelos y de tiempo aproximadamente lineal. Estos incluyen
cosas como los rastreadores, indexadores y clasificadores también creemos 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 de
sistemas operativos en el sistemas operativos comunes (actualmente ejecutamos
tanto en Solaris como en Linux). Estos incluyen cosas como memoria direccionable,
número de descriptores de archivos abiertos, sockets de red y ancho de banda, y
muchos otros. Creemos que expandir a más de 100 millones de páginas aumentaría
enormemente la complejidad de nuestros sistemas.

9.2 Escalabilidad de las arquitecturas de indexación centralizadas

A medida que aumentan las capacidades de las computadoras, es posible indexar
una gran cantidad de texto para un costo razonable. Por supuesto, es probable que
otros medios más intensivos en ancho de banda, como el video, se conviertan en
más generalizada. Pero, debido a que el costo de producción de texto es bajo en
comparación con los medios como el video, el texto es probable que se mantenga
muy generalizado. Además, es probable que pronto tengamos reconocimiento de
voz que haga un trabajo razonable que convierte el habla en texto, ampliando la
cantidad de texto disponible todo esto proporciona increíbles posibilidades para la
indexación centralizada. Aquí hay un ejemplo ilustrativo. Asumimos que queremos
Índice todo lo que todos en los Estados Unidos han escrito durante un
año. Suponemos que hay 250 millones de personas en los Estados Unidos y
escriben un promedio de 10k por día. Eso funciona a unos 850 terabytes también
supongamos que la indexación de un terabyte se puede hacer ahora por un costo
razonable. También asumimos que los métodos de indexación utilizados sobre el
texto son lineales, o casi lineales en su complejidad. Teniendo en cuenta todas
estas suposiciones que podemos calcular cuánto tiempo tomaría antes de que
pudiéramos indexar nuestros 850 terabytes para un costo razonable asumiendo
ciertos factores de crecimiento. La Ley de Moore fue definida en 1965 como una
duplicación de cada 18 meses en potencia de procesador se ha mantenido
notablemente cierto, no solo 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 todos en Estados Unidos ha escrito
durante un año por un precio que una pequeña empresa podía pagar. Por supuesto,
los expertos en hardware son algo preocupado La Ley de Moore no puede seguir
vigente durante los próximos 15 años, pero hay sin duda muchas aplicaciones
centralizadas interesantes, incluso si solo conseguimos una parte del camino hacia
nuestra ejemplo hipotético por supuesto, un sistema distribuido como G l oss
[Gravano 94] o Harvest será a menudo el más eficiente y eficiente. Solución técnica
elegante para la indexación, pero parece difícil convencer al mundo de que use
estos sistemas. Debido a los altos costos administrativos de configurar un gran
número de instalaciones. Por supuesto que es bastante probable que sea posible
reducir drásticamente el costo de administración. Si eso sucede, y todos comienzan
a ejecutar un sistema de indexación distribuida, la búsqueda sin duda mejoraría
drásticamente. Debido a que los humanos solo pueden escribir o hablar una
cantidad finita, y mientras las computadoras continúan mejorando, el texto la
indexación se escalará incluso mejor que ahora. Por supuesto que podría haber una
cantidad infinita de máquina. El contenido generado, pero solo indexar enormes
cantidades de contenido generado por humanos parece tremendamente útil. Así
que somos optimistas de que nuestra arquitectura de motor de búsqueda web
centralizada mejorará en su capacidad para cubrir la información de texto pertinente
a lo largo del tiempo y que hay un futuro brillante para la búsqueda.