Bem, não tenho certeza se é o MapReduce que resolve o problema, mas certamente não seria o MapReduce sozinho para resolver todas essas questões que você levantou. Mas aqui estão algumas coisas importantes a serem levadas em consideração e que tornam possível ter uma latência tão baixa nas consultas de todos esses TBs de dados em diferentes máquinas:
- computação distribuída: ao serem distribuídos não significa que os índices são simplesmente distribuídos em máquinas diferentes, eles são realmente replicados em clusters diferentes, o que permite a muitos usuários realizar consultas diferentes com baixo tempo de recuperação (sim, grandes empresas podem pagar por isso de máquinas);
- cache: os caches reduzem tremendamente o tempo de execução, seja na etapa de rastreamento, na recuperação de páginas ou na classificação e exposição dos resultados;
- muitos ajustes: todos os algoritmos / soluções acima e muito eficientes só podem ser eficazes se a implementação também for eficiente. Existem toneladas de otimizações (codificadas), como localidade de referência, compactação, cache; todos eles geralmente aplicáveis a diferentes partes do processamento.
Considerando isso, vamos tentar responder às suas perguntas:
mas imagino inviável que os resultados de cada consulta possível sejam indexados
Sim, seria e, na verdade, é inviável ter resultados para todas as consultas possíveis . Existe um número infinito de termos no mundo (mesmo que você assuma que apenas os termos escritos corretamente serão inseridos) e existe um número exponencial de consultas a partir desses n -> inftermos ( 2^n). Então o que é feito? Armazenamento em cache. Mas se houver tantas consultas / resultados, quais armazenar em cache? Políticas de armazenamento em cache. As consultas mais frequentes / populares / relevantes para o usuário são armazenadas em cache.
a latência de hardware no hardware do Google não seria enorme? Mesmo que todos os dados no Google sejam armazenados em SS / TB / s
Atualmente, com esses processadores altamente desenvolvidos, as pessoas tendem a pensar que todas as tarefas possíveis que devem terminar em um segundo (ou menos) e que lidam com tantos dados devem ser processadas por processadores extremamente poderosos, com vários núcleos e muita memória. No entanto, a única coisa que domina o mercado é o dinheiro e os investidores não estão interessados em desperdiçá-lo. Então o que é feito?
A preferência é realmente ter muitas máquinas, cada uma usando processadores simples / acessíveis (em termos de custo), o que reduz o preço da construção da multiplicidade de clusters existentes. E sim, funciona. O principal gargalo sempre se resume ao disco, se você considerar medidas simples de desempenho . Porém, uma vez que existem tantas máquinas, é possível carregar coisas na memória principal, em vez de trabalhar em discos rígidos.
Os cartões de memória são caros para nós, meros seres humanos, mas são muito baratos para empresas que compram muitos desses cartões ao mesmo tempo. Como não é caro, ter muita memória necessária para carregar índices e manter os caches à mão não é um problema. E como existem tantas máquinas, não há necessidade de processadores super rápidos, pois você pode direcionar consultas para locais diferentes e ter agrupamentos de máquinas responsáveis por atender regiões geográficas específicas , o que permite cache de dados mais especializado e resposta ainda melhor vezes.
O MapReduce ajuda a resolver esse problema?
Embora eu ache que o uso ou não do MapReduce seja uma informação restrita no Google, não estou familiarizado com esse ponto. No entanto, a implementação do MapReduce pelo Google (que certamente não é o Hadoop) deve ter muitas otimizações, muitas envolvendo os aspectos discutidos acima. Portanto, a arquitetura do MapReduce provavelmente ajuda a orientar como os cálculos são fisicamente distribuídos, mas há muitos outros pontos a serem considerados para justificar essa velocidade no tempo de consulta.
Ok, entendo que pesquisas populares podem ser armazenadas em cache na memória. Mas e as pesquisas impopulares?
O gráfico abaixo apresenta uma curva de como os tipos de consultas ocorrem. Você pode ver que existem três tipos principais de pesquisas, cada uma contendo aproximadamente 1/3 do volume de consultas (área abaixo da curva). A trama mostra a lei de energia e reforça o fato de que consultas menores são as mais populares. O segundo terço das consultas ainda é possível de processar, uma vez que contêm poucas palavras. Mas o conjunto de chamadas obscuras , que geralmente consistem em consultas de usuários não experientes, não é uma parte desprezível das consultas.
E existe espaço para novas soluções. Como não são apenas uma ou duas consultas (mas um terço delas), elas devem ter resultados relevantes . Se você digitar algo muito obscuro em uma pesquisa no Google, não demorará mais para retornar uma lista de resultados, mas provavelmente mostrará algo que você deduziu . Ou pode simplesmente declarar que não havia documento com esses termos - ou até reduzir sua pesquisa para 32 palavras (o que aconteceu comigo em um teste aleatório aqui).
Existem dezenas de heurísticas aplicáveis, que podem ser para ignorar algumas palavras ou para tentar dividir a consulta em palavras menores e reunir os resultados mais populares . E todas essas soluções podem ser personalizadas e ajustadas para respeitar os tempos de espera viáveis de, digamos, menos de um segundo? : D
O MapReduce não tem nada a ver com nada em tempo real. É uma estrutura de processamento orientada a lotes, adequada para algumas tarefas offline, como ETL e criação de índice. O Google saiu do MapReduce para a maioria dos trabalhos agora, e até o ecossistema Hadoop está fazendo o mesmo.
A resposta para a baixa latência é geralmente manter os índices pré-computados na memória. Qualquer coisa que toque no disco é difícil de ser rápida e dimensionada. É assim que os mecanismos SQL baseados em Hadoop de nova geração, como o Impala, obtêm tanta velocidade em comparação com a infraestrutura baseada no MapReduce como o Hive , por exemplo.
A infraestrutura de pesquisa não pode armazenar em cache os resultados de cada consulta. Mas com certeza pode armazenar em cache resultados intermediários ou resultados mais completos para as principais consultas. Com um pouco de cache, você pode exibir resultados para uma minoria significativa de todas as consultas.
A pesquisa também é dividida entre servidores. Assim, uma máquina pode delegar para 100 para cada uma obter uma parte do resultado e depois combiná-las.
Você também pode se safar com algum grau de aproximação. O Google não forma literalmente mil páginas de resultados de pesquisa; só precisa obter a primeira página da maneira certa.
Lembre-se de que o Google tem milhões de computadores em todo o mundo. Suas consultas estão indo para um data center geograficamente próximo a você e isso serve apenas para sua região geográfica. Isso elimina a maior parte da latência, que é a rede e não o tempo de processamento no data center.
fonte
O MapReduce não é usado na pesquisa. Foi usado há muito tempo para criar o índice; mas é uma estrutura de processamento em lote, e a maior parte da Web não muda o tempo todo; portanto, as arquiteturas mais recentes são todas incrementais em vez de orientadas por lote.
A pesquisa no Google funcionará basicamente da mesma forma que na Lucene e na Elastic Search, exceto por muitas otimizações e ponderações extras. Mas no fundo, eles usarão alguma forma de índice invertido . Em outras palavras, eles não pesquisam vários terabytes quando você insere uma consulta de pesquisa (mesmo quando não está em cache). Eles provavelmente não olham para os documentos reais. Mas eles usam uma tabela de pesquisa que lista quais documentos correspondem ao seu termo de consulta (com stemming, erros de ortografia, sinônimos etc., todos pré-processados). Eles provavelmente recuperam a lista dos 10000 documentos principais para cada palavra (10.000 números inteiros - apenas alguns kb!) E calculam as melhores correspondências a partir disso. Somente se não houver boas correspondências nessas listas, elas serão expandidas para os próximos blocos, etc.
As consultas por palavras comuns podem ser facilmente armazenadas em cache; e por meio do pré-processamento, você pode criar uma lista dos 10 mil principais resultados e, em seguida, refazer a classificação de acordo com o perfil do usuário. Não há nada a ganhar com a computação de uma resposta "exata" também. Olhar para os 10 mil principais resultados é provável; não há resposta correta; e se um resultado melhor em algum lugar na posição 10001 for perdido, ninguém saberá ou notará (ou se importará). Provavelmente, ele já havia sido classificado em pré-processamento e não seria o top 10 apresentado ao usuário no final (ou os três primeiros, o usuário realmente vê)
Termos raros, por outro lado, também não são um grande desafio - uma das listas contém apenas alguns documentos correspondentes e você pode descartar imediatamente todos os outros.
Eu recomendo a leitura deste artigo:
E sim, foram os fundadores do Google que escreveram isso. Não é o estado mais recente, mas já funcionará em uma escala bastante grande.
fonte