la anatomÍa de una gran escala del motor de bÚsqueda web de hipertextual

5/17/2018 LA ANATOMÍA DE UNA GRAN ESCALA DEL MOTOR DE BÚSQUEDA WEB DE HIPERTEXTUAL - slidepdf.com

http://slidepdf.com/reader/full/la-anatomia-de-una-gran-escala-del-motor-de-busqueda-web-de-hipertextual 1/21

LA ANATOMÍA DE UNA GRAN ESCALA DEL MOTOR DE BÚSQUEDA WEB DEHIPERTEXTUAL

Sergey Brin y Lawrence Page{Sergey, en la página} @ cs.stanford.eduDepartamento de Informática de la Universidad de Stanford, Stanford, CA 94305Resumen

En este trabajo, presentamos Google, un prototipo de un motor de búsqueda a gran escala quehace un uso intensivo de la estructura presente en el hipertexto. Google está diseñado pararastrear e indexar la Web de manera eficiente y producir resultados de búsqueda mucho mássatisfactoria que los sistemas existentes. El prototipo, con un texto completo y base de datos deenlace de al menos 24 millones de páginas se encuentra disponible enhttp://google.stanford.edu/

Para diseñar un motor de búsqueda es una tarea difícil. Los motores de búsqueda índice dedecenas a cientos de millones de páginas web que involucran un número comparable detérminos distintos. Responden a decenas de millones de consultas cada día. A pesar de laimportancia de los motores de búsqueda a gran escala en la web, la investigación académicamuy poco se ha hecho en ellos. Además, debido al rápido avance de la tecnología y laproliferación de Internet, la creación de un motor de búsqueda en la Web hoy en día es muydiferente de hace tres años. Este documento proporciona una descripción en profundidad denuestro gran motor de búsqueda en la web - la primera descripción detallada del público comosabemos de la fecha.

Aparte de los problemas de técnicas de escalamiento de búsqueda tradicionales a los datos de

esta magnitud, hay nuevos desafíos técnicos relacionados con el uso de la presente informaciónadicional en hipertexto para producir mejores resultados de búsqueda. Este artículo aborda lacuestión de cómo construir una práctica a gran escala del sistema que se puede explotar lapresente información adicional en el hipertexto. También nos fijamos en el problema de cómohacer frente eficazmente a las colecciones de hipertexto sin control en el que cualquiera puedepublicar cualquier cosa que quieran.Palabras clave: World Wide Web, motores de búsqueda, recuperación de información, el

PageRank, Google

1. INTRODUCCIÓN

(Nota: Hay dos versiones de este documento, una versión más completa y una versión máscorta impresa La versión completa está disponible en la web y la conferencia de CD-ROM.).La web crea nuevos retos para la recuperación de información. La cantidad de información en lared está creciendo rápidamente, así como el número de nuevos usuarios inexpertos en el arte dela investigación de la tela. La gente tiende a navegar por la web utilizando su grafo, comenzandoa menudo con humanos de alta calidad índices mantenidos como Yahoo! o con los motores debúsqueda. Humanos listas mantenidas cubren temas populares con eficacia, pero sonsubjetivas, son caros de construir y mantener, tardo para mejorar, y no puede cubrir todos lostemas esotéricos. Motores de búsqueda automatizados que dependen de la concordancia depalabras clave suelen volver partidos de baja calidad, demasiadas. Para empeorar las cosas,



algunos anunciantes tratan de llamar la atención de las personas mediante la adopción demedidas destinadas a engañar a los motores de búsqueda automatizados. Hemos construido unmotor de búsqueda a gran escala que aborda muchos de los problemas de los sistemasexistentes. Se hace un uso especialmente intensivo de la actual estructura adicional en elhipertexto para proporcionar resultados de búsqueda mucho más altos de calidad. Elegimos elnombre de nuestra sistema, Google, porque es una ortografía común de googol, o 10.100 yencaja perfectamente con nuestro objetivo de construir a muy gran escala los motores de

búsqueda.

1.1Web Search Engines - la ampliación de escala: desde 1994 hasta 2000

La tecnología de motores de búsqueda ha tenido que reducir drásticamente para mantenerseal día con el crecimiento de la web. En 1994, uno de los primeros motores de búsqueda web,el gusano de la World Wide Web (wwww) [McBryan 94] tuvo un índice de 110.000 páginasweb y documentos web accesibles. A partir de noviembre de 1997, los principales motores debúsqueda afirman índice de 2 millones de dólares (WebCrawler) a 100 millones dedocumentos web (de Search Engine Watch). Es previsible que en el año 2000, un índiceexhaustivo de la web contendrá más de mil millones de documentos. Al mismo tiempo, elnúmero de consultas de búsqueda motores mango ha crecido increíblemente demasiado. Enmarzo y abril de 1994, el gusano de la World Wide Web recibió una media de cerca de1500 consultas por día. En noviembre de 1997, AltaVista afirmóque maneja aproximadamente 20 millones de consultas por día. Con el creciente númerode usuarios en la web y los sistemas automatizados que consultan los motores debúsqueda, es probable que los principales motores de búsqueda se encargará de cientos demillones de consultas diarias en el año 2000. El objetivo de nuestro sistema es hacer frente

a muchos de los problemas, tanto en la calidad y capacidad de ampliación, presentado por latecnología del motor de búsqueda de escala a un número tan extraordinarios.

1,2. Google: Ampliación de la Web

Creación de un motor de búsqueda que las escalas, incluso a la web de hoy presenta muchosdesafíos. La tecnología de rastreo rápido y es necesario para reunir los documentos web ymantenerlos al día. El espacio de almacenamiento debe ser utilizado eficientemente paraalmacenar índices y, opcionalmente, los propios documentos. El sistema de indexación debe

procesar cientos de gigabytes de datos de manera eficiente. Las consultas deben sermanipuladas rápidamente, a una velocidad de cientos de miles por segundo.Estas tareas son cada vez más difícil, ya que la web crece. Sin embargo, el rendimiento delhardware y el coste han mejorado considerablemente para compensar en parte ladificultad. Hay, sin embargo, varias excepciones notables a este progreso, como un discoTiempo de búsqueda y la robustez del sistema operativo. En el diseño de Google, se haconsiderado tanto la tasa de crecimiento de la Web y los cambios tecnológicos. Google estádiseñado para escalar así a los conjuntos de datos extremadamente grandes. Se hace un usoeficiente del espacio de almacenamiento para almacenar el índice. Sus estructuras de datosestán optimizados para un acceso rápido y eficiente (ver sección 4.2). Además, 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 (véase el Apéndice B). Esto dará lugar a propiedades deescala favorables para sistemas centralizados como Google.

1.3 Objetivos del diseño

1.3.1 Calidad de Búsqueda mejorada

Nuestro objetivo principal es mejorar la calidad de los motores de búsqueda web. En 1994,algunas personas creían que un índice de búsqueda completo haría posibleencontrar cualquier cosa fácilmente. De acuerdo con lo mejor de la Web 1994 -Navegantes, "El mejor servicio de navegación debe hacer que sea fácil encontrar casicualquier 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 búsquedarecientemente, fácilmente pueden dar testimonio de que la integridad del índice no es el únicofactor en la calidad de los resultados de búsqueda. "Los resultados de basura" amenudo vaciar los resultados que un usuario está interesado pulg De hecho, a partirde noviembre de 1997, sólo uno de los cuatro principales motores de búsqueda

comerciales se encuentra (devuelve su propia página de búsqueda en respuesta a sunombre en el top ten resultados). Una de las principales causas de este problema es que elnúmero de documentos en los índices ha aumentado en muchos órdenes demagnitud, pero la capacidad del usuario para ver los documentos no tiene. La gentetodavía sólo está dispuesta a ver las primeras decenas de resultados. Debido a esto, ya queel tamaño de la colección crece, necesitamos herramientas que tienen una precisión muyalta (número de documentos relevantes devueltos, por ejemplo en lostop ten de losresultados). De hecho, queremos que nuestra noción de "relevante" para incluir sólo losdocumentos de mejores ya que puede haber decenas de miles de

