of 37/37
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

La Anatomía de Una Búsqueda Hipertextual Web Motor Scale

  • View
    221

  • Download
    3

Embed Size (px)

DESCRIPTION

anatomia de Google Brin y Page

Text of La Anatomía de Una Búsqueda Hipertextual Web Motor Scale

La anatoma de una Bsqueda Hipertextual Web Motor Scale-Large

Sergey Brin y Lawrence Page

@cs.stanford.edu

Informtica Departamento de Ciencias de la Universidad de Stanford, Stanford, CA 94305

Abstracto

En este trabajo, presentamos Google, un prototipo de un motor de bsqueda a gran escala que hace un uso intensivo de la estructura presente en el hipertexto. Google est diseado para rastrear e indexar la Web de manera eficiente y producir resultados mucho ms satisfactorios que los sistemas existentes. El prototipo con una base de datos de texto completo y hipervnculo de al menos 24 millones de pginas est disponible en http://google.stanford.edu/ Para disear un motor de bsqueda es una tarea difcil. Decenas Buscar ndice motores a cientos de millones de pginas web que involucran un nmero comparable de trminos distintos. Responden a decenas de millones de consultas cada da. A pesar de la importancia de los motores de bsqueda a gran escala en la web, muy poca investigacin acadmica se ha hecho sobre ellos. Adems, debido al rpido avance de la tecnologa y la proliferacin de Internet, la creacin de un motor de bsqueda en la web hoy en da es muy diferente a la de hace tres aos. Este documento ofrece una descripcin en profundidad de nuestro motor de bsqueda en Internet a gran escala - la primera descripcin pblica detallada que conocemos hasta la fecha. Aparte de los problemas de la ampliacin de las tcnicas de bsqueda tradicionales a los datos de esta magnitud, hay nuevos retos tcnicos involucrados con el uso de la informacin adicional presente en el hipertexto para producir mejores resultados de bsqueda. En este trabajo se aborda la cuestin de cmo construir un sistema prctico a gran escala que puede explotar la informacin presente en el hipertexto. Tambin nos fijamos en el problema de cmo tratar eficazmente con colecciones de hipertexto no controlados donde cualquiera puede publicar lo que quieran.

Palabras clave: World Wide Web, motores de bsqueda, recuperacin de informacin, PageRank, Google

1. Introduccin

(Nota: Hay dos versiones de este trabajo - una versin ms larga completa y una versin ms corta impresa La versin completa est disponible en la web y el CD-ROM de la conferencia..) La web crea nuevos retos para la recuperacin de informacin. La cantidad de informacin en la web est creciendo rpidamente, as como el nmero de nuevos usuarios sin experiencia en el arte de la investigacin de la tela. Las personas tienden a navegar por la web utilizando su grfica enlace, a menudo a partir de los ndices humanos mantenido alta calidad tales como Yahoo! o con motores de bsqueda. Humano mantiene listas abarcan temas populares con eficacia pero son subjetivas, caros de construir y mantener, lento para mejorar, y no puede cubrir todos los temas esotricos. Buscadores automticos que dependen de concordancia de palabras clave por lo general vuelven demasiados partidos de baja calidad. Para empeorar las cosas, algunos anunciantes tratan de llamar la atencin de las personas mediante la adopcin de medidas destinadas a engaar a los motores de bsqueda automatizados. Hemos construido un motor de bsqueda a gran escala que aborda muchos de los problemas de los sistemas existentes. Se hace uso especialmente intensivo de la estructura adicional presente en el hipertexto para proporcionar resultados de bsqueda mucho ms altos de calidad. Elegimos nuestro nombre del sistema, Google, ya que es una ortografa comn de googol, o 10 100 y encaja bien con nuestra meta de construir motores de bsqueda muy gran escala.

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

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

1.2. Google: Escala con la Web

La creacin de un motor de bsqueda que escala hasta la web de hoy presenta muchos desafos. Se necesita la tecnologa de rastreo rpido para reunir los documentos web y mantenerlos actualizados. El espacio de almacenamiento debe ser utilizado de manera eficiente para almacenar ndices y, opcionalmente, los propios documentos. El sistema de indexacin debe procesar cientos de gigabytes de datos de manera eficiente. Las consultas deben ser manejado de manera rpida, a una velocidad de cientos a miles por segundo.

Estas tareas se estn convirtiendo cada vez ms difcil a medida que crece la Web. Sin embargo, el rendimiento del hardware y el coste han mejorado dramticamente para compensar parcialmente la dificultad. Hay, sin embargo, varias excepciones notables a este progreso, tales como buscar disco tiempo y la robustez del sistema operativo. En el diseo de Google, se ha considerado tanto la tasa de crecimiento de la Web y los cambios tecnolgicos. Google est diseado para escalar bien a conjuntos de datos extremadamente grandes. Se hace un uso eficiente de espacio de almacenamiento para almacenar el ndice. Sus estructuras de datos estn optimizados para un acceso rpido y eficiente (ver seccin 4.2). Adems, se espera que el costo para indexar y almacenar texto o HTML eventualmente disminuir respecto a la cantidad que estar disponible (ver Apndice B). Esto dar lugar a propiedades de escala favorables para sistemas centralizados como Google.

1.3 Objetivos de diseo

1.3.1 Mejora de la Calidad de Bsqueda

Nuestro principal objetivo es mejorar la calidad de los motores de bsqueda web. En 1994, algunas personas crean que un ndice de bsqueda completa hara posible encontrar cualquier cosa con facilidad. De acuerdo con Best of the Web 1994 - Navegantes, "El mejor servicio de navegacin debera hacer ms fcil para encontrar casi cualquier cosa en la web (una vez se introduce todos los datos)." Sin embargo, la web de 1997 es muy diferente. Cualquiera que haya usado un motor de bsqueda recientemente, puede testificar fcilmente que la integridad del ndice no es el nico factor en la calidad de los resultados de bsqueda. "Los resultados de basura" a menudo se lavan a cabo ningn resultado que un usuario est interesado en. De hecho, a partir de noviembre de 1997, slo una de las cuatro principales motores de bsqueda comerciales se encuentra (devuelve su propia pgina de bsqueda en respuesta a su nombre en el top ten Resultados). Una de las principales causas de este problema es que el nmero de documentos en los ndices ha ido en aumento en muchos rdenes de magnitud, pero la capacidad del usuario para ver los documentos no tiene. La gente todava slo est dispuesto a mirar las primeras decenas de resultados. Debido a esto, ya que el tamao de la coleccin crece, necesitamos herramientas que tienen muy alta precisin (nmero de documentos relevantes devueltos, decimos en las primeras decenas de resultados). De hecho, queremos que nuestra nocin de "relevante" para incluir slo los mejores documentos ya que puede haber decenas de miles de documentos poco relevantes. Esta muy alta precisin es importante, incluso a expensas de la recuperacin (el nmero total de documentos relevantes que el sistema es capaz de volver). Hay un poco de reciente optimismo de que el uso de ms informacin hipertextual puede ayudar a mejorar la bsqueda y otras aplicaciones [Marchiori 97] [Spertus 97] [Weiss 96] [Kleinberg 98]. En particular, la estructura de enlace [Pgina 98] y el texto del enlace proporcionan una gran cantidad de informacin para hacer juicios de relevancia y filtrado de calidad. Google hace uso tanto de la estructura de enlace y el texto de anclaje (ver secciones 2.1 y 2.2).

