La anatomía de una Búsqueda Hipertextual Web Motor Scale-Large

Sergey Brin y Lawrence Page @cs.stanford.edu

Informática Departamento de Ciencias de la Universidad de Stanford, Stanford, CA 94305

Abstracto

En este trabajo, presentamos Google, un prototipo de un motor de búsqueda a gran escala que hace un uso intensivo de la estructura presente en el hipertexto. Google está diseñado para rastrear e indexar la Web de manera eficiente y producir resultados mucho más satisfactorios que los sistemas existentes. El prototipo con una base de datos de texto completo y hipervínculo de al menos 24 millones de páginas está disponible en http://google.stanford.edu/ Para diseñar un motor de búsqueda es una tarea difícil. Decenas Buscar índice motores a cientos de millones de páginas web que involucran 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 de la tecnología y la proliferación de Internet, la creación de un motor de búsqueda en la web hoy en día es muy diferente a la de hace tres años. Este documento ofrece una descripción en profundidad de nuestro motor de búsqueda en Internet a gran escala - la primera descripción pública detallada que conocemos hasta la fecha. Aparte de los problemas de la ampliación de las técnicas de búsqueda tradicionales a los datos de esta magnitud, hay nuevos retos técnicos involucrados con el uso de la información adicional presente en el hipertexto para producir mejores resultados de búsqueda. En este trabajo se aborda la cuestión de cómo construir un sistema práctico a gran escala que puede explotar la información presente en el hipertexto. También nos fijamos en el problema de cómo tratar eficazmente con colecciones de hipertexto no controlados donde cualquiera puede publicar lo que quieran.

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 trabajo - una versión más larga completa y una versión más corta impresa La versión completa está disponible en la web y 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 está creciendo rápidamente, así como el número de nuevos usuarios sin experiencia en el arte de la investigación de la tela. Las personas tienden a navegar por la web utilizando su gráfica enlace, a menudo a partir de los índices humanos mantenido alta calidad tales como Yahoo! o con motores de búsqueda. Humano mantiene listas abarcan

temas populares con eficacia pero son subjetivas, caros de construir y mantener, lento para mejorar, y no puede cubrir todos los temas esotéricos. Buscadores automáticos que dependen de concordancia de palabras clave por lo general vuelven demasiados partidos de baja calidad. Para empeorar las cosas, algunos anunciantes tratan de llamar la atención de las personas mediante la adopción de 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. Se hace uso especialmente intensivo de la estructura adicional presente en el hipertexto para proporcionar resultados de búsqueda mucho más altos de calidad. Elegimos nuestro nombre del sistema, Google, ya que es una ortografía común de googol, o 10 100 y encaja bien con nuestra meta de construir motores de búsqueda muy gran escala.

1.1 Web Motores de búsqueda - Scaling Up: 1994 - 2000

Tecnología de los motores de búsqueda se ha tenido que reducir drásticamente para mantenerse al día con el crecimiento de la web. En 1994, uno de los primeros motores de búsqueda web, el gusano de la World Wide Web (WWWW) [McBryan 94] tenían un índice de 110.000 páginas web y documentos accesibles web. A partir de noviembre de 1997, los principales motores de búsqueda afirman índice de 2 millones (WebCrawler) a 100 millones de documentos web (de Search Engine Watch). Es previsible que en el año 2000, un índice completo del Web contendrá más de mil millones de documentos. Al mismo tiempo, el número de consultas de búsqueda motores de mango ha crecido increíblemente también. En marzo y abril de 1994, la World Wide Web Worm recibió un promedio de alrededor de 1.500 consultas por día. En noviembre de 1997, Altavista afirmó que maneja aproximadamente 20 millones de consultas por día. Con el creciente número de usuarios en la web, y los sistemas automatizados que consulta los motores de búsqueda, es probable que los principales motores de búsqueda se encargará de cientos de millones de consultas por día para el año 2000. El objetivo de nuestro sistema es hacer frente a muchos de los problemas, tanto en calidad y capacidad de ampliación, presentó al escalar la tecnología de motores de búsqueda para un número tan extraordinarias.

1.2. Google: Escala con la Web

La creación de un motor de búsqueda que escala hasta la web de hoy presenta muchos desafíos. Se necesita la tecnología de rastreo rápido para reunir los documentos web y mantenerlos actualizados. El espacio de almacenamiento debe ser utilizado de manera eficiente para almacenar índices y, opcionalmente, los propios documentos. El sistema de indexación debe procesar cientos de gigabytes de datos de manera eficiente. Las consultas deben ser manejado de manera rápida, a una velocidad de cientos a miles por segundo.

Estas tareas se están convirtiendo cada vez más difícil a medida que crece la Web. Sin embargo, el rendimiento del hardware y el coste han mejorado dramáticamente para compensar parcialmente la dificultad. Hay, sin embargo, varias excepciones notables a este progreso, tales como buscar disco tiempo y la robustez del sistema operativo. En el diseño de Google, se ha considerado tanto la tasa de crecimiento de la Web y los cambios tecnológicos. Google está diseñado para escalar bien a conjuntos de datos extremadamente

grandes. Se hace un uso eficiente de espacio de almacenamiento para almacenar el índice. Sus estructuras de datos están optimizados para un acceso rápido y eficiente (ver sección 4.2). Además, se espera que el costo para indexar y almacenar texto o HTML eventualmente disminuirá respecto a la cantidad que estará disponible (ver Apéndice B). Esto dará lugar a propiedades de escala favorables para sistemas centralizados como Google.

1.3 Objetivos de diseño

1.3.1 Mejora de la Calidad de Búsqueda

Nuestro principal objetivo es mejorar la calidad de los motores de búsqueda web. En 1994, algunas personas creían que un índice de búsqueda completa haría posible encontrar cualquier cosa con facilidad. De acuerdo con Best of the Web 1994 - Navegantes, "El mejor servicio de navegación debería hacer más fácil para encontrar casi cualquier cosa en la web (una vez se introduce todos los datos)." Sin embargo, la web de 1997 es muy diferente. Cualquiera que haya usado un motor de 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 de basura" a menudo se lavan a cabo ningún resultado que un usuario está interesado en. De hecho, a partir de noviembre de 1997, sólo una de las cuatro principales motores de búsqueda comerciales se encuentra (devuelve su propia página de búsqueda en respuesta a su nombre en el top ten Resultados). Una de las principales causas de este problema es que el número de documentos en los índices ha ido en aumento en muchos órdenes de magnitud, pero la capacidad del usuario para ver los documentos no tiene. La gente todavía sólo está dispuesto a mirar las primeras decenas de resultados. Debido a esto, ya que el tamaño de la colección crece, necesitamos herramientas que tienen muy alta precisión (número de documentos relevantes devueltos, decimos en las primeras decenas de resultados). De hecho, queremos que nuestra noción de "relevante" para incluir sólo los mejores documentos ya que puede haber decenas de miles de documentos poco relevantes. Esta muy alta precisión es importante, incluso a expensas de la recuperación (el número total de documentos relevantes que el sistema es capaz de volver). Hay un poco de reciente optimismo 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 [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 tanto de la estructura de enlace y el texto de anclaje (ver secciones 2.1 y 2.2).

1.3.2 Académico Investigación Search Engine