documentos poco relevantes. Esta tecnología de alta precisión es importante, incluso aexpensas de la memoria (el número total de documentos pertinentes del sistema es capaz devolver). Hay un poco de optimismo reciente de que el uso de másinformación hipertextual puede ayudar a mejorar la búsqueda y otras aplicaciones[Marchiori 97] [Spertus 97] [Weiss 96] [Kleinberg 98]. En particular, la estructura deenlace, [Página 98] y de enlaces de texto proporcionan una gran cantidad de información parahacer juicios de relevancia y filtrado de calidad. Google hace uso de la estructura de enlacede ambos y el ancla de texto (véanse las secciones 2.1 y 2.2).

1.3.2 Academic Search Engine Investigación-Academia de búsqueda del motor deinvestigación

Aparte de un gran crecimiento, la Web también se ha convertido cada vez más comercial através del tiempo. En 1993, el 1,5% de los servidores web estaban en los dominios.Com. Este número creció a más del 60% en 1997. Al mismo tiempo, los motores de búsquedahan migrado desde el ámbito académico a la comercial. Hasta ahora la mayor parte deldesarrollo motor de búsqueda ha ido a las empresas con pequeña publicación de los detallestécnicos. Esta búsqueda de las causas de la tecnología de motores siguen siendo en granmedida un arte negro y de ser orientado a la publicidad (ver Apéndice A). Con Google,

tenemos un objetivo fuerte para impulsar un mayor desarrollo y comprensión en el ámbitoacadémico.



Otro objetivo importante del diseño fue la de construir los sistemas que un número razonablede personas que realmente puede utilizar. El uso era importante para nosotros porquecreemos que algunas de las investigaciones más interesantes implicarán aprovechar la grancantidad de datos de uso que está disponible en los sistemas web modernos. Por ejemplo,hay muchas decenas de millones de búsquedas realizadas cada día. Sin embargo, es muydifícil obtener estos datos, principalmente porque se considera comercialmente valioso.

Nuestro objetivo de diseño final fue la de construir una arquitectura que pueda apoyar lasactividades de investigación sobre nuevos datos de la web a gran escala. Para apoyar lainvestigación nuevos usos, Google almacena todos los documentos reales que se arrastra enforma comprimida. Uno de nuestros objetivos principales en el diseño de Google fue lacreación de un entorno en el que otros investigadores pueden llegar rápidamente, procesargrandes porciones de la web, y producir resultados interesantes que habría sido muy difícil deproducir de otra manera. En el poco tiempo que el sistema ha estado funcionando, ya hahabido varios trabajos que utilizan bases de datos generadas por Google, y muchos otrosestán en marcha. Otro de los objetivos que tenemos es la creación de un entorno delaboratorio espacial Spacelab-como el que los investigadores e incluso los estudiantespueden proponer y realizar experimentos interesantes en nuestros datos de la web a granescala.

2. CARACTERÍSTICAS DEL SISTEMA

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

lugar, Google utiliza enlaces para mejorar los resultados de búsqueda.

2.1 PageRank: poner orden en la Web

La cita (enlace) el gráfico de la web es un recurso importante que ha desaparecido en granmedida no utilizada en los actuales motores de búsqueda web. Hemos creado mapas quecontienen hasta 518 millones de estos enlaces, una muestra significativa del total. Estosmapas permiten el cálculo rápido de "PageRank" de una página web, una medida objetivade la importancia de la citación que se corresponde bien con la idea subjetiva de laspersonas de importancia. Debido a esta correspondencia, el PageRank es una excelente

manera de dar prioridad a los resultados de las búsquedas de palabrasclave web. Para temas más populares, un texto simple juego de búsqueda que se limita alos títulos de las páginas web se desempeña admirablemente cuando PageRank prioriza losresultados (demo disponible en google.stanford.edu). Para el tipo de búsquedas de textocompleto en el sistema principal de Google, PageRank también ayuda mucho.

2.1.1 Descripción de cálculo de PageRank

La literatura cita académica se ha aplicado a la web, en gran parte por contar las citas olos vínculos de retroceso a una página determinada. Esto da una aproximación de laimportancia de una página o la calidad. PageRank se extiende esta idea al no contarlos

enlaces de todas las páginas por igual, y por la normalización por el número de enlaces enuna página. PageRank se define como sigue:



Asumimos la página A. Tiene páginas T1... Tn que apuntan a la misma (es decir, son lascitas) El parámetro d es un factor de amortiguamiento que se puede establecer entre 0 y1. Por lo general, establecer d a 0,85. Hay más detalles sobre d en la siguientesección. También C (A) se define como el número de enlaces que salen dela página A. ElPageRank de una página A se da como sigue:PR (A) = (1-d) + d (PR (T1) / C (T1) + ... + PR (Tn) / C (Tn))

Tenga en cuenta que el PageRank formar una distribución de probabilidad sobre las páginasweb, por lo que la suma de todas las páginas web PageRank 'será uno.

PageRank o PR (A) se puede calcular utilizando un sencillo algoritmo iterativo, y correspondeal auto vector principal de la matriz enlace normalizado de la banda. Además, unPageRank de 26 millones de páginas web se puede calcular en unas pocas horas enuna estación de trabajo de tamaño medio. Hay muchos otros detalles que están fueradel alcance de este documento.

2.1.2 Justificación intuitiva

PageRank puede ser considerado como un modelo de comportamiento del usuario.Suponemos que hay un "navegante aleatorio" que se le da una página web al azar y semantiene a hacer clic en enlaces, no golpear "de vuelta", pero finalmente se aburre yempieza en otra página al azar. La probabilidad de que el internauta visita una página alazar es su PageRank. Y, el factor de amortiguamiento d es la probabilidad en cada páginade la "persona que practica surf al azar" se aburrirá y pedir otra página al azar. Una variaciónimportante es añadir sólo el factor de amortiguamiento d en una sola página, o un grupode páginas. Esto permite la personalización y puede hacer que sea casi imposible paraengañar deliberadamente al sistema a fin de obtener un ranking más alto. Tenemosvarias otras extensiones de PageRank, una vez más ver [Página 98].Otra justificación intuitiva es que una página puede tener un PageRank alto, si hay muchaspáginas que apuntan a la misma, o si hay algunas páginas que apuntan a ella y tiene unPageRank alto. Intuitivamente, las páginas que están bien citados en muchoslugares alrededor de la web que vale la pena mirar. Además, las páginas que tienen tal vezsólo una cita de algo parecido a la página principal de Yahoo! Son también, en general vale lapena mirar. Si una página no es de alta calidad, o era un vínculo roto, es muy probable quela página de inicio de Yahoo no se uniría a él. PageRank maneja ambos casos, y todo lodemás de forma recursiva la propagación de pesos a través de la estructura de enlaces de laweb.

2.2 Anclaje de texto

El texto de los enlaces es tratado de una manera especial en nuestro motor de búsqueda. Lamayoría de los motores de búsqueda de asociar el texto de un vínculo con la página queel enlace está encendida. Además, lo asociamos con la página el enlace apunta. Esto tienevarias ventajas. En primer lugar, anclas a menudo proporcionan descripciones más exactasde las páginas web que las propias páginas. En segundo lugar, pueden existir anclajes paralos documentos que no pueden ser indexados por un texto basado en el motor de búsqueda,como imágenes, programas y bases de datos. Esto hace que sea posible volver laspáginas webs a las que en realidad no han sido rastreadas. Nótese que las páginas que no sehan rastreado pueden causar problemas, ya que nunca se comprueba su validez antes de serdevuelta al usuario. En este caso, el motor de búsqueda también puede devolver una página

