Massimo Mantellini scrive che il motore di ricerca della Big G «Fa schifo per scelta aziendale, non per altro, e fa schifo ogni anno di più», e su questo sono abbastanza d’accordo. Tra l’altro ho notato che ormai è spesso impossibile scoprire se un risultato è recente o no senza aprire la pagina, cosa che fa perdere ancora più tempo.
Ma soprattutto scrive che «il punto centrale resta che al momento non esistono alternative serie»; e qui sono estremamente d’accordo. Io continuo a provare nuovi e vecchi motori di ricerca, famosi o di nicchia: per questi ultimi, se siete curiosi, potete guardare per esempio Brave o Marginalia. A parità di stringa, e dopo aver eliminato dai risultati Google tutti i siti “ottimizzati” (o se preferite sponsorizzati), gli altri motori hanno comunque una frazione dei risultati di Google. È possibile che ci sia semplicemente troppa roba in rete, e quindi (a) salvarla costi troppo e (b) persino Google deve trovare un modo di rientrare delle spese. Ma il risultato pratico è che la serendipità nelle ricerche ormai è morta. Il periodo in cui si potevano trovare «testi favolosi ed inaspettati» è stato intenso ma breve.
Bing ormai non se la fila proprio più nessuno, neanche come backup del backup, è finito proprio male.
Sul tema in oggetto, la struttura di costo di un motore di ricerca è principalmente accentrata non tanto sulla collezione di dati in una struttura ad albero più o meno ramificata, ma sul costo computazionale di accesso agli utenti del sistema. Mi spiego: maggiore il numero di query, tanto più il costo si alza, al contrario ad esempio di produrre un oggetto fisico.
Quindi BigG è vittima del suo stesso successo…e qualsiasi “nuovo arrivato” i costi se li deve rifare pure lui, ricadendo nella stessa spirale. Dato che non vedo realisitici piani tariffari di ricerche su abbonamento, penso che ci dovremo convivere.
dici che il costo (computazionale, non di banda ovviamente) sia così alto?
Sì, lo è. Il modello BigG si fonda su una architettura di calcolo distribuito molto elegante ma estremamente granulare. In questo modo si possono gestire in maniera efficace molte operazioni in parallelo, ma con un consumo di risorse più elevato di altre architetture più monolitiche. Inoltre una parte dei nodi è in fuzione del numero di utenti/query da servire, e non in base alla dimensione/profondità dell’albero.
Da qualche parte c’era un paper di Google che descriveva a grandi linee l’architettura, ma non lo ritrovo…:-)