Aparte de un gran crecimiento, la Web también se ha convertido cada vez más comercial con el 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 emigrado desde el dominio académico al comercial. Hasta ahora la mayor parte del desarrollo de motores de búsqueda se ha encendido en las empresas con poco publicación de detalles técnicos. Esto hace que la tecnología de motores de búsqueda para seguir siendo en gran medida un arte negro y ser la publicidad orientada (ver Apéndice A). Con Google,

tenemos un objetivo fuerte para empujar más el desarrollo y la comprensión en el ámbito académico.

Otro de los objetivos de diseño importante era construir sistemas que un número razonable de la gente puede utilizar realmente. Uso era importante para nosotros porque pensamos que algunas de las investigaciones más interesantes implicará aprovechar la gran cantidad de datos de uso que está disponible en los sistemas modernos de Web. Por ejemplo, hay muchas decenas de millones de búsquedas realizadas cada día. Sin embargo, es muy difícil obtener estos datos, sobre todo porque se considera de gran valor comercial.

Nuestra meta diseño final fue la de construir una arquitectura que pueda apoyar las actividades de investigación novedosas en datos de la web a gran escala. Para apoyar a 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 la creación de un ambiente donde otros investigadores pueden venir en forma rápida, procesar grandes trozos de la web, y producir resultados interesantes que habría sido muy difícil de producir de otra manera. En el poco tiempo que el sistema ha estado haciendo, ya ha habido varios trabajos utilizando las bases de datos generadas por Google, y muchos otros están en marcha. Otro de los objetivos que tenemos es la creación de un entorno Spacelab-como donde los investigadores o incluso los estudiantes pueden proponer y hacer experimentos interesantes en nuestros datos de la web a gran escala.

2. Características del sistema

El motor de búsqueda Google tiene dos características importantes que le ayudan a producir resultados de alta precisión. En primer lugar, se hace uso de la estructura de enlaces de la web para calcular el ranking de cada página web de calidad. Esta clasificación se llama PageRank y se describe en detalle en [Página 98]. En segundo lugar, Google utiliza enlace para mejorar los resultados de búsqueda.

2.1 PageRank: poner orden en la Web