que en realidad nunca existió, sino que los hipervínculos 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 página que se refiere a se llevó a cabo enel gusano de la World Wide Web [McBryan 94] sobre todo porque no ayuda a buscarinformación de texto, y amplía la cobertura de la búsqueda con menos documentosdescargados. Nuestro método de propagación de anclaje sobre todo porque el ancla detexto puede ayudar a proporcionar mejores resultados de calidad. El uso de texto deanclaje de manera eficiente es técnicamente difícil, debido a las grandes cantidades dedatos que deben ser procesados. En nuestro rastreo actual de 24millones depáginas, que contaba con más de 259 millones anclas que nos indexados.

2.3 Otras características

Aparte de PageRank y el uso del texto del ancla, Google tiene varias otras características. Enprimer lugar, tiene información sobre la ubicación de todos los éxitos y por lo que hace un usoextensivo de la proximidad en la búsqueda. En segundo lugar, Google realiza un seguimientode algunos detalles de la presentación visual, como el tamaño de la fuente de laspalabras. Las palabras en letra más grande o más audaces se ponderan más altoque palabras. HTML En tercer lugar, lleno prima de las páginas está disponible en unrepositorio.

3 TRABAJOS RELACIONADOS

La investigación Buscar en la web tiene una historia breve y conciso. El gusano de la WorldWide Web (wwww) [McBryan 94] fue uno de los primeros motores de búsqueda web. Lesiguió por varios otros motores de búsqueda académicos, muchos de los cuales son ahora lasempresas públicas. En comparación con el crecimiento de la Web y la importancia de losmotores de búsqueda hay muy pocos documentos sobre los últimos motores debúsqueda [Pinkerton 94]. De acuerdo con Michael Mauldin(científico en jefede Lycos Inc.) [Mauldin], "los diferentes servicios (incluyendo Lycos) guardan estrecha losdetalles de estas bases de datos". Sin embargo, ha habido una buena cantidad de trabajosobre las características específicas de los motores de búsqueda. Especialmente bienrepresentado es el trabajo que se pueden obtener resultados por el post-procesamiento de losresultados de los actuales motores de búsqueda comerciales, o producir a pequeñaescala "individualizada" motores de búsqueda. Por último, ha habido muchainvestigación sobre los sistemas de recuperación de información, sobre todoen colecciones bien controladas. En las dos secciones siguientes, se discuten algunas áreasen las que esta investigación debe ampliarse para trabajar mejor en la web.

3.1 Recuperación de la Información

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

bien desarrollado [Witten 94]. Sin embargo, la mayor parte de la investigación en sistemas derecuperación de información se encuentra en pequeñas colecciones homogéneas biencontroladas, tales como colecciones de artículos científicos o noticias sobre un temarelacionado. De hecho, la referencia fundamental para la recuperación de información, laConferencia de recuperación de textos [TREC 96], utiliza un bastante pequeño, lacolección bien controlada por sus puntos de referencia. El "Corpus Muy Grande" punto dereferencia es sólo de 20 GB 147 GB en comparación con el de nuestro rastreo de 24 millonesde páginas web. Las cosas que funcionan bien en TREC a menudo no producen buenosresultados en la web. Por ejemplo, el modelo de espacio vectorial estándar intenta devolver

el documento que más se aproxima a la consulta, dado que tanto la consulta y eldocumento son vectores definidos por su ocurrencia palabra. En la web, esta estrategia a



menudo, se mostrarán documentos muy cortos que son la consulta, más unas cuantaspalabras. Por ejemplo, hemos visto un importante motor de búsqueda devuelve unapágina que contiene sólo "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 precisión lo quequieren y añadir más palabras a su consulta. No estamos de acuerdo con esta posición convehemencia. Si un usuario realiza una consulta como "Bill Clinton" deben obtenerresultados razonables, ya que hay una enorme cantidad de información de alta

calidad disponible sobre este tema. Teniendo en cuenta ejemplos como estos, creemos que eltrabajo de recuperación de información estándar debe ampliarse para abordar con eficacia laweb.

3.2 Diferencias entre la Web y colecciones bien controladas

La web es una vasta colección de documentos heterogéneos totalmente incontrolados. Losdocumentos en la web tienen una variación extrema interna de los documentos, y también enla meta-información externa que pueda estar disponible. Por ejemplo, los documentos difiereninternamente en su idioma (tanto humanos como de programación), vocabulario (direccionesde correo electrónico, enlaces, códigos postales, números de teléfono, números de producto),el tipo o el formato (texto, HTML, PDF, imágenes, sonidos), y puede incluso ser generada pormáquina (archivos de registro o de salida a partir de una base de datos). Por otro lado,definimos meta información externa como la información que puede deducirse de undocumento, pero no está contenido dentro de ella. Ejemplos de meta-información externaincluyen cosas como la reputación de la fuente, la frecuencia de actualización, calidad,popularidad o uso, y las citas. No sólo son las posibles fuentes de información de la metaexterna variadas, pero las cosas que están siendo medidos varían muchos órdenes demagnitud también. Por ejemplo, comparar la información sobre el uso de una página

importante, al igual que Yahoo, que en la actualidad recibe millones de visitas todos los díascon un artículo oscuro histórico que podría recibir una consulta cada diez años. Es evidenteque estos dos temas deben ser tratados de manera muy diferente por un motor de búsqueda.Otra gran diferencia entre la web y tradicionales colecciones bien controladas es quevirtualmente no hay control sobre lo que la gente puede poner en la web. Pareja de estaflexibilidad para publicar cualquier cosa con la enorme influencia de los motores de búsquedapara enrutar el tráfico y las empresas que, deliberadamente, la manipulación de los motoresde búsqueda con fines de lucro convertido en un problema grave. Este problema de que no seha abordado en los tradicionales sistemas cerrados de recuperación de información. Además,

es interesante notar que los esfuerzos de metadatos han fracasado en gran medida con losmotores de búsqueda en la Web, ya que cualquier texto en la página que no estádirectamente representado para el usuario se abusa de manipular los motores debúsqueda. Hay numerosas empresas, incluso que se especializan en la manipulación de losmotores de búsqueda con fines de lucro.

4 SISTEMA DE ANATOMÍA

En primer lugar, se proporcionará una discusión de alto nivel de la arquitectura. Entonces,hay algunas descripciones en profundidad de las estructuras de datos importantes. Por

último, las aplicaciones principales: Rastreo, indexación y búsqueda será examinadoen profundidad.



4.1 Google Descripción de la Arquitectura

En esta sección, vamos a dar una visión general de alto nivel de cómo el sistema funcionacomo se muestra en la Figura 1. Otras secciones discutiremos las aplicaciones y estructurasde datos que no se mencionan en esta sección. La mayor parte de Google está implementadoen C o C + + de eficiencia y puede correr en Solaris o Linux.En Google, el rastreo web (descarga de páginas web) se lleva a cabo por varios crawlers

distribuidos. Hay una URLserver que envía listas de URLs que se debe buscar a losrastreadores. Las páginas web que se buscan, se envían a la store server. El store servercomprime y almacena las páginas Web en un repositorio. Cada página web tiene un númerode identificación asociado denominado docID que se le asigna una nueva dirección URL cadavez que se analiza de una página web. La función de indexación se realiza por el indexador yel 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 deocurrencias de palabras llamado hits. Los éxitos grabar la palabra, la posición en eldocumento, una aproximación del tamaño de la fuente, y la capitalización. El indexadordistribuye estos aciertos en una serie de "barriles", la creación de un índice parcialmenteordenados hacia adelante. El indexador lleva a cabo otra función importante. Analiza todos losenlaces en cada página web y almacena información importante sobre los mismos en unfichero de anclas. Este archivo contiene información suficiente para determinar que cadaenlace 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 absolutasy, a su vez en docIDs. Se pone el texto de anclaje en el índice hacia adelante, asociado con eldocID que el ancla apunta. También genera una base de datos de enlaces que son pares dedocIDs. 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 unasimplificación, véase la Sección 4.2.5), y centros turísticos de ellos wordID para generar elíndice invertido. Esto se hace en lugar de modo que el espacio temporal que se necesita pocopara esta operación. El clasificador produce también una lista de wordIDs y compensacionesen el índice invertido. Un programa llamado DumpLexicon toma esta lista junto con el léxicoproducido por el indexador y genera un nuevo léxico para ser utilizado por el buscador. Elbuscador está dirigido por un servidor web y usa el léxico 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 colección dedocumentos de gran tamaño puede ser rastreado, indexado, y buscó con poco costo. A pesarde que las CPU y las tasas de insumo-producto a granel han mejorado dramáticamente en losúltimos años, un disco de buscar aún requiere alrededor de 10 ms paracompletar. Google está diseñado para evitar búsquedas en disco siempre que sea posible, yesto ha tenido una influencia considerable en el diseño de las estructuras de datos.



