![]() |
![]() |
|
Ti stiamo aspettando: Registrati subito e gratis. Entra a far parte di una delle comunità più attive in Italia. Se hai dimenticato i tuoi dati li puoi recuperare subito. Video IV Convegno gt guarda in video le relazioni dei migliori Esperti SEO Italiani: clicca qui.Esperienze, conoscenze, tecniche in 14 ore di pura condivisione SEO. |
|
|||||||||
Hey Amico Visitatore, Condividi con noi le tue idee e la tua conoscenza Aprendo una nuova discussione nella sezione SEO Focus |
|
|
LinkBack (6) | Strumenti di discussione |
|
|
#16 (permalink) |
|
Di questo abbiamo parlato nel Botta e Risposta (un Live Forum). Non so se Nicola ha in mente di fare un piccolo riassunto
![]() | |
|
__________________
Tutte le anticipazioni ed i segreti di gt su Twitter! Giorgio Taverniti Blog ![]() PRONTI I VIDEO DEL IV CONVEGNO GT |
|
|
|
|
|
|
#17 (permalink) |
|
Esperto
Data di 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 |
|
|
|
|
|
|
#18 (permalink) | |||||||
|
ModSenior
|
Quote:
Quote:
Quote:
) di ogni successiva elaborazione (ranking)Quote:
Quote:
Quote:
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 )Quote:
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 - 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 21:18. |
||||||||
|
|
|
| Tags: big table, bigtable, brevetti, brevetti google, dati storici, google big table, google bigtable |
| Strumenti di discussione | |
|
|
LinkBacks (?)
LinkBack to this Thread: http://www.giorgiotave.it/forum/seo-focus/23768-google-bigtable-e-l-archiviazione-dei-dati-storici-e-altre-congetture.html
|
||||
| Scritto da | For | Type | Data | |
| bufferOverflow » Blog Archive » BigTable, SimpleDB, Ec2 e S3: cloud computing per tutti? | This thread | Pingback | 07-04-08 02:19 | |
| La grande memoria di Google: i dati di storico | This thread | Pingback | 05-02-07 14:10 | |
| Top Ten Hit Parade Web Marketing Dicembre 2006 | Post #1 | Pingback | 08-01-07 11:47 | |
| SpazioDigitale (blog) » Blog Archive » Forum GT: i thread di dicembre | This thread | Pingback | 03-01-07 21:51 | |
| Hit Parade Del Web Marketing / Seo - Primo Appuntamento Dicembre 2006 | Post #1 | Pingback | 08-12-06 12:34 | |
| » Google BigTable: come li incamera i dati? - Web Marketing e Posizionamento | This thread | Pingback | 05-12-06 01:52 | |