La citación (enlace) gráfico de la web es un recurso importante que ha pasado gran parte no utilizada en los motores de búsqueda web existentes. Hemos creado mapas que contienen tantos como 518 millones de estos hipervínculos, una muestra significativa del total. Estos mapas permiten un rápido cálculo de de una página web "PageRank", una medida objetiva de la importancia de la citación que se corresponde bien con la idea subjetiva de la gente de la importancia. Debido a esta correspondencia, PageRank es una excelente manera de dar prioridad a los resultados de búsquedas de palabras clave web. Para temas más populares, una simple búsqueda en concordancia texto que se limita a la página web títulos realiza admirablemente cuando PageRank prioriza los resultados (demo 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 de Cálculo PageRank

Literatura cita académica se ha aplicado a la web, en gran parte por contar las citas o los vínculos de retroceso a una página determinada. Esto da una aproximación de importancia o calidad de una página. PageRank se extiende esta idea al 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 la página A tiene páginas T1 ... Tn que apuntan a ella (es decir, son las citas). El parámetro d es un factor de amortiguación que se puede establecer entre 0 y 1. Por lo general, establecemos d a 0,85. Hay más detalles acerca de d en la siguiente sección. También C (A) se define como el número de enlaces que salen 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 sobre páginas web, por lo que la suma de todas las páginas web PageRank 'será uno.

PageRank o PR (A) se puede calcular utilizando un algoritmo iterativo simple, y corresponde a el vector propio principal de la matriz de enlace normalizada de la web. Además, un PageRank de 26 millones de páginas web puede calcularse 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 intuitiva Justificación

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 se mantiene al hacer clic en los enlaces, no golpear "atrás", pero finalmente se aburre y empieza en otra página al azar. La probabilidad de que el surfista aleatorio visita una página es su PageRank. Y, el d factor de amortiguamiento es la probabilidad en cada página de la "surfista aleatorio" se aburrirá y solicite otra página al azar. Una variación importante es agregar sólo el factor de amortiguamiento d para una sola página, o un grupo de páginas. Esto permite la personalización y puede hacer que sea casi imposible de engañar deliberadamente el sistema con el fin de conseguir una graduación más alta. Tenemos varias otras extensiones al PageRank, de nuevo ver [Página 98].

Otra justificación intuitiva es que una página puede tener un alto PageRank si hay muchas páginas que apuntan a la misma, o si hay algunas páginas que apuntan a la misma y tener un alto PageRank. Intuitivamente, las páginas que están bien citan desde muchos lugares en la web son vale la pena mirar. Además, las páginas que tienen tal vez sólo una cita de algo así como el Yahoo! página de inicio son también generalmente vale la pena mirar. Si una página no era de alta calidad, o era un vínculo roto, es muy probable que la página de inicio de Yahoo no se uniría a ella. PageRank maneja ambos casos y todo lo demás propagando recursivamente pesos a través de la estructura de enlaces de la web.

2.2 Anchor Text

El texto de los enlaces es tratado de una manera especial en nuestro motor de búsqueda. La mayoría de los motores de búsqueda asocian el texto de un enlace con la página que el enlace está activado. Además, lo asociamos con la página el enlace apunta. Esto tiene varias ventajas. En primer lugar, las anclas a menudo proporcionan descripciones más precisas de las páginas web que los propios páginas. En segundo lugar, pueden existir anclajes para los 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 que sea posible para volver las páginas web 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 comprueban para la validez antes de ser devuelto al usuario. En este caso, el motor de búsqueda incluso puede devolver una página que nunca ha existido en realidad, pero tenía hipervínculos apuntando a la misma. Sin embargo, es posible ordenar los resultados, por lo que este problema particular, rara vez sucede.

Esta idea de propagar texto de anclaje a la página se refiere a se implementó en el Worm World Wide Web [McBryan 94] sobre todo porque ayuda a la búsqueda de información no textual, y amplía la cobertura de búsqueda con un menor número de documentos descargados. Utilizamos la propagación de anclaje sobre todo porque el ancla de texto puede ayudar a proporcionar mejores resultados de calidad. El uso de texto de anclaje es eficiente 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, tuvimos más de 259 millones de anclajes que hemos indexado.

2.3 Otras características

Aparte de PageRank y el uso de texto de anclaje, Google tiene varias otras características. En primer lugar, se tiene información de la ubicación de todos los éxitos y por lo que hace un uso extensivo de la proximidad en la búsqueda. En segundo lugar, Google realiza un seguimiento de algunos detalles de la presentación visual, como el tamaño de fuente de las palabras. Palabras en un tipo de letra más grande o más audaz se ponderan más alto que otras palabras. Tercer HTML puro, lleno de páginas está disponible en un repositorio.

3 Trabajo relacionado

Investigación Búsqueda en la web tiene una historia breve y conciso. El gusano de la World Wide Web (WWWW) [McBryan 94] fue uno de los primeros motores de búsqueda web. Fue seguido posteriormente por otros buscadores académicos, muchos de los cuales son ahora las empresas públicas. En comparación con el crecimiento de la Web y la importancia de los motores de búsqueda, hay muy pocos documentos sobre los últimos motores de búsqueda [Pinkerton 94]. Según Michael Mauldin (jefe científico, Lycos Inc) [Mauldin], "los diferentes servicios (incluyendo Lycos) vigilan de cerca los detalles de estas bases de datos". Sin embargo, ha habido una buena cantidad de trabajo en las características específicas de los motores de búsqueda. Especialmente bien representado es un trabajo que puede obtener resultados por el post-procesamiento de los resultados de los motores de búsqueda comerciales existentes o producir pequeños motores de búsqueda escala "individualizados". Por último, ha habido un montón de investigación en sistemas de

recuperación de información, en especial sobre las colecciones bien controladas. En las siguientes dos secciones, se discuten algunas áreas en las que esta investigación debe ampliarse para trabajar mejor en la web.

3.1 Recuperación de Información

El trabajo en los 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 colecciones homogéneas bien controlados, tales 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 la información, el texto de recuperación Conferencia [TREC 96], utiliza una colección bastante pequeño y bien controlado por sus puntos de referencia. El punto de referencia "Muy Grande Corpus" sólo se compara con la de 20 GB 147 GB de nuestro rastreo de 24 millones de páginas web. Las cosas que funcionan bien en TREC menudo no producen buenos resultados en la web. Por ejemplo, el modelo de espacio vectorial norma intenta devolver el documento que más se aproxima la consulta, dado que tanto la consulta y el documento son vectores definidos por su ocurrencia palabra. En la web, esta estrategia a menudo retorna documentos muy cortos que son la consulta además de algunas palabras. Por ejemplo, hemos visto un importante motor de búsqueda me devuelve 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 con mayor precisión lo que quieren y añadir más palabras a su consulta. No estamos de acuerdo con vehemencia con esta posición. Si un usuario envía una consulta como "Bill Clinton" que debe obtener resultados razonables ya que hay una enorme cantidad de información de alta calidad disponibles en este tema. Ejemplos dados como estos, que creen que el trabajo de recuperación de información estándar debe ampliarse para abordar con eficacia la web.

3.2 Diferencias entre la Web y Colecciones bien controlados

La web es una vasta colección de documentos heterogéneos totalmente incontrolados. Documentos en la web tienen extrema variación interna de los documentos, y también en la meta información externa que pueda estar disponible. Por ejemplo, los documentos difieren internamente en su idioma (tanto humanos como de programación), vocabulario (direcciones de correo electrónico, enlaces, códigos postales, números de teléfono, números de productos), forma o formato (texto, HTML, PDF, imágenes, sonidos), y puede incluso a máquina generado (archivos o salida de una base de datos de registro). Por otro lado, definimos meta información externa como información que se puede deducir sobre un documento, pero no está contenido dentro de ella. Ejemplos de información externa meta incluyen cosas como la reputación de la fuente, frecuencia de actualización, calidad, popularidad o uso, y las citas. No sólo son las posibles fuentes de información externa meta variaron, pero las cosas que se están midiendo varían muchos órdenes de magnitud también. Por ejemplo, comparar la información de uso de una página importante, al igual que Yahoo de los que recibe actualmente a millones de páginas vistas cada día con un artículo histórico oscura que podría recibir un punto de vista cada diez años. Es evidente que estos dos temas deben ser tratados de manera muy diferente por un motor de búsqueda.

Otra gran diferencia entre la web y colecciones bien controlados tradicionales es que no hay prácticamente ningún control sobre lo que la gente puede poner en la web. Si unimos esto flexibilidad para publicar cualquier cosa con la enorme influencia de los motores de búsqueda para enrutar el tráfico y las empresas que la manipulación deliberada los motores de búsqueda con fines de lucro convertido en un problema grave. Este problema que no ha sido abordado en los sistemas de recuperación de información cerrada tradicionales. Además, es interesante observar que los metadatos esfuerzos han fracasado en gran medida con los motores de búsqueda web, ya que cualquier texto en la página que no está directamente representado al usuario se abusa de 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.

Anatomía 4 Sistema

En primer lugar, vamos a ofrecer un debate de alto nivel de la arquitectura. Entonces, hay algunas descripciones en profundidad de las estructuras de datos importantes. Por último, las principales aplicaciones: rastreo, indexación y búsqueda serán examinadas en profundidad.

4.1 Google Arquitectura general

En esta sección, vamos a dar una visión general de alto nivel de cómo funciona todo el sistema como se muestra en la Figura 1. Otras secciones discutirán las aplicaciones y estructuras de datos que no se mencionan en esta sección. La mayor parte de Google se implementa en C o C ++ para la eficiencia y puede ejecutarse en Solaris o Linux.

En Google, la web de rastreo (la descarga de páginas web) se lleva a cabo por varios rastreadores distribuidos. Hay una URLserver que envía listas de URLs para ser exagerado los rastreadores. Las páginas web que son descabellada se envían a la storeserver. El storeserver luego 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 cada vez que una nueva URL se analiza de una página web. La función de indexación se realiza por el indexador y el clasificador. El indizador realiza una serie de funciones. Se lee el repositorio, descomprime los documentos, y las analiza. Cada documento se convierte en un conjunto de ocurrencias de palabras llamado hits. Los éxitos grabar la palabra, la posición en el documento, una aproximación del tamaño de fuente, y la capitalización. El indexador distribuye estos éxitos en un conjunto de "barriles", la creación de un índice de avance parcialmente ordenados. El indexador realiza otra función importante. Analiza todos los enlaces en cada página web y almacenes de información importante acerca de ellos en

Figura 1. Arquitectura de Alto Nivel de Google

un archivo de anclajes. Este archivo contiene información suficiente para determinar donde cada enlace apunta desde y hacia, y el texto del enlace.

El URLresolver lee el archivo de anclas y convierte las direcciones URL relativas en URLs absolutas y a su vez en docIDs. Se pone el texto de anclaje en el índice hacia adelante, asociado con el docID que los puntos de anclaje a. También genera una base de datos de enlaces que son pares de docIDs. La base de datos enlaces se utiliza para calcular PageRanks para todos los documentos.

El clasificador toma los barriles, que se ordenan por docID (esto es una simplificación, véase la Sección 4.2.5), y les recurre por wordID para generar el índice invertido. Esto se hace en lugar de modo que se necesita poco espacio temporal para esta operación. El clasificador también produce una lista de wordIDs 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 utilizado por el buscador. El buscador está dirigido 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 Estructuras de datos Mayor

Estructuras de datos de Google están optimizadas para que una colección de documentos de gran tamaño puede ser rastreado, indexados, y buscaron con poco costo. Aunque, CPUs y las tasas de salida de entrada a granel han mejorado dramáticamente en los últimos años, un disco buscan aún requiere unos 10 ms para completar. Google está diseñada para evitar búsquedas en disco siempre que sea posible, y esto ha tenido una influencia considerable en el diseño de las estructuras de datos.

4.2.1 BigFiles

BigFiles son archivos virtuales que abarcan múltiples sistemas de archivos y son direccionables por 64 bits enteros. El reparto entre los múltiples sistemas de archivos se maneja automáticamente. El paquete BigFiles también se encarga de la asignación y cancelación de asignación de descriptores de archivos, ya que los sistemas operativos no proporcionan suficiente para nuestras necesidades. BigFiles también admite opciones de compresión rudimentarias.

4.2.2 Repositorio

El repositorio contiene el HTML de cada página web. Cada página se comprime usando zlib (ver RFC1950). La elección de la técnica de compresión es un compromiso 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 era

Figura 2. Estructura de datos del repositorio

aproximadamente de 4 a 1 en el repositorio en comparación con el 3 a 1 de compresión de zlib. En el repositorio, los documentos se almacenan uno tras otro y están prefijados por docID, longitud y URL como puede verse en la Figura 2. El repositorio no requiere otras estructuras de datos para ser utilizados con el fin de acceder a él. Esto ayuda a la consistencia de los datos y hace el desarrollo mucho más fácil; podemos reconstruir todas las otras estructuras de datos de sólo el repositorio y un archivo que lista los errores de orugas.

4.2.3 Índice de documentos

El índice de documento mantiene la información sobre cada documento. Es un ISAM ancho fijo (modo de acceso secuencial Index) índice, ordenado por docID. La información almacenada en cada entrada incluye el estado actual del documento, un puntero en el repositorio, una suma de comprobación de documentos y diversas estadísticas. Si el documento se ha rastreado, también contiene un puntero a un archivo de ancho variable llamada DOCINFO que contiene su URL y el título. De lo contrario, el puntero en la urllist que contiene sólo la URL. Esta decisión de diseño fue impulsado por el deseo de tener una estructura de datos razonablemente compacto, y la posibilidad de buscar un registro en un disco seek durante una búsqueda

Además, hay un archivo que se utiliza para convertir las URL en docIDs. Es una lista de sumas de comprobación de URL con sus correspondientes docIDs y está ordenada por la suma de comprobación. Con el fin de encontrar el docID de un URL en particular, la suma de comprobación de la URL se calcula y una búsqueda binaria se realiza en el archivo de sumas de comprobación para encontrar su docID. URLs se pueden convertir en docIDs en el lote haciendo una fusión con este archivo. Esta es la técnica del URLresolver utiliza para convertir las URL en docIDs. Este modo lote de actualización es crucial, ya que de lo contrario hay que realizar un solo buscan por todos los eslabones que asumir un disco tomaría más de un mes para nuestro conjunto de datos de 322 millones de enlace.

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 la 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 se añadieron al léxico). Se lleva a cabo en dos partes - una lista de las palabras (concatenados juntos pero separados por nulos) y una tabla hash de punteros. Para las diversas funciones, la lista de las palabras tiene alguna información auxiliar que está más allá del alcance de este documento para explicar plenamente.

