LA ANATOMA DE UNA GRAN ESCALA DEL MOTOR DE BSQUEDA WEB DE HIPERTEXTUAL Sergey Brin y Lawrence Page {Sergey, en la pgina}

@ cs.stanford.edu Departamento de Informtica de la Universidad de Stanford, Stanford, CA 94305 Resumen 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 de bsqueda mucho ms satisfactoria que los sistemas existentes. El prototipo, con un texto completo y base de datos de enlace de al menos 24 millones de pginas se encuentra disponible en http://google.stanford.edu/ Para disear un motor de bsqueda es una tarea difcil. Los motores de bsqueda ndice de decenas 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, la investigacin acadmica muy poco se ha hecho en 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 de hace tres aos. Este documento proporciona una descripcin en profundidad de nuestro gran motor de bsqueda en la web - la primera descripcin detallada del pblico como sabemos de la fecha. Aparte de los problemas de tcnicas de escalamiento de bsqueda tradicionales a los datos de esta magnitud, hay nuevos desafos tcnicos relacionados con el uso de la presente informacin adicional en hipertexto para producir mejores resultados de bsqueda. Este artculo aborda la cuestin de cmo construir una prctica a gran escala del sistema que se puede explotar la presente informacin adicional en el hipertexto. Tambin nos fijamos en el problema de cmo hacer frente eficazmente a las colecciones de hipertexto sin control en el que cualquiera puede publicar cualquier cosa que quieran. Palabras clave: World Wide Web, motores de bsqueda, recuperacin de informacin, el PageRank, Google 1. INTRODUCCIN (Nota: Hay dos versiones de este documento, una versin ms completa y una versin ms corta impresa La versin completa est disponible en la web y la conferencia de CD-ROM.). La web crea nuevos retos para la recuperacin de informacin. La cantidad de informacin en la red est creciendo rpidamente, as como el nmero de nuevos usuarios inexpertos en el arte de la investigacin de la tela. La gente tiende a navegar por la web utilizando su grafo, comenzando a menudo con humanos de alta calidad ndices mantenidos como Yahoo! o con los motores de bsqueda. Humanos listas mantenidas cubren temas populares con eficacia, pero son subjetivas, son caros de construir y mantener, tardo para mejorar, y no puede cubrir todos los temas esotricos. Motores de bsqueda automatizados que dependen de la concordancia de palabras clave suelen volver partidos de baja calidad, demasiadas. 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 un uso especialmente intensivo de la actual estructura adicional en el hipertexto para proporcionar resultados de bsqueda mucho ms altos de calidad. Elegimos el nombre de nuestra sistema, Google, porque es una ortografa comn de googol, o 10.100 y encaja perfectamente con nuestro objetivo de construir a muy gran escala los motores de bsqueda.

1.1 Web Search Engines - la ampliacin de escala: desde 1994 hasta 2000 La tecnologa de motores de bsqueda 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] tuvo un ndice de 110.000 pginas web y documentos web accesibles. A partir de noviembre de 1997, los principales motores de bsqueda afirman ndice de 2 millones de dlares (WebCrawler) a 100 millones de documentos web (de Search Engine Watch). Es previsible que en el ao 2000, un ndice exhaustivo de la web contendr ms de mil millones de documentos. Al mismo tiempo, el nmero de consultas de bsqueda motores mango ha crecido increblemente demasiado. En marzo y abril de 1994, el gusano de la World Wide Web recibi una media de cerca de 1500 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 consultan los motores de bsqueda, es probable que los principales motores de bsqueda se encargar de cientos de millones de consultas diarias en el ao 2000. El objetivo de nuestro sistema es hacer frente a muchos de los problemas, tanto en la calidad y capacidad de ampliacin, presentado por la tecnologa del motor de bsqueda de escala a un nmero tan extraordinarios. 1,2. Google: Ampliacin de la Web Creacin de un motor de bsqueda que las escalas, incluso a la web de hoy presenta muchos desafos. La tecnologa de rastreo rpido y es necesario para reunir los documentos web y mantenerlos al da. El espacio de almacenamiento debe ser utilizado eficientemente 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 manipuladas rpidamente, a una velocidad de cientos de miles por segundo. Estas tareas son cada vez ms difcil, ya que la web crece. Sin embargo, el rendimiento del hardware y el coste han mejorado considerablemente para compensar en parte la dificultad. Hay, sin embargo, varias excepciones notables a este progreso, como un disco Tiempo de bsqueda 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 as a los conjuntos de datos extremadamente grandes. Se hace un uso eficiente del 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 prev que el costo para indexar y almacenar texto o HTML con el tiempo se reducir con respecto a la

cantidad que estar disponible (vase el Apndice B). Esto dar lugar a propiedades de escala favorables para sistemas centralizados como Google. 1.3 Objetivos del diseo 1.3.1 Calidad de Bsqueda mejorada Nuestro objetivo principal es mejorar la calidad de los motores de bsqueda web. En 1994, algunas personas crean que un ndice de bsqueda completo hara posible encontrar cualquier cosa fcilmente. De acuerdo con lo mejor de la Web 1994 Navegantes, "El mejor servicio de navegacin debe hacer que sea fcil encontrar casi cualquier cosa en la Web (una vez que todos los datos se introducen)." Sin embargo, la web de 1997 es muy diferente. Cualquiera que haya usado un motor de bsqueda recientemente, fcilmente pueden dar testimonio de que la integridad del ndice no es el nico factor en la calidad de los resultados de bsqueda. "Los resultados de basura" a menudo vaciar los resultados que un usuario est interesado pulg De hecho, a partir de noviembre de 1997, slo uno de los 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 aumentado en muchos rdenes de magnitud, pero la capacidad del usuario para ver los documentos no tiene. La gente todava slo est dispuesta a ver las primeras decenas de resultados. Debido a esto, ya que el tamao de la coleccin crece, necesitamos herramientas que tienen una precisin muy alta (nmero de documentos relevantes devueltos, por ejemplo en lostop ten de los resultados). De hecho, queremos que nuestra nocin de "relevante" para incluir slo los documentos de mejores ya que puede haber decenas de miles de documentos poco relevantes. Esta tecnologa de alta precisin es importante, incluso a expensas de la memoria (el nmero total de documentos pertinentes del sistema es capaz de volver). Hay un poco de optimismo reciente 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 de enlaces de texto proporcionan una gran cantidad de informacin para hacer juicios de relevancia y filtrado de calidad. Google hace uso de la estructura de enlace de ambos y el ancla de texto (vanse las secciones 2.1 y 2.2). 1.3.2 Academic Search Engine Investigacin-Academia de bsqueda del motor de investigacin Aparte de un gran crecimiento, la Web tambin se ha convertido cada vez ms comercial a travs del tiempo. En 1993, el 1,5% de los servidores web estaban en los dominios. Com. Este nmero creci a ms del 60% en 1997. Al mismo tiempo, los motores de bsqueda han migrado desde el mbito acadmico a la comercial. Hasta ahora la mayor parte del desarrollo motor de bsqueda ha ido a las empresas con pequea publicacin de los detalles tcnicos. Esta bsqueda de las causas de la tecnologa de motores siguen siendo en gran medida un arte negro y de ser orientado a la publicidad (ver Apndice A). Con Google, tenemos un objetivo fuerte para impulsar un mayor desarrollo y comprensin en el mbito acadmico.

