[Brevetti Google] Sistema e metodo per focalizzare la ricerca in parti del database

[Giorgiotave]

Apprendo da Seobythesea il rilascio di un nuovo brevetto da parte di Google: Sistema e metodo per focalizzare la ricerca in parti del database (spero sia corretto).

Abstract

When a search query is received, a plurality of partition indexes are searched using the set of search terms in the search query. Each partition index corresponds to a partition of a document index. The search of each respective partition index identifies a subset of a plurality of document index sub-partitions corresponding to the respective partition index. Next, the search query is executed by only those document index sub-partitions identified by the subsets, thereby identifying documents that satisfy the search query. By using the partition index to reduce the number of document index sub-partitions searched while executing a search query, the execution of the search query is made more efficient.

Bill Slawski si chiede, se non sbaglio, se c'entra qualcosa si Risultati Supplementari?

Is this extended index what we have been referring to as Google’s supplemental index? It could possibly be, or could have been. A recent blog post at the Official Google Webmaster Central Blog on supplemental results, Supplemental goes mainstream, tells us that Google is going to stop labeling supplemental results as “supplemental” because the differences between main index and supplemental index results is growing narrower, and supplemental results are now fresher and more comprehensive than they have ever been.

Cosa ne pensate?

[mister.jinx]

E' da un pò che Google contribuisce al progetto Hibernate, proprio sul settore del partizionamento orizzontale (sottoprogetto Shards).

[petro]

Giorgiotave

Cosa ne pensate?

Bingo!
è la prova di una cosa che avevo notato e sulla quale volevo fare un test, ma ora non ce n'è più bisogno perchè ho la certezza che già la usano.

Ciò che avevo notato non ha nulla a che fare coi supplementari, vado a illustrare.

L'ipotesi era questa: volevo dimostrare che in una serp, all'interno di una singola pagina di risultati, confluissero contemporaneamente informazioni provenienti da più di un indice (database).

Come me ne sono accorto?

1. Ho fatto indicizzare un dominio A, poi ho creato un terzo livello di un dominio B.
   
2. Il sottodominio del dominio B era nuovo di pacca, mai esistito prima, e non ha mai ricevuto alcun backlink, mentre invece il dominio A era indicizzato.
   
3. In queste condizioni, ho eseguito un redirect 301 dal dominio A al sottodominio del dominio B.
   
4. Lo spider ha seguito il redirect di A, ed ha trovato ed indicizzato il sottodominio B.
   
5. L'unico modo in cui può aver trovato il sottodominio B è proprio attraverso il redirect, perchè sottodominio B non ha mai ricevuto backlinks, nè visite (fino a quel momento i log erano immacolati).
   
6. Google avrebbe quindi dovuto de-indicizzare il dominio A, o meglio trasferire tutte le informazioni che aveva su A verso il sottodominio B, e contemporaneamente rimuovere A dall'indice (quello che succede normalmente col 301)
   
7. Se non che, ad un certo punto, nella stessa serp comparivano contemporaneamente sia il dominio A che il sottodominio B.
   
8. Dopo qualche giorno, tutto è tornato alla normalità: dominio A è stato deindicizzato, e le informazioni sono state trasferite al sottodominio B.
   
9. Ma per un periodo hanno convissuto nella medesima serp, e non potevano che provenire da due indici distinti e non sincronizzati.

Avrei voluto mettere un test per avere la conferma definitiva, ma questo brevetto descrive esattamente (anche) questo comportamento:

# The use of a cache to return results for popular searches,
# How terms may be mapped to different partitions and sub partitions

Il resto del brevetto me lo studio con calma al ritorno dalle ferie, per adesso basta SEO.

Buon ferragosto a tutti

[beke]

petro

...Ma per un periodo hanno convissuto nella medesima serp, e non potevano che provenire da due indici distinti e non sincronizzati....

Non lo so Petro...
Oggi in treno, come ultima azione SEO prima dell'inizio delle ferie, ho dato un'occhiata al paper in questione e a me sembra che parli di tecniche per trattare in modo separato determinate parti di uno stesso indice e non di un sistema per ordinare dati provenienti da indici diversi.

Non credo che possa giustificare il tipo di fenomeno a cui tu hai assistito.

Credo invece, anche se nel documento questo non viene mai menzionato in modo esplicito, che si tratti del modo in cui zio Google tratta (trattava? Boh...) i risultati supplementari.

[fdaguanno]

petro

e non potevano che provenire da due indici distinti e non sincronizzati

In base a quale legge ? Non credo dipenda da una limitazione del database, che non accetti due record (quasi) identici (l'ho detta in maniera semplicistica, ma spero sia chiaro il senso )...

petro

perché sottodominio B non ha mai ricevuto backlinks, nè visite (fino a quel momento i log erano immacolati)

Per log intendi i "log del webserver" ? Intendi dire che oltre ai visitatori, non era passato neanche uno spider ? Mi sembra strano che Google mostri risultati solo in base ad un redirect, senza prima aver controllato di "persona"...

petro

volevo dimostrare che in una serp, all'interno di una singola pagina di risultati, confluissero contemporaneamente informazioni provenienti da più di un indice (database)

Non ho ancora capito bene quale sia l'idea comune... Ma dite un po', credete che Google tenga miliardi di record un un'unica tabella e in unico database ? Ho lavorato per qualche tempo con database che gestivano centinaia di milioni di record (ma mai miliardi per tabella, e neanche per database) e penso fermamente che i dati degli indici di Google risiedano su più tabelle e quasi di sicuro su più database, in base a qualche strano criterio di archiviazione. Purtroppo non ne ho le prove, ma credo che non ci siano neanche le prove per escluderlo.

Ciao.

[Giorgiotave]

Ciao Francesco e Benvenuto nel Forum GT

ti volevo segnalare questo thread, forse ti può interessare: Google BigTable e l’archiviazione dei dati storici

Buon Forum GT