1.3.2 Acadmico Investigacin Search Engine

Aparte de un gran crecimiento, la Web tambin se ha convertido cada vez ms comercial con el tiempo. En 1993, el 1,5% de los servidores web estaban en dominios .com. Este nmero creci a ms del 60% en 1997. Al mismo tiempo, los motores de bsqueda han emigrado desde el dominio acadmico al comercial. Hasta ahora la mayor parte del desarrollo de motores de bsqueda se ha encendido en las empresas con poco publicacin de detalles tcnicos. Esto hace que la tecnologa de motores de bsqueda para seguir siendo en gran medida un arte negro y ser la publicidad orientada (ver Apndice A). Con Google, tenemos un objetivo fuerte para empujar ms el desarrollo y la comprensin en el mbito acadmico.

Otro de los objetivos de diseo importante era construir sistemas que un nmero razonable de la gente puede utilizar realmente. Uso era importante para nosotros porque pensamos que algunas de las investigaciones ms interesantes implicar aprovechar la gran cantidad de datos de uso que est disponible en los sistemas modernos de Web. Por ejemplo, hay muchas decenas de millones de bsquedas realizadas cada da. Sin embargo, es muy difcil obtener estos datos, sobre todo porque se considera de gran valor comercial.

Nuestra meta diseo final fue la de construir una arquitectura que pueda apoyar las actividades de investigacin novedosas en datos de la web a gran escala. Para apoyar a nuevos usos de investigacin, Google almacena todos los documentos reales que rastrea en forma comprimida. Uno de nuestros principales objetivos en el diseo de Google fue la creacin de un ambiente donde otros investigadores pueden venir en forma rpida, procesar grandes trozos de la web, y producir resultados interesantes que habra sido muy difcil de producir de otra manera. En el poco tiempo que el sistema ha estado haciendo, ya ha habido varios trabajos utilizando las bases de datos generadas por Google, y muchos otros estn en marcha. Otro de los objetivos que tenemos es la creacin de un entorno Spacelab-como donde los investigadores o incluso los estudiantes pueden proponer y hacer experimentos interesantes en nuestros datos de la web a gran escala.

2. Caractersticas del sistema

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

2.1 PageRank: poner orden en la Web

La citacin (enlace) grfico de la web es un recurso importante que ha pasado gran parte no utilizada en los motores de bsqueda web existentes. Hemos creado mapas que contienen tantos como 518 millones de estos hipervnculos, una muestra significativa del total. Estos mapas permiten un rpido clculo de de una pgina web "PageRank", una medida objetiva de la importancia de la citacin que se corresponde bien con la idea subjetiva de la gente de la importancia. Debido a esta correspondencia, PageRank es una excelente manera de dar prioridad a los resultados de bsquedas de palabras clave web. Para temas ms populares, una simple bsqueda en concordancia texto que se limita a la pgina web ttulos realiza admirablemente cuando PageRank prioriza los resultados (demo disponible en google.stanford.edu). Para el tipo de bsquedas de texto completo en el sistema principal de Google, PageRank tambin ayuda mucho.

2.1.1 Descripcin de Clculo PageRank

Literatura cita acadmica se ha aplicado a la web, en gran parte por contar las citas o los vnculos de retroceso a una pgina determinada. Esto da una aproximacin de importancia o calidad de una pgina. PageRank se extiende esta idea al no contar los enlaces de todas las pginas por igual, y por la normalizacin por el nmero de enlaces en una pgina. PageRank se define como sigue:

Asumimos la pgina A tiene pginas T1 ... Tn que apuntan a ella (es decir, son las citas). El parmetro d es un factor de amortiguacin que se puede establecer entre 0 y 1. Por lo general, establecemos d a 0,85. Hay ms detalles acerca de d en la siguiente seccin. Tambin C (A) se define como el nmero de enlaces que salen de la pgina A. El PageRank de una pgina A se da como sigue:

PR (A) = (1-d) + d (PR (T1) / C (T1) + ... + PR (Tn) / C (Tn))

Tenga en cuenta que los PageRanks forman una distribucin de probabilidad sobre pginas web, por lo que la suma de todas las pginas web PageRank 'ser uno.

PageRank o PR (A) se puede calcular utilizando un algoritmo iterativo simple, y corresponde a el vector propio principal de la matriz de enlace normalizada de la web. Adems, un PageRank de 26 millones de pginas web puede calcularse en unas pocas horas en una estacin de trabajo de tamao medio. Hay muchos otros detalles que estn ms all del alcance de este documento.

2.1.2 intuitiva Justificacin

PageRank se puede considerar como un modelo de comportamiento del usuario. Suponemos que hay un "surfista aleatorio" que se le da una pgina web al azar y se mantiene al hacer clic en los enlaces, no golpear "atrs", pero finalmente se aburre y empieza en otra pgina al azar. La probabilidad de que el surfista aleatorio visita una pgina es su PageRank. Y, el d factor de amortiguamiento es la probabilidad en cada pgina de la "surfista aleatorio" se aburrir y solicite otra pgina al azar. Una variacin importante es agregar slo el factor de amortiguamiento d para una sola pgina, o un grupo de pginas. Esto permite la personalizacin y puede hacer que sea casi imposible de engaar deliberadamente el sistema con el fin de conseguir una graduacin ms alta. Tenemos varias otras extensiones al PageRank, de nuevo ver [Pgina 98].

Otra justificacin intuitiva es que una pgina puede tener un alto PageRank si hay muchas pginas que apuntan a la misma, o si hay algunas pginas que apuntan a la misma y tener un alto PageRank. Intuitivamente, las pginas que estn bien citan desde muchos lugares en la web son vale la pena mirar. Adems, las pginas que tienen tal vez slo una cita de algo as como el Yahoo! pgina de inicio son tambin generalmente vale la pena mirar. Si una pgina no era de alta calidad, o era un vnculo roto, es muy probable que la pgina de inicio de Yahoo no se unira a ella. PageRank maneja ambos casos y todo lo dems propagando recursivamente pesos a travs de la estructura de enlaces de la web.

