+ Rispondi alla Discussione
Pagina 2 di 2 PrimaPrima 12
Risultati da 16 a 19 di 19

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

Ultimo Messaggio di Giorgiotave il:
  1. #16
    L'avatar di Giorgiotave
    Data Registrazione
    Oct 2004
    Località
    Monasterace
    Messaggi
    36,020
    Segui Giorgiotave su Twitter Aggiungi Giorgiotave su Google+ Aggiungi Giorgiotave su Facebook Aggiungi Giorgiotave su Linkedin Visita il canale Youtube di Giorgiotave
    Di questo abbiamo parlato nel Botta e Risposta (un Live Forum). Non so se Nicola ha in mente di fare un piccolo riassunto
    Giorgio Taverniti Blog. Ciao Architè!
    Ecco il Corso SEO per il 2013...completo, 25 ore, molte lezioni live: scopri tutto il programma!
    A Roma, il 28 Giugno, arriva il Festival del Web Marketing: WebReevolution!

  2. #17
    Esperto
    Data Registrazione
    Apr 2006
    Messaggi
    94
    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 ;-)

    Shades by Everfluxx

  3. #18
    Esperto L'avatar di nbriani
    Data Registrazione
    May 2005
    Località
    Firenze
    Messaggi
    1,938
    Citazione Originariamente Scritto da Ray71
    Ho letto il thread con interesse. Volevo fare qualche commento anche prima ma poi me ne sono scordato...
    Grazie, per essertene "ricordato"

    Citazione Originariamente Scritto da 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...


    Citazione Originariamente Scritto da 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)

    Citazione Originariamente Scritto da 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...

    Citazione Originariamente Scritto da 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...

    Citazione Originariamente Scritto da 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 ! ... )

    Citazione Originariamente Scritto da 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?
    Ultima modifica di nbriani; 13-12-06 alle 19:18

  4. #19
    L'avatar di Giorgiotave
    Data Registrazione
    Oct 2004
    Località
    Monasterace
    Messaggi
    36,020
    Segui Giorgiotave su Twitter Aggiungi Giorgiotave su Google+ Aggiungi Giorgiotave su Facebook Aggiungi Giorgiotave su Linkedin Visita il canale Youtube di Giorgiotave
    Giorgio Taverniti Blog. Ciao Architè!
    Ecco il Corso SEO per il 2013...completo, 25 ore, molte lezioni live: scopri tutto il programma!
    A Roma, il 28 Giugno, arriva il Festival del Web Marketing: WebReevolution!

+ Rispondi alla Discussione
Pagina 2 di 2 PrimaPrima 12

Tag per Questa Discussione

^ Permessi di Scrittura

  • Tu non puoi inviare nuove discussioni
  • Tu non puoi inviare risposte
  • Tu non puoi inviare allegati
  • Tu non puoi modificare i tuoi messaggi
  •  
  • Il codice BB è Attivato
  • Le faccine sono Attivato
  • Il codice [IMG] è Attivato
  • Il codice [VIDEO] è Attivato
  • Il codice HTML è Disattivato
  • Trackbacks Attivato
  • Pingback Attivato
  • Refback Attivato

SEO by vBSEO 3.6.0 PL2 ©2011, Crawlability, Inc.