4.2.5 Listas de ataque

Una lista de resultados corresponde a una lista de ocurrencias de una palabra en particular en un documento particular, incluyendo la posición, la fuente, y la información de la capitalización. Hit listas representan la mayor parte del espacio utilizado tanto en el avance y los índices invertidos. Debido a esto, es importante que los represente tan eficientemente

como sea posible. Se consideraron varias alternativas para la posición de codificación, la fuente, y la capitalización - codificación simple (un triple de números enteros), una codificación compacta (una asignación optimizada mano de bits), y la codificación de Huffman. Al final se optó por una mano optimizado codificación compacta ya que requiere mucho menos espacio que la simple codificación y mucho menos manipulación de bits de codificación de Huffman. Los detalles de los accesos se muestran en la Figura 3.

Nuestra codificación compacta utiliza dos bytes para cada golpe. Hay dos tipos de resultados: éxitos de lujo y éxitos de civil. Éxitos de lujo incluyen éxitos que ocurren en una URL, título, texto de anclaje o etiqueta meta. Accesos Plain incluyen todo lo demás. Un golpe normal consiste en un poco de capitalización, tamaño de fuente y 12 bits de posición de la palabra en un documento (todas las posiciones superiores a 4095 se etiquetan 4096). Tamaño de la fuente se representa en relación con el resto del documento usando tres bits (sólo 7 valores se utilizan en realidad, porque 111 es la bandera que señala un golpe de fantasía). Un golpe de lujo consta de un poco de capitalización, el tamaño de fuente se establece en 7 para indicar que es un golpe de lujo, 4 bits para codificar el tipo de golpe de fantasía, y 8 bits de posición. Para visitas de anclaje, los 8 bits de posición se dividen en 4 bits para la posición de anclaje y 4 bits para un hash de la docID el ancla se produce. Esto nos da alguna frase limita la búsqueda, siempre y cuando no hay que muchos anclajes para un palabra en particular. Esperamos actualizar la forma en que los accesos de anclaje se almacenan para permitir una mayor resolución en la posición y campos docIDhash. Utilizamos tamaño de la fuente en relación con el resto del documento, ya que en la búsqueda, usted no desea clasificar los documentos por lo demás idénticas de manera diferente sólo porque uno de los documentos está en un tipo de letra más grande.

La longitud de una lista de resultados se almacena antes de los propios éxitos. Para ahorrar espacio, la longitud de la lista de resultados se combina con la wordID en el índice hacia adelante y el docID en el índice invertido. Esto limita a 8 y 5 bits respectivamente (hay algunos trucos que permiten a 8 bits para ser prestados desde el wordID). Si la duración es más larga que cabría en que muchos bits, se utiliza un código de escape en esos bits, y los siguientes dos bytes contienen la longitud real.

4.2.6 Índice Adelante

El índice de avance es en realidad ya parcialmente ordenadas. Se almacena en un número de barriles (utilizamos 64). Cada barril tiene una gama de wordID de. Si un documento contiene palabras que caen dentro de un barril particular, la docID se registra en el barril,

Figura 3. avance y retroceso Índices y el Léxico

seguido por una lista de de wordID con hitlists que corresponden a esas palabras. Este esquema requiere un poco más de almacenamiento debido a docIDs duplicados pero la diferencia es muy pequeña para un número razonable de cubos y ahorra considerable tiempo y la complejidad de codificación en la fase final de la indexación realizada por el clasificador. Por otra parte, en lugar de almacenar de wordID reales, almacenamos cada wordID como una diferencia relativa del wordID mínimo que cae en el cañón del wordID es. De esta manera, podemos utilizar sólo 24 bits para los años wordID en los barriles sin ordenar, dejando 8 bits para la longitud lista de resultados.

4.2.7 Índice invertido

El índice invertido se compone de las mismas barricas como el índice hacia adelante, excepto que han sido procesados por el clasificador. Por cada wordID válida, el léxico contiene un puntero en el barril que wordID cae en. Apunta a una doclist de docID de junto con sus correspondientes listas de éxitos. Este doclist representa todas las ocurrencias de esa palabra en todos los documentos.

Una cuestión importante es en qué orden los docID de deben aparecer en el doclist. Una solución simple es almacenarlos ordenados por docID. Esto permite una rápida fusión de diferentes doclists para varias consultas de palabras. Otra opción es almacenarlos según un ranking de la aparición de la palabra en cada documento. Esto hace que responder una consulta de palabras triviales y hace probable que las respuestas a varias consultas de palabras son cerca del inicio. Sin embargo, la fusión es mucho más difícil. Además, esto hace que el desarrollo mucho más difícil en que un cambio en la función de clasificación requiere una reconstrucción del índice. Elegimos un compromiso entre estas opciones, mantener dos conjuntos de barriles invertidas - un conjunto de listas de resultados que incluyen éxitos de título o de anclaje y otro conjunto de todas las listas de éxitos. De esta manera, se comprueba la primera serie de barriles primero y si no hay suficientes resultados dentro de esos barriles comprobamos los más grandes.

4.3 Rastreo de la Web