2.2 Anchor Text

El texto de los enlaces es tratado de una manera especial en nuestro motor de bsqueda. La mayora de los motores de bsqueda asocian el texto de un enlace con la pgina que el enlace est activado. Adems, lo asociamos con la pgina el enlace apunta. Esto tiene varias ventajas. En primer lugar, las anclas a menudo proporcionan descripciones ms precisas de las pginas web que los propios pginas. En segundo lugar, pueden existir anclajes para los documentos que no pueden ser indexados por un motor de bsqueda basado en texto, como imgenes, programas y bases de datos. Esto hace que sea posible para volver las pginas web que en realidad no se han rastreado. Tenga en cuenta que las pginas que no se han rastreado pueden causar problemas, ya que nunca se comprueban para la validez antes de ser devuelto al usuario. En este caso, el motor de bsqueda incluso puede devolver una pgina que nunca ha existido en realidad, pero tena hipervnculos apuntando a la misma. Sin embargo, es posible ordenar los resultados, por lo que este problema particular, rara vez sucede.

Esta idea de propagar texto de anclaje a la pgina se refiere a se implement en el Worm World Wide Web [McBryan 94] sobre todo porque ayuda a la bsqueda de informacin no textual, y ampla la cobertura de bsqueda con un menor nmero de documentos descargados. Utilizamos la propagacin de anclaje sobre todo porque el ancla de texto puede ayudar a proporcionar mejores resultados de calidad. El uso de texto de anclaje es eficiente tcnicamente difcil debido a las grandes cantidades de datos que deben ser procesados. En nuestro rastreo actual de 24 millones de pginas, tuvimos ms de 259 millones de anclajes que hemos indexado.

2.3 Otras caractersticas

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

3 Trabajo relacionado

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

3.1 Recuperacin de Informacin

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

3.2 Diferencias entre la Web y Colecciones bien controlados

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

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

Anatoma 4 Sistema

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

Figura 1. Arquitectura de Alto Nivel de Google

4.1 Google Arquitectura general

En esta seccin, vamos a dar una visin general de alto nivel de cmo funciona todo el sistema como se muestra en la Figura 1. Otras secciones discutirn las aplicaciones y estructuras de datos que no se mencionan en esta seccin. La mayor parte de Google se implementa en C o C ++ para la eficiencia y puede ejecutarse en Solaris o Linux.

En Google, la web de rastreo (la descarga de pginas web) se lleva a cabo por varios rastreadores distribuidos. Hay una URLserver que enva listas de URLs para ser exagerado los rastreadores. Las pginas web que son descabellada se envan a la storeserver. El storeserver luego comprime y almacena las pginas web en un repositorio. Cada pgina web tiene un nmero de identificacin asociado llamado docID que se asigna cada vez que una nueva URL se analiza de una pgina web. La funcin de indexacin se realiza por el indexador y el clasificador. El indizador realiza una serie de funciones. Se lee el repositorio, descomprime los documentos, y las analiza. Cada documento se convierte en un conjunto de ocurrencias de palabras llamado hits. Los xitos grabar la palabra, la posicin en el documento, una aproximacin del tamao de fuente, y la capitalizacin. El indexador distribuye estos xitos en un conjunto de "barriles", la creacin de un ndice de avance parcialmente ordenados. El indexador realiza otra funcin importante. Analiza todos los enlaces en cada pgina web y almacenes de informacin importante acerca de ellos en un archivo de anclajes. Este archivo contiene informacin suficiente para determinar donde cada enlace apunta desde y hacia, y el texto del enlace.

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

El clasificador toma los barriles, que se ordenan por docID (esto es una simplificacin, vase la Seccin 4.2.5), y les recurre por wordID para generar el ndice invertido. Esto se hace en lugar de modo que se necesita poco espacio temporal para esta operacin. El clasificador tambin produce una lista de wordIDs y desplazamientos en el ndice invertido. Un programa llamado DumpLexicon toma esta lista junto con el lxico producido por el indexador y genera un nuevo lxico para ser utilizado por el buscador. El buscador est dirigido por un servidor web y utiliza el lxico construido por DumpLexicon junto con el ndice invertido y los PageRanks para responder consultas.

4.2 Estructuras de datos Mayor

Estructuras de datos de Google estn optimizadas para que una coleccin de documentos de gran tamao puede ser rastreado, indexados, y buscaron con poco costo. Aunque, CPUs y las tasas de salida de entrada a granel han mejorado dramticamente en los ltimos aos, un disco buscan an requiere unos 10 ms para completar. Google est diseada para evitar bsquedas en disco siempre que sea posible, y esto ha tenido una influencia considerable en el diseo de las estructuras de datos.

4.2.1 BigFiles

BigFiles son archivos virtuales que abarcan mltiples sistemas de archivos y son direccionables por 64 bits enteros. El reparto entre los mltiples sistemas de archivos se maneja automticamente. El paquete BigFiles tambin se encarga de la asignacin y cancelacin de asignacin de descriptores de archivos, ya que los sistemas operativos no proporcionan suficiente para nuestras necesidades. BigFiles tambin admite opciones de compresin rudimentarias.

4.2.2 Repositorio

Figura 2. Estructura de datos del repositorio

El repositorio contiene el HTML de cada pgina web. Cada pgina se comprime usando zlib (ver RFC1950). La eleccin de la tcnica de compresin es un compromiso entre la velocidad y la relacin de compresin. Elegimos la velocidad de zlib sobre una mejora significativa en la compresin ofrecida por bzip. La tasa de compresin de bzip era aproximadamente de 4 a 1 en el repositorio en comparacin con el 3 a 1 de compresin de zlib. En el repositorio, los documentos se almacenan uno tras otro y estn prefijados por docID, longitud y URL como puede verse en la Figura 2. El repositorio no requiere otras estructuras de datos para ser utilizados con el fin de acceder a l. Esto ayuda a la consistencia de los datos y hace el desarrollo mucho ms fcil; podemos reconstruir todas las otras estructuras de datos de slo el repositorio y un archivo que lista los errores de orugas.

4.2.3 ndice de documentos

