Bueno, no estoy seguro de si es MapReduce el que resuelve el problema, pero seguramente no sería MapReduce solo para resolver todas estas preguntas que planteó. Pero aquí hay cosas importantes a tener en cuenta, y que hacen posible tener una latencia tan baja en las consultas de todos estos TB de datos en diferentes máquinas:
- Computación distribuida: al distribuirse no significa que los índices se distribuyan simplemente en diferentes máquinas, en realidad se replican a lo largo de diferentes clústeres, lo que permite que muchos usuarios realicen consultas diferentes con un tiempo de recuperación bajo (sí, las grandes empresas pueden permitirse eso de máquinas);
- almacenamiento en caché: los cachés reducen enormemente el tiempo de ejecución, ya sea para el paso de rastreo, para la recuperación de páginas, o para la clasificación y exposición de resultados;
- muchos ajustes: todos los algoritmos / soluciones anteriores y muy eficientes solo pueden ser efectivos si la implementación también es eficiente. Hay toneladas de optimizaciones (codificadas), como la localidad de referencia, la compresión, el almacenamiento en caché; todos ellos generalmente aplicables a diferentes partes del procesamiento.
Teniendo en cuenta eso, tratemos de responder a sus preguntas:
pero me imagino que no es posible indexar los resultados de cada consulta posible
Sí, lo sería, y en realidad no es factible tener resultados para cada consulta posible . Hay un número infinito de términos en el mundo (incluso si asume que solo se ingresarán los términos escritos correctamente), y hay un número exponencial de consultas de estos n -> inftérminos ( 2^n). Entonces, ¿qué se hace? Almacenamiento en caché. Pero si hay tantas consultas / resultados, ¿cuáles almacenar en caché? Políticas de almacenamiento en caché. Las consultas más frecuentes / populares / relevantes para el usuario son las que se almacenan en caché.
¿No sería enorme la latencia de hardware en el hardware de Google? Incluso si los datos en Google estuvieran almacenados en SSD de TB / s
Hoy en día, con procesadores tan altamente desarrollados, las personas tienden a pensar que cada tarea posible que debe terminar en un segundo (o menos), y que trata con tantos datos, debe ser procesada por procesadores extremadamente potentes con múltiples núcleos y mucha memoria. Sin embargo, lo único que rige el mercado es el dinero, y los inversores no están interesados en desperdiciarlo. Entonces, ¿qué se hace?
La preferencia es en realidad tener muchas máquinas, cada una con procesadores simples / accesibles (en términos de costo), lo que reduce el precio de construir la multitud de clústeres que existen. Y sí, funciona. El cuello de botella principal siempre se reduce al disco, si considera mediciones simples de rendimiento . Pero una vez que hay tantas máquinas, uno puede permitirse cargar cosas en la memoria principal, en lugar de trabajar en discos duros.
Las tarjetas de memoria son caras para nosotros, simples seres humanos, pero son muy baratas para las empresas que compran muchas de esas tarjetas a la vez. Como no es costoso, no es un problema tener tanta memoria como sea necesaria para cargar índices y mantener cachés a mano. Y dado que hay tantas máquinas, no hay necesidad de procesadores súper rápidos, ya que puede dirigir las consultas a diferentes lugares y tener grupos de máquinas responsables de atender regiones geográficas específicas , lo que permite un almacenamiento en caché de datos más especializado y una respuesta aún mejor veces.
¿MapReduce ayuda a resolver este problema?
Aunque no creo que el uso o no de MapReduce sea información restringida dentro de Google, no estoy familiarizado con este punto. Sin embargo, la implementación de MapReduce de Google (que seguramente no es Hadoop) debe tener muchas optimizaciones, muchas de las cuales involucran los aspectos discutidos anteriormente. Entonces, la arquitectura de MapReduce probablemente ayuda a guiar cómo se distribuyen físicamente los cálculos, pero hay muchos otros puntos a considerar para justificar tal velocidad en el tiempo de consulta.
Bien, entiendo que las búsquedas populares pueden almacenarse en la memoria caché. ¿Pero qué pasa con las búsquedas impopulares?
El siguiente gráfico presenta una curva de cómo se producen los tipos de consultas. Puede ver que hay tres tipos principales de búsquedas, cada una de las cuales contiene aproximadamente 1/3 del volumen de consultas (área debajo de la curva). La trama muestra la ley de poder y refuerza el hecho de que las consultas más pequeñas son las más populares. El segundo tercio de las consultas aún es factible de procesar, ya que contienen pocas palabras. Pero el conjunto de las llamadas consultas oscuras , que generalmente consisten en consultas de usuarios no experimentados, no son una parte insignificante de las consultas.
Y ahí yace espacio para soluciones novedosas. Dado que no son solo una o dos consultas (sino un tercio de ellas), deben tener resultados relevantes . Si escribe algo demasiado oscuro en una búsqueda en Google, no tardará más en devolver una lista de resultados, pero lo más probable es que le muestre algo que dedujo que le gustaría decir. O simplemente puede indicar que no había ningún documento con tales términos, o incluso reducir su búsqueda a 32 palabras (lo que me sucedió en una prueba aleatoria aquí).
Hay docenas de heurísticas aplicables, que pueden ser ignorar algunas palabras o tratar de dividir la consulta en otras más pequeñas y obtener los resultados más populares . ¿Y todas estas soluciones se pueden adaptar y ajustar para respetar los tiempos de espera factibles de, digamos, menos de un segundo? :RE