Ejecución de un rastreador web es una tarea difícil. Hay problemas de rendimiento y fiabilidad difíciles y aún más importante, hay cuestiones sociales. El gateo es la aplicación más frágil, ya que implica la interacción con cientos de miles de servidores web y varios servidores de nombres que son todos más allá del 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. Una sola URLserver sirve listas de direcciones URL a una serie de rastreadores (que normalmente encontramos aproximadamente 3). Tanto el URLserver y los rastreadores son implementados en Python. Cada rastreador mantiene aproximadamente 300 conexiones abiertas a la vez. Esto es necesario para recuperar páginas web a un ritmo 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 600K por segundo de datos. Un gran estrés rendimiento es búsqueda de DNS. Cada rastreador mantiene una su propia caché de DNS para que no se tiene que hacer una

búsqueda de DNS antes de meterse cada documento. Cada uno de los cientos de conexiones puede estar en un número de diferentes estados: mirando hacia arriba DNS, conectando con el anfitrión, el envío de la solicitud, y la recepción de la respuesta. Estos factores hacen que el rastreador un componente complejo del sistema. Utiliza asíncrono IO para gestionar eventos, y un número de colas para pasar la página obtiene de estado a estado.

Resulta que la ejecución de un rastreador que conecta a más de medio millón de servidores, y genera decenas de millones de entradas de registro genera una buena cantidad de correo electrónico y llamadas telefónicas. Debido a la gran cantidad de personas que vienen en la línea, siempre hay aquellos que no saben lo que es un rastreador es, porque este es el primero que han visto. Casi a diario, recibimos un correo electrónico algo como, "Wow, te veías a una gran cantidad de páginas de mi sitio web. ¿Cómo te gusta?" También hay algunas personas que no conocen el protocolo de exclusión de robots, y piensan que su página debe ser protegido de la indexación de una declaración como, "Esta página tiene derechos de autor y no debe ser indexados", que no hace falta decir que es difícil para los rastreadores web entender. También, debido a la enorme cantidad de datos involucrados, cosas inesperadas sucederán. Por ejemplo, nuestro sistema intentó arrastrarse un juego en línea. Esto dio lugar a un montón de mensajes de basura en el centro de su juego! Resulta que este era un problema fácil de solucionar. Pero este problema no se había acercado 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 ejecutar en gran parte de la Internet. Invariablemente, hay cientos de problemas oscuros que sólo pueden ocurrir en una página de toda la web y hacer que el rastreador se bloquee, o peor, provocar un comportamiento impredecible o incorrecta. Los sistemas que acceden a grandes partes de la Internet deben ser diseñados para ser muy robusta y cuidadosamente probado. Desde los grandes sistemas complejos como rastreadores invariablemente causar problemas, es necesario que sean importantes recursos dedicados a la lectura del correo electrónico y la solución de estos problemas a medida que surgen.

4.4 Indexación de la Web

De análisis - Cualquier programa de análisis que está diseñado para ejecutarse en toda la Web debe manejar una gran cantidad de errores posibles. Estos van desde errores tipográficos en las etiquetas HTML para kilobytes de ceros en el medio de una etiqueta, los caracteres no ASCII, etiquetas HTML anidado cientos de profundidad, y una gran variedad de otros errores que desafían la imaginación de nadie para llegar a los igualmente creativas. Para obtener la máxima velocidad, en lugar de utilizar YACC para generar un analizador CFG, usamos flex para generar un analizador léxico que atuendo con su propia pila. El desarrollo de este programa de análisis que funciona a una velocidad razonable y es muy robusto implicó una buena cantidad de trabajo.

Para poner un límite en el tiempo de respuesta, una vez que un cierto número (actualmente 40000) de los documentos se encuentran a juego, el buscador pasa automáticamente al paso 8 en la Figura 4. Esto significa que es posible que los resultados subóptimos serían devueltos. Actualmente estamos investigando otras

maneras de resolver este problema. En el pasado, nos lo solucionaron los accesos de acuerdo con PageRank, que parecía mejorar la situación.

4.5.1 El sistema de clasificación

Google mantiene mucha más información sobre los documentos web que los motores de búsqueda típicos. Cada lista negra incluye la posición, la fuente, y la información de la capitalización. Además, tenemos en cuenta los éxitos de texto de anclaje y el PageRank del documento. La combinación de toda esta información en un rango es difícil. Hemos diseñado nuestra función de clasificación para que ningún factor en particular puede tener demasiada influencia. En primer lugar, consideremos el caso más simple - una sola consulta de textos. Con el fin de clasificar un documento con una sola consulta de textos, Google mira a la lista negra de ese documento para esa palabra. Google considera que cada golpe sea uno de varios tipos diferentes (título, ancla, URL, llanura fuente grande de texto, sin formato de fuente pequeño texto, ...), cada uno de los cuales tiene su propio peso tipo. El tipo-pesos constituyen un vector indexado por tipo. Google cuenta el número de accesos de cada tipo en la lista de resultados. Entonces, cada recuento se convierte en un peso recuento. Conde-pesos aumentan linealmente con recuentos al principio, pero rápidamente disminuir de manera que más de un cierto conde no le ayudará. Tomamos el producto escalar del vector de recuento-pesos con el vector de tipo-pesos para calcular una puntuación de IR para el documento. Por último, la puntuación IR se combina con PageRank para dar un rango final al documento.

Para una búsqueda de varias palabras, la situación es más complicada. Ahora varias listas de éxitos deben ser escaneados a través de una sola vez para que golpea ocurren juntos en un documento se ponderan más alto que golpea ocurren lejos. Los éxitos de las múltiples listas de resultados se corresponden de modo que los accesos cercanos coinciden juntos. Para cada conjunto combinado de hits, una proximidad se calcula. La proximidad se basa en lo lejos los éxitos están en el documento (o ancla), pero se clasifica en 10 de valor "contenedores" diferentes que van desde una concordancia de frase de "ni de lejos". Los recuentos se calculan no sólo para cada tipo de golpe, sino para todo tipo y de proximidad. Cada par de tipo y la proximidad tiene una prox peso tipo. Los recuentos se convierten en conteo-pesos y nos toman el producto escalar del Conde-pesos y el tipo-PROX-pesos para calcular una puntuación de IR. Todos estos números y matrices posible que todos aparezcan con los resultados de búsqueda utilizando un modo de depuración especial. Estas pantallas han sido de gran ayuda en el desarrollo del sistema de clasificación.

4.5.2 Evaluación

La función de la clasificación tiene muchos parámetros como el tipo-pesos y el tipo-PROX-pesos. Averiguar los valores correctos para estos parámetros es algo de un arte negro. Para ello, contamos con un mecanismo de retroalimentación de los usuarios en el motor de búsqueda. Un usuario de confianza puede opcionalmente evaluar todos los resultados que se devuelven. Se guarda Esta retroalimentación. Luego, 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 una 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 un motor de búsqueda es la calidad de sus resultados de búsqueda. Si bien una evaluación de usuario completa está más allá del alcance de este trabajo, nuestra propia experiencia con Google ha demostrado que para producir mejores resultados que los principales motores de búsqueda comerciales para la mayoría de las búsquedas. Como un ejemplo que ilustra el uso de PageRank, el ancla de texto, y la proximidad, la figura 4 muestra los resultados de Google para una búsqueda en "bill clinton". Estos resultados demuestran algunas de las características de Google. Los resultados se agrupan por servidor. Esto ayuda considerablemente cuando tamizado a través de conjuntos de resultados. Una serie de resultados son de dominio whitehouse.gov que es lo que uno puede esperar razonablemente de tal búsqueda. En la actualidad, la mayoría de los principales motores de búsqueda comercial no devuelven ningún resultado de whitehouse.gov, mucho menos los más adecuados. Observe que no hay ningún título para el primer resultado. Esto se debe a que no se ha rastreado. En su lugar, Google se basó en el texto de anclaje para determinar esto era una buena respuesta a la consulta. Del mismo modo, el quinto resultado es una 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 páginas de alta calidad y, en última comprobación, ninguno era enlaces rotos. Esto es en gran parte porque todos tienen alto PageRank. Los PageRanks son los porcentajes en rojo junto con gráficos de barras. Por último, no hay resultados sobre un proyecto de ley que no sea Clinton o