Otro objetivo importante del diseo fue la de construir los sistemas que un nmero razonable de personas que realmente puede utilizar. El uso era importante para nosotros porque creemos que algunas de las investigaciones ms interesantes implicarn aprovechar la gran cantidad de datos de uso que est disponible en los sistemas web modernos. Por ejemplo, hay muchas decenas de millones de bsquedas realizadas cada da. Sin embargo, es muy difcil obtener estos datos, principalmente porque se considera comercialmente valioso. Nuestro objetivo de diseo final fue la de construir una arquitectura que pueda apoyar las actividades de investigacin sobre nuevos datos de la web a gran escala. Para apoyar la investigacin nuevos usos, Google almacena todos los documentos reales que se arrastra en forma comprimida. Uno de nuestros objetivos principales en el diseo de Google fue la creacin de un entorno en el que otros investigadores pueden llegar rpidamente, procesar grandes porciones 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 funcionando, ya ha habido varios trabajos que utilizan bases de datos generadas por Google, y muchos otros estn en marcha. Otro de los objetivos que tenemos es la creacin de un entorno de laboratorio espacial Spacelab-como el que los investigadores e incluso los estudiantes pueden proponer y realizar experimentos interesantes en nuestros datos de la web a gran escala. 2. CARACTERSTICAS DEL SISTEMA El motor de bsqueda de Google tiene dos caractersticas importantes que le ayudan a producir resultados de alta precisin. En primer lugar, hace uso de la estructura de enlaces de la Web para calcular el ranking de calidad para cada pgina web. Esta clasificacin se denomina PageRank y se describe en detalle en [Pgina 98]. En segundo lugar, Google utiliza enlaces para mejorar los resultados de bsqueda. 2.1 PageRank: poner orden en la Web La cita (enlace) el grfico de la web es un recurso importante que ha desaparecido en gran medida no utilizada en los actuales motores de bsqueda web. Hemos creado mapas que contienen hasta 518 millones de estos enlaces, una muestra significativa del total. Estos mapas permiten el clculo rpido de "PageRank" de una pgina web, una medida objetiva de la importancia de la citacin que se corresponde bien con la idea subjetiva de las personas de importancia. Debido a esta correspondencia, el PageRank es una excelente manera de dar prioridad a los resultados de las bsquedas de palabras clave web. Para temas ms populares, un texto simple juego de bsqueda que se limita a los ttulos de las pginas web se desempea 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 de PageRank La 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 la importancia de una pgina o la calidad. PageRank se extiende esta idea al no contarlos 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 la misma (es decir, son las citas) El parmetro d es un factor de amortiguamiento que se puede establecer entre 0 y 1. Por lo general, establecer d a 0,85. Hay ms detalles sobre d en la siguiente seccin. Tambin C (A) se define como el nmero de enlaces que salen dela 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 el PageRank formar una distribucin de probabilidad sobre las pginas web, por lo que la suma de todas las pginas web PageRank 'ser uno. PageRank o PR (A) se puede calcular utilizando un sencillo algoritmo iterativo, y corresponde al auto vector principal de la matriz enlace normalizado de la banda. Adems, un PageRank de 26 millones de pginas web se puede calcular en unas pocas horas en una estacin de trabajo de tamao medio. Hay muchos otros detalles que estn fuera del alcance de este documento. 2.1.2 Justificacin intuitiva PageRank puede ser considerado como un modelo de comportamiento del usuario. Suponemos que hay un "navegante aleatorio" que se le da una pgina web al azar y se mantiene a hacer clic en enlaces, no golpear "de vuelta", pero finalmente se aburre y empieza en otra pgina al azar. La probabilidad de que el internauta visita una pgina al azar es su PageRank. Y, el factor de amortiguamiento d es la probabilidad en cada pgina de la "persona que practica surf al azar" se aburrir y pedir otra pgina al azar. Una variacin importante es aadir slo el factor de amortiguamiento d en una sola pgina, o un grupo de pginas. Esto permite la personalizacin y puede hacer que sea casi imposible para engaar deliberadamente al sistema a fin de obtener un ranking ms alto. Tenemos varias otras extensiones de PageRank, una vez ms ver [Pgina 98]. Otra justificacin intuitiva es que una pgina puede tener un PageRank alto, si hay muchas pginas que apuntan a la misma, o si hay algunas pginas que apuntan a ella y tiene un PageRank alto. Intuitivamente, las pginas que estn bien citados en muchos lugares alrededor de la web que vale la pena mirar. Adems, las pginas que tienen tal vez slo una cita de algo parecido a la pgina principal de Yahoo! Son tambin, en general vale la pena mirar. Si una pgina no es de alta calidad, o era un vnculo roto, es muy probable que la pgina de inicio de Yahoo no se unira a l. PageRank maneja ambos casos, y todo lo dems de forma recursiva la propagacin de pesos a travs de la estructura de enlaces de la web. 2.2 Anclaje de texto El texto de los enlaces es tratado de una manera especial en nuestro motor de bsqueda. La mayora de los motores de bsqueda de asociar el texto de un vnculo con la pgina que el enlace est encendida. Adems, lo asociamos con la pgina el enlace apunta. Esto tiene varias ventajas. En primer lugar, anclas a menudo proporcionan descripciones ms exactas de las pginas web que las propias pginas. En segundo lugar, pueden existir anclajes para los documentos que no pueden ser indexados por un texto basado en el motor de bsqueda, como imgenes, programas y bases de datos. Esto hace que sea posible volver las pginas webs a las que en realidad no han sido rastreadas. Ntese que las pginas que no se han rastreado pueden causar problemas, ya que nunca se comprueba su validez antes de ser devuelta al usuario. En este caso, el motor de bsqueda tambin puede devolver una pgina que en realidad nunca existi, sino que los hipervnculos que enlazan con l. Sin embargo, es posible ordenar los resultados, por lo que este problema particular, rara vez ocurre.