4.2.1 BigFiles-grandes archivos

BigFiles son archivos virtuales que abarcan múltiples sistemas de archivos y sondireccionables por enteros de 64 bits. La asignación de los múltiples sistemas de archivos serealiza automáticamente. El paquete BigFiles también se encarga de la asignación yliberación de los descriptores de archivo, ya que los sistemas operativos noproporcionan suficiente para nuestras necesidades. BigFiles también apoyan las opciones de

compresión rudimentarios.

4.2.2 Repositorio

El repositorio contiene todo el HTML de cada página web. Cada página es comprimidausando zlib (ver RFC1950). La elección de la técnica de compresión es un equilibrio entre lavelocidad y relación de compresión. Elegimos zlib de velocidad sobre una mejorasignificativa en la compresión ofrecida por bzip. La tasa de compresión de bzip fue deaproximadamente 4 a 1 en el depósito en comparación con los zlib 3 a 1 de compresión. Enel depósito, se almacenan los documentos uno tras otro y tienen el prefijo docID, longitudy URL como puede verse en la Figura 2. El repositorio no requiere otras estructuras dedatos que se utilizarán con el fin de acceder a él. Esto ayuda a la consistencia de los datos yhace mucho más fácil el desarrollo, podemos reconstruir todas las otras estructuras dedatos de sólo el repositorio y un archivo que lista los errores de cadenas.

4.2.3 Índice de documentos

El índice de documento mantiene la información sobre cada documento. Se trata de un anchofijo ISAM (modo de índice de acceso secuencial) de índice, ordenado por docID. La

información almacenada en cada entrada incluye el estado actual del documento, unpuntero en el repositorio, un checksum de documentos y estadísticas varias. Si eldocumento se ha rastreado, también contiene un puntero a un archivo de ancho variablellamada DOCINFO que contiene la dirección URL y el título. De lo contrario elpuntero apunta a la URL list que sólo contiene la dirección URL. Esta decisión de diseño fueimpulsado por el deseo de tener una estructura de datos razonablemente compacto y lacapacidad para buscar un registro en un disco de buscar durante un registroAdemás, hay un archivo que se utiliza para convertir URLs en docIDs. Se trata de una listade sumas de comprobación de URL con sus correspondientes docIDs y está ordenada

por checksum. Con el fin de encontrar el docID de una URL concreta, de suma decomprobación de la URL se calcula y una búsqueda binaria se realiza en el archivo de lassumas de comprobación para encontrar su docID. URL se puede convertiren docIDs en lotes haciendo una fusión con este archivo. Esta es la técnica de la URLresolver utiliza para convertir las URL en docIDs. Este modo de proceso porlotes de actualización es crucial, porque de lo contrario, debe realizar una búsqueda de todoslos eslabones que asumir un disco tomaría más de un mes para nuestra base de datos enlacede 322 millones.

4.2.4 Léxico

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



que el léxico puede caber en la memoria por un precio razonable. En la implementaciónactual podemos mantener el léxico en la memoria en una máquina con256 MB de memoriaprincipal. El léxico actual contiene 14 millones de palabras(aunque algunas palabras raras nose han añadido al léxico). Se lleva a cabo en dos partes: una lista de laspalabras (concatenadas pero separadas por nulos) y una tabla hash de punteros. Para lasdiversas funciones, la lista de palabras tiene alguna información auxiliar que está más 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 enun documento en particular incluyendo la posición, la fuente y la información decapitalización. Listas de golpe en cuenta para la mayor parte del espacio utilizado tanto en elavance y los índices invertidos. Debido a esto, es importante que ellos representen taneficientemente como sea posible. Se consideraron varias alternativas para la posición de lacodificación, la fuente, y la capitalización - la codificación simple (un triple de enteros), unacodificación compacta (con una asignación optimizada de la mano bits) y Huffman. Al final seoptó por un lado optimizar la codificación compacta, ya que requiere mucho menos espacioque la codificación simple y mucho menos la manipulación de bits de codificación deHuffman. Los detalles de los accesos se muestran en la Figura 3.Nuestra codificación compacta usa dos bytes por cada golpe. Hay dos tipos de resultados:golpes de fantasía y golpes simples. Golpes de fantasía incluyen éxitos que ocurren en unadirección URL, el título, el ancla de texto, o etiqueta meta. Accesos simples incluyen todo lodemás. Un golpe normal se compone de varios pedazos de bits de capitalización, tamaño defuente, y 12 de posición de la palabra en un documento (todas las posiciones superiores a4095 se etiquetan 4096). Tamaño de la fuente se representa en relación con el resto del

documento usando tres bits (sólo el 7 valores se utilizan realmente, porque 111 es la banderaque señala un golpe de fantasía). Un golpe de lujo se compone de un poco de capitalización,el tamaño de fuente establece en 7 para indicar que es un golpe de lujo, 4 bits para codificarel tipo de golpe de fantasía, y 8 bits de posición. Para visitas de anclaje, los 8 bits de posiciónse dividen en 4 bits para la posición de anclaje y los bits 4 a un hash de la docID el anclaaparece pulg Esto nos da una frase de búsqueda limitada, siempre y cuando no hay muchosque las anclas para un palabra en particular. Esperamos actualizar la forma en que sealmacenan los accesos de anclaje para permitir una mayor resolución en la posición y loscampos de docIDhash. Usamos el tamaño de fuente en relación con el resto del documento,

porque cuando se busca, no desea clasificar los documentos por lo demás idénticos demanera diferente sólo porque uno de los documentos se encuentra en un tipo de letra másgrande.

La longitud de una lista de resultados se almacena antes de los propios éxitos. Para ahorrarespacio, la longitud de la lista de resultados se combina con la wordID en el índice haciaadelante y la docID en el índice invertido. Esto lo limita a 8 y 5, respectivamente, los bits (hayalgunos trucos que permiten 8 bits para ser tomado de la wordID). Si la longitud es mayor queencajaría en que muchos bits, un código de escape se utiliza en esos bits, y los siguientes dosbytes contienen la longitud real.



4.2.6 Índice de Avance

El índice de avance es en realidad ya está parcialmente ordenados. Se almacena enun número 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 elbarril, seguido por una lista de wordID con listas de resultados que se correspondencon aquellas palabras. Este esquema requiere un poco más de almacenamiento debido a

la duplicación de docIDs pero la diferencia es muy pequeña para un número razonablede cubos y ahorra un tiempo considerable y la complejidad de la codificación en la fase finalde la indexación realizada por la clasificadora. Por otra parte, en lugar dealmacenar wordID real es, almacenamos todos los wordID como una diferencia relativa dela wordID mínimo que entra en el cañón del wordID es pulg De esta manera, se puedeutilizar sólo 24 bits para el wordID está en los barriles sin ordenar, dejando 8 bits para lalongitud de la lista de resultados.

4.2.7 índice invertido

El índice invertido consiste en los barriles mismo que el índice hacia adelante, excepto quehan sido procesados por el clasificador. Por cada wordID válido, el léxico contiene unpuntero en el cañón que cae en wordID. Apunta a un DocList de docID, junto con sus listas deresultados correspondientes. Este DocList representa a todas las ocurrencias de esapalabra en todos los documentos.Una cuestión importante es en qué orden el docID debe aparecer en el DocList. Una soluciónsimple es almacenarlos clasificados por docID. Esto permite la rápida fusiónde DocLists diferentes para las consultas de varias palabras. Otra opción consiste enalmacenar los ordenados por una clasificación de la aparición de la palabra en cada