Pregunta: bill clinton http://www.whitehouse.gov/ 100,00% (sin fecha) (0K) http://www.whitehouse.gov/ Oficina del Presidente 99,67% (23 de diciembre 1996) (2K) http://www.whitehouse.gov/WH/EOP/OP/html/OP_Home.html   Bienvenido a La Casa Blanca 99,98% (09 de noviembre 1997) (5K) http: // www.whitehouse.gov/WH/Welcome.html~~MD~~aux   Enviar correo electrónico al Presidente 99.86% (14 de julio 1997)

 

"No oficial" de Bill Clinton 94,06% (11 de noviembre 1997) (14K) http://zpub.com/un/un-bc.html   Bill Clinton se reúne La encoge 86,27% (29 de junio 1997) (63K) http://zpub.com/un/un-bc9.html presidente Bill Clinton - El lado oscuro 97,27% (10 de noviembre 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 ejemplo de Google

sobre un Clinton aparte de Bill. Esto se debe a que le damos pesada importancia de la proximidad de las ocurrencias de palabras. Por supuesto una verdadera prueba de la calidad de un motor de búsqueda implicaría un extenso estudio de usuario o resultados de análisis que no tenemos espacio para aquí. En lugar de ello, invitamos al lector a probar Google por sí mismos en http://google.stanford.edu.

5.1 Requisitos de almacenamiento

Aparte de la calidad de búsqueda, Google está diseñado para escalar de forma rentable para el tamaño de la Web a medida que crece. Un aspecto de esto es utilizar el almacenamiento de manera eficiente. Tabla 1 presenta un desglose de algunas estadísticas y los requisitos de almacenamiento de Google. Debido a la compresión del tamaño total del depósito es de aproximadamente 53 GB, poco más de un tercio del total de datos que almacena. A los precios actuales de disco esto hace que el depósito de una fuente relativamente 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. Por otra parte, la mayoría de las preguntas pueden ser contestadas utilizando sólo el índice corta invertida. Con una mejor codificación y compresión del Índice de documentos, un motor de búsqueda web de alta calidad puede caber en una unidad de 7GB de un nuevo PC.

Rendimiento 5.2 Sistema

Es importante para un motor de búsqueda para rastrear e indexar de manera eficiente. De esta manera la información puede mantenerse al día y los principales cambios en el sistema se puede probar con relativa rapidez. Para Google, las principales operaciones están rastreo, la indexación y clasificación. Es difícil medir cuánto tiempo tomó el rastreo global porque los discos se llenaron, los servidores de nombres se

Estadísticas de Almacenamiento

Tamaño total de descabellada Páginas

147.8 GB Repositorio Comprimido

53.5 GB

Índice invertido Corto 4.1 GB

Índice completo Invertido 37.2 GB

Léxico 293 MB

Datos de anclaje temporal (no en total)

6.6 GB

Índice de documentos Incl. Ancho de datos variables

9.7 GB

Enlaces Base de datos 3.9 GB

Total sin Repositorio 55.2 GB

Con total Repositorio 108.7 GB

Página web Estadísticas

Número de páginas Web recuperados de

24000000

Número de Urls Seen 76500000

Número de 1,7

estrelló, o cualquier número de otros problemas que dejaron el sistema. En total tardó aproximadamente 9 días para descargar los 26 millones de páginas (incluyendo errores). Sin embargo, una vez que el sistema estaba funcionando sin problemas, se corría mucho más rápido, la descarga de los últimos 11 millones de páginas en sólo 63 horas, con un promedio de poco más de 4 millones de páginas al día o 48,5 páginas por segundo. Corrimos el indexador y el rastreador de forma simultánea. El indexador corrió solo más rápido que los rastreadores. Esto es en gran parte porque pasamos el tiempo justo optimizar el indexador de modo que no sería un cuello de botella. Estas optimizaciones incluyen actualizaciones masivas al índice de documentos y colocación de estructuras de datos críticos en el disco local. El indexador funciona a aproximadamente 54 páginas por segundo. Los clasificadores pueden ejecutarse completamente en paralelo; utilizando cuatro máquinas, todo el proceso de clasificación toma alrededor de 24 horas.

5.3 Búsqueda Rendimiento

Mejorar el rendimiento de búsqueda no fue el foco principal de nuestra investigación hasta este punto. La versión actual de Google responde a la mayoría de las consultas de entre 1 y 10 segundos. Esta vez está dominado en su mayoría por el disco IO a través de NFS (ya que los discos están distribuidas en un número de máquinas). Por otra parte, Google no tiene ningún optimizaciones tales como el almacenamiento en caché de consultas, subíndices en términos comunes, y otras optimizaciones comunes. Tenemos la intención de acelerar Google considerablemente a través de la distribución y el hardware, el software y mejoras algorítmicas. Nuestro objetivo es ser capaz de manejar varios cientos de consultas por segundo. Tabla 2 tiene unos tiempos de consulta de la muestra de la versión actual de Google. Se repiten para mostrar las aceleraciones resultantes de caché IO.

6. Conclusiones

Google está diseñado para ser un motor de búsqueda escalable. El objetivo principal es proporcionar resultados de búsqueda de alta calidad sobre un mundo en rápido crecimiento Wide Web. Google emplea una serie de técnicas para mejorar la calidad de búsqueda incluyendo fila de la página, el texto de anclaje, y la información de proximidad. Además, Google es una arquitectura completa para la recopilación de

Tabla 2. Tiempos de búsqueda

Página web Estadísticas

Número de páginas Web recuperados de

24000000

Número de Urls Seen 76500000

Número de 1,7

Consulta Inicial

Misma consulta repetida (IO mayormente en caché)

Consulta CPU

Tiempo (s)

Tiempo total (s)

CPU Tiempo (s)

Tiempo total (s)

al gore 0.09 2.13 0.06 0.06

vicepresidente 1.77 3.84 1.66 1.80

discos duros 0.25 4.86 0.20 0.24

los motores de búsqueda

1.31 9.63 1.16 1.16

páginas web, la indexación de ellos, y la realización de consultas de búsqueda por encima de ellos.

6.1 Trabajo Futuro