Esta idea de propagar el ancla de texto a la pgina que se refiere a se llev a cabo en el gusano de la World Wide Web [McBryan 94] sobre todo porque no ayuda a buscar informacin de texto, y ampla la cobertura de la bsqueda con menos documentos descargados. Nuestro mtodo de propagacin de anclaje sobre todo porque el ancla de texto puede ayudar a proporcionar mejores resultados de calidad. El uso de texto de anclaje de manera eficiente es tcnicamente difcil, debido a las grandes cantidades de datos que deben ser procesados. En nuestro rastreo actual de 24millones de pginas, que contaba con ms de 259 millones anclas que nos indexados. 2.3 Otras caractersticas Aparte de PageRank y el uso del texto del ancla, Google tiene varias otras caractersticas. En primer lugar, tiene informacin sobre 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 la fuente de las palabras. Las palabras en letra ms grande o ms audaces se ponderan ms alto que palabras. HTML En tercer lugar, lleno prima de las pginas est disponible en un repositorio. 3 TRABAJOS RELACIONADOS La investigacin Buscar 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. Le sigui por varios otros motores de bsqueda 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]. De acuerdo con Michael Mauldin(cientfico en jefe de Lycos Inc.) [Mauldin], "los diferentes servicios (incluyendo Lycos) guardan estrecha los detalles de estas bases de datos". Sin embargo, ha habido una buena cantidad de trabajo sobre las caractersticas especficas de los motores de bsqueda. Especialmente bien representado es el trabajo que se pueden obtener resultados por el post-procesamiento de los resultados de los actuales motores de bsqueda comerciales, o producir a pequea escala "individualizada" motores de bsqueda. Por ltimo, ha habido mucha investigacin sobre los sistemas de recuperacin de informacin, sobre todo en colecciones bien controladas. En las dos secciones siguientes, se discuten algunas reas en las que esta investigacin debe ampliarse para trabajar mejor en la web. 3.1 Recuperacin de la 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 en sistemas de recuperacin de informacin se encuentra en pequeas colecciones homogneas bien controladas, tales como colecciones de artculos cientficos o noticias sobre un tema relacionado. De hecho, la referencia fundamental para la recuperacin de informacin, la Conferencia de recuperacin de textos [TREC 96], utiliza un bastante pequeo, la coleccin bien controlada por sus puntos de referencia. El "Corpus Muy Grande" punto de referencia es slo de 20 GB 147 GB en comparacin con el de nuestro rastreo de 24 millones de pginas web. Las cosas que funcionan bien en TREC a menudo no producen buenos resultados en la web. Por ejemplo, el modelo de espacio vectorial estndar intenta devolver el documento que ms se aproxima a la consulta, dado que tanto la consulta y el documento son vectores definidos por su ocurrencia palabra. En la web, esta estrategia a

menudo, se mostrarn documentos muy cortos que son la consulta, ms unas cuantas palabras. Por ejemplo, hemos visto un importante motor de bsqueda devuelve una pgina que contiene slo "Bill Clinton Sucks" y la imagen de un "Bill Clinton" de la 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 esta posicin con vehemencia. Si un usuario realiza una consulta como "Bill Clinton" deben obtener resultados razonables, ya que hay una enorme cantidad de informacin de alta calidad disponible sobre este tema. Teniendo en cuenta ejemplos como estos, creemos 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 controladas La web es una vasta coleccin de documentos heterogneos totalmente incontrolados. Los documentos en la web tienen una variacin extrema 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 producto), el tipo o el formato (texto, HTML, PDF, imgenes, sonidos), y puede incluso ser generada por mquina (archivos de registro o de salida a partir de una base de datos). Por otro lado, definimos meta informacin externa como la informacin que puede deducirse de un documento, pero no est contenido dentro de ella. Ejemplos de meta-informacin externa incluyen cosas como la reputacin de la fuente, la frecuencia de actualizacin, calidad, popularidad o uso, y las citas. No slo son las posibles fuentes de informacin de la meta externa variadas, pero las cosas que estn siendo medidos varan muchos rdenes de magnitud tambin. Por ejemplo, comparar la informacin sobre el uso de una pgina importante, al igual que Yahoo, que en la actualidad recibe millones de visitas todos los das con un artculo oscuro histrico que podra recibir una consulta 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 tradicionales colecciones bien controladas es que virtualmente no hay control sobre lo que la gente puede poner en la web. Pareja de esta flexibilidad para publicar cualquier cosa con la enorme influencia de los motores de bsqueda para enrutar el trfico y las empresas que, deliberadamente, la manipulacin de los motores de bsqueda con fines de lucro convertido en un problema grave. Este problema de que no se ha abordado en los tradicionales sistemas cerrados de recuperacin de informacin. Adems, es interesante notar que los esfuerzos de metadatos han fracasado en gran medida con los motores de bsqueda en la Web, ya que cualquier texto en la pgina que no est directamente representado para el usuario se abusa de manipular los motores de bsqueda. Hay numerosas empresas, incluso que se especializan en la manipulacin de los motores de bsqueda con fines de lucro. 4 SISTEMA DE ANATOMA En primer lugar, se proporcionar una discusin de alto nivel de la arquitectura. Entonces, hay algunas descripciones en profundidad de las estructuras de datos importantes. Por ltimo, las aplicaciones principales: Rastreo, indexacin y bsqueda ser examinado en profundidad.