documento. Esto hace que responder a una consulta de palabras trivial y hace que seaprobable que las respuestas a las preguntas de varias palabras están cerca de la salida. Sinembargo, la fusión es mucho más difícil. Además, esto hace que el desarrollo mucho másdifícil en que un cambio en la función de clasificación requiere una reconstrucción delíndice. Hemos elegido una solución de compromiso entre estas dosposibilidades, mantener dos conjuntos de barriles invertidos: un juego para las listasde éxitos que incluyen títulos 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 nohay coincidencias suficientes dentro de los barriles que ver los más grandes.

4.3 Rastreo de la web

Ejecución de un rastreador web es una tarea difícil. Hay desempeño difícil y los problemas deconfiabilidad y aún más importante, hay cuestiones sociales. El gateo es la aplicación másconsolidada, ya que implica interactuar con cientos de miles de servidores web y servidoresde nombres de varios que están todos fuera del control del sistema.Con el fin de escalar a cientos de millones de páginas web, Google dispone de un rápidosistema de distribución de rastreo. Una sola URLserver sirve listas de URLs a un número deorugas (que normalmente corrían 3). Tanto el URLserver y los rastreadores están

implementados en Python. Cada rastreador mantiene alrededor de 300 conexiones abiertas ala vez. Esto es necesario para recuperar las páginas web a un ritmo lo suficientemente



rápido. A velocidades máximas, el sistema puede rastrear más de 100 páginas web porsegundo por medio de cuatro orugas. Esto equivale a alrededor de 600K por segundo dedatos. Un esfuerzo importante es el rendimiento de búsqueda de DNS. Cada crawlermantiene una caché de su propio DNS para que no se necesita hacer una búsqueda de DNSantes de rastrear cada documento. Cada uno de los cientos de conexiones puede estar en unnúmero de estados diferentes: en busca de DNS, la conexión al host, enviando petición yrecibir la respuesta. Estos factores hacen que el rastreador un componente complejo del

sistema. Utiliza S asíncrona para gestionar eventos, y un número de colas para pasar lapágina obtiene a partir de un estado a otro.

Resulta que la ejecución de un rastreador que conecta a más de medio millón de servidores, ygenera decenas de millones de entradas en el registro genera una buena cantidad dellamadas de correo electrónico y teléfono. Debido a la gran cantidad de personas que vienenen línea, siempre hay aquellos que no saben lo que es un rastreador, ya que este es elprimero que han visto. Casi todos los días, recibimos un correo electrónico algo como, "Wow,que daba a un montón de páginas de mi sitio web. ¿Cómo te gusta?" También hay algunaspersonas que no conocen el protocolo de exclusión de robots, y piensan que su página debeser protegido de la indexación de una declaración como, "Esta página está protegido porcopyright y no debe ser indexada", lo que hace falta decir que es difícil para los rastreadoresweb de entender. Además, debido a la enorme cantidad de datos involucrados, las cosasinesperadas que sucederán. Por ejemplo, nuestro sistema ha intentado rastrear un juego enlínea. Esto dio lugar a un montón de mensajes basura en el centro de su juego! Resulta queeste era un problema fácil de solucionar. Pero este problema no se había acercado hasta quese había descargado decenas de millones de páginas. Debido a la inmensa variación en laspáginas web y los servidores, es prácticamente imposible de probar un rastreador, sinejecutarlo en gran parte de la Internet. Invariablemente, hay cientos de problemas oscuros

que sólo pueden ocurrir en una página de toda la red y hacer que el rastreador se bloquee, opeor aún, provocar un comportamiento impredecible o incorrecto. Sistemas que tienen accesoa gran parte de la Internet deben ser diseñados para ser muy robusto y probadocuidadosamente. Desde los grandes sistemas complejos, tales como rastreadores a causarproblemas, es necesario que haya recursos importantes dedicados a la lectura del correoelectrónico y la solución de estos problemas a medida que surgen.

4.4 de indexación de la Web

Análisis - Cualquier analizador, que está diseñado para ejecutarse en toda la Web debemanejar una enorme variedad de posibles errores. Estos van desde errores en etiquetasHTML para kilobytes de ceros en el medio de una etiqueta, los caracteres no ASCII, etiquetasHTML anidadas cientos de profundidad, y una gran variedad de otros errores que laimaginación de cualquiera de desafío para llegar a otros igualmente creativos. Para la máximavelocidad, en lugar de utilizar YACC para generar un analizador de CFG, que utilizar flex paragenerar un analizador léxico que traje con su propia pila. El desarrollo de este analizador quefunciona a una velocidad razonable y es muy robusto implicados una buena cantidad detrabajo.La indexación de documentos en barriles - Después de cada documento se analiza, secodifica en una serie de barriles. Cada palabra se convierte en una wordID mediante el uso deuna tabla hash en memoria - en el léxico. Las nuevas adiciones a la tabla hash léxico se



registra en un archivo. Una vez que las palabras se convierten en wordID, sus ocurrencias enel documento actual se traducen en listas de ataque y se escriben en los barriles haciaadelante. La principal dificultad con la paralelización de la fase de indexación es que el léxicodebe ser compartido. En lugar de compartir el léxico, tomamos el enfoque de la escritura deun registro de todas las palabras adicionales que no estaban en un léxico de base, que se fijaen 14 millones de palabras. De esta forma múltiples indexadores pueden ejecutarse enparalelo y luego el archivo de registro pequeño de palabras adicionales pueden ser

procesados por un indexador final.Clasificación - Para generar el índice invertido, el clasificador toma cada uno de los barrileshacia adelante y la ordena por wordID para producir un barril invertido por sus lanzamientosde títulos y un ancla y un barril texto completo invertido. Este proceso tiene lugar un barril a lavez, lo que requiere el almacenamiento temporal pequeño. También, en paralelo la fase declasificación para usar tantas máquinas como tenemos simplemente mediante la ejecución declasificadores múltiples, que pueden procesar cubos diferentes al mismo tiempo. Dado que losbarriles no se ajustan a la memoria principal, el clasificador de ellas se subdivide en máscanastas que caben en la memoria sobre la base de wordID y docID. A continuación, elclasificador, se carga cada canasta en la memoria, lo ordena y escribe su contenido en elcañón corto invertida y el barril invertido por completo.

4.5 Búsqueda

El objetivo de la búsqueda es para proporcionar resultados de búsqueda de calidad demanera eficiente. Muchos de los grandes motores de búsqueda comercial les parecíahaber hecho un gran progreso en términos de eficiencia. Por lo tanto, nos hemoscentrado más en la calidad de la búsqueda en nuestra investigación, aunque creemosque nuestras soluciones son escalables a los volúmenes comerciales con un esfuerzo unpoco más. La consulta de google proceso de evaluación 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 cañón corto para cada palabra.4. Analizar a través de los doclists hasta que haya un documento que coincide contodos los términos de búsqueda.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 dela 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 partesuperior.

Para poner un límite en el tiempo de respuesta, una vez que un cierto número(actualmente 40.000) de los documentos correspondientes se encuentran, el buscadorautomáticamente va al paso 8 en la Figura 4. Esto significa que es posible que sub-óptimos resultados se devuelva. Actualmente estamos investigando otras maneras deresolver este problema. En el pasado, hemos ordenado los accesos de acuerdo aPageRank,que parecía mejorar la situación.



4.5.1 El sistema de clasificación

Google mantiene mucha más información sobre documentos web que los motores debúsqueda habituales. Cada lista negra incluye la posición, la fuente y la información decapitalización. Además, tenemos en cuenta los éxitos de texto del ancla y el PageRank deldocumento. La combinación de toda esta información en un rango es difícil. Hemos diseñadonuestra función de ranking para que ningún factor en particular puede tener demasiadainfluencia. En primer lugar, consideremos el caso más simple - una consulta sola palabra. Con