El ndice de documento mantiene la informacin sobre cada documento. Es un ISAM ancho fijo (modo de acceso secuencial Index) ndice, ordenado por docID. La informacin almacenada en cada entrada incluye el estado actual del documento, un puntero en el repositorio, una suma de comprobacin de documentos y diversas estadsticas. Si el documento se ha rastreado, tambin contiene un puntero a un archivo de ancho variable llamada DOCINFO que contiene su URL y el ttulo. De lo contrario, el puntero en la urllist que contiene slo la URL. Esta decisin de diseo fue impulsado por el deseo de tener una estructura de datos razonablemente compacto, y la posibilidad de buscar un registro en un disco seek durante una bsqueda

Adems, hay un archivo que se utiliza para convertir las URL en docIDs. Es una lista de sumas de comprobacin de URL con sus correspondientes docIDs y est ordenada por la suma de comprobacin. Con el fin de encontrar el docID de un URL en particular, la suma de comprobacin de la URL se calcula y una bsqueda binaria se realiza en el archivo de sumas de comprobacin para encontrar su docID. URLs se pueden convertir en docIDs en el lote haciendo una fusin con este archivo. Esta es la tcnica del URLresolver utiliza para convertir las URL en docIDs. Este modo lote de actualizacin es crucial, ya que de lo contrario hay que realizar un solo buscan por todos los eslabones que asumir un disco tomara ms de un mes para nuestro conjunto de datos de 322 millones de enlace.

4.2.4 Lxico

El lxico tiene varias formas diferentes. Un cambio importante de los sistemas anteriores es que el lxico puede caber en la memoria por un precio razonable. En la implementacin actual podemos mantener el lxico en la memoria en una mquina con 256 MB de memoria principal. El lxico actual contiene 14 millones de palabras (aunque algunas palabras raras no se aadieron al lxico). Se lleva a cabo en dos partes - una lista de las palabras (concatenados juntos pero separados por nulos) y una tabla hash de punteros. Para las diversas funciones, la lista de las palabras tiene alguna informacin auxiliar que est ms all del alcance de este documento para explicar plenamente.

4.2.5 Listas de ataque

Una lista de resultados corresponde a una lista de ocurrencias de una palabra en particular en un documento particular, incluyendo la posicin, la fuente, y la informacin de la capitalizacin. Hit listas representan la mayor parte del espacio utilizado tanto en el avance y los ndices invertidos. Debido a esto, es importante que los represente tan eficientemente como sea posible. Se consideraron varias alternativas para la posicin de codificacin, la fuente, y la capitalizacin - codificacin simple (un triple de nmeros enteros), una codificacin compacta (una asignacin optimizada mano de bits), y la codificacin de Huffman. Al final se opt por una mano optimizado codificacin compacta ya que requiere mucho menos espacio que la simple codificacin y mucho menos manipulacin de bits de codificacin de Huffman. Los detalles de los accesos se muestran en la Figura 3.

Nuestra codificacin compacta utiliza dos bytes para cada golpe. Hay dos tipos de resultados: xitos de lujo y xitos de civil. xitos de lujo incluyen xitos que ocurren en una URL, ttulo, texto de anclaje o etiqueta meta. Accesos Plain incluyen todo lo dems. Un golpe normal consiste en un poco de capitalizacin, tamao de fuente y 12 bits de posicin de la palabra en un documento (todas las posiciones superiores a 4095 se etiquetan 4096). Tamao de la fuente se representa en relacin con el resto del documento usando tres bits (slo 7 valores se utilizan en realidad, porque 111 es la bandera que seala un golpe de fantasa). Un golpe de lujo consta de un poco de capitalizacin, el tamao de fuente se establece en 7 para indicar que es un golpe de lujo, 4 bits para codificar el tipo de golpe de fantasa, y 8 bits de posicin. Para visitas de anclaje, los 8 bits de posicin se dividen en 4 bits para la posicin de anclaje y 4 bits para un hash de la docID el ancla se produce. Esto nos da alguna frase limita la bsqueda, siempre y cuando no hay que muchos anclajes para un palabra en particular. Esperamos actualizar la forma en que los accesos de anclaje se almacenan para permitir una mayor resolucin en la posicin y campos docIDhash. Utilizamos tamao de la fuente en relacin con el resto del documento, ya que en la bsqueda, usted no desea clasificar los documentos por lo dems idnticas de manera diferente slo porque uno de los documentos est en un tipo de letra ms grande.

Figura 3. avance y retroceso ndices y el Lxico

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 duracin es ms larga que cabra en que muchos bits, se utiliza un cdigo de escape en esos bits, y los siguientes dos bytes contienen la longitud real.

4.2.6 ndice Adelante

El ndice de avance es en realidad ya parcialmente ordenadas. Se almacena en un nmero de barriles (utilizamos 64). Cada barril tiene una gama de wordID de. Si un documento contiene palabras que caen dentro de un barril particular, la docID se registra en el barril, seguido por una lista de de wordID con hitlists que corresponden a esas palabras. Este esquema requiere un poco ms de almacenamiento debido a docIDs duplicados pero la diferencia es muy pequea para un nmero razonable de cubos y ahorra considerable tiempo y la complejidad de codificacin en la fase final de la indexacin realizada por el clasificador. Por otra parte, en lugar de almacenar de wordID reales, almacenamos cada wordID como una diferencia relativa del wordID mnimo que cae en el can del wordID es. De esta manera, podemos utilizar slo 24 bits para los aos wordID en los barriles sin ordenar, dejando 8 bits para la longitud lista de resultados.

4.2.7 ndice invertido

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

Una cuestin importante es en qu orden los docID de deben aparecer en el doclist. Una solucin simple es almacenarlos ordenados por docID. Esto permite una rpida fusin de diferentes doclists para varias consultas de palabras. Otra opcin es almacenarlos segn un ranking de la aparicin de la palabra en cada documento. Esto hace que responder una consulta de palabras triviales y hace probable que las respuestas a varias consultas de palabras son cerca del inicio. Sin embargo, la fusin es mucho ms difcil. Adems, esto hace que el desarrollo mucho ms difcil en que un cambio en la funcin de clasificacin requiere una reconstruccin del ndice. Elegimos un compromiso entre estas opciones, mantener dos conjuntos de barriles invertidas - un conjunto de listas de resultados que incluyen xitos de ttulo o de anclaje y otro conjunto de todas las listas de xitos. De esta manera, se comprueba la primera serie de barriles primero y si no hay suficientes resultados dentro de esos barriles comprobamos los ms grandes.

4.3 Rastreo de la Web

Ejecucin de un rastreador web es una tarea difcil. Hay problemas de rendimiento y fiabilidad difciles y an ms importante, hay cuestiones sociales. El gateo es la aplicacin ms frgil, ya que implica la interaccin con cientos de miles de servidores web y varios servidores de nombres que son todos ms all del control del sistema.