4.1 Google Descripcin de la Arquitectura En esta seccin, vamos a dar una visin general de alto nivel de cmo el sistema funciona como se muestra en la Figura 1. Otras secciones discutiremos las aplicaciones y estructuras de datos que no se mencionan en esta seccin. La mayor parte de Google est implementado en C o C + + de eficiencia y puede correr en Solaris o Linux. En Google, el rastreo web (descarga de pginas web) se lleva a cabo por varios crawlers distribuidos. Hay una URLserver que enva listas de URLs que se debe buscar a los rastreadores. Las pginas web que se buscan, se envan a la store server. El store server comprime y almacena las pginas Web en un repositorio. Cada pgina web tiene un nmero de identificacin asociado denominado docID que se le asigna una nueva direccin URL cada vez que se analiza de una pgina web. La funcin de indexacin se realiza por el indexador y el clasificador de la. El indizador realiza una serie de funciones. Se lee el repositorio, descomprime los documentos y los 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 la fuente, y la capitalizacin. El indexador distribuye estos aciertos en una serie de "barriles", la creacin de un ndice parcialmente ordenados hacia adelante. El indexador lleva a cabo otra funcin importante. Analiza todos los enlaces en cada pgina web y almacena informacin importante sobre los mismos en un fichero de anclas. Este archivo contiene informacin suficiente para determinar que cada enlace apunta desde y hacia, y el texto del enlace. El URL resolver lee el archivo de las anclas y convierte las URLs 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 el ancla apunta. Tambin genera una base de datos de enlaces que son pares de docIDs. La base de datos de enlaces se utiliza para calcular PageRanks para todos los documentos. El clasificador tiene los barriles, los cuales son ordenados por docID (esta es una simplificacin, vase la Seccin 4.2.5), y centros tursticos de ellos wordID para generar el ndice invertido. Esto se hace en lugar de modo que el espacio temporal que se necesita poco para esta operacin. El clasificador produce tambin una lista de wordIDs y compensaciones 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 usa el lxico construido por DumpLexicon junto con el ndice invertido y los PageRank para responder a consultas. 4.2 Estructuras de datos importantes Estructuras de datos de Google se han optimizado de manera que una coleccin de documentos de gran tamao puede ser rastreado, indexado, y busc con poco costo. A pesar de que las CPU y las tasas de insumo-producto a granel han mejorado dramticamente en los ltimos aos, un disco de buscar an requiere alrededor de 10 ms para completar. Google est diseado 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-grandes archivos BigFiles son archivos virtuales que abarcan mltiples sistemas de archivos y son direccionables por enteros de 64 bits. La asignacin de los mltiples sistemas de archivos se realiza automticamente. El paquete BigFiles tambin se encarga de la asignacin y liberacin de los descriptores de archivo, ya que los sistemas operativos no proporcionan suficiente para nuestras necesidades. BigFiles tambin apoyan las opciones de compresin rudimentarios. 4.2.2 Repositorio El repositorio contiene todo el HTML de cada pgina web. Cada pgina es comprimida usando zlib (ver RFC1950). La eleccin de la tcnica de compresin es un equilibrio entre la velocidad y relacin de compresin. Elegimos zlib de velocidad sobre una mejora significativa en la compresin ofrecida por bzip. La tasa de compresin de bzip fue de aproximadamente 4 a 1 en el depsito en comparacin con los zlib 3 a 1 de compresin. En el depsito, se almacenan los documentos uno tras otro y tienen el prefijo docID, longitud y URL como puede verse en la Figura 2. El repositorio no requiere otras estructuras de datos que se utilizarn con el fin de acceder a l. Esto ayuda a la consistencia de los datos y hace mucho ms fcil el desarrollo, podemos reconstruir todas las otras estructuras de datos de slo el repositorio y un archivo que lista los errores de cadenas. 4.2.3 ndice de documentos El ndice de documento mantiene la informacin sobre cada documento. Se trata de un ancho fijo ISAM (modo de ndice de acceso secuencial) de ndice, ordenado por docID. La informacin almacenada en cada entrada incluye el estado actual del documento, un puntero en el repositorio, un checksum de documentos y estadsticas varias. Si el documento se ha rastreado, tambin contiene un puntero a un archivo de ancho variable llamada DOCINFO que contiene la direccin URL y el ttulo. De lo contrario el puntero apunta a la URL list que slo contiene la direccin URL. Esta decisin de diseo fue impulsado por el deseo de tener una estructura de datos razonablemente compacto y la capacidad para buscar un registro en un disco de buscar durante un registro Adems, hay un archivo que se utiliza para convertir URLs en docIDs. Se trata de una lista de sumas de comprobacin de URL con sus correspondientes docIDs y est ordenada por checksum. Con el fin de encontrar el docID de una URL concreta, de suma de comprobacin de la URL se calcula y una bsqueda binaria se realiza en el archivo de las sumas de comprobacin para encontrar su docID. URL se puede convertir en docIDs en lotes haciendo una fusin con este archivo. Esta es la tcnica de la URL resolver utiliza para convertir las URL en docIDs. Este modo de proceso por lotes de actualizacin es crucial, porque de lo contrario, debe realizar una bsqueda de todos los eslabones que asumir un disco tomara ms de un mes para nuestra base de datos enlace de 322 millones. 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 con256 MB de memoria principal. El lxico actual contiene 14 millones de palabras(aunque algunas palabras raras no se han aadido al lxico). Se lleva a cabo en dos partes: una lista de las palabras (concatenadas pero separadas por nulos) y una tabla hash de punteros. Para las diversas funciones, la lista de palabras tiene alguna informacin auxiliar que est ms all del alcance de este documento para explicar completamente. 4.2.5 listas de xitos Una lista de resultados corresponde a una lista de las apariciones de una palabra concreta en un documento en particular incluyendo la posicin, la fuente y la informacin de capitalizacin. Listas de golpe en cuenta para la mayor parte del espacio utilizado tanto en el avance y los ndices invertidos. Debido a esto, es importante que ellos representen tan eficientemente como sea posible. Se consideraron varias alternativas para la posicin de la codificacin, la fuente, y la capitalizacin - la codificacin simple (un triple de enteros), una codificacin compacta (con una asignacin optimizada de la mano bits) y Huffman. Al final se opt por un lado optimizar la codificacin compacta, ya que requiere mucho menos espacio que la codificacin simple y mucho menos la manipulacin de bits de codificacin de Huffman. Los detalles de los accesos se muestran en la Figura 3. Nuestra codificacin compacta usa dos bytes por cada golpe. Hay dos tipos de resultados: golpes de fantasa y golpes simples. Golpes de fantasa incluyen xitos que ocurren en una direccin URL, el ttulo, el ancla de texto, o etiqueta meta. Accesos simples incluyen todo lo dems. Un golpe normal se compone de varios pedazos de bits de capitalizacin, tamao de fuente, y 12 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 el 7 valores se utilizan realmente, porque 111 es la bandera que seala un golpe de fantasa). Un golpe de lujo se compone de un poco de capitalizacin, el tamao de fuente 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 los bits 4 a un hash de la docID el ancla aparece pulg Esto nos da una frase de bsqueda limitada, siempre y cuando no hay muchos que las anclas para un palabra en particular. Esperamos actualizar la forma en que se almacenan los accesos de anclaje para permitir una mayor resolucin en la posicin y los campos de docIDhash. Usamos el tamao de fuente en relacin con el resto del documento, porque cuando se busca, no desea clasificar los documentos por lo dems idnticos de manera diferente slo porque uno de los documentos se encuentra en un tipo de letra ms grande. La longitud de una lista de resultados se almacena antes de los propios xitos. Para ahorrar espacio, la longitud de la lista de resultados se combina con la wordID en el ndice hacia adelante y la docID en el ndice invertido. Esto lo limita a 8 y 5, respectivamente, los bits (hay algunos trucos que permiten 8 bits para ser tomado de la wordID). Si la longitud es mayor que encajara en que muchos bits, un cdigo de escape se utiliza en esos bits, y los siguientes dos bytes contienen la longitud real.

4.2.6 ndice de Avance El ndice de avance es en realidad ya est parcialmente ordenados. Se almacena en un nmero de barriles (se utiliz 64). Cada barril tiene una amplia gama de los wordID. Si un documento contiene palabras que caen en un barril particular, la docID se registra en el barril, seguido por una lista de wordID con listas de resultados que se corresponden con aquellas palabras. Este esquema requiere un poco ms de almacenamiento debido a la duplicacin de docIDs pero la diferencia es muy pequea para un nmero razonable de cubos y ahorra un tiempo considerable y la complejidad de la codificacin en la fase final de la indexacin realizada por la clasificadora. Por otra parte, en lugar de almacenar wordID real es, almacenamos todos los wordID como una diferencia relativa de la wordID mnimo que entra en el can del wordID es pulg De esta manera, se puede utilizar slo 24 bits para el wordID est en los barriles sin ordenar, dejando 8 bits para la longitud de la lista de resultados. 4.2.7 ndice invertido El ndice invertido consiste en los barriles mismo que el ndice hacia adelante, excepto que han sido procesados por el clasificador. Por cada wordID vlido, el lxico contiene un puntero en el can que cae en wordID. Apunta a un DocList de docID, junto con sus listas de resultados correspondientes. Este DocList representa a todas las ocurrencias de esa palabra en todos los documentos. Una cuestin importante es en qu orden el docID debe aparecer en el DocList. Una solucin simple es almacenarlos clasificados por docID. Esto permite la rpida fusin de DocLists diferentes para las consultas de varias palabras. Otra opcin consiste en almacenar los ordenados por una clasificacin de la aparicin de la palabra en cada documento. Esto hace que responder a una consulta de palabras trivial y hace que sea probable que las respuestas a las preguntas de varias palabras estn cerca de la salida. 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. Hemos elegido una solucin de compromiso entre estas dos posibilidades, mantener dos conjuntos de barriles invertidos: un juego para las listas de xitos que incluyen ttulos o xitos de anclaje y otro conjunto para todas las listas de xitos. De esta manera, comprobamos el primer conjunto de barriles la primera y si no hay coincidencias suficientes dentro de los barriles que ver los ms grandes. 4.3 Rastreo de la web Ejecucin de un rastreador web es una tarea difcil. Hay desempeo difcil y los problemas de confiabilidad y an ms importante, hay cuestiones sociales. El gateo es la aplicacin ms consolidada, ya que implica interactuar con cientos de miles de servidores web y servidores de nombres de varios que estn todos fuera del control del sistema. Con el fin de escalar a cientos de millones de pginas web, Google dispone de un rpido sistema de distribucin de rastreo. Una sola URLserver sirve listas de URLs a un nmero de orugas (que normalmente corran 3). Tanto el URLserver y los rastreadores estn implementados en Python. Cada rastreador mantiene alrededor de 300 conexiones abiertas a la vez. Esto es necesario para recuperar las pginas web a un ritmo lo suficientemente