el fin de clasificar un documento con una consulta sola palabra, Google mira a lista deresultados de ese documento para esa palabra. Google considera cada hit a ser uno de variostipos (título, ancla, dirección, tipo de letra grande de texto sin formato, tipo de letra pequeñotexto sin formato, ...), cada una de ellas tiene su propio tipo de peso. Los de tipo pesosconstituyen un vector indexado por el tipo. Google cuenta el número de visitas de cada tipo enla lista de resultados. Entonces, cada recuento se convierte en un recuento de peso. Contarlos pesos aumentan linealmente con la cuenta en el primer cono, pero rápidamente de modoque más que un recuento de algunos no ayuda. Nos tomamos el producto escalar del vectorde conteo de los pesos con el vector de pesos de tipo para calcular una puntuación de IR parael documento. Por último, la puntuación IR se combina con PageRank para dar un últimorango al documento.

Para realizar una búsqueda de varias palabras, la situación es más complicada. Ahora variaslistas de éxitos deben ser escaneados a través a la vez, para que se produzcan golpes juntosen un documento que se ponderan más alto que se produzcan accesos separados. Los éxitosde las listas de éxitos múltiples se combinan de tal manera que éxitos cercanos secorresponden entre sí. Por cada juego completo de visitas, una proximidad se calcula. Laproximidad se basa en la distancia entre los accesos se encuentran en el documento (oanclaje), pero se clasifica en 10 valores diferentes "contenedores" que van desde un partidode la frase de "ni siquiera está cerca". Los recuentos se calcula no sólo para cada tipo degolpe, sino de todo tipo y de proximidad. Cada tipo y un par de proximidad tiene un tipo deproximidad de peso. Las cuentas se convierten en cuentas de diez pesos y nos tomamos elproducto escalar de la cuenta atrás de pesos y los de tipo de proximidad de pesos paracalcular una puntuación IR. Todos estos números y las matrices de todas se pueden mostrarcon los resultados de búsqueda que utilizan un modo de depuración especial. Estas pantallashan sido muy útiles en el desarrollo del sistema de clasificación.

4.5.2 Comentarios

La función de ranking tiene muchos parámetros como el tipo de pesos y los pesos deproximidad tipo. Descubrir los valores correctos para estos parámetros es algo así comoun arte negro. Para ello, contamos con un mecanismo de retroalimentación de los usuarios en

el motor de búsqueda. Un usuario de confianza, opcionalmente, pueden evaluar todos losresultados que se devuelven. Esta información se guarda. Luego, cuando modificamos lafunción de clasificación, podemos ver el impacto de este cambio en todas lasbúsquedas anteriores que fueron clasificados. Aunque lejos de ser perfecto, esto nos da unaidea de cómo un cambio en la función de clasificación afecta a los resultados de búsqueda.

5 RESULTADOS Y RENDIMIENTO

La medida más importante de un motor de búsqueda es la calidad de sus resultados debúsqueda. Si bien una evaluación completa de usuario está fuera del alcance de estetrabajo, nuestra propia experiencia con Google ha demostrado que para producir mejores

resultados que los principales motores de búsqueda comerciales para la mayoría de lasbúsquedas. Como un ejemplo que ilustra el uso de PageRank, texto ancla, y la proximidad, la



figura 4 muestra los resultados de Google para una búsqueda en "Bill Clinton". Estosresultados se muestran algunas de las características de Google. Los resultados seagrupan por el servidor. Esto ayuda considerablemente cuando tamizado a travésde conjuntos de resultados. Una serie de resultados son del dominio whitehouse.gov que es loque razonablemente se puede esperar de una búsqueda. En la actualidad, losmotores comerciales más importantes de la búsqueda no devuelve ningúnresultado de whitehouse.gov, y mucho menos los más adecuados. Tenga en cuenta que nohay título para el primer resultado. Esto se debe a que no se ha rastreado. En su

lugar, Google se basó en el texto de anclaje para determinar esto era una buena respuestaa la consulta. Del mismo modo, el resultado es un quinto dirección de correo electrónico que,por supuesto, no es rastreable. También es un resultado de texto de anclaje.

Todos los resultados son páginas de calidad razonablemente alta y, en últimacomprobación, no había ningún enlace roto. Esto es así porque todos ellos tienen unPageRank alto. El PageRank es el porcentaje en rojo, junto con gráficos de barras. Porúltimo, no hay resultados sobre un proyecto de ley que no sea Clinton o de otro que BillClinton. Esto se debe a que dan importancia pesado en la proximidad de las ocurrencias depalabras. Por supuesto una verdadera prueba de la calidad de un motor debúsqueda implicaría un estudio de usuarios extensos o el análisis 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 búsqueda, Google está diseñado para escalar rentable con el tamañode la Web a medida que crece. Un aspecto de esto es utilizar eficientemente elalmacenamiento. La Tabla 1 presenta un desglose de algunas estadísticas y requisitos dealmacenamiento de Google. Debido a la compresión del tamaño total del depósito esde 53 GB, un poco más de un tercio del total de datos que almacena. A losprecios actuales de disco esto hace que el depósito de una fuente relativamente baratade datos útiles. Más importante aún, el total de todos los datos utilizados por el motor debúsqueda requiere una cantidad comparable de almacenamiento, aproximadamente55 GB. Por otra parte, la mayoría de las preguntas se pueden contestar usando sólo el índiceinvertido corto. Con una mejor codificación y compresión del índice de documentos, unared de alta calidad motor de búsqueda puede caber en una unidad de 7GB de un nuevo PC.

5.2 Rendimiento del sistema

Es importante para un motor de búsqueda para rastrear e indexar de manera eficiente. Deesta manera la información se puede mantener hasta la fecha y los cambios importantes en el

sistema puede ser probado con relativa rapidez. Para Google, las principalesoperaciones se Rastreo, indexación y clasificación. Es difícil medir el tiempoque se arrastra en general porque los discos llenos, los servidores de nombres se estrelló, ocualquier número de otros problemas que dejaron el sistema. En total se llevaron alrededorde 9 días para descargar los 26 millones de páginas (incluidos los errores). Sin embargo, unavez que el sistema estaba funcionando sin problemas, corría mucho más rápido, la descargade los últimos 11 millones de páginas en tan sólo 63 horas, un promedio de poco más de4 millones de páginas al día, o 48.5páginas por segundo. Corrimos el indexador y elrastreador de forma simultánea. El indizador corrió solo más rápido que los rastreadores. Estoes así porque hemos pasado el tiempo suficiente optimizar el indexador de modo queno sería un cuello de botella. Estas optimizaciones incluyen actualizaciones masivas en el

índice de documentos y colocación de estructuras de datos críticos en el disco local. Elindizador se ejecuta en aproximadamente 54 páginas por segundo. Los clasificadores se

http://google.stanford.edu/






puede ejecutar completamente en paralelo, utilizando cuatro máquinas, todo el proceso deselección dura aproximadamente 24 horas.

TABLA 1Estadísticas de almacenamientoTamaño total de recuperados de Páginas--------------------147,8 GBRepositorio comprimido------------------------------------------ 53,5 GBÍndice de corto invertido------------------------------------------ 4,1 GBÍndice completo invertido----------------------------------------- 37,2 GBLexicon---------------------------------------------------------------- 293 MBLos datos provisionales de anclaje (no en total)----------- 6.6 GBDocumento Incluye índice. De ancho variable de datos-- 9,7 GBBase de datos------------------------------------------------------- 3.9 GBTotal sin depósito--------------------------------------------------- 5,2 GBTotal con depósito-------------------------------------------------- 108,7 GB

Página Web Estadísticas

Número de páginas web recuperados------------------------ 24 millonesNúmero de URLs visto-------------------------------------------- 76,5 millonesNúmero de Direcciones de correo electrónico-------------- 1700000Número de 404 's-------------------------------------------------- 1,6 millones

5.3 Buscador de rendimiento