Un motor de búsqueda en Internet a gran escala es un sistema complejo y mucho queda por hacer. Nuestros objetivos inmediatos son mejorar la eficiencia de búsqueda y escalar a aproximadamente 100 millones de páginas web. Algunas mejoras simples a la eficiencia incluyen el almacenamiento en caché de consultas, la asignación de disco inteligente, y subíndices. Otra área que requiere mucha investigación es actualizaciones. Debemos tener algoritmos inteligentes para decidir qué páginas web antiguas deben recrawled y qué otros nuevos deben ser rastreadas. Trabajar hacia esta meta se ha hecho en [Cho 98]. Una prometedora área de investigación está utilizando memorias caché de proxy para construir las bases de datos de búsqueda, ya que son impulsados demanda. Estamos planeando añadir características simples apoyados por motores de búsqueda comerciales como operadores booleanos, la negación, y frenar. Sin embargo, otras características están empezando a ser explorado como retroalimentación relevancia y la agrupación (Actualmente Google es compatible con una sencilla basada en la agrupación nombre de host). También planeamos apoyar contexto de usuario (como la ubicación del usuario), y el resultado de resumen. También estamos trabajando para extender el uso de la estructura de enlace y el texto del vínculo. Experimentos sencillos indican PageRank se puede personalizar mediante el aumento del peso de la página o marcadores de inicio del usuario. En cuanto a texto del enlace, estamos experimentando con el uso de texto enlaces, además del texto del enlace en sí circundante. Un motor de búsqueda Web es un ambiente muy rico para las ideas de investigación. Tenemos demasiados para enumerar aquí, así que no esperamos que esta sección de trabajo futuro para convertirse en mucho más corto en un futuro próximo.

6.2 de alta calidad de Búsqueda

El mayor problema que enfrentan los usuarios de motores de búsqueda web hoy en día es la calidad de los resultados que obtienen espalda. Si bien los resultados son a menudo divertido y expanden los horizontes de los usuarios, son a menudo frustrante y consume un tiempo precioso. Por ejemplo, el primer resultado de búsqueda para "Bill Clinton" en uno de los motores de búsqueda comerciales más populares fue la de Bill Clinton Broma del Día: 14 de abril 1997 Google está diseñado para proporcionar la búsqueda de mayor calidad con el fin de la Web sigue. creciendo rápidamente, la información se puede encontrar fácilmente. Con el fin de lograr esto Google hace un uso intensivo de la información hipertextual que consta de estructura de enlace y enlace (ancla) texto. Google también utiliza la información de proximidad y la fuente. Si bien es difícil la evaluación de un motor de búsqueda, hemos encontrado subjetivamente que Google devuelve resultados de búsqueda de calidad más altos que los actuales motores de búsqueda comerciales. 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 enlaces de texto como una descripción de lo que el enlace apunta a ayuda al retorno de motores de búsqueda relevantes (y hasta cierto punto de alta calidad) resultados. Por último, el uso de la información de proximidad ayuda a aumentar la relevancia de un gran negocio para muchas consultas.

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 y el tiempo, y los factores constantes son muy importantes cuando se trata de toda la Web. En la aplicación de Google, hemos visto los cuellos de botella en la CPU, acceso a la memoria, la capacidad de memoria, disco busca, rendimiento del disco, capacidad de disco, y la red de IO. Google ha evolucionado para superar una serie de estos cuellos de botella durante las diversas operaciones. Principales estructuras de datos de Google hacen uso eficiente del espacio de almacenamiento disponible. Por otra parte, las rastrear, indexar y operaciones de clasificación son lo suficientemente eficientes para poder construir un índice de una parte sustancial de la web - 24 millones de páginas, en menos de una semana. Esperamos ser capaces de 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 de Google ha recogido ya ha dado lugar a muchos otros documentos presentados a congresos y muchos más en camino. Investigaciones recientes como [Abiteboul 97] ha demostrado una serie de limitaciones a las preguntas acerca de la Web que pueden ser contestadas sin tener la Web disponibles localmente. Esto significa que Google (o un sistema similar) no es sólo una valiosa herramienta de investigación pero necesario para una amplia gama de aplicaciones. Esperamos que Google va a ser un recurso para los investigadores e investigadores de todo el mundo y provocará la próxima generación de tecnología de los motores de búsqueda.

7 Agradecimientos

De Scott Hassan y Alan Steremberg han sido fundamentales para el desarrollo de Google. Sus contribuciones talentosos son insustituibles, y los autores les debemos mucha gratitud. También nos gustaría dar las gracias a Héctor García-Molina, Rajeev Motwani, Jeff Ullman, y Terry Winograd y todo el grupo WebBase por su apoyo y discusiones interesantes. Por último, nos gustaría reconocer el generoso apoyo de nuestros donantes de equipos IBM, Intel y Sun y nuestros financiadores. La investigación descrita aquí se llevó a cabo como parte del Proyecto de Biblioteca Digital Integrado de Stanford, con el apoyo de la National Science Foundation bajo el Acuerdo Cooperativo IRI-9411306. La financiación de este acuerdo de cooperación también es proporcionada por DARPA y la NASA, y por Interval

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

Referencias

o

o [Marchiori 97] Massimo Marchiori. La búsqueda de la información correcta en la Web:. Hyper motores de búsqueda La Sexta Conferencia Internacional WWW (WWW 97). Santa Clara, EE.UU., 7 a 11 abril 1997.

o [McBryan 94] Oliver A. McBryan. GENVL y WWWW: Herramientas para Taming the Web. Primera Conferencia Internacional sobre la. World Wide Web CERN, Ginebra (Suiza), mayo de 1994. 25-26-27 http://www.cs.colorado.edu/home/mcbryan/mypapers/www94.ps

o . [Página 98] Lawrence Página, Sergey Brin, Rajeev Motwani, Terry Winograd Clasificación La Cita PageRank: poner orden en la Web. Manuscrito en curso. Http://google.stanford.edu/~backrub/pageranksub.ps

o [Pinkerton 94] Brian Pinkerton, encontrar lo que se quiere:. Experiencias con el WebCrawler La Segunda Internacional WWW Conferencia de Chicago, EE.UU., 17-20 de octubre de 1994. http://info.webcrawler.com/bp/WWW94.html

o . [Spertus 97] Ellen Spertus parásito: Minería información estructural en la Web. La Sexta Conferencia Internacional WWW (WWW 97). Santa Clara, EE.UU., 7 a 11 abril 1997.

o [TREC 96] Actas de la quinta Conferencia texto REcuperación (TREC-5). Gaithersburg, Maryland, Noviembre 20-22, 1996. Editorial: Departamento de Comercio, el Instituto Nacional de Estándares y Tecnología. Editores: DK Harman y EM Voorhees. Texto completo en: http://trec.nist.gov/

o [Witten 94] Ian H Witten, Alistair Moffat, y Timothy C. Bell. Gigabytes Administración: La compresión y la indexación de documentos e imágenes. Nueva York: Van Nostrand Reinhold, 1994.

o [Weiss 96] Ron Weiss, Bienvenido Vélez, Mark A. Sheldon, Chanathip Manprempre, Peter Szilagyi, Andrzej Duda, y David K. Gifford. HyPursuit: Un motor de búsqueda jerárquica de la red que explota Content-Enlace hipertexto Clustering. Actas de la séptima ACM Conferencia sobre

hipertexto. Nueva York, 1.996.

Vitae

Sergey Brin recibió su licenciatura en

matemáticas y ciencias de la computación de la Universidad de Maryland en College Park en 1993. Actualmente es un Ph.D. candidato en ciencias de la computación en la Universidad de Stanford, donde recibió su maestría en 1995. Él es un receptor de una Fundación Nacional de Ciencia de Becas de Postgrado. Sus intereses de investigación incluyen los motores de búsqueda, extracción de información de fuentes no estructuradas, y la minería de datos de grandes colecciones de textos y datos científicos.

