Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Pgina 2
motores.
1.1 Motores de bsqueda web - Ampliacin: 1994 - 2000
La tecnologa de los motores de bsqueda ha tenido que escalar dramticamente para
mantenerse al da con el crecimiento de la web. En 1994,
uno de los primeros motores de bsqueda web, el World Wide Web Worm (WWWW)
[McBryan 94] tena un ndice
de 110.000 pginas web y documentos web accesibles. A partir de noviembre de 1997,
los principales motores de bsqueda
reclaman un ndice de 2 millones (WebCrawler) a 100 millones de documentos web
(desde Search Engine
Reloj). Es previsible que para el ao 2000, un ndice comprensivo de la Web contenga
millones de documentos. Al mismo tiempo, el nmero de buscadores de motores de
bsqueda de manejar ha crecido increblemente
tambin. En marzo y abril de 1994, el gusano de la World Wide Web recibi un promedio
de aproximadamente 1500 consultas
por da. En noviembre de 1997, Altavista afirm que manejaba aproximadamente 20
millones de consultas por da. Con el
nmero creciente de usuarios en la web, y sistemas automatizados que consultan los
motores de bsqueda, es probable
que los principales motores de bsqueda manejarn cientos de millones de consultas por
da para el ao 2000. El objetivo de
nuestro sistema es abordar muchos de los problemas, tanto en calidad como en
escalabilidad, introducidos por escalamiento
tecnologa de motores de bsqueda a estos nmeros extraordinarios.
1.2. Google: Escala con la Web
La creacin de un motor de bsqueda que escalas incluso a la web de hoy presenta muchos
desafos. Rastreo rpido
la tecnologa es necesaria para reunir los documentos web y mantenerlos actualizados. Se
debe utilizar espacio de almacenamiento
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 manejadas
rpidamente, a un ritmo de cientos a
miles por segundo.
Estas tareas son cada vez ms difciles a medida que crece la Web. Sin embargo, el
rendimiento del hardware y
los costos han mejorado dramticamente para compensar parcialmente la dificultad. Hay,
sin embargo, varios
excepciones a este progreso como tiempo de bsqueda de disco y robustez del sistema
operativo. Al disear Google,
hemos considerado tanto la tasa de crecimiento de la Web como los cambios
tecnolgicos. Google est diseado para
escala bien a conjuntos de datos extremadamente grandes. Hace un uso eficiente del
espacio de almacenamiento para almacenar el ndice. Sus datos
las estructuras estn optimizadas para un acceso rpido y eficiente (ver seccin
4.2). Adems, esperamos que el costo de
el ndice y el texto del almacn o el HTML disminuirn eventual con respecto a la
cantidad que estar disponible (vase
Apndice B). Esto resultar en propiedades de escala favorables para sistemas
centralizados como Google.
1.3 Objetivos del diseo
1.3.1 Calidad de bsqueda mejorada
Nuestro principal objetivo es mejorar la calidad de los motores de bsqueda web. En
1994, algunas personas crean que
ndice de bsqueda completo hara posible encontrar algo fcilmente. Segn Best of the
Web
1994 - Navigators, "El mejor servicio de navegacin debera facilitar la bsqueda de casi
cualquier
Web (una vez que se han introducido todos los datos). "Sin embargo, la web de 1997 es
bastante diferente.
un motor de bsqueda recientemente, puede fcilmente testificar que la integridad del
ndice no es el nico factor en
la calidad de los resultados de bsqueda. "Los resultados basura" suelen eliminar 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
comercial se encuentra (devuelve su propia
pgina de bsqueda en respuesta a su nombre en los diez primeros 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 el usuario
la capacidad de mirar los documentos no. La gente todava est dispuesta a mirar las
primeras decenas de resultados.
Pgina 3
Pgina 4
medida objetiva de su importancia de citacin que corresponde bien con la idea subjetiva
importancia. Debido a esta correspondencia, PageRank es una excelente manera de
priorizar los resultados de
bsquedas de palabras clave web. Para la mayora de los temas populares, una simple
bsqueda de concordancia de texto que est restringida a la web
ttulos de pgina 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 del clculo del PageRank
La literatura de citas acadmicas se ha aplicado a la web, en gran medida contando citas
o vnculos de retroceso a un
pgina dada. Esto da alguna aproximacin de la importancia o calidad de una
pgina. PageRank extiende esto
idea de no contar los enlaces de todas las pginas por igual, y por la normalizacin por el
nmero de enlaces en una pgina.
PageRank se define como sigue:
Asumimos que la pgina A tiene pginas T1 ... Tn que apuntan a ella (es decir, son
citas). El parmetro d
es un factor de amortiguacin que se puede establecer entre 0 y 1. Normalmente fijamos
d a 0,85. Existen
ms detalles acerca de d en la siguiente seccin. Tambin C (A) se define como el nmero
de enlaces que van
fuera de la pgina A. El PageRank de una pgina A se da como sigue:
PR (T _ {1}) + ... + PR (T _ {n}) / C (T _ {n}))
Tenga en cuenta que los PageRanks forman una distribucin de probabilidad sobre
pginas web, por lo que la suma de todos
pginas web 'PageRank ser uno.
PageRank o PR (A) pueden calcularse usando un simple algoritmo iterativo, y
corresponde a la
vector propio principal de la matriz de enlace normalizada de la banda. Adems, un
PageRank para 26 millones de web
pginas se pueden calcular en 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 pensado como un modelo de comportamiento del
usuario. Asumimos que hay un "surfista aleatorio" que es
dado una pgina web al azar y sigue haciendo clic en los enlaces, nunca golpear "atrs",
pero finalmente se aburre
y comienza en otra pgina aleatoria. La probabilidad de que la persona que practica surf
al azar visite una pgina es su PageRank.
Y, el factor de amortiguamiento D es la probabilidad en cada pgina del "navegante
aleatorio" se aburrir y la solicitud
otra pgina aleatoria. Una variacin importante es slo para agregar el factor de
amortiguamiento d para una sola pgina, o una
grupo de pginas. Esto permite la personalizacin y puede hacer casi imposible deliberar
engaar al sistema para obtener una clasificacin ms alta. Tenemos varias otras
extensiones a PageRank,
ver de nuevo [Pgina 98].
Otra justificacin intuitiva es que una pgina puede tener un PageRank alto si hay muchas
pginas que apuntan
a l, o si hay algunas pginas que apuntan a ella y tienen un PageRank
alto. Intuitivamente, las pginas que estn bien
citados de muchos lugares alrededor de la web vale la pena mirar. Tambin, las pginas
que quizs slo tienen una
citacin de algo como el Yahoo! pgina principal tambin son generalmente vale la pena
mirar. Si una pgina no fue
alta calidad, o era un acoplamiento quebrado, es muy probable que la pgina inicial de
Yahoo no enlazara a ella.
PageRank maneja estos dos casos y todo lo dems mediante la propagacin recursiva de
pesos
a travs de la estructura de enlace de la red.
Pgina 5
Pgina 6
Pgina 7
Pgina 8
4.2.1 BigFiles
BigFiles son archivos virtuales que abarcan mltiples sistemas de archivos y son
direccionables por enteros de 64 bits. los
la asignacin entre mltiples sistemas de archivos se maneja automticamente. El paquete
BigFiles tambin maneja
asignacin y desasignacin de descriptores de archivo, ya que los sistemas operativos no
proporcionan suficiente
necesariamente. BigFiles tambin soportan opciones de compresin rudimentarias.
4.2.2 Repositorio
El repositorio contiene el HTML completo de cada pgina web.
Cada pgina se comprime con zlib (vase RFC1950). los
la eleccin de la tcnica de compresin es una compensacin entre la velocidad
y la relacin de compresin. Elegimos la velocidad de zlib
mejora significativa en la compresin ofrecida por bzip. los
la tasa de compresin de bzip fue de aproximadamente 4 a 1 en la
repositorio en comparacin con la compresin de 3 a 1 de zlib. En el
repositorio, los documentos se almacenan uno tras otro y
son prefijados por docID, longitud y URL como se puede ver en
Figura 2. El repositorio no requiere ninguna otra estructura de datos para ser utilizada
para acceder a ella. Esto ayuda con
la coherencia de los datos y facilita mucho el desarrollo; podemos reconstruir todas las
otras estructuras de datos de
slo el repositorio y un archivo que lista los errores del rastreador.
4.2.3 ndice de documentos
El ndice de documentos mantiene informacin sobre cada documento. Es un ancho fijo
ISAM (ndice secuencial
modo de acceso), ordenado por docID. La informacin almacenada en cada entrada
incluye la
el estado del documento, un puntero en el repositorio, una suma de comprobacin del
documento y varias estadsticas. Si el
documento se ha rastreado, tambin contiene un puntero en un archivo de anchura
variable llamado docinfo que
contiene su URL y ttulo. De lo contrario, el puntero apunta a la URLlist que contiene
slo la URL.
Esta decisin de diseo fue impulsada por el deseo de tener una estructura de datos
razonablemente compacta, y la
capacidad de buscar un registro en una bsqueda de disco durante una bsqueda
Adems, hay un archivo que se utiliza para convertir URLs en docIDs. Es una lista de
sumas de comprobacin de URL
con sus docIDs correspondientes y se clasifica por checksum. Con el fin de encontrar el
docID de un particular
URL, se calcula la suma de comprobacin de la URL y se realiza una bsqueda binaria
en el archivo de sumas de comprobacin para encontrar
su docID. Las URL pueden convertirse en docIDs en lote haciendo una combinacin con
este archivo. Este es el
tcnica que el URLresolver utiliza para convertir URLs en docIDs. Este modo de
actualizacin por lotes es crucial porque
de lo contrario debemos realizar una bsqueda por cada enlace que asumiendo que un
disco llevara ms de un
mes para nuestro conjunto de datos de enlaces 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
memoria en una mquina con 256 MB de memoria principal. El lxico actual contiene 14
millones de palabras
(aunque algunas palabras raras no fueron agregadas al lxico). Se implementa en dos
partes: una lista de las
palabras (concatenadas juntas pero separadas por nulos) y una tabla hash de
punteros. Para diversas funciones,
Figura 2. Estructura de datos del repositorio
Pgina 9
la lista de palabras tiene alguna informacin auxiliar que est ms all del alcance de este
artculo para explicarlo completamente.
4.2.5 Listas de aciertos
Una lista de resultados corresponde a una lista de ocurrencias de una palabra en particular
en un documento particular incluyendo
informacin de posicin, fuente y maysculas. Las listas de visitas representan la mayor
parte del espacio
adelante y los ndices invertidos. Por ello, es importante representarlos tan eficientemente
como
posible. Consideramos varias alternativas para codificar la posicin, la fuente y la
mayscula - simple
codificacin (un triple de enteros), una codificacin compacta (una asignacin optimizada
a mano de bits), y Huffman
codificacin. Al final elegimos una codificacin compacta optimizada manualmente ya
que requera mucho menos espacio que el
codificacin simple y mucho menos manipulacin de bits que Huffman codificacin. Los
detalles de los golpes se muestran en
Figura 3.
Nuestra codificacin compacta utiliza dos bytes para cada golpe. Hay dos tipos de xitos:
golpes de lujo y golpes sencillos.
Los impactos de lujo incluyen los impactos que ocurren en una URL, ttulo, texto de
anclaje o metaetiqueta. Los xitos sencillos incluyen todo
ms. Un golpe simple consiste en un bit de maysculas, tamao de fuente y 12 bits de
posicin de palabra en un documento (todos
las posiciones superiores a 4095 estn marcadas como 4096). El tamao de la fuente se
representa con relacin al resto del documento
utilizando tres bits (slo 7 valores se utilizan realmente porque 111 es la bandera que
seala un golpe de fantasa). Un elegante
hit consiste en un bit de maysculas, el tamao de fuente establecido en 7 para indicar
que es un golpe de fantasa, 4 bits para codificar el
tipo de golpe de fantasa, y 8 bits de posicin. Para los golpes de anclaje, los 8 bits de
posicin se dividen en 4 bits para
posicin en ancla y 4 bits para un hash del docID en el que se produce el ancla. Esto nos
da algunas limitaciones
mientras no hay muchas anclas para una palabra en particular. Esperamos actualizar
la forma en que los golpes de anclaje se almacenan para permitir una mayor resolucin
en los campos de posicin y docIDhash.
Utilizamos el tamao de fuente en relacin con el resto del documento porque al buscar,
no desea clasificar
de lo contrario documentos idnticos de manera diferente slo porque uno de los
documentos est en una fuente ms grande.
La longitud de una lista de resultados se almacena antes de los golpes.
Para ahorrar espacio, la longitud de la lista de resultados se combina con la
wordID en el ndice directo y el docID en el invertido
ndice. Esto limita a 8 y 5 bits respectivamente (hay
algunos trucos que permiten obtener 8 bits de la
wordID). Si la longitud es ms larga de lo que cabra en
bits, se utiliza un cdigo de escape en esos bits, y los siguientes dos
bytes contienen la longitud real.
4.2.6 Forward Index
El ndice forward est en realidad ya parcialmente ordenado. Es
almacenado en un nmero de barriles (utilizamos 64). Cada barril
contiene un rango de ID de palabra. Si un documento contiene palabras
que caen en un determinado barril, el docID se registra en
el barril, seguido por una lista de ID de palabra con listas de
corresponden a esas palabras. Este esquema requiere
ms de almacenamiento debido a duplicados docIDs, pero el
la diferencia es muy pequea para un nmero razonable de cubos y ahorra tiempo
considerable y la codificacin
complejidad en la fase de indexacin final realizada por el clasificador. Adems, en lugar
de almacenar
wordID, almacenamos cada ID de palabra como una diferencia relativa con respecto al
ID de palabra mnimo que cae en la
Figura 3. ndices hacia delante y hacia atrs
y el Lxico
Pgina 10
barrel el wordID es pulg De esta manera, podemos utilizar slo 24 bits para el wordID en
los barriles sin clasificar,
dejando 8 bits para la longitud de la lista de aciertos.
4.2.7 ndice invertido
El ndice invertido consiste en los mismos barriles que el ndice forward, excepto que han
sido
procesado por el clasificador. Para cada wordID vlido, el lxico contiene un puntero en
el barril que
wordID cae en. Seala a un doclist de docID junto con sus listas de golpe
correspondientes. Este doclist
representa todas las ocurrencias de esa palabra en todos los documentos.
Una cuestin importante es en qu orden deben aparecer los docID en el doclist. Una
solucin sencilla es
almacnelos ordenados por docID. Esto permite la rpida fusin de diferentes doclists
para mltiples palabras
consultas. Otra opcin es almacenarlos ordenados por una clasificacin de la ocurrencia
de la palabra en cada
documento. Esto hace que responder a una palabra consultas trivial y hace probable que
las respuestas a
las consultas de palabras mltiples estn cerca del comienzo. Sin embargo, la fusin es
mucho ms difcil. Adems, esto hace que
desarrollo mucho ms difcil en que un cambio a la funcin de clasificacin requiere una
reconstruccin del ndice.
Elegimos un compromiso entre estas opciones, manteniendo dos conjuntos de barriles
invertidos - un conjunto para el xito
listas que incluyen golpes de ttulo o de anclaje y otro conjunto para todas las listas de
aciertos. De esta manera, verificamos el primer conjunto de
barriles primero y si no hay suficientes fsforos dentro de esos barriles comprobamos los
ms grandes.
4.3 Rastreo de la Web
Ejecutar un rastreador web es una tarea difcil. Hay problemas difciles de rendimiento y
confiabilidad y
an ms importante, hay asuntos sociales. El rastreo es la aplicacin ms frgil ya que
implica
interactuando con cientos de miles de servidores web y varios servidores de nombres que
estn ms all
el control del sistema.
Con el fin de escalar a cientos de millones de pginas web, Google tiene un sistema de
rastreo distribuido rpido. UN
servidor URL nico sirve listas de direcciones URL a un nmero de rastreadores
(normalmente se ejecuta alrededor de 3). Ambos
URLserver y los rastreadores son implementados en Python. Cada rastreador mantiene
alrededor de 300 conexiones
abrir a la vez. Esto es necesario para recuperar las pginas web a un ritmo lo
suficientemente rpido. A velocidades de pico, el sistema de
puede rastrear ms de 100 pginas web por segundo utilizando cuatro rastreadores. Esto
equivale a aproximadamente 600 K por segundo
de datos. Un gran estrs rendimiento es la bsqueda de DNS. Cada rastreador mantiene
una su propia cach DNS por lo que
no necesita hacer una bsqueda de DNS antes de meterse cada documento. Cada uno de
los cientos de conexiones
puede ser en un nmero de diferentes estados: mirando hacia arriba DNS, conectar con el
equipo, el envo de la solicitud, y
recibir la respuesta. Estos factores hacen que el rastreador de un componente complejo
del sistema. Usa
S asncrona para gestionar eventos, y un nmero de colas para mover 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 de registro genera una buena cantidad de correo electrnico y las
llamadas telefnicas. Debido a la gran cantidad
de personas que vienen en lnea, no siempre son los que no saben lo que es un rastreador
es, porque este es el
primero que han visto. Casi todos los das, recibimos un correo electrnico algo como,
"Wow, se vea a una gran cantidad de
pginas de mi sitio web. Cmo te gusta?" Tambin hay algunas personas que no saben
acerca de la
robots de protocolo de exclusin, y piensan que su pgina debe ser protegido de la
indexacin de una declaracin como,
"Esta pgina tiene derechos de autor y no debe ser indexado", lo que no hace falta decir
es difcil para los rastreadores web
comprender. Adems, debido a la enorme cantidad de datos implicados, las cosas van a
suceder inesperados. por
ejemplo, nuestro sistema trat de arrastrarse un juego en lnea. Esto dio lugar a una gran
cantidad de mensajes basura en la
medio de su juego! Resulta que este era un problema fcil de solucionar. Sin embargo,
este problema no se haba acercado
Pgina 11
hasta que haba descargado decenas de millones de pginas. Debido a la gran variacin
en las pginas web y
servidores, es prcticamente imposible probar una oruga sin ejecutarlo en gran parte de
la Internet.
Invariablemente, hay cientos de problemas oscuros que slo pueden ocurrir en una pgina
fuera de la totalidad
web y hacer que el rastreador se bloquee, o peor, provocar un comportamiento
impredecible o incorrecta. Los sistemas que
de acceso a una gran parte de la necesidad de Internet a ser diseados para ser muy robusto
y probado cuidadosamente. Desde grandes
sistemas complejos tales como rastreadores destinada a causar problemas, es necesario
que haya recursos significativos
dedicado a la lectura del correo electrnico y la solucin de estos problemas a medida que
surgen.
4.4 Indexacin de la Web
Anlisis sintctico - Cualquier programa de anlisis que est diseado para funcionar en
toda la Web debe manejar una enorme variedad de
posibles errores. Estos van desde errores tipogrficos en las etiquetas HTML de kilobytes
de ceros en el medio de una etiqueta,
caracteres no ASCII, etiquetas HTML anidadas cientos de profundidad, y una gran
variedad de otros errores que se
desafiar la imaginacin de cualquiera de llegar a los igualmente creativas. Para una
velocidad mxima,
en lugar de utilizar YACC para generar un analizador CFG, utilizamos flex que genere
un analizador lxico, que
equipamos con su propia pila. El desarrollo de este analizador, que funciona a una
velocidad razonable y es muy
robusta implic una buena cantidad de trabajo.
Documentos de indexacin en Barriles - Despus se analiza cada documento, se
codifica en un nmero
de barriles. Cada palabra se convierte en un wordID mediante el uso de una tabla hash en
memoria - el lxico.
Las nuevas adiciones a la tabla hash de lxico se registran en un archivo. Una vez que las
palabras se convierten en
wordID de, sus ocurrencias en el documento actual se traducen en listas negras y estn
escritos en
los barriles hacia adelante. La principal dificultad con la paralelizacin de la fase de
indexacin es que el
lxico tiene que ser compartida. En lugar de compartir el lxico, tomamos el enfoque de
escribir un registro de
todas las palabras adicionales que no estaban en un lxico de base, que fija en 14 millones
de palabras. De esa manera
varios indizadores pueden ejecutarse en paralelo y luego el archivo de registro pequea
de palabras adicionales pueden ser procesados por
un ltimo paso a paso.
Ordenando - Con el fin de generar el ndice invertido, la clasificadora toma cada uno de
los barriles hacia adelante y hacia
la ordena por wordID para producir un barril invertido en el ttulo y anclaje hits y un texto
completo invertidas
barril. Este proceso se produce un barril a la vez, por lo que requiere poco de
almacenamiento temporal. Tambin nosotros
paralelizar la fase de clasificacin para usar tantas mquinas como lo hemos hecho,
simplemente mediante la ejecucin de mltiples
clasificadores, que pueden procesar diferentes cubos al mismo tiempo. Dado que los
barriles no encajan en principal
la memoria, el clasificador de las subdivide adems en cestas que hacen encajar en la
memoria sobre la base de
wordID y docID. A continuacin, el clasificador, se carga cada canasta en la memoria, la
ordena y escribe su contenido
en el can corto invertida y el can invertido completo.
4.5 Bsqueda
El objetivo de la bsqueda es para proporcionar resultados de bsqueda de calidad de
manera eficiente. Muchas de las grandes superficies comerciales
motores de bsqueda parecen haber hecho grandes progresos 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 comerciales
volmenes con un esfuerzo poco ms. El proceso de evaluacin consulta Google es
muestra en la Figura 4.
Pgina 12
Para poner un lmite en el tiempo de respuesta, una vez que un cierto nmero de
(Actualmente 40.000) de los documentos que coincidan se encuentran, la
buscador pasa automticamente al paso 8 en la Figura 4. Este
significa que es posible que los resultados sub-ptimos seran
devuelto. Actualmente estamos investigando otras maneras de resolver
este problema. En el pasado, hemos solucionado los accesos de acuerdo con
PageRank, que pareca mejorar la situacin.
4.5.1 El sistema de clasificacin
Google mantiene mucha ms informacin sobre Web
documentos que los motores de bsqueda tpicos. cada lista negra
incluye la posicin, la fuente y la informacin de capitalizacin.
Adems, tenemos en cuenta los xitos de texto de anclaje y la
PageRank del documento. Combinando todo esto
informacin en un rango es difcil. Hemos diseado nuestro ranking
funcin de manera que ningn factor en particular puede tener demasiado
influencia. En primer lugar, consideremos el caso ms simple - una sola palabra
consulta. Con el fin de clasificar un documento con una sola palabra
consulta, Google mira a la lista negra de ese documento para esa palabra.
Google considera cada golpe al ser uno de varios tipos diferentes (ttulo, ancla, URL,
texto plano fuente grande,
texto sin formato de fuente pequeo, ...), cada uno de los cuales tiene su propio tipo de
peso. El tipo-pesos componen un vector
indexadas por tipo. Google cuenta el nmero de visitas de cada tipo en la lista de
resultados. A continuacin, cada cuenta es
convertido en un recuento de peso. Count-pesos aumentan linealmente con recuentos al
principio, pero rpidamente disminuir
de manera que ms de un cierto nmero de no ayudar. Tomamos el producto escalar del
vector de recuento de pesos
con el vector de tipo-pesos para calcular una puntuacin de IR para el documento. Por
ltimo, la puntuacin es de IR
combinado con PageRank para dar un rango final al documento.
Para realizar una bsqueda de varias palabras, la situacin es ms complicada. Ahora
mltiples listas de resultados deben ser escaneados
a travs de una sola vez para que golpea ocurren juntos en un documento son ponderados
superiores a golpes
que ocurre muy separados. Los xitos de las mltiples listas de resultados se corresponden
de manera que se hacen coincidir xitos cercanas
juntos. Para cada conjunto combinado de xitos, una proximidad se calcula. La
proximidad se basa en qu tan lejos
Aparte de los xitos estn en el documento (o ancla), pero se clasifica en 10
"contenedores" diferentes valores que van desde
un partido de la frase a "ni de lejos". Los recuentos se calculan no slo para cada tipo de
golpe, sino para todos los tipos
y la proximidad. Cada tipo y la proximidad par tiene una prox-peso tipo. Los recuentos
se convierten en
Contamos-pesos y tomamos el producto escalar de los recuentos de pesos y los pesos-
PROX-tipo para calcular
una puntuacin de IR. Todos estos nmeros y matrices posible que todos aparezcan los
resultados de bsqueda utilizando una
el modo de depuracin especial. Estas pantallas han sido muy tiles en el desarrollo del
sistema de clasificacin.
4.5.2 Evaluacin
La funcin de clasificacin tiene muchos parmetros como el tipo-pesos y los-PROX-
pesos de tipo. averiguar
los valores correctos de estos parmetros es algo de un arte negro. Con el fin de hacer
esto, tenemos un usuario
mecanismo de retroalimentacin en el motor de bsqueda. Un usuario de confianza puede
evaluar opcionalmente todos los resultados que
son devueltos. Esta retroalimentacin 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 cierta
1. analizar la consulta.
2. Convertir las palabras en wordIDs.
3. Se desplaza hasta el inicio de la Lista de documentos de de
el can corto para cada palabra.
4. Scan a travs de los doclists hasta
hay un documento que coincida
todos los trminos de bsqueda.
5. Calcular el rango de ese
documento para la consulta.
6. Si estamos en los caones cortos y por lo
al final de cualquier Lista de documentos de, buscar la
comenzar de la Lista de documentos de en el barril lleno
por cada palabra y vaya al paso 4.
7. Si no estamos al final de cualquier
Lista de documentos de ir al paso 4.
Clasificar los documentos que tienen
emparejado por rango y devolver la parte superior
k.
Figura 4. Evaluacin de consulta Google
Pgina 13
Pgina 14
Aparte de la calidad de bsqueda, Google est diseado para escalar de forma rentable
con el tamao de la web, ya que
crece. Un aspecto de esto es utilizar el almacenamiento de manera eficiente. La Tabla 1
presenta un desglose de algunas estadsticas y
los requisitos de almacenamiento de Google. Debido a la compresin del tamao total del
depsito es de aproximadamente 53 GB, simplemente
ms de un tercio del total de la almacena datos. A los precios actuales de disco esto hace
que el depsito de un tiempo relativamente
fuente barata de datos tiles. Ms importante an, el total de todos los datos que utiliza el
motor de bsqueda requiere
una cantidad comparable de almacenamiento, alrededor de 55 GB. Por otra parte, la
mayora de las preguntas pueden ser contestadas utilizando slo el
ndice invertido corto. Con una mejor codificacin y compresin del ndice de
documentos, una tela de alta calidad
motor de bsqueda puede caber en una unidad de 7 GB de un nuevo PC.
Rendimiento 5.2 Sistema
Es importante para un motor de bsqueda para rastrear e indexar
eficientemente. Esta informacin forma se puede mantener hasta la fecha y
cambios importantes en el sistema pueden probarse con relativa rapidez.
Para Google, los grandes trabajos de rastreo, la indexacin,
y la clasificacin. Es difcil medir el tiempo de rastreo
tom global porque los discos se llenaron, los servidores de nombres chocaron,
o cualquier nmero de otros problemas que detuvo el sistema.
En total se tom aproximadamente 9 das para descargar los 26 millones
pginas (incluidos los errores). Sin embargo, una vez que el sistema era
funcionando sin problemas, que corri mucho ms rpido, la descarga de la ltima
11 millones de pginas en tan slo 63 horas, con un promedio de poco ms de 4
milln de pginas por da o 48,5 pginas por segundo. Nos encontramos con la
indexador y el rastreador simultneamente. El indexador corri solo
ms rpido que los rastreadores. Esto es en gran parte porque pasamos justo
tiempo suficiente optimizar el indexador de modo que no sera una
embotellamiento. Estas optimizaciones incluyen actualizaciones masivas a la
ndice de documento y la colocacin de estructuras de datos crticos en
el disco local. El indexador funciona a aproximadamente 54 pginas por
segundo. Los clasificadores pueden ejecutarse completamente en paralelo; utilizando
cuatro mquinas, todo el proceso de clasificacin toma alrededor de 24
horas.
Rendimiento 5.3 Buscar
Mejorar el rendimiento de la bsqueda no era el principal objetivo de nuestra
investigacin hasta este punto. los
versin actual de Google responde a la mayora de las consultas de entre 1 y 10
segundos. Esta vez es en su mayora
dominado por S de disco a travs de NFS (ya que los discos se extienden por un nmero
de mquinas). Adems,
Google no tiene ningn optimizaciones tales como el almacenamiento en cach de
consultas, subndices en trminos comunes, y otra
optimizaciones comunes. Tenemos la intencin de acelerar considerablemente Google 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. Tabla 2 tiene algunos tiempos de consulta de la muestra a partir de la versin
actual de Google. Se repiten a
mostrar las aceleraciones resultantes de IO en cach.
Estadsticas de almacenamiento
Tamao total de 147,8 GB descabellada Pginas
Repositorio comprimido
53.5 GB
ndice invertida corta
4,1 GB
ndice de Inversin total
37.2 GB
Lxico
293 MB
Datos de anclaje temporal
(No en total)
6,6 GB
ndice de documentos Incl.
Ancho de datos variables
9,7 GB
enlaces Base de Datos
3.9 GB
Total sin Repositorio de 55.2 GB
Total con Repositorio 108,7 GB
Pgina Web Estadsticas
Nmero de pginas Web
descabellada
24 millones
Visto nmero de URLs
76,5 millones
Nmero de correo electrnico
direcciones
1,7 millones
Nmero de de 404
1.6 millones
Tabla 1. Estadsticas
Pgina 15
6. Conclusiones
Google est diseado para ser un motor de bsqueda escalable.
El objetivo principal es proporcionar alta calidad de bsqueda
Resultados Durante un mundo en rpido crecimiento Wide Web.
Google emplea una serie de tcnicas para mejorar
incluyendo la calidad de bsqueda fila de la pgina, el texto de anclaje, y
informacin de proximidad. Por otra parte, Google es una
arquitectura completa para la recopilacin de pginas web,
indexacin de ellos, y la realizacin de consultas de bsqueda ms
ellos.
6.1 Trabajo Futuro
Un motor de bsqueda web a gran escala es un sistema complejo y queda mucho por
hacer. nuestro inmediata
objetivos son mejorar la eficiencia de bsqueda y escalar a aproximadamente 100
millones de pginas web. Algunos
simples mejoras en la eficiencia incluyen el almacenamiento en cach de consultas,
asignacin de disco inteligente y subndices.
Otra rea que requiere mucha investigacin es actualizaciones. Debemos tener algoritmos
inteligentes para decidir qu
pginas web de edad deben volver a rastrear y qu otros nuevos deben ser
rastreadas. Trabajar hacia este objetivo tiene
ha hecho en [Cho 98]. Un rea prometedora de la investigacin est utilizando cachs de
proxy para construir las bases de datos de bsqueda,
ya que son impulsado la demanda. Estamos planeando aadir caractersticas simples con
el apoyo de bsqueda comercial
los motores como los operadores booleanos, negacin, y frenar. Sin embargo, otras
caractersticas estn empezando a ser
explorado tales como la pertinencia de retroalimentacin y la agrupacin (Google es
compatible actualmente con un nombre de host simple basado
clustering). Tambin tenemos la intencin de apoyar el contexto del usuario (como la
ubicacin del usuario), y resumen de resultados. Nosotros
Tambin estamos trabajando para extender el uso de la estructura de enlaces y enlaces de
texto. sencillos experimentos indican PageRank
se puede personalizar mediante el aumento del peso de la pgina de inicio del usuario o
marcadores. En cuanto a los enlaces de texto, nos
estn experimentando con el uso de texto enlaces, adems de la propia texto del enlace
circundante. Una bsqueda en la Web
el motor es un entorno muy rico para las ideas de investigacin. Tenemos demasiados
para enumerar aqu, as que no lo hacemos
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 buscadores web hoy en da es la
calidad de los resultados que obtienen espalda.
Si bien los resultados son a menudo divertido y se expanden los horizontes de los
usuarios, que a menudo son frustrantes y consumen
tiempo precioso. Por ejemplo, el primer resultado de una bsqueda de "Bill Clinton" en
uno de los ms populares
Los motores de bsqueda comerciales fue el Bill Clinton Broma del Da: 14 de abril de
1997. Google est diseado para
proporcionar la bsqueda de mayor calidad as como la Web contina 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 enlace
estructura y el texto del enlace (ancla). Google tambin utiliza la proximidad y la fuente
de informacin. Mientras que la evaluacin de un
motor de bsqueda es difcil, hemos encontrado que subjetivamente Google devuelve
resultados de bsqueda de mayor calidad
que los motores de bsqueda comerciales actuales. El anlisis de la estructura de enlaces
a travs de PageRank permite a Google
Evaluar la calidad de las pginas web. El uso de enlaces de texto como una descripcin
de qu puntos del enlace de ayuda a
el retorno del motor de bsqueda relevantes (y hasta cierto punto de alta calidad)
resultados. Por ltimo, el uso de la proximidad
informacin ayuda a aumentar la relevancia de un gran negocio para muchas consultas.
consulta inicial
misma consulta
Repetida (IO
sobre todo en cach)
Consulta
UPC
Veces)
Total
Veces)
UPC
Veces)
Total
Veces)
al gore
0,09
2.13
0,06
0,06
vicio
presidente
1,77
3,84
1,66
1,80
difcil
discos
0,25
4,86
0,20
0,24
buscar
motores
1,31
9,63
1,16
1,16
Tabla 2. Los tiempos de bsqueda
Pgina 16
Pgina 17
Pgina 18
Pgina 20