Bene, non sono sicuro che sia MapReduce a risolvere il problema, ma sicuramente non sarebbe MapReduce da solo a risolvere tutte queste domande che hai sollevato. Ma qui ci sono cose importanti da prendere in considerazione, e che lo fanno possibile avere una latenza così bassa sulle query da tutti questi TB di dati in macchine diverse:
- calcolo distribuito: essendo distribuito non significa che gli indici siano semplicemente distribuiti su macchine diverse, in realtà vengono replicati lungo cluster diversi, il che consente a molti utenti di eseguire query diverse con tempi di recupero ridotti (sì, le grandi aziende possono permetterselo di macchine);
- memorizzazione nella cache: le cache riducono enormemente i tempi di esecuzione, sia per la fase di scansione, per il recupero delle pagine, sia per la classificazione e la visualizzazione dei risultati;
- molte modifiche: tutto quanto sopra e algoritmi / soluzioni molto efficienti possono essere efficaci solo se l'implementazione è anche efficiente. Ci sono tonnellate di ottimizzazioni (hard coded), come località di riferimento, compressione, memorizzazione nella cache; tutti generalmente applicabili a diverse parti dell'elaborazione.
Considerando ciò, proviamo a rispondere alle tue domande:
ma immagino che sia impossibile indicizzare i risultati di ogni singola query possibile
Sì, lo sarebbe, ed effettivamente non è possibile avere risultati per ogni singola query possibile . Esiste un numero infinito di termini nel mondo (anche se si presume che verranno inseriti solo termini scritti correttamente) e esiste un numero esponenziale di query da questi n -> inftermini ( 2^n). Quindi cosa si fa? Caching. Ma se ci sono così tante query / risultati, quali memorizzare nella cache? Politiche di memorizzazione nella cache. Le query più frequenti / popolari / pertinenti per l'utente sono quelle memorizzate nella cache.
la latenza dell'hardware nell'hardware di Google non sarebbe enorme? Anche se i dati in Google erano tutti archiviati in SSD TB / s
Al giorno d'oggi, con processori così altamente sviluppati, le persone tendono a pensare che ogni possibile compito che deve finire in un secondo (o meno) e che si occupa di così tanti dati, debba essere elaborato da processori estremamente potenti con più core e molta memoria. Tuttavia, l'unica cosa dominante mercato è il denaro e gli investitori non sono interessati a sprecarlo. Quindi cosa si fa?
La preferenza è in realtà avere molte macchine, ognuna delle quali utilizza processori semplici / accessibili (in termini di costi), il che riduce il prezzo di costruzione della moltitudine di cluster che ci sono. E sì, funziona. Il principale collo di bottiglia si riduce sempre al disco, se si considerano semplici misurazioni delle prestazioni . Ma una volta che ci sono così tante macchine, ci si può permettere di caricare le cose nella memoria principale, invece di lavorare su dischi rigidi.
Le schede di memoria sono costose per noi, semplici esseri umani, ma sono molto economiche per le aziende che acquistano molte di queste carte contemporaneamente. Poiché non è costoso, disporre di molta memoria necessaria per caricare gli indici e tenere a portata di mano le cache non è un problema. E poiché ci sono così tante macchine, non è necessario disporre di processori super veloci, poiché è possibile indirizzare query in luoghi diversi e disporre di cluster di macchine responsabili della partecipazione a specifiche aree geografiche , il che consente una memorizzazione dei dati più specializzata e una risposta ancora migliore volte.
MapReduce aiuta a risolvere questo problema?
Anche se non credo che l'utilizzo o meno di MapReduce sia limitato alle informazioni all'interno di Google, non sono a conoscenza di questo punto. Tuttavia, l'implementazione di Google di MapReduce (che sicuramente non è Hadoop) deve avere molte ottimizzazioni, molte delle quali riguardano gli aspetti discussi sopra. Quindi, l'architettura di MapReduce probabilmente aiuta a guidare il modo in cui i calcoli sono fisicamente distribuiti, ma ci sono molti altri punti da considerare per giustificare tale velocità nei tempi di interrogazione.
Va bene, quindi capisco che le ricerche popolari possono essere memorizzate nella cache. Ma per quanto riguarda le ricerche impopolari?
Il grafico seguente mostra una curva di come si verificano i tipi di query. Puoi vedere che ci sono tre tipi principali di ricerche, ognuna delle quali contiene circa 1/3 del volume di query (area sotto la curva). La trama mostra la legge del potere e rafforza il fatto che le query più piccole sono le più popolari. È ancora possibile elaborare il secondo terzo delle query, poiché contengono poche parole. Ma l'insieme delle cosiddette query oscure , che di solito consistono in query di utenti non esperti, non è una parte trascurabile delle query.
E c'è spazio per nuove soluzioni. Dal momento che non sono solo una o due query (ma un terzo di esse), devono avere risultati pertinenti . Se digiti qualcosa di troppo oscuro in una ricerca di Google, non ci vorrà più tempo per restituire un elenco di risultati, ma molto probabilmente ti mostrerà qualcosa che ha dedotto che vorresti dire. Oppure potrebbe semplicemente affermare che non esisteva un documento con tali termini - o addirittura ridurre la tua ricerca a 32 parole (cosa che mi è appena capitata in un test casuale qui).
Esistono dozzine di euristiche applicabili, che possono essere o ignorare alcune parole o provare a suddividere la query in parole più piccole e raccogliere i risultati più popolari . E tutte queste soluzioni possono essere personalizzate e ottimizzate per rispettare i tempi di attesa fattibili , diciamo, meno di un secondo? : D