Lawrence Página nació en East Lansing, Michigan, y recibió una EEB en Ingeniería Informática en la Universidad de Michigan, Ann Arbor en 1995. En la actualidad es un 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, la interacción persona-ordenador, motores de búsqueda, la escalabilidad de las interfaces de acceso a la información, y la minería de datos personales.

8 Apéndice A: Publicidad y Motivos mixtos

En la actualidad, el modelo de negocio predominante para los motores de búsqueda comerciales es la publicidad. Los objetivos del modelo de negocio de la publicidad no siempre corresponden a la prestación de búsqueda de calidad a los usuarios. Por ejemplo, en nuestra búsqueda prototipo de motor de uno de los mejores resultados para el teléfono celular es "El Efecto de Cellular Phone Uso Al conductor Atención", un estudio que explica con gran detalle las distracciones y los riesgos asociados con la conversación en un teléfono celular mientras se conduce. Este resultado de la búsqueda se acercó primero a causa de su gran importancia, a juzgar por el algoritmo de PageRank, una aproximación de la citación importancia en la web [Página 98]. Está claro que un motor de búsqueda que fue tomando el dinero por mostrar anuncios de teléfonos celulares tendría dificultades para justificar la página que nuestro sistema regresó a sus anunciantes que pagan. Para este tipo de razón y la experiencia histórica con otros medios de comunicación [Bagdikian 83], esperamos que la publicidad financiada motores de búsqueda se hará con preferencia inherente hacia los anunciantes y lejos de las necesidades de los consumidores.

Dado que es muy difícil incluso para los expertos para evaluar los motores de búsqueda, el sesgo de motor de búsqueda es particularmente insidioso. Un buen ejemplo fue OpenText, que fue informado de que la venta de las empresas el derecho a ser incluido en la parte superior de los resultados de búsqueda para determinadas consultas [Marchiori 97]. Este tipo de sesgo es mucho más insidioso que la publicidad, ya que no está claro que "merece" estar ahí, y que está dispuesto a pagar dinero para ser enumeradas. Este modelo de negocio se tradujo en un alboroto, y OpenText ha dejado de ser un motor de búsqueda viable. Pero sesgo menos flagrante son susceptibles de ser tolerado por el mercado. Por ejemplo, un motor de búsqueda podría añadir un pequeño factor de los resultados de búsqueda de las empresas "amigables", y restar un factor de los resultados de los

competidores. Este tipo de sesgo es muy difícil de detectar, pero todavía podría tener un efecto significativo en el mercado. Por otra parte, los ingresos de publicidad a menudo proporciona un incentivo para proporcionar resultados de búsqueda de mala calidad. Por ejemplo, hemos observado un importante motor de búsqueda no volvería página de inicio de una gran compañía aérea cuando el nombre de la compañía aérea se le dio como una consulta. Dio la casualidad de que la aerolínea había colocado un anuncio costoso, vinculado a la consulta que era su nombre. Una mejor motor de búsqueda no habría requerido este anuncio, y posiblemente como resultado la pérdida de los ingresos de la compañía aérea al motor de búsqueda. En general, se podría argumentar desde el punto de vista del consumidor que la mejor es, se necesitará el motor de búsqueda de los menos anuncios para el consumidor para encontrar lo que quieren. Por supuesto, esto erosiona la publicidad apoyada modelo de negocio de los motores de búsqueda existentes. Sin embargo, siempre habrá dinero de los anunciantes que quieren un cliente para cambiar los productos, o que tienen algo que es realmente nuevo. Pero creemos que la cuestión de la publicidad hace que suficientes incentivos mixtos que es fundamental contar con un motor de búsqueda competitiva 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. Acabamos de recibir el disco y máquinas para manejar más o menos de esa cantidad. Todas las piezas que requieren mucho tiempo del sistema son paralelizar y hora más o menos lineal. Estos incluyen cosas como los rastreadores, indexadores y clasificadores. También pensamos que la mayoría de las estructuras de datos se ocupará con gracia con la expansión. Sin embargo, en 100 millones de páginas web que estaremos muy cerca contra todo tipo de límites del sistema operativo en los sistemas operativos más comunes (actualmente corremos tanto en Solaris y Linux). Estos incluyen cosas como la memoria direccionable, el número de descriptores de archivos abiertos, tomas de corriente de red y ancho de banda, y muchos otros. Creemos que la ampliación a un montón más de 100 millones de páginas que aumentaría considerablemente la complejidad de nuestro sistema.

9.2 Escalabilidad de arquitecturas centralizadas de indexación

Como las capacidades de las computadoras aumentan, se hace posible indexar una cantidad muy grande de texto para un costo razonable. Por supuesto, otros medios de comunicación más intensivas en ancho de banda, como el vídeo es probable que se convierta más penetrante. Pero, debido a que el costo de producción de un texto es bajo comparado con los medios de comunicación como el vídeo, el texto es probable que siga siendo muy generalizada. Además, es probable que pronto vamos a tener reconocimiento de voz que hace un trabajo razonable convertir voz en texto,

la ampliación de la cantidad de texto disponible. Todo esto ofrece posibilidades increíbles para la indexación centralizada. Aquí está un ejemplo ilustrativo. Suponemos que queremos indexar todo a todos en los EE.UU. ha escrito durante un año. Suponemos que hay 250 millones de personas en los EE.UU. y escribimos un promedio de 10k por día. Eso se resuelve en alrededor de 850 terabytes. También suponen que la indexación de un terabyte puede hacerse ahora por un costo razonable. También suponemos que los métodos de indexación utilizados sobre el texto son lineales o casi lineales en su complejidad. Teniendo en cuenta todos estos supuestos podemos calcular cuánto tiempo le tomaría antes de que pudiéramos índice nuestros 850 terabytes por un costo razonable asumir ciertos factores de crecimiento. La Ley de Moore se definió en 1965 como se duplica cada 18 meses en el poder del procesador. Se ha mantenido notablemente cierto, no sólo para los procesadores, pero para otros parámetros importantes del sistema, como disco también. Si asumimos que la ley de Moore se mantiene para el futuro, necesitamos sólo 10 más duplicaciones, o 15 años para llegar a nuestra meta de la indexación de todo a todos en los EE.UU. ha escrito durante un año por un precio que una compañía pequeña podría permitirse. Por supuesto, los expertos de hardware son algo preocupados Ley de Moore no puede continuar manteniendo durante los próximos 15 años, pero sin duda hay una gran cantidad de aplicaciones centralizadas interesantes, incluso si sólo tenemos una parte del camino a nuestro ejemplo hipotético.

Por supuesto a los sistemas distribuidos como G l oss [Gravano 94] o la cosecha a menudo será la solución técnica más eficiente y elegante para la indexación, pero parece difícil de convencer al mundo de utilizar estos sistemas, debido a los altos costos de la administración de la creación de grandes número de instalaciones. Por supuesto, es muy probable que la reducción del costo de la administración drásticamente es posible. Si eso ocurre, y todo el mundo comienza la ejecución de 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 computadoras continúan mejorando, la indexación de texto escalarán incluso mejor que lo hace ahora. Por supuesto que podría haber una cantidad infinita de máquina de contenido generado, pero sólo indexación enormes cantidades de contenido generado humana parece tremendamente útil. Así que somos optimistas de que nuestra búsqueda en la web arquitectura centralizada motor mejorará en su capacidad para cubrir la información de texto pertinente en el tiempo y que hay un futuro brillante para la búsqueda.