Le ricerche di codice in GitHub sono numerose e devono poter essere anche ampie. Il vantaggio del riuscire a esplorare al suo interno, infatti, è quello di poter spaziare in oltre 200 milioni di repository, senza temere che il sistema arranchi. Per continuare a garantire tutto ciò, dallo scorso novembre, esiste una versione beta, con un nuovo motore di ricerca del codice sorgente. È stato disegnato per allungare la vita a GitHub, rendendolo al passo coi tempi. Con questa mossa, infatti, si dimostrerebbe in grado supportare l’irrefrenabile ondata di innovazione in corso, e perfino di favorirla.
Il cambio motore di GitHub
Molti sistemi e soluzioni si dovrebbero domandare se, in futuro, continueranno a essere funzionali e necessari, garantendo agli utenti competitività. GitHub lo ha fatto, già sapendo che le maggiori criticità avrebbero potuto emergere dal punto di vista “dimensionale”. In un certo senso, infatti, anche quello emerso con la funzione di ricerca codice, lo è. Ed è anche non nuovo per Github che, fin dalla nascita, non ha mai avuto un rapporto sereno con questi engine. Il processo di indicizzazione era spesso complesso e la user experience non entusiasmante.
Per liberarsi da questa “penalty”, si è passati a un motore di ricerca del codice costruito in Rust, per effettuare una ricerca in circa un quarto dei 200 milioni di repository citati. Blackbird, cosí si chiama, si è dimostrato capace di reggere tali volumi, garantendo un buon funzionamento con 45 milioni di repository GitHub, pari a 115 TB di codice e 15,5 miliardi di documenti. Innovazione disruptive premiata.
Nulla di paragonabile, infatti, a ciò che permette di fare grep, uno strumento a riga di comando comune sui sistemi Unix per la ricerca di dati di testo. Restando fermi a questo strumento, ci si dovrebbe accontentare di performance molto più modeste e, persino, incompatibili con un utilizzo agile di GitHub.
Data una CPU Intel a 8 core, per eseguire una query su un file da 13 GB ci potrebbero volere quasi 3 secondi. Una quantità di tempo di attesa che diventa inaccettabile, alla luce della quantità di dati in possesso di GitHub. Senza contare il fatto che ciascuna query andrebbe eseguita da sola, tutte le altre resterebbero in fila di attesa.
Database più ampi richiedono motori potenti
Di fronte a uno 0,01 query al secondo assicurato con grep, GitHub ha compreso di dover cambiare approccio. Per prima cosa, si è portato avanti, caricando in anticipo una parte del lavoro sugli indici di ricerca precalcolati. Lo ha fatto utilizzando mappe di coppie chiave-valore, un “trucco” utile per minimizzare la richiesta di capacità di computing per ogni ricerca. Meno impegnativi, con questo approccio, anche il linguaggio di programmazione o le sequenze di parole, ora che una semplice chiave numerica ha sostituito una stringa di testo.
Per inserire tali indici nella memoria, è stato necessario ridurre ancora con le dimensioni. Stavolta GitHub ha costruito degli iteratori per ogni indice a cui doveva accedere. L’idea era di farsi restituire gli ID dei documenti ordinati che rappresentano il rango del documento associato e che soddisfano i criteri della query.
Un altro aspetto importante è rappresentato dalla gestione degli indici di ricerca. Per renderla più agile, si è puntato sullo sharding. Questa tecnica prevede la suddivisione dei dati con lo schema di hashing indirizzabile al contenuto di Git, e la memorizzazione delle differenze di dati (delta) per ridurre i dati e i metadati, da sottoporre a crawling (codifica delta).
Così procedendo, i 115 TB “iniziali” di dati si riducono a 25 TB. A livello pratico, il sistema risultante funziona molto più velocemente di grep: 640 query al secondo invece che 0,01. Questo nuovo motore di ricerca è attualmente in fase di beta testing, con il nome di GitHub Code Search. In attesa che se ne verifichino il funzionamento e le performance, si amplia lo sguardo sul panorama sempre più data driven che si sta prefigurando agli orizzonti. In ogni settore e contesto, la quantità di dati a disposizione aumenta vertiginosamente.
Prima o poi, tutti si troveranno a doversi curare dell’efficacia del proprio motore di ricerca. La soluzione non sarà unica ma cercarla sarà necessaria, per soddisfare un utente che desidera estrarre il massimo valore da qualsiasi database abbia tra le mani.
