Tehnologia căutării: evoluția capacităților de indexare ale motoarelor de căutare

Recent, am realizat câteva teste practice pentru a înțelege mai bine dimensiunea resurselor și costurile implicate de dezvoltarea unui motor de căutare de la zero. Experimentul a constat în scrierea unui script simplu de crawling (parcurgere web) și configurarea unei baze de date relaționale pentru stocarea și indexarea paginilor descărcate. Rezultatele inițiale arată cât de repede explodează cerințele de stocare pe măsură ce volumul de date crește.

Experimentul practic: primele 500 de pagini indexate

În faza de test, scriptul a descărcat și analizat aproximativ 500 de pagini web în doar câteva minute. Datele colectate — structura HTML, textul curățat, metadatele și indecșii asociați — au ocupat în jur de 20 MB în baza de date. Deși cifra pare modestă la prima vedere, extrapolarea acesteia relevă provocările uriașe de infrastructură cu care se confruntă marile motoare de căutare.

Făcând un calcul estimativ pentru a atinge volumele declarate la acea vreme de proiecte precum Cuil (care anunța indexarea a peste 120 de miliarde de pagini), cerințele teoretice de stocare ar fi depășit pragul de 1.000 TB (un petabyte):

• Costul estimativ al mediilor de stocare: la un preț de circa 250 de euro per terabyte pe hard diskuri de clasă server, investiția minimă ajungea la cel puțin 250.000 de euro strict pentru capacitatea de stocare pe disc.
• Infrastructura omisă din calculul simplist: la aceste sume se adaugă serverele de calcul pentru procesare, memoria RAM masivă pentru menținerea indexului inversat, echipamentele de rețea, consumul de energie, răcirea și lățimea de bandă continuă necesară parcurgerii webului.

De la calculul brut la arhitectura reală de căutare

În realitate, un motor de căutare modern nu stochează paginile web sub formă de text brut neoptimizat. Pentru a gestiona miliarde de pagini în mod eficient și economic, companii precum Google au reinventat tehnologia distribuită:

• Sisteme de fișiere distribuite: soluții precum Google File System (GFS) și baze de date distribuite de tip Bigtable împart sarcinile pe mii de noduri hardware accesibile.
• Indexul inversat comprimat (Inverted Index): căutarea rapidă se bazează pe vectori de cuvinte cheie și referințe comprimate masiv, reducând footprint-ul fiecărui document la o fracțiune din dimensiunea inițială.
• Separarea indexului de cache-ul de documente: paginile complete sunt arhivate doar în măsura în care este necesară afișarea unui fragment (snippet), restul procesării bazându-se pe grafuri de legături și tokeni.

Lecția proiectului Cuil și barierele de intrare în industrie

Lansat cu mari speranțe de către o echipă experimentată de foști ingineri Google, motorul de căutare Cuil a demonstrat că un număr mare de pagini indexate pe hârtie nu garantează succesul. Fără un algoritm de relevanță performant, capabil să filtreze duplicatele și conținutul de slabă calitate, capacitatea brută de indexare devine o cheltuială nesustenabilă.

Costurile hardware uriașe și complexitatea matematică din spatele algoritmilor de căutare arată de ce această piață a rămas concentrată în mâinile câtorva giganți capabili să susțină investiții constante în centre de date și infrastructură de calcul distribuit.