Google BigTable e l’archiviazione dei dati storici (…e altre congetture)

[Giorgiotave]

Di questo abbiamo parlato nel Botta e Risposta (un Live Forum). Non so se Nicola ha in mente di fare un piccolo riassunto

[Ray71]

Ho letto il thread con interesse. Volevo fare qualche commento anche prima ma poi me ne sono scordato...
Dopo aver letto il messaggio di Jeff Dean (e considerando anche i nomi dei progetti nella tabella allegata) credo che la cosa vada interpretata cosi':

Il progetto Crawl riguarda evidentemente gli spider, e non l'indicizzazione (sono due fasi ben diverse).

A occhio e croce, la tabellona piu grande contiene il contenuto vero e proprio delle pagine (piu' vari dati aggiuntivi, tipo http headers, content-type, data, eventuali redirect etc.).

La tabella piu' piccola invece contiene probabilmente soltanto lo stato degli URL da scaricare (e/o scaricati), informazioni quali l'IP, la frequenza con cui "colpire" l'host, eventuali errori/redirect/404 etc., magari qualche informazione su PR, priorita' con cui selezionare gli URL per il crawling, chissa' forse pure qualche info su eventuali sitemaps etc.

Non credo invece che, queste tabelle, contengano informazioni particolari per il ranking vero e proprio (tra il crawling e il ranking ci sono diversi passi intermedi), e poi mi sembra di capire che Jeff Dean ( http://labs.google.com/people/jeff/ ) si occupi piu' di infrastruttura che di "search quality".

Per quanto riguarda i "locality groups" credo che siano principalmente una questione di ottimizzazione (per le performances), cioe' se programmi diversi accedono a gruppi diversi di colonne, possono limitarsi a leggere solo le colonne che gli interessano, invece di caricare l'intera riga.

Considera che qui stiamo parlando di tabellone costruite ad-hoc, non tabelle di database SQL, e non e' possibile formulare queries sql complicate, per cui, se ho capito bene l'articolo, secondo me, questi locality groups sono l'equivalente di query sql precompilate, cioe' se un programma ha bisogno di leggere solo le colonne x,y,z viene creato un locality-group per queste tre colonne (e quindi i dati relativi a queste colonne vengono affidati alle stesse macchine).

Infine, credo che prima di pubblicare l'articolo, sia stato passato sotto esame da gente tipo Matt Cutts per filtrare eventuali informazioni che potessero essere di aiuto ai SEO ;-)

[nbriani]

Ray71

Ho letto il thread con interesse. Volevo fare qualche commento anche prima ma poi me ne sono scordato...

Grazie, per essertene "ricordato"

Ray71

Dopo aver letto il messaggio di Jeff Dean (e considerando anche i nomi dei progetti nella tabella allegata) credo che la cosa vada interpretata cosi':

Il progetto Crawl riguarda evidentemente gli spider, e non l'indicizzazione (sono due fasi ben diverse).

Infatti, avevo fatto una supposizione errata.. lo stesso Dean (Jeff per gli amici! ) lo dice chiaramente, l'indicizzazione non sta in Big Table...

Ray71

A occhio e croce, la tabellona piu grande contiene il contenuto vero e proprio delle pagine (piu' vari dati aggiuntivi, tipo http headers, content-type, data, eventuali redirect etc.).

La tabella piu' piccola invece contiene probabilmente soltanto lo stato degli URL da scaricare (e/o scaricati), informazioni quali l'IP, la frequenza con cui "colpire" l'host, eventuali errori/redirect/404 etc., magari qualche informazione su PR, priorita' con cui selezionare gli URL per il crawling, chissa' forse pure qualche info su eventuali sitemaps etc.

Quoto. La tabellona contiene "the full contents" (Jeff) delle pagine web... a mio giudizio quindi i "parametri di base" (16 tipologie? ) di ogni successiva elaborazione (ranking)

Ray71

Non credo invece che, queste tabelle, contengano informazioni particolari per il ranking vero e proprio (tra il crawling e il ranking ci sono diversi passi intermedi), e poi mi sembra di capire che Jeff Dean ( http://labs.google.com/people/jeff/ ) si occupi piu' di infrastruttura che di "search quality".

Infatti. Punto cruciale ... chiaro che il ranking è un altra cosa e probabilmente come dici tu gli algoritmi si basano anche su tabelle di dati ulteriori ... ma l'impressione che ho è che comunque la base di queste, gli ingredienti "primordiali" di algoritmi "di ranking" (o che comunque elaborino parametri ai fini del ranking) possano essere proprio quelli in quella grande prima tabellona...

Ray71

Per quanto riguarda i "locality groups" credo che siano principalmente una questione di ottimizzazione (per le performances), cioe' se programmi diversi accedono a gruppi diversi di colonne, possono limitarsi a leggere solo le colonne che gli interessano, invece di caricare l'intera riga.

Considera che qui stiamo parlando di tabellone costruite ad-hoc, non tabelle di database SQL, e non e' possibile formulare queries sql complicate, per cui, se ho capito bene l'articolo, secondo me, questi locality groups sono l'equivalente di query sql precompilate, cioe' se un programma ha bisogno di leggere solo le colonne x,y,z viene creato un locality-group per queste tre colonne (e quindi i dati relativi a queste colonne vengono affidati alle stesse macchine).

si esatto è quello che ho capito anchio...

Ray71

Infine, credo che prima di pubblicare l'articolo, sia stato passato sotto esame da gente tipo Matt Cutts per filtrare eventuali informazioni che potessero essere di aiuto ai SEO ;-)

Certo, certo... indiscutibile... comuque, come detto anche al convegno, non è per carpire segreti SEO che è interessante approfondire, ma capire il funzionamento generale del motore di certo aiuta a farci far valutare piu' correttamente il "seo quotidiano" e tutto il suo mondo di ipotesi e teorie....

(per la cronaca, oggi ho scritto pure a Matt Cutts ... vediamo se dice qualcosa al riguardo... gli ho solo chiesto "Bigaddy=Bigtable?" Tra le altre cose il nome Bigdaddy era a sentire Cutts, il nomignolo con cui i bambini chiamavano un webmaster conosciuto durante un incontro il cui nick è .... JEFFM ! ... )

giorgiotave

Di questo abbiamo parlato nel Botta e Risposta (un Live Forum). Non so se Nicola ha in mente di fare un piccolo riassunto

Bè... ancora? .. dopo lo scherzetto al convegno (ancora devo smaltire adrenalina ed emozione) ... ancora un intervento , vuoi?

Faccio un estremissima sintesi:

BigTable (sistema di archiviazione in funzione da fine 2005 per diverse applicazioni di Google, tra cui il motore stesso)

1° conclusione : Dati storici e brevetti (?) (L'articolo su BigTable rivela che la storicizzazione dei dati, qualunque essi siano, è nativa e standard in BigTable) ora siamo certi che Google puo' tenerne conto!

2° conclusione (azzardata) : Probabilmente l'analisi fatta con paocavo qui, relativamente ai metodi di tracciamento di dati storici (nel caso specifico il numero di BL di un documento) tramite "punti discreti" è plausibile!

1° ipotesi (azzardata) : BigDaddy = Bigtable ?

2° Ipotesi (iper-azzardata ) : La tabella riassuntiva esposta nell'articolo ci dice diverse cose interessanti sull'archivio di Google

- circa 100/200 dati mediamente archiviati per documento e 16/18 tipologie di dati .... 1000 miliardi di celle occupate per 10 miliardi di documenti, plausibile?
- quindi un numero limitato di "timestamps"? (cioè di intervalli di dati archiviati)

altre idee?