Mejorar el rendimiento de la búsqueda no era el principal foco de nuestra investigación hastaeste punto. La versión actual de Google responde a la mayoría de las consultas de entre 1 y10 segundos. Esta vez es sobre todo dominado por S de disco a través de NFS (ya que losdiscos se distribuyen en un número de máquinas). Además, Google no tiene ningunaoptimización, tales como el almacenamiento en caché de consultas, los subíndices de lostérminos más comunes, y otras optimizaciones comunes. Tenemos la intención de acelerarGoogle considerablemente a través de la distribución y el hardware, software y mejorasalgorítmicas. Nuestro objetivo es ser capaz de manejar varios cientos de consultas porsegundo. La Tabla 2 tiene algunos tiempos de consulta de muestra de la versión actual deGoogle. Se repiten para mostrar las aceleraciones resultantes de caché IO.

TABLA 2

---------------------- Inicial de consultas----- misma consulta-----repetida (IO sobre todo encaché)Consulta ----------- tiempo de CPU (s) ------Tiempo total (s) -----tiempo de CPU (s)---Tiempototal (s)Al Gore -------------------- 0,09------------------------2,13---------------------- 0,06-----------------0,06vicepresidente -----------1,77-------------------------3,84----------------------- 1,66----------------1,80discos duros-------------- 0.25-------------------------4.86----------------------- 0.20----------------0.24motores de búsqueda---1,31-------------------------9,63----------------------- 1,16----------------1,16



6 CONCLUSIONES

Google está diseñado para ser un motor de búsqueda escalable. El objetivo principal esproporcionar alta calidad de los resultados de búsqueda en una red mundial de rápidocrecimiento amplio. Google emplea una serie de técnicas para mejorar la calidad de labúsqueda incluyendo fila de la página, el texto de anclaje, y la información de proximidad. Porotra parte, Google es una arquitectura completa de recogida de páginas web, la indexación

de ellos, y la realización de consultas de búsqueda por encima de ellos.

6.1 Trabajo Futuro

Un motor Web a gran escala de búsqueda es un sistema complejo y aún queda mucho porhacer. Nuestros objetivos inmediatos son mejorar la eficiencia de búsqueda y escalar a unos100 millones de páginas web. Algunas mejoras simples a la eficiencia incluyen el cacheo deconsultas, de asignación de disco inteligente, y los subíndices. Otra área que requiere muchainvestigación son las actualizaciones. Debemos tener algoritmos inteligentes para decidir quépáginas web de edad deben ser recrawled y lo que los nuevos deben ser rastreado. Trabajarhacia esta meta se ha hecho en [Cho 98]. Una prometedora área de investigación estáutilizando proxies para construir bases de datos de búsqueda, ya que son impulsadas por lademanda. Estamos planeando agregar características simples soportados por los motores debúsqueda comerciales, como los operadores booleanos, negación, y que hayan generado. Sinembargo, otras características están empezando a ser exploradas, tales como feedback derelevancia y la agrupación (Google es compatible actualmente con un simple agrupamientobasado en el nombre de host). También tenemos planes para apoyar el contexto del usuario(como la ubicación del usuario), y resumen de resultados. También estamos trabajando paraextender el uso de la estructura de enlace y el texto del vínculo. Experimentos sencillosindican PageRank puede ser personalizado por el aumento del peso de la página principal deun usuario o los marcadores. En cuanto a los enlaces de texto, estamos experimentando con

el uso de enlaces de texto que lo rodea, además de el texto del vínculo en sí. Un motor debúsqueda en la Web es un entorno muy rico en ideas para la investigación. Tenemosdemasiados para enumerar aquí, así que no esperamos que esta sección de trabajo futuropara convertirse en mucho más corto en un futuro próximo.

6.2 Búsqueda de alta calidad

El mayor problema que enfrentan los usuarios de los motores de búsqueda en la Web hoy endía es la calidad de los resultados que obtienen de vuelta. Si bien los resultados son amenudo divertidas y ampliar los horizontes de los usuarios, son a menudo frustrante yconsume un tiempo precioso. Por ejemplo, el primer resultado de una búsqueda de "Bill

Clinton" en uno de los motores de búsqueda más populares comerciales fue la de Bill ClintonBroma del Día: 14 de abril de 1997. Google está diseñado para proporcionar una mayorbúsqueda de calidad por lo que la Web sigue creciendo rápidamente, la información se puedeencontrar fácilmente. Con el fin de lograr esto Google hace un uso intensivo de la informaciónhipertextual que consiste en estructura de enlaces y el enlace (anchor) de texto. Googletambién utiliza la información de proximidad y la fuente. Aunque la evaluación de un motor debúsqueda es difícil, hemos encontrado que subjetivamente, Google devuelve más resultadosde la búsqueda de calidad que los actuales motores de búsqueda comerciales. El análisis dela estructura de enlace a través del PageRank de Google permite evaluar la calidad de laspáginas web. El uso de enlaces de texto como una descripción de lo que el enlace apunta aayuda al retorno de motor de búsqueda relevantes (y en cierta calidad de alto grado) los

resultados. Por último, el uso de la información de proximidad ayuda a aumentar la relevanciade una gran cantidad de consultas de muchos.



6.3 Arquitectura escalable

Aparte de la calidad de búsqueda, Google está diseñado para escalar. Debe ser eficienteen espacio y tiempo, y los factores constantes son muy importantes cuando se trata de toda laWeb. En la aplicación de Google, hemos visto que los cuellos de botella en la CPU, el accesoa la memoria, capacidad de memoria a disco, el rendimiento del disco, capacidad deldisco 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 deGoogle hacer un uso eficiente del espacio de almacenamiento disponible. Además, el rastreo,la indexación, y las operaciones de ordenación son lo suficientemente eficientes para sercapaces de construir un índice de una parte sustancial de la web - 24 millones de páginas, enmenos de una semana. Esperamos ser capaces de construir un índice de 100 millones depáginas en menos de un mes.

6.4 una herramienta de investigación

Además de ser un motor de búsqueda de alta calidad, Google es una herramienta deinvestigación. El de datos de Google ha recogido ya ha dado lugar en muchos otrostrabajos presentados en congresos y muchos más en el camino. Investigaciones recientes,como [Abiteboul 97] ha demostrado una serie de limitaciones a las preguntas sobre la Webque puede ser contestada sin tener la web disponible a nivel local. Esto significa queGoogle (o un sistema similar) no sólo es una valiosa herramienta de investigación, pero unacondición necesaria para una una amplia gama de aplicaciones. Esperamos que Google vaa ser un recurso para investigadores e investigadores de todo el mundo y despertará lapróxima generación de tecnología de motores de búsqueda.

7 RECONOCIMIENTOS

Scott, Hassan y Alan Steremberg han sido fundamentales para el desarrollo de Google.Suscontribuciones talentosos son insustituibles, y los autores les debemos muchagratitud. También nos gustaría dar las gracias a Héctor García-Molina, Rajeev Motwani,Ullman Jeff, y Terry Winograd y el grupo WebBase todo por su apoyoy profundas discusiones. Finalmente, nos gustaría reconocer el apoyo generoso de nuestrosequipos de los donantes de IBM, Intel y Sun y nuestros patrocinadores. La investigaciónsedescribe aquí se llevó a cabo como parte del Proyecto Integrado de Stanford, la BibliotecaDigital, con el apoyo de la National Science Foundation bajo el Acuerdo Cooperativo IRI-9411306. La financiación de este acuerdo de cooperación también es proporcionada

por DARPA y la NASA, y por Interval Research, y los socios industrialesdel proyecto deBibliotecas Digitales de Stanford.

VITAE

Sergey Brin, recibió su B.S. Licenciado en matemáticas y ciencias de la computaciónde laUniversidad de Maryland en College Park en 1993. Actualmente, es un doctoradocandidatoen ciencias de la computación en la Universidad de Stanford, donde recibiósu maestría en1995. Él es un receptor de la National Science Foundation Graduate Fellowship. Sus interesesde investigación incluyen los motores de búsqueda, extracción de información de fuentes no

estructuradas y extracción de datos de largas recopilaciones de texto y datos científicos.Lawrence Page nació en East Lansing, Michigan, y recibió una encefalopatía espongiformebovina en Ingeniería Informática en la Universidad de Michigan en Ann Arbor en 1995. En la