Con el fin de escalar a cientos de millones de pginas web, Google tiene un sistema de rastreo distribuido rpido. Una sola URLserver sirve listas de direcciones URL a una serie de rastreadores (que normalmente encontramos aproximadamente 3). Tanto el URLserver y los rastreadores son implementados en Python. Cada rastreador mantiene aproximadamente 300 conexiones abiertas a la vez. Esto es necesario para recuperar pginas web a un ritmo suficientemente rpido. A velocidades mximas, el sistema puede rastrear ms de 100 pginas web por segundo utilizando cuatro rastreadores. Esto equivale a aproximadamente 600K por segundo de datos. Un gran estrs rendimiento es bsqueda de DNS. Cada rastreador mantiene una su propia cach de DNS para que no se tiene que hacer una bsqueda de DNS antes de meterse cada documento. Cada uno de los cientos de conexiones puede estar en un nmero de diferentes estados: mirando hacia arriba DNS, conectando con el anfitrin, el envo de la solicitud, y la recepcin de la respuesta. Estos factores hacen que el rastreador un componente complejo del sistema. Utiliza asncrono IO para gestionar eventos, y un nmero de colas para pasar la pgina obtiene de estado a estado.

Resulta que la ejecucin de un rastreador que conecta a ms de medio milln de servidores, y genera decenas de millones de entradas de registro genera una buena cantidad de correo electrnico y llamadas telefnicas. Debido a la gran cantidad de personas que vienen en la lnea, siempre hay aquellos que no saben lo que es un rastreador es, porque este es el primero que han visto. Casi a diario, recibimos un correo electrnico algo como, "Wow, te veas a una gran cantidad de pginas de mi sitio web. Cmo te gusta?" Tambin hay algunas personas que no conocen el protocolo de exclusin de robots, y piensan que su pgina debe ser protegido de la indexacin de una declaracin como, "Esta pgina tiene derechos de autor y no debe ser indexados", que no hace falta decir que es difcil para los rastreadores web entender. Tambin, debido a la enorme cantidad de datos involucrados, cosas inesperadas sucedern. Por ejemplo, nuestro sistema intent arrastrarse un juego en lnea. Esto dio lugar a un montn de mensajes de basura en el centro de su juego! Resulta que este era un problema fcil de solucionar. Pero este problema no se haba acercado hasta que habamos descargado decenas de millones de pginas. Debido a la inmensa variacin en las pginas web y servidores, es prcticamente imposible probar un rastreador sin ejecutar en gran parte de la Internet. Invariablemente, hay cientos de problemas oscuros que slo pueden ocurrir en una pgina de toda la web y hacer que el rastreador se bloquee, o peor, provocar un comportamiento impredecible o incorrecta. Los sistemas que acceden a grandes partes de la Internet deben ser diseados para ser muy robusta y cuidadosamente probado. Desde los grandes sistemas complejos como rastreadores invariablemente causar problemas, es necesario que sean importantes recursos dedicados a la lectura del correo electrnico y la solucin de estos problemas a medida que surgen.

4.4 Indexacin de la Web

De anlisis - Cualquier programa de anlisis que est diseado para ejecutarse en toda la Web debe manejar una gran cantidad de errores posibles. Estos van desde errores tipogrficos en las etiquetas HTML para kilobytes de ceros en el medio de una etiqueta, los caracteres no ASCII, etiquetas HTML anidado cientos de profundidad, y una gran variedad de otros errores que desafan la imaginacin de nadie para llegar a los igualmente creativas. Para obtener la mxima velocidad, en lugar de utilizar YACC para generar un analizador CFG, usamos flex para generar un analizador lxico que atuendo con su propia pila. El desarrollo de este programa de anlisis que funciona a una velocidad razonable y es muy robusto implic una buena cantidad de trabajo.

Para poner un lmite en el tiempo de respuesta, una vez que un cierto nmero (actualmente 40000) de los documentos se encuentran a juego, el buscador pasa automticamente al paso 8 en la Figura 4. Esto significa que es posible que los resultados subptimos seran devueltos. Actualmente estamos investigando otras maneras de resolver este problema. En el pasado, nos lo solucionaron los accesos de acuerdo con PageRank, que pareca mejorar la situacin.

4.5.1 El sistema de clasificacin

Google mantiene mucha ms informacin sobre los documentos web que los motores de bsqueda tpicos. Cada lista negra incluye la posicin, la fuente, y la informacin de la capitalizacin. Adems, tenemos en cuenta los xitos de texto de anclaje y el PageRank del documento. La combinacin de toda esta informacin en un rango es difcil. Hemos diseado nuestra funcin de clasificacin para que ningn factor en particular puede tener demasiada influencia. En primer lugar, consideremos el caso ms simple - una sola consulta de textos. Con el fin de clasificar un documento con una sola consulta de textos, Google mira a la lista negra de ese documento para esa palabra. Google considera que cada golpe sea uno de varios tipos diferentes (ttulo, ancla, URL, llanura fuente grande de texto, sin formato de fuente pequeo texto, ...), cada uno de los cuales tiene su propio peso tipo. El tipo-pesos constituyen un vector indexado por tipo. Google cuenta el nmero de accesos de cada tipo en la lista de resultados. Entonces, cada recuento se convierte en un peso recuento. Conde-pesos aumentan linealmente con recuentos al principio, pero rpidamente disminuir de manera que ms de un cierto conde no le ayudar. Tomamos el producto escalar del vector de recuento-pesos con el vector de tipo-pesos para calcular una puntuacin de IR para el documento. Por ltimo, la puntuacin IR se combina con PageRank para dar un rango final al documento.

Para una bsqueda de varias palabras, la situacin es ms complicada. Ahora varias listas de xitos deben ser escaneados a travs de una sola vez para que golpea ocurren juntos en un documento se ponderan ms alto que golpea ocurren lejos. Los xitos de las mltiples listas de resultados se corresponden de modo que los accesos cercanos coinciden juntos. Para cada conjunto combinado de hits, una proximidad se calcula. La proximidad se basa en lo lejos los xitos estn en el documento (o ancla), pero se clasifica en 10 de valor "contenedores" diferentes que van desde una concordancia de frase de "ni de lejos". Los recuentos se calculan no slo para cada tipo de golpe, sino para todo tipo y de proximidad. Cada par de tipo y la proximidad tiene una prox peso tipo. Los recuentos se convierten en conteo-pesos y nos toman el producto escalar del Conde-pesos y el tipo-PROX-pesos para calcular una puntuacin de IR. Todos estos nmeros y matrices posible que todos aparezcan con los resultados de bsqueda utilizando un modo de depuracin especial. Estas pantallas han sido de gran ayuda en el desarrollo del sistema de clasificacin.

