In che modo Google memorizza le tendenze di ricerca nel back-end?

Question

In che modo Google memorizza le tendenze di ricerca nel back-end?

#1 da (1 voti)

4

Le tendenze di Google mostrano quale query è stata cercata quante volte e altre proprietà della suddetta query. Ma come vengono memorizzati questi dati in un database?

Memorizzare una nuova riga per ogni ricerca non sembra corretta. Dicono anche la query su un grafico temporale, quindi devono avere un modo per cercare le singole ricerche fatte dagli utenti, ma il numero di query che ottengono ogni giorno, non sembra giusto che memorizzino ogni ricerca in una riga del database insieme a una marca temporale.

Questo non si applica solo alle tendenze di Google o Google in generale, ma a qualsiasi altro sito di grandi dimensioni che ottiene un numero terribile di query e quindi ha strumenti per vederle in profondità. Non sono un esperto in questo, ma sono interessato a conoscere alcune strutture di alto livello su come funzionano le cose dietro le quinte.

database big-data

posta Achshar 21.10.2012 - 21:03

fonte

1 risposta

Leggi altre domande sui tag database big-data

Esiste un'impostazione per abilitare anti-contraffazione a livello globale in ASP.NET MVC e, in caso negativo, perché? Ricompilazione di dll e aggiunta di più durante il runtime: quali sono le mie opzioni?

score 1 · Answer 1

Per essere in grado di fare il grafico temporale dovrebbero memorizzare ogni ricerca, o almeno i timestamp collegati alla voce di ricerca. Questo è probabilmente archiviato in un database distribuito e diviso. Esistono diversi approcci al modo in cui i dati possono essere condivisi, ma è probabile che si tratti di un segreto commerciale insieme a gran parte del design dei motori di ricerca.

Dai loro termini di servizio e dal ritardo nella finalizzazione delle entrate pubblicitarie, sembra che facciano la stessa cosa ogni volta che visualizzano un annuncio.

EDIT: Separando i dati per query (memorizzando tutti i dati per un particolare set di query su un datastore e quelli per altre query su datastore diversi) è abbastanza semplice scalare. Ciascun datastore può avere dimensioni ragionevoli e può essere interrogato e aggiornato rapidamente. Parte del trucco è come decidere quale archivio dati ottiene quali query. Questo può essere regolato nel tempo. In questo caso, se perdi un datastore, perdi solo una porzione verticale (set di query in questo caso) di dati, non l'intero database.

I dati possono essere memorizzati in un modello relazionale tradizionale, nel qual caso l'indice della chiave primaria della tabella degli eventi di query fornirebbe il timestamp per le query. A seconda delle esigenze, potrebbe essere possibile utilizzare uno dei nuovi database noSQL o un altro archivio non relazionale.