actualidad es un doctorado candidato en Ciencias de la Computación en la Universidad deStanford. Algunos de sus intereses de investigación incluyen la estructura de enlaces de laweb, interacción persona-ordenador, los motores de búsqueda, la escalabilidad de lasinterfaces de acceso a la información, y la minería de datos personales.

8 APÉNDICE A: PUBLICIDAD Y MOTIVOS MEZCLADOS

En la actualidad, el modelo de empresa predominante para los motores de búsquedacomerciales es la publicidad. Los objetivos del modelo de negocio de la publicidad no siemprecorresponden a ofrecer búsquedas de calidad a los usuarios. Por ejemplo, en nuestro motorde búsqueda prototipo de uno de los primeros resultados para el teléfono celular es "El efectodel uso del teléfono celular por la atención del controlador", un estudio que explica en grandetalle las distracciones y los riesgos asociados con la conversación en un teléfono celularmientras se conduce. Este resultado de la búsqueda se acercó primero a causa de su granimportancia, a juzgar por el algoritmo de PageRank, una aproximación de la importancia de lacitación en la web [Página, 98]. Está claro que un motor de búsqueda que se estaba llevando

dinero para publicar anuncios de teléfonos celulares que tienen dificultades para justificar lapágina que nuestro sistema vuelva a sus anunciantes pagados. Para este tipo de razón y laexperiencia histórica con otros medios de comunicación [Bagdikian 83], se espera que losmotores de búsqueda de publicidad serán financiados por inherentemente sesgada hacia losanunciantes y lejos de las necesidades de los consumidores.Dado que es muy difícil incluso para los expertos para evaluar los motores de búsqueda, elsesgo de motores de búsqueda 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 superiorde los resultados de la búsqueda para las consultas particulares [Marchiori 97]. Este tipo de

sesgo es mucho más insidioso que la publicidad, porque no está claro quién "merece" estarahí, y que está dispuesto a pagar dinero para ser enumeradas. Este modelo de negocioresultó en un gran alboroto, y OpenText ha dejado de ser un motor de búsqueda viable. Sinembargo, el sesgo menos evidente es probable que sean tolerados por el mercado. Porejemplo, un motor de búsqueda podría añadir un factor pequeño para buscar los resultadosde las empresas "amigables", y restar un factor de los resultados de los competidores. Estetipo de sesgo es muy difícil de detectar, pero todavía podría tener un efecto significativo en elmercado. Por otra parte, los ingresos por publicidad a menudo proporciona un incentivo paraproporcionar pobres resultados de la búsqueda de calidad. Por ejemplo, nos dimos cuenta deun motor de búsqueda no volvería página de inicio de una gran compañía aérea cuando el

nombre de la aerolínea se dio como una consulta. Dio la casualidad de que la aerolínea habíapuesto un anuncio caro, vinculado a la consulta que era su nombre. Un motor de búsquedamejor no hubiera sido necesario este anuncio, y posiblemente como resultado la pérdida delos ingresos de la compañía aérea para el motor de búsqueda. En general, se podríaargumentar desde el punto de vista del consumidor que cuanto mejor sea el motor debúsqueda es, los anuncios menos serán necesarios para que el consumidor encuentre lo quedesee. Por supuesto, esto erosiona la publicidad apoyada modelo de negocio de los motoresde búsqueda existentes. Sin embargo, siempre habrá dinero de los anunciantes que quierenun cliente para cambiar los productos, o tiene algo que es realmente nuevo. Sin embargo,

creemos que la cuestión de la publicidad hace que los incentivos lo suficientemente mixtos



que es fundamental contar con un motor de búsqueda competitiva que sea transparente y enel ámbito académico.

9 APÉNDICE B: ESCALABILIDAD

9. Una escalabilidad de Google

Hemos diseñado Google para que sea escalable en el corto plazo a una meta de 100millonesde páginas web. Acabamos de recibir el disco y las máquinas para manejar más o menos deesa cantidad. Todas las partes que consumen tiempo del sistema son paralelizar ylineales aproximadamente tiempo. Estos incluyen cosas como las orugas, indizadoresy clasificación de residuos. También pensamos que la mayoría de las estructuras de datos seocupará de gracia con la expansión. Sin embargo, en 100 millones de páginas web que va aser muy de cerca contra todo tipo de límites del sistema operativo en los sistemas operativosmás comunes (en la actualidad se ejecutan en Solaris y Linux). Estos incluyen cosas como lamemoria direccionable, el número de descriptores de archivos abiertos, tomas de corriente dered y ancho de banda, y muchos otros. Creemos que la ampliación a un montón más de100 millones de páginas aumentaría en gran medida la complejidad de nuestro sistema.

9.2 La escalabilidad de las arquitecturas centralizadas de indexación

Como las capacidades de aumento ordenadores, se hace posible índice una cantidad muygrande de texto para un coste razonable. Por supuesto, otros medios de comunicación másintensivas de banda ancha tales como vídeo es probable que se torna más difundido. Pero,debido a que el costo de producción del texto es baja en comparación a los medios como elvídeo, el texto es probable que siga siendo muy penetrante. Además, es probable que pronto

vamos a tener el reconocimiento de voz que hace un trabajo razonable de convertir voz entexto, ampliando la cantidad de texto disponible. Todo esto ofrece posibilidades increíblespara la indexación centralizada. He aquí un ejemplo ilustrativo. Suponemos que queremos atodo el mundo índice de todo lo que en los EE.UU. ha escrito durante un año. Se supone quehay 250 millones de personas en los EE.UU. y escriben un promedio de 10k por día. Eso seresuelve a ser cerca de 850 terabytes. Suponga también que la indexación de un terabytepuede hacer ahora por un costo razonable. También se asume que los métodos de indizaciónutilizados en el texto es lineal, lineal o casi en su complejidad. Teniendo en cuenta todos estossupuestos se puede calcular cuánto tiempo le tomaría antes de que pudiéramos índice de los

850 terabytes por un precio razonable asumir ciertos factores de crecimiento. La Ley deMoore se definió en 1965 como una duplicación cada 18 meses en el poder delprocesador. Se ha mantenido muy fiel, no sólo para los procesadores, pero para otrosparámetros importantes del sistema como un disco así.Si asumimos que la ley de Moore secumple para el futuro, necesitamos sólo 10 duplicaciones más, o 15 años para alcanzarnuestra meta de todo el mundo todo lo que la indexación en los EE.UU. ha escrito durante unaño por un precio que una compañía pequeña podría permitirse. Por supuesto, los expertosde hardware son algo que se trate la Ley de Moore no se puede seguir para mantener durantelos próximos 15 años, pero sin duda hay un montón de interesantes aplicacionescentralizadas, incluso si sólo tenemos una parte del camino a nuestro ejemplo hipotético.

Por supuesto, un brillo de sistemas distribuidos como los [Gravano 94] o de la cosecha será a



menudo la solución técnica más eficiente y elegante para la indexación, pero parece difícilconvencer al mundo en utilizar estos sistemas debido a los altos costos de administración dela creación de un gran número de instalaciones. Por supuesto, es muy probable que lareducción del costo de administración drásticamente es posible.Si eso sucede, y todo elmundo se pone en marcha un sistema de indexación distribuida, la búsqueda va a mejorardrásticamente.

Porque los seres humanos sólo se puede escribir o hablar de una cantidad finita, y como lascomputadoras continúan mejorando, la indexación de texto se escalará aún mejor que en laactualidad. Por supuesto que podría haber una cantidad infinita de contenidos generados porla máquina, pero sólo indexar grandes cantidades de contenido generado por el ser humanoparece tremendamente útil. Así que somos optimistas de que nuestra búsqueda centralizadaweb de arquitectura del motor va a mejorar en su capacidad para cubrir la información detexto correspondiente en el tiempo y que hay un futuro brillante para la búsqueda.

la anatomÍa de una gran escala del motor de bÚsqueda web de hipertextual

Documents