4.5.2 Evaluacin

La funcin de la clasificacin tiene muchos parmetros como el tipo-pesos y el tipo-PROX-pesos. Averiguar los valores correctos para estos parmetros es algo de un arte negro. Para ello, contamos con un mecanismo de retroalimentacin de los usuarios en el motor de bsqueda. Un usuario de confianza puede opcionalmente evaluar todos los resultados que se devuelven. Se guarda Esta retroalimentacin. Luego, cuando modificamos la funcin de clasificacin, podemos ver el impacto de este cambio en todas las bsquedas anteriores que fueron clasificados. Aunque lejos de ser perfecto, esto nos da una idea de cmo un cambio en la funcin de clasificacin afecta a los resultados de bsqueda.

5 Resultados y Rendimiento

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 electrnico 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 rene 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

La medida ms importante de un motor de bsqueda es la calidad de sus resultados de bsqueda. Si bien una evaluacin de usuario completa est ms all del alcance de este trabajo, nuestra propia experiencia con Google ha demostrado que para producir mejores resultados que los principales motores de bsqueda comerciales para la mayora de las bsquedas. 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 bsqueda en "bill clinton". Estos resultados demuestran algunas de las caractersticas de Google. Los resultados se agrupan por servidor. Esto ayuda considerablemente cuando tamizado a travs de conjuntos de resultados. Una serie de resultados son de dominio whitehouse.gov que es lo que uno puede esperar razonablemente de tal bsqueda. En la actualidad, la mayora de los principales motores de bsqueda comercial no devuelven ningn resultado de whitehouse.gov, mucho menos los ms adecuados. Observe que no hay ningn ttulo para el primer resultado. Esto se debe a que no se ha rastreado. En su lugar, Google se bas en el texto de anclaje para determinar esto era una buena respuesta a la consulta. Del mismo modo, el quinto resultado es una direccin de correo electrnico que, por supuesto, no es rastreable. Tambin es un resultado de texto de anclaje.

Todos los resultados son razonablemente pginas de alta calidad y, en ltima comprobacin, ninguno era enlaces rotos. Esto es en gran parte porque todos tienen alto PageRank. Los PageRanks son los porcentajes en rojo junto con grficos de barras. Por ltimo, no hay resultados sobre un proyecto de ley que no sea Clinton o sobre un Clinton aparte de Bill. Esto se debe a que le damos pesada importancia de la proximidad de las ocurrencias de palabras. Por supuesto una verdadera prueba de la calidad de un motor de bsqueda implicara un extenso estudio de usuario o resultados de anlisis que no tenemos espacio para aqu. En lugar de ello, invitamos al lector a probar Google por s mismos en http://google.stanford.edu.

5.1 Requisitos de almacenamiento

Aparte de la calidad de bsqueda, Google est diseado para escalar de forma rentable para el tamao de la Web a medida que crece. Un aspecto de esto es utilizar el almacenamiento de manera eficiente. Tabla 1 presenta un desglose de algunas estadsticas y los requisitos de almacenamiento de Google. Debido a la compresin del tamao total del depsito es de aproximadamente 53 GB, poco ms de un tercio del total de datos que almacena. A los precios actuales de disco esto hace que el depsito de una fuente relativamente barata de datos tiles. Ms importante an, el total de todos los datos utilizados por el motor de bsqueda requiere una cantidad comparable de almacenamiento, alrededor de 55 GB. Por otra parte, la mayora de las preguntas pueden ser contestadas utilizando slo el ndice corta invertida. Con una mejor codificacin y compresin del ndice de documentos, un motor de bsqueda web de alta calidad puede caber en una unidad de 7GB de un nuevo PC.

Estadsticas de Almacenamiento

Tamao total de descabellada Pginas

147.8 GB

Repositorio Comprimido

53.5 GB

ndice invertido Corto

4.1 GB

ndice completo Invertido

37.2 GB

Lxico

293 MB

Datos de anclaje temporal (no en total)

6.6 GB

ndice de documentos Incl. 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

Pgina web Estadsticas

Nmero de pginas Web recuperados de

24000000

Nmero de Urls Seen

76500000

Nmero de direcciones de correo electrnico

1,7 millones

Nmero de de 404

1,6 millones

Tabla 1. Estadsticas

Rendimiento 5.2 Sistema

Es importante para un motor de bsqueda para rastrear e indexar de manera eficiente. De esta manera la informacin puede mantenerse al da y los principales cambios en el sistema se puede probar con relativa rapidez. Para Google, las principales operaciones estn rastreo, la indexacin y clasificacin. Es difcil medir cunto tiempo tom el rastreo global porque los discos se llenaron, los servidores de nombres se estrell, o cualquier nmero de otros problemas que dejaron el sistema. En total tard aproximadamente 9 das para descargar los 26 millones de pginas (incluyendo errores). Sin embargo, una vez que el sistema estaba funcionando sin problemas, se corra mucho ms rpido, la descarga de los ltimos 11 millones de pginas en slo 63 horas, con un promedio de poco ms de 4 millones de pginas al da o 48,5 pginas por segundo. Corrimos el indexador y el rastreador de forma simultnea. El indexador corri solo ms rpido que los rastreadores. Esto es en gran parte porque pasamos el tiempo justo optimizar el indexador de modo que no sera un cuello de botella. Estas optimizaciones incluyen actualizaciones masivas al ndice de documentos y colocacin de estructuras de datos crticos en el disco local. El indexador funciona a aproximadamente 54 pginas por segundo. Los clasificadores pueden ejecutarse completamente en paralelo; utilizando cuatro mquinas, todo el proceso de clasificacin toma alrededor de 24 horas.

5.3 Bsqueda Rendimiento

Mejorar el rendimiento de bsqueda no fue el foco principal de nuestra investigacin hasta este punto. La versin actual de Google responde a la mayora de las consultas de entre 1 y 10 segundos. Esta vez est dominado en su mayora por el disco IO a travs de NFS (ya que los discos estn distribuidas en un nmero de mquinas). Por otra parte, Google no tiene ningn optimizaciones tales como el almacenamiento en cach de consultas, subndices en trminos comunes, y otras optimizaciones comunes. Tenemos la intencin de acelerar Google considerablemente a travs de la distribucin y el hardware, el software y mejoras algortmicas. 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 versin actual de Google. Se repiten para mostrar las aceleraciones resultantes de cach IO.

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 bsqueda

1.31

9.63

1.16