rpido. A velocidades mximas, el sistema puede rastrear ms de 100 pginas web por segundo por medio de cuatro orugas. Esto equivale a alrededor de 600K por segundo de datos. Un esfuerzo importante es el rendimiento de bsqueda de DNS. Cada crawler mantiene una cach de su propio DNS para que no se necesita hacer una bsqueda de DNS antes de rastrear cada documento. Cada uno de los cientos de conexiones puede estar en un nmero de estados diferentes: en busca de DNS, la conexin al host, enviando peticin y recibir la respuesta. Estos factores hacen que el rastreador un componente complejo del sistema. Utiliza S asncrona para gestionar eventos, y un nmero de colas para pasar la pgina obtiene a partir de un estado a otro. Resulta que la ejecucin de un rastreador que conecta a ms de medio milln de servidores, y genera decenas de millones de entradas en el registro genera una buena cantidad de llamadas de correo electrnico y telfono. Debido a la gran cantidad de personas que vienen en lnea, siempre hay aquellos que no saben lo que es un rastreador, ya que este es el primero que han visto. Casi todos los das, recibimos un correo electrnico algo como, "Wow, que daba a un montn 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 est protegido por copyright y no debe ser indexada", lo que hace falta decir que es difcil para los rastreadores web de entender. Adems, debido a la enorme cantidad de datos involucrados, las cosas inesperadas que sucedern. Por ejemplo, nuestro sistema ha intentado rastrear un juego en lnea. Esto dio lugar a un montn de mensajes 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 se haba descargado decenas de millones de pginas. Debido a la inmensa variacin en las pginas web y los servidores, es prcticamente imposible de probar un rastreador, sin ejecutarlo en gran parte de la Internet. Invariablemente, hay cientos de problemas oscuros que slo pueden ocurrir en una pgina de toda la red y hacer que el rastreador se bloquee, o peor an, provocar un comportamiento impredecible o incorrecto. Sistemas que tienen acceso a gran parte de la Internet deben ser diseados para ser muy robusto y probado cuidadosamente. Desde los grandes sistemas complejos, tales como rastreadores a causar problemas, es necesario que haya recursos importantes dedicados a la lectura del correo electrnico y la solucin de estos problemas a medida que surgen. 4.4 de indexacin de la Web Anlisis - Cualquier analizador, que est diseado para ejecutarse en toda la Web debe manejar una enorme variedad de posibles errores. Estos van desde errores en etiquetas HTML para kilobytes de ceros en el medio de una etiqueta, los caracteres no ASCII, etiquetas HTML anidadas cientos de profundidad, y una gran variedad de otros errores que la imaginacin de cualquiera de desafo para llegar a otros igualmente creativos. Para la mxima velocidad, en lugar de utilizar YACC para generar un analizador de CFG, que utilizar flex para generar un analizador lxico que traje con su propia pila. El desarrollo de este analizador que funciona a una velocidad razonable y es muy robusto implicados una buena cantidad de trabajo. La indexacin de documentos en barriles - Despus de cada documento se analiza, se codifica en una serie de barriles. Cada palabra se convierte en una wordID mediante el uso de una tabla hash en memoria - en el lxico. Las nuevas adiciones a la tabla hash lxico se

registra en un archivo. Una vez que las palabras se convierten en wordID, sus ocurrencias en el documento actual se traducen en listas de ataque y se escriben en los barriles hacia adelante. La principal dificultad con la paralelizacin de la fase de indexacin es que el lxico debe ser compartido. En lugar de compartir el lxico, tomamos el enfoque de la escritura de un registro de todas las palabras adicionales que no estaban en un lxico de base, que se fija en 14 millones de palabras. De esta forma mltiples indexadores pueden ejecutarse en paralelo y luego el archivo de registro pequeo de palabras adicionales pueden ser procesados por un indexador final. Clasificacin - Para generar el ndice invertido, el clasificador toma cada uno de los barriles hacia adelante y la ordena por wordID para producir un barril invertido por sus lanzamientos de ttulos y un ancla y un barril texto completo invertido. Este proceso tiene lugar un barril a la vez, lo que requiere el almacenamiento temporal pequeo. Tambin, en paralelo la fase de clasificacin para usar tantas mquinas como tenemos simplemente mediante la ejecucin de clasificadores mltiples, que pueden procesar cubos diferentes al mismo tiempo. Dado que los barriles no se ajustan a la memoria principal, el clasificador de ellas se subdivide en ms canastas que caben en la memoria sobre la base de wordID y docID. A continuacin, el clasificador, se carga cada canasta en la memoria, lo ordena y escribe su contenido en el can corto invertida y el barril invertido por completo. 4.5 Bsqueda El objetivo de la bsqueda es para proporcionar resultados de bsqueda de calidad de manera eficiente. Muchos de los grandes motores de bsqueda comercial les pareca haber hecho un gran progreso en trminos de eficiencia. Por lo tanto, nos hemos centrado ms en la calidad de la bsqueda en nuestra investigacin, aunque creemos que nuestras soluciones son escalables a los volmenes comerciales con un esfuerzo un poco ms. La consulta de google proceso de evaluacin es muestra en la Figura 4. 1. Analizar la consulta. 2. Convertir las palabras en wordIDs. 3. Se desplaza hasta el inicio de la DocList en el can corto para cada palabra. 4. Analizar a travs de los doclists hasta que haya un documento que coincide con todos los trminos de bsqueda. 5. Calcular el rango de ese documento para la consulta. 6. Si nos encontramos en los barriles cortos y al final de cualquier DocList, buscan el inicio de la DocList en el barril completo para cada palabra y vaya al paso 4. 7. Si no estamos al final de cualquier DocList vaya al paso 4. Clasificar los documentos que se han encontrados por el rango y devolver el k la parte superior. Para poner un lmite en el tiempo de respuesta, una vez que un cierto nmero (actualmente 40.000) de los documentos correspondientes se encuentran, el buscador automticamente va al paso 8 en la Figura 4. Esto significa que es posible que subptimos resultados se devuelva. Actualmente estamos investigando otras maneras de resolver este problema. En el pasado, hemos ordenado los accesos de acuerdo aPageRank, que pareca mejorar la situacin.

4.5.1 El sistema de clasificacin Google mantiene mucha ms informacin sobre documentos web que los motores de bsqueda habituales. Cada lista negra incluye la posicin, la fuente y la informacin de capitalizacin. Adems, tenemos en cuenta los xitos de texto del ancla y el PageRank del documento. La combinacin de toda esta informacin en un rango es difcil. Hemos diseado nuestra funcin de ranking para que ningn factor en particular puede tener demasiada influencia. En primer lugar, consideremos el caso ms simple - una consulta sola palabra. Con el fin de clasificar un documento con una consulta sola palabra, Google mira a lista de resultados de ese documento para esa palabra. Google considera cada hit a ser uno de varios tipos (ttulo, ancla, direccin, tipo de letra grande de texto sin formato, tipo de letra pequeo texto sin formato, ...), cada una de ellas tiene su propio tipo de peso. Los de tipo pesos constituyen un vector indexado por el tipo. Google cuenta el nmero de visitas de cada tipo en la lista de resultados. Entonces, cada recuento se convierte en un recuento de peso. Contar los pesos aumentan linealmente con la cuenta en el primer cono, pero rpidamente de modo que ms que un recuento de algunos no ayuda. Nos tomamos el producto escalar del vector de conteo de los pesos con el vector de pesos de tipo para calcular una puntuacin de IR para el documento. Por ltimo, la puntuacin IR se combina con PageRank para dar un ltimo rango al documento. Para realizar una bsqueda de varias palabras, la situacin es ms complicada. Ahora varias listas de xitos deben ser escaneados a travs a la vez, para que se produzcan golpes juntos en un documento que se ponderan ms alto que se produzcan accesos separados. Los xitos de las listas de xitos mltiples se combinan de tal manera que xitos cercanos se corresponden entre s. Por cada juego completo de visitas, una proximidad se calcula. La proximidad se basa en la distancia entre los accesos se encuentran en el documento (o anclaje), pero se clasifica en 10 valores diferentes "contenedores" que van desde un partido de la frase de "ni siquiera est cerca". Los recuentos se calcula no slo para cada tipo de golpe, sino de todo tipo y de proximidad. Cada tipo y un par de proximidad tiene un tipo de proximidad de peso. Las cuentas se convierten en cuentas de diez pesos y nos tomamos el producto escalar de la cuenta atrs de pesos y los de tipo de proximidad de pesos para calcular una puntuacin IR. Todos estos nmeros y las matrices de todas se pueden mostrar con los resultados de bsqueda que utilizan un modo de depuracin especial. Estas pantallas han sido muy tiles en el desarrollo del sistema de clasificacin. 4.5.2 Comentarios La funcin de ranking tiene muchos parmetros como el tipo de pesos y los pesos de proximidad tipo. Descubrir los valores correctos para estos parmetros es algo as como un arte negro. Para ello, contamos con un mecanismo de retroalimentacin de los usuarios en el motor de bsqueda. Un usuario de confianza, opcionalmente, pueden evaluar todos los resultados que se devuelven. Esta informacin se guarda. 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 La medida ms importante de un motor de bsqueda es la calidad de sus resultados de bsqueda. Si bien una evaluacin completa de usuario est fuera 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, texto ancla, y la proximidad, la

figura 4 muestra los resultados de Google para una bsqueda en "Bill Clinton". Estos resultados se muestran algunas de las caractersticas de Google. Los resultados se agrupan por el servidor. Esto ayuda considerablemente cuando tamizado a travs de conjuntos de resultados. Una serie de resultados son del dominio whitehouse.gov que es lo que razonablemente se puede esperar de una bsqueda. En la actualidad, los motores comerciales ms importantes de la bsqueda no devuelve ningn resultado de whitehouse.gov, y mucho menos los ms adecuados. Tenga en cuenta que no hay 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 resultado es un quinto direccin de correo electrnico que, por supuesto, no es rastreable. Tambin es un resultado de texto de anclaje. Todos los resultados son pginas de calidad razonablemente alta y, en ltima comprobacin, no haba ningn enlace roto. Esto es as porque todos ellos tienen un PageRank alto. El PageRank es el porcentaje en rojo, junto con grficos de barras. Por ltimo, no hay resultados sobre un proyecto de ley que no sea Clinton o de otro que Bill Clinton. Esto se debe a que dan importancia pesado en la proximidad de las ocurrencias de palabras. Por supuesto una verdadera prueba de la calidad de un motor de bsqueda implicara un estudio de usuarios extensos o el anlisis de resultados que no tenemos espacio para aqu. En cambio, invitamos al lector a probar por s mismos en Google http://google.stanford.edu. 5.1 Requerimientos de almacenaje Aparte de la calidad de bsqueda, Google est diseado para escalar rentable con el tamao de la Web a medida que crece. Un aspecto de esto es utilizar eficientemente el almacenamiento. La Tabla 1 presenta un desglose de algunas estadsticas y requisitos de almacenamiento de Google. Debido a la compresin del tamao total del depsito es de 53 GB, un 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, aproximadamente 55 GB. Por otra parte, la mayora de las preguntas se pueden contestar usando slo el ndice invertido corto. Con una mejor codificacin y compresin del ndice de documentos, una red de alta calidad motor de bsqueda puede caber en una unidad de 7GB de un nuevo PC. 5.2 Rendimiento del sistema Es importante para un motor de bsqueda para rastrear e indexar de manera eficiente. De esta manera la informacin se puede mantener hasta la fecha y los cambios importantes en el sistema puede ser probado con relativa rapidez. Para Google, las principales operaciones se Rastreo, indexacin y clasificacin. Es difcil medir el tiempo que se arrastra en general porque los discos llenos, los servidores de nombres se estrell, o cualquier nmero de otros problemas que dejaron el sistema. En total se llevaron alrededor de 9 das para descargar los 26 millones de pginas (incluidos los errores). Sin embargo, una vez que el sistema estaba funcionando sin problemas, corra mucho ms rpido, la descarga de los ltimos 11 millones de pginas en tan slo 63 horas, un promedio de poco ms de 4 millones de pginas al da, o 48.5pginas por segundo. Corrimos el indexador y el rastreador de forma simultnea. El indizador corri solo ms rpido que los rastreadores. Esto es as porque hemos pasado el tiempo suficiente optimizar el indexador de modo que no sera un cuello de botella. Estas optimizaciones incluyen actualizaciones masivas en el ndice de documentos y colocacin de estructuras de datos crticos en el disco local. El indizador se ejecuta en aproximadamente 54 pginas por segundo. Los clasificadores se