1.16

Tabla 2. Tiempos de bsqueda

6. Conclusiones

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

6.1 Trabajo Futuro

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

6.2 de alta calidad de Bsqueda

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

6.3 Arquitectura escalable

Aparte de la calidad de la bsqueda, Google est diseado para escalar. Debe ser eficiente tanto en el espacio y el tiempo, y los factores constantes son muy importantes cuando se trata de toda la Web. En la aplicacin de Google, hemos visto los cuellos de botella en la CPU, acceso a la memoria, la capacidad de memoria, disco busca, rendimiento del disco, capacidad de disco, y la red de IO. Google ha evolucionado para superar una serie de estos cuellos de botella durante las diversas operaciones. Principales estructuras de datos de Google hacen uso eficiente del espacio de almacenamiento disponible. Por otra parte, las rastrear, indexar y operaciones de clasificacin son lo suficientemente eficientes para poder construir un ndice de una parte sustancial de la web - 24 millones de pginas, en menos de una semana. Esperamos ser capaces de construir un ndice de 100 millones de pginas en menos de un mes.

6.4 Una herramienta de investigacin

Adems de ser un motor de bsqueda de alta calidad, Google es una herramienta de investigacin. Los datos de Google ha recogido ya ha dado lugar a muchos otros documentos presentados a congresos y muchos ms en camino. Investigaciones recientes como [Abiteboul 97] ha demostrado una serie de limitaciones a las preguntas acerca de la Web que pueden ser contestadas sin tener la Web disponibles localmente. Esto significa que Google (o un sistema similar) no es slo una valiosa herramienta de investigacin pero necesario para una amplia gama de aplicaciones. Esperamos que Google va a ser un recurso para los investigadores e investigadores de todo el mundo y provocar la prxima generacin de tecnologa de los motores de bsqueda.

7 Agradecimientos

De Scott Hassan y Alan Steremberg han sido fundamentales para el desarrollo de Google. Sus contribuciones talentosos son insustituibles, y los autores les debemos mucha gratitud. Tambin nos gustara dar las gracias a Hctor Garca-Molina, Rajeev Motwani, Jeff Ullman, y Terry Winograd y todo el grupo WebBase por su apoyo y discusiones interesantes. Por ltimo, nos gustara reconocer el generoso apoyo de nuestros donantes de equipos IBM, Intel y Sun y nuestros financiadores. La investigacin descrita aqu se llev a cabo como parte del Proyecto de Biblioteca Digital Integrado de Stanford, con el apoyo de la National Science Foundation bajo el Acuerdo Cooperativo IRI-9411306. La financiacin de este acuerdo de cooperacin tambin es proporcionada por DARPA y la NASA, y por Interval Research, y los socios industriales del Proyecto de Bibliotecas Digitales de Stanford.

Referencias

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

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

. [Pgina 98] Lawrence Pgina, Sergey Brin, Rajeev Motwani, Terry Winograd Clasificacin La Cita PageRank: poner orden en la Web. Manuscrito en curso. Http://google.stanford.edu/~backrub/pageranksub.ps

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

. [Spertus 97] Ellen Spertus parsito: Minera informacin estructural en la Web. La Sexta Conferencia Internacional WWW (WWW 97). Santa Clara, EE.UU., 7 a 11 abril 1997.

[TREC 96] Actas de la quinta Conferencia texto REcuperacin (TREC-5). Gaithersburg, Maryland, Noviembre 20-22, 1996. Editorial: Departamento de Comercio, el Instituto Nacional de Estndares y Tecnologa. Editores: DK Harman y EM Voorhees. Texto completo en: http://trec.nist.gov/

[Witten 94] Ian H Witten, Alistair Moffat, y Timothy C. Bell. Gigabytes Administracin: La compresin y la indexacin de documentos e imgenes. Nueva York: Van Nostrand Reinhold, 1994.

[Weiss 96] Ron Weiss, Bienvenido Vlez, Mark A. Sheldon, Chanathip Manprempre, Peter Szilagyi, Andrzej Duda, y David K. Gifford. HyPursuit: Un motor de bsqueda jerrquica de la red que explota Content-Enlace hipertexto Clustering. Actas de la sptima ACM Conferencia sobre hipertexto. Nueva York, 1.996.

Vitae

Sergey Brin recibi su licenciatura en matemticas y ciencias de la computacin de la Universidad de Maryland en College Park en 1993. Actualmente es un Ph.D. candidato en ciencias de la computacin en la Universidad de Stanford, donde recibi su maestra en 1995. l es un receptor de una Fundacin Nacional de Ciencia de Becas de Postgrado. Sus intereses de investigacin incluyen los motores de bsqueda, extraccin de informacin de fuentes no estructuradas, y la minera de datos de grandes colecciones de textos y datos cientficos.

Lawrence Pgina naci en East Lansing, Michigan, y recibi una EEB en Ingeniera Informtica en la Universidad de Michigan, Ann Arbor en 1995. En la actualidad es un Ph.D. candidato en Ciencias de la Computacin en la Universidad de Stanford. Algunos de sus intereses de investigacin incluyen la estructura de enlaces de la web, la interaccin persona-ordenador, motores de bsqueda, la escalabilidad de las interfaces de acceso a la informacin, y la minera de datos personales.

8 Apndice A: Publicidad y Motivos mixtos