puede ejecutar completamente en paralelo, utilizando cuatro mquinas, todo el proceso de seleccin dura aproximadamente 24 horas. TABLA 1 Estadsticas de almacenamiento Tamao total de recuperados de Pginas--------------------147,8 GB Repositorio comprimido------------------------------------------ 53,5 GB ndice de corto invertido------------------------------------------ 4,1 GB ndice completo invertido----------------------------------------- 37,2 GB Lexicon---------------------------------------------------------------- 293 MB Los datos provisionales de anclaje (no en total)----------- 6.6 GB Documento Incluye ndice. De ancho variable de datos-- 9,7 GB Base de datos------------------------------------------------------- 3.9 GB Total sin depsito--------------------------------------------------- 5,2 GB Total con depsito-------------------------------------------------- 108,7 GB Pgina Web Estadsticas Nmero de pginas web recuperados------------------------ 24 millones Nmero de URLs visto-------------------------------------------- 76,5 millones Nmero de Direcciones de correo electrnico-------------- 1700000 Nmero de 404 's-------------------------------------------------- 1,6 millones 5.3 Buscador de rendimiento Mejorar el rendimiento de la bsqueda no era el principal foco 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 es sobre todo dominado por S de disco a travs de NFS (ya que los discos se distribuyen en un nmero de mquinas). Adems, Google no tiene ninguna optimizacin, tales como el almacenamiento en cach de consultas, los subndices de los trminos ms comunes, y otras optimizaciones comunes. Tenemos la intencin de acelerar Google considerablemente a travs de la distribucin y el hardware, software y mejoras algortmicas. Nuestro objetivo es ser capaz de manejar varios cientos de consultas por segundo. La Tabla 2 tiene algunos tiempos de consulta de muestra de la versin actual de Google. Se repiten para mostrar las aceleraciones resultantes de cach IO. TABLA 2 ---------------------- Inicial de consultas----- misma consulta-----repetida (IO sobre todo en cach) Consulta ----------- tiempo de CPU (s) ------Tiempo total (s) -----tiempo de CPU (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 motores de bsqueda---1,31-------------------------9,63----------------------- 1,16----------------1,16

6 CONCLUSIONES Google est diseado para ser un motor de bsqueda escalable. El objetivo principal es proporcionar alta calidad de los resultados de bsqueda en una red mundial de rpido crecimiento amplio. Google emplea una serie de tcnicas para mejorar la calidad de la bsqueda incluyendo fila de la pgina, el texto de anclaje, y la informacin de proximidad. Por otra parte, Google es una arquitectura completa de recogida de pginas web, la indexacin de ellos, y la realizacin de consultas de bsqueda por encima de ellos. 6.1 Trabajo Futuro Un motor Web a gran escala de bsqueda es un sistema complejo y an queda mucho por hacer. Nuestros objetivos inmediatos son mejorar la eficiencia de bsqueda y escalar a unos 100 millones de pginas web. Algunas mejoras simples a la eficiencia incluyen el cacheo de consultas, de asignacin de disco inteligente, y los subndices. Otra rea que requiere mucha investigacin son las actualizaciones. Debemos tener algoritmos inteligentes para decidir qu pginas web de edad deben ser recrawled y lo que los nuevos deben ser rastreado. Trabajar hacia esta meta se ha hecho en [Cho 98]. Una prometedora rea de investigacin est utilizando proxies para construir bases de datos de bsqueda, ya que son impulsadas por la demanda. Estamos planeando agregar caractersticas simples soportados por los motores de bsqueda comerciales, como los operadores booleanos, negacin, y que hayan generado. Sin embargo, otras caractersticas estn empezando a ser exploradas, tales como feedback de relevancia y la agrupacin (Google es compatible actualmente con un simple agrupamiento basado en el nombre de host). Tambin tenemos planes para apoyar el contexto del usuario (como la ubicacin del usuario), y resumen de resultados. Tambin estamos trabajando para extender el uso de la estructura de enlace y el texto del vnculo. Experimentos sencillos indican PageRank puede ser personalizado por el aumento del peso de la pgina principal de un usuario o los marcadores. En cuanto a los enlaces de texto, estamos experimentando con el uso de enlaces de texto que lo rodea, adems de el texto del vnculo en s. Un motor de bsqueda en la Web es un entorno muy rico en ideas para la 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 Bsqueda de alta calidad El mayor problema que enfrentan los usuarios de los motores de bsqueda en la Web hoy en da es la calidad de los resultados que obtienen de vuelta. Si bien los resultados son a menudo divertidas y ampliar los horizontes de los usuarios, son a menudo frustrante y consume un tiempo precioso. Por ejemplo, el primer resultado de una bsqueda de "Bill Clinton" en uno de los motores de bsqueda ms populares comerciales fue la de Bill Clinton Broma del Da: 14 de abril de 1997. Google est diseado para proporcionar una mayor bsqueda de calidad por lo que 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 consiste en estructura de enlaces y el enlace (anchor) de texto. Google tambin utiliza la informacin de proximidad y la fuente. Aunque la evaluacin de un motor de bsqueda es difcil, hemos encontrado que subjetivamente, Google devuelve ms resultados de la bsqueda de calidad que los actuales motores de bsqueda comerciales. El anlisis de la estructura de enlace a travs del PageRank de Google permite 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 motor de bsqueda relevantes (y en cierta calidad de alto grado) los resultados. Por ltimo, el uso de la informacin de proximidad ayuda a aumentar la relevancia de una gran cantidad de consultas de muchos.

6.3 Arquitectura escalable Aparte de la calidad de bsqueda, Google est diseado para escalar. Debe ser eficiente en espacio y tiempo, y los factores constantes son muy importantes cuando se trata de toda la Web. En la aplicacin de Google, hemos visto que los cuellos de botella en la CPU, el acceso a la memoria, capacidad de memoria a disco, el rendimiento del disco, capacidad del disco y la red de IO. Google se ha desarrollado para superar una serie de estos cuellos de botella durante las diversas operaciones. Las principales estructuras de datos de Google hacer un uso eficiente del espacio de almacenamiento disponible. Adems, el rastreo, la indexacin, y las operaciones de ordenacin son lo suficientemente eficientes para ser capaces de 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. El de datos de Google ha recogido ya ha dado lugar en muchos otros trabajos presentados en congresos y muchos ms en el camino. Investigaciones recientes, como [Abiteboul 97] ha demostrado una serie de limitaciones a las preguntas sobre la Web que puede ser contestada sin tener la web disponible a nivel local. Esto significa que Google (o un sistema similar) no slo es una valiosa herramienta de investigacin, pero una condicin necesaria para una una amplia gama de aplicaciones. Esperamos que Google va a ser un recurso para investigadores e investigadores de todo el mundo y despertar la prxima generacin de tecnologa de motores de bsqueda. 7 RECONOCIMIENTOS 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 GarcaMolina, Rajeev Motwani,Ullman Jeff, y Terry Winograd y el grupo WebBase todo por su apoyo y profundas discusiones. Finalmente, nos gustara reconocer el apoyo generoso de nuestros equipos de los donantes de IBM, Intel y Sun y nuestros patrocinadores. La investigacinse describe aqu se llev a cabo como parte del Proyecto Integrado de Stanford, la Biblioteca Digital, con el apoyo de la National Science Foundation bajo el Acuerdo Cooperativo IRI9411306. La financiacin de este acuerdo de cooperacin tambin es proporcionada por DARPA y la NASA, y por Interval Research, y los socios industrialesdel proyecto de Bibliotecas Digitales de Stanford. VITAE Sergey Brin, recibi su B.S. Licenciado en matemticas y ciencias de la computacinde la Universidad de Maryland en College Park en 1993. Actualmente, es un doctoradocandidato en ciencias de la computacin en la Universidad de Stanford, donde recibisu maestra en 1995. l es un receptor de la National Science Foundation Graduate Fellowship. Sus intereses de investigacin incluyen los motores de bsqueda, extraccin de informacin de fuentes no estructuradas y extraccin de datos de largas recopilaciones de texto y datos cientficos. Lawrence Page naci en East Lansing, Michigan, y recibi una encefalopata espongiforme bovina en Ingeniera Informtica en la Universidad de Michigan en Ann Arbor en 1995. En la