En la actualidad, el modelo de negocio predominante para los motores de bsqueda comerciales es la publicidad. Los objetivos del modelo de negocio de la publicidad no siempre corresponden a la prestacin de bsqueda de calidad a los usuarios. Por ejemplo, en nuestra bsqueda prototipo de motor de uno de los mejores resultados para el telfono celular es "El Efecto de Cellular Phone Uso Al conductor Atencin", un estudio que explica con gran detalle las distracciones y los riesgos asociados con la conversacin en un telfono celular mientras se conduce. Este resultado de la bsqueda se acerc primero a causa de su gran importancia, a juzgar por el algoritmo de PageRank, una aproximacin de la citacin importancia en la web [Pgina 98]. Est claro que un motor de bsqueda que fue tomando el dinero por mostrar anuncios de telfonos celulares tendra dificultades para justificar la pgina que nuestro sistema regres a sus anunciantes que pagan. Para este tipo de razn y la experiencia histrica con otros medios de comunicacin [Bagdikian 83], esperamos que la publicidad financiada motores de bsqueda se har con preferencia inherente hacia los anunciantes y lejos de las necesidades de los consumidores.Dado que es muy difcil incluso para los expertos para evaluar los motores de bsqueda, el sesgo de motor de bsqueda es particularmente insidioso. Un buen ejemplo fue OpenText, que fue informado de que la venta de las empresas el derecho a ser incluido en la parte superior de los resultados de bsqueda para determinadas consultas [Marchiori 97]. Este tipo de sesgo es mucho ms insidioso que la publicidad, ya que no est claro que "merece" estar ah, y que est dispuesto a pagar dinero para ser enumeradas. Este modelo de negocio se tradujo en un alboroto, y OpenText ha dejado de ser un motor de bsqueda viable. Pero sesgo menos flagrante son susceptibles de ser tolerado por el mercado. Por ejemplo, un motor de bsqueda podra aadir un pequeo factor de los resultados de bsqueda de las empresas "amigables", y restar un factor de los resultados de los competidores. Este tipo de sesgo es muy difcil de detectar, pero todava podra tener un efecto significativo en el mercado. Por otra parte, los ingresos de publicidad a menudo proporciona un incentivo para proporcionar resultados de bsqueda de mala calidad. Por ejemplo, hemos observado un importante motor de bsqueda no volvera pgina de inicio de una gran compaa area cuando el nombre de la compaa area se le dio como una consulta. Dio la casualidad de que la aerolnea haba colocado un anuncio costoso, vinculado a la consulta que era su nombre. Una mejor motor de bsqueda no habra requerido este anuncio, y posiblemente como resultado la prdida de los ingresos de la compaa area al motor de bsqueda. En general, se podra argumentar desde el punto de vista del consumidor que la mejor es, se necesitar el motor de bsqueda de los menos anuncios para el consumidor para encontrar lo que quieren. Por supuesto, esto erosiona la publicidad apoyada modelo de negocio de los motores de bsqueda existentes. Sin embargo, siempre habr dinero de los anunciantes que quieren un cliente para cambiar los productos, o que tienen algo que es realmente nuevo. Pero creemos que la cuestin de la publicidad hace que suficientes incentivos mixtos que es fundamental contar con un motor de bsqueda competitiva que es transparente y en el mbito acadmico.

9 Apndice B: Escalabilidad

9. 1 Escalabilidad de Google

Hemos diseado Google para ser escalable en el corto plazo a una meta de 100 millones de pginas web. Acabamos de recibir el disco y mquinas para manejar ms o menos de esa cantidad. Todas las piezas que requieren mucho tiempo del sistema son paralelizar y hora ms o menos lineal. Estos incluyen cosas como los rastreadores, indexadores y clasificadores. Tambin pensamos que la mayora de las estructuras de datos se ocupar con gracia con la expansin. Sin embargo, en 100 millones de pginas web que estaremos muy cerca contra todo tipo de lmites del sistema operativo en los sistemas operativos ms comunes (actualmente corremos tanto en Solaris y Linux). Estos incluyen cosas como la memoria direccionable, el nmero de descriptores de archivos abiertos, tomas de corriente de red y ancho de banda, y muchos otros. Creemos que la ampliacin a un montn ms de 100 millones de pginas que aumentara considerablemente la complejidad de nuestro sistema.

9.2 Escalabilidad de arquitecturas centralizadas de indexacin

Como las capacidades de las computadoras aumentan, se hace posible indexar una cantidad muy grande de texto para un costo razonable. Por supuesto, otros medios de comunicacin ms intensivas en ancho de banda, como el vdeo es probable que se convierta ms penetrante. Pero, debido a que el costo de produccin de un texto es bajo comparado con los medios de comunicacin como el vdeo, el texto es probable que siga siendo muy generalizada. Adems, es probable que pronto vamos a tener reconocimiento de voz que hace un trabajo razonable convertir voz en texto, la ampliacin de la cantidad de texto disponible. Todo esto ofrece posibilidades increbles para la indexacin centralizada. Aqu est un ejemplo ilustrativo. Suponemos que queremos indexar todo a todos en los EE.UU. ha escrito durante un ao. Suponemos que hay 250 millones de personas en los EE.UU. y escribimos un promedio de 10k por da. Eso se resuelve en alrededor de 850 terabytes. Tambin suponen que la indexacin de un terabyte puede hacerse ahora por un costo razonable. Tambin suponemos que los mtodos de indexacin utilizados sobre el texto son lineales o casi lineales en su complejidad. Teniendo en cuenta todos estos supuestos podemos calcular cunto tiempo le tomara antes de que pudiramos ndice nuestros 850 terabytes por un costo razonable asumir ciertos factores de crecimiento. La Ley de Moore se defini en 1965 como se duplica cada 18 meses en el poder del procesador. Se ha mantenido notablemente cierto, no slo para los procesadores, pero para otros parmetros importantes del sistema, como disco tambin. Si asumimos que la ley de Moore se mantiene para el futuro, necesitamos slo 10 ms duplicaciones, o 15 aos para llegar a nuestra meta de la indexacin de todo a todos en los EE.UU. ha escrito durante un ao por un precio que una compaa pequea podra permitirse. Por supuesto, los expertos de hardware son algo preocupados Ley de Moore no puede continuar manteniendo durante los prximos 15 aos, pero sin duda hay una gran cantidad de aplicaciones centralizadas interesantes, incluso si slo tenemos una parte del camino a nuestro ejemplo hipottico.

Por supuesto a los sistemas distribuidos como G l oss [Gravano 94] o

HYPERLINK "https://translate.googleusercontent.com/translate_c?act=url&depth=1&hl=es&ie=UTF8&prev=_t&rurl=translate.google.com&sl=en&tl=es&u=http://harvest.transarc.com/&usg=ALkJrhg0Fn97_IK5Cj_EV-U_5bEGJSx0iQ" la cosecha a menudo ser la solucin tcnica ms eficiente y elegante para la indexacin, pero parece difcil de convencer al mundo de utilizar estos sistemas, debido a los altos costos de la administracin de la creacin de grandes nmero de instalaciones. Por supuesto, es muy probable que la reduccin del costo de la administracin drsticamente es posible. Si eso ocurre, y todo el mundo comienza la ejecucin de un sistema de indexacin distribuida, la bsqueda sin duda mejorar drsticamente.

Debido a que los seres humanos slo pueden escribir o hablar una cantidad finita, y como computadoras continan mejorando, la indexacin de texto escalarn incluso mejor que lo hace ahora. Por supuesto que podra haber una cantidad infinita de mquina de contenido generado, pero slo indexacin enormes cantidades de contenido generado humana parece tremendamente til. As que somos optimistas de que nuestra bsqueda en la web arquitectura centralizada motor mejorar en su capacidad para cubrir la informacin de texto pertinente en el tiempo y que hay un futuro brillante para la bsqueda.