actualidad es un doctorado 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, interaccin persona-ordenador, los 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 MEZCLADOS En la actualidad, el modelo de empresa predominante para los motores de bsqueda comerciales es la publicidad. Los objetivos del modelo de negocio de la publicidad no siempre corresponden a ofrecer bsquedas de calidad a los usuarios. Por ejemplo, en nuestro motor de bsqueda prototipo de uno de los primeros resultados para el telfono celular es "El efecto del uso del telfono celular por la atencin del controlador", un estudio que explica en 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 importancia de la citacin en la web [Pgina, 98]. Est claro que un motor de bsqueda que se estaba llevando dinero para publicar anuncios de telfonos celulares que tienen dificultades para justificar la pgina que nuestro sistema vuelva a sus anunciantes pagados. Para este tipo de razn y la experiencia histrica con otros medios de comunicacin [Bagdikian 83], se espera que los motores de bsqueda de publicidad sern financiados por inherentemente sesgada 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 motores de bsqueda es particularmente insidiosa. Un buen ejemplo fue OpenText, que fue informado de que la venta de las empresas el derecho a figurar en la parte superior de los resultados de la bsqueda para las consultas particulares [Marchiori 97]. Este tipo de sesgo es mucho ms insidioso que la publicidad, porque no est claro quin "merece" estar ah, y que est dispuesto a pagar dinero para ser enumeradas. Este modelo de negocio result en un gran alboroto, y OpenText ha dejado de ser un motor de bsqueda viable. Sin embargo, el sesgo menos evidente es probable que sean tolerados por el mercado. Por ejemplo, un motor de bsqueda podra aadir un factor pequeo para buscar los resultados 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 por publicidad a menudo proporciona un incentivo para proporcionar pobres resultados de la bsqueda de calidad. Por ejemplo, nos dimos cuenta de un motor de bsqueda no volvera pgina de inicio de una gran compaa area cuando el nombre de la aerolnea se dio como una consulta. Dio la casualidad de que la aerolnea haba puesto un anuncio caro, vinculado a la consulta que era su nombre. Un motor de bsqueda mejor no hubiera sido necesario este anuncio, y posiblemente como resultado la prdida de los ingresos de la compaa area para el motor de bsqueda. En general, se podra argumentar desde el punto de vista del consumidor que cuanto mejor sea el motor de bsqueda es, los anuncios menos sern necesarios para que el consumidor encuentre lo que desee. 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 tiene algo que es realmente nuevo. Sin embargo, creemos que la cuestin de la publicidad hace que los incentivos lo suficientemente mixtos

que es fundamental contar con un motor de bsqueda competitiva que sea transparente y en el mbito acadmico. 9 APNDICE B: ESCALABILIDAD 9. Una escalabilidad de Google Hemos diseado Google para que sea escalable en el corto plazo a una meta de 100millones de pginas web. Acabamos de recibir el disco y las mquinas para manejar ms o menos de esa cantidad. Todas las partes que consumen tiempo del sistema son paralelizar y lineales aproximadamente tiempo. Estos incluyen cosas como las orugas, indizadores y clasificacin de residuos. Tambin pensamos que la mayora de las estructuras de datos se ocupar de gracia con la expansin. Sin embargo, en 100 millones de pginas web que va a ser muy de cerca contra todo tipo de lmites del sistema operativo en los sistemas operativos ms comunes (en la actualidad se ejecutan 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 aumentara en gran medida la complejidad de nuestro sistema. 9.2 La escalabilidad de las arquitecturas centralizadas de indexacin Como las capacidades de aumento ordenadores, se hace posible ndice una cantidad muy grande de texto para un coste razonable. Por supuesto, otros medios de comunicacin ms intensivas de banda ancha tales como vdeo es probable que se torna ms difundido. Pero, debido a que el costo de produccin del texto es baja en comparacin a los medios como el vdeo, el texto es probable que siga siendo muy penetrante. Adems, es probable que pronto vamos a tener el reconocimiento de voz que hace un trabajo razonable de convertir voz en texto, ampliando la cantidad de texto disponible. Todo esto ofrece posibilidades increbles para la indexacin centralizada. He aqu un ejemplo ilustrativo. Suponemos que queremos a todo el mundo ndice de todo lo que en los EE.UU. ha escrito durante un ao. Se supone que hay 250 millones de personas en los EE.UU. y escriben un promedio de 10k por da. Eso se resuelve a ser cerca de 850 terabytes. Suponga tambin que la indexacin de un terabyte puede hacer ahora por un costo razonable. Tambin se asume que los mtodos de indizacin utilizados en el texto es lineal, lineal o casi en su complejidad. Teniendo en cuenta todos estos supuestos se puede calcular cunto tiempo le tomara antes de que pudiramos ndice de los 850 terabytes por un precio razonable asumir ciertos factores de crecimiento. La Ley de Moore se defini en 1965 como una duplicacin cada 18 meses en el poder del procesador. Se ha mantenido muy fiel, no slo para los procesadores, pero para otros parmetros importantes del sistema como un disco as.Si asumimos que la ley de Moore se cumple para el futuro, necesitamos slo 10 duplicaciones ms, o 15 aos para alcanzar nuestra meta de todo el mundo todo lo que la indexacin 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 que se trate la Ley de Moore no se puede seguir para mantener durante los prximos 15 aos, pero sin duda hay un montn de interesantes aplicaciones centralizadas, incluso si slo tenemos una parte del camino a nuestro ejemplo hipottico. Por supuesto, un brillo de sistemas distribuidos como los [Gravano 94] o de la cosecha ser a

menudo la solucin tcnica ms eficiente y elegante para la indexacin, pero parece difcil convencer al mundo en utilizar estos sistemas debido a los altos costos de administracin de la creacin de un gran nmero de instalaciones. Por supuesto, es muy probable que la reduccin del costo de administracin drsticamente es posible.Si eso sucede, y todo el mundo se pone en marcha un sistema de indexacin distribuida, la bsqueda va a mejorar drsticamente. Porque los seres humanos slo se puede escribir o hablar de una cantidad finita, y como las computadoras continan mejorando, la indexacin de texto se escalar an mejor que en la actualidad. Por supuesto que podra haber una cantidad infinita de contenidos generados por la mquina, pero slo indexar grandes cantidades de contenido generado por el ser humano parece tremendamente til. As que somos optimistas de que nuestra bsqueda centralizada web de arquitectura del motor va a mejorar en su capacidad para cubrir la informacin de texto correspondiente en el tiempo y que hay un futuro brillante para la bsqueda.