Menu
Menu
Contattaci
Il nostro settore richiede uno studio continuo e una forte attenzione all’innovazione. Incentiviamo quindi dei programmi formativi annuali per tutti i componenti del team, con ore dedicate (durante l’orario di lavoro) e serate formative sia online che in presenza. Sponsorizziamo eventi, sia come partner che semplicemente come partecipanti, e scriviamo articoli su quello che abbiamo imparato per essere, a nostra volta, dei divulgatori.
Vai alla sezione TeamAl giorno d’oggi, i motori di ricerca assumono un ruolo sempre più centrale nella vita delle persone: grazie ad essi restiamo aggiornati sul mondo che ci circonda, recuperiamo informazioni utili per il lavoro e per le nostre passioni.
Esiste tuttavia una seconda tipologia di ricerca, meno conosciuta al grande pubblico e ai non addetti del settore: quella dedicata alle realtà aziendali più o meno grandi, denominata per questo motivo Business (o Enterprise) Search.
Varie soluzioni software permettono di implementare paradigmi di ricerca nei processi aziendali, spesso con sforzo minimo da parte dello sviluppatore.
Tra le soluzioni dedicate principalmente agli ecommerce, vale la pena ricordare Doofinder e cVetta. Grazie ad un approccio cloud-first, questi software si integrano facilmente in molti tipi di ambienti e riducono in modo significativo il Time To Market delle funzionalità di ricerca, migliorando la UX dei siti web in cui vengono inseriti, a vantaggio sia del cliente che del venditore.
Per quanto interessanti dal punto di vista architetturale, gli ecommerce sono solo la punta dell’iceberg della Business Search: spesso le aziende sono interessate ad indicizzare documenti interni o dati sensibili, allo scopo di facilitarne la ricerca da parte dei dipendenti e del management.
La natura di questi dati può suggerire di mantenerne la ownership; soluzioni come le precedenti diventano poco praticabili, o quantomeno non opportune in contesti in cui la sicurezza è fondamentale.
Vengono quindi in nostro aiuto due piattaforme di ricerca che permettono di realizzare motori di Enterprise Search verticali con relativa facilità, mantenendo la data ownership e impiegando politiche più o meno stringenti di controllo degli accessi: Solr e elasticsearch.
Sulla carta le due piattaforme software sembrano simili, sono infatti basate entrambe sulla libreria di ricerca Apache Lucene, tuttavia vi sono caratteristiche e peculiarità che potrebbero farci propendere per l’una o l’altra soluzione, come andremo a scoprire nel seguito di questo articolo.
Solr (si pronuncia “solar”) è un software libero completamente open source, distribuito sotto licenza Apache 2.0, che ne permette la ridistribuzione e l’utilizzo in opere derivative.
Originariamente creato nel 2004 da Yonik Seeley è stato poi donato alla Apache Software Foundation, che lo sviluppa e lo gestisce fin dal 2006.
Solr è il più “anziano” dei contendenti, elasticsearch è nato infatti solo 6 anni più tardi, nel 2010. Sebbene negli ultimi anni la popolarità di Solr sia in declino, non dobbiamo farci spaventare dalla sua età anagrafica: è un progetto attivamente sviluppato, la cui nuova versione, che utilizzerà Lucene 9.0, è in dirittura d’arrivo.
La popolarità passata di Solr e il grande impiego che se ne fa nell’industria, rendono estremamente facile trovare documentazione attendibile e aggiornata.
Solr utilizza una REST API per l’indicizzazione dei documenti e l’interrogazione dell’indice, può quindi essere integrato facilmente con tecnologie eterogenee.
Originariamente, Solr utilizzava un approccio basato su uno schema di dati, era quindi impossibile utilizzarlo senza descrivere accuratamente la struttura dei dati da indicizzare. Da un po’ di tempo questa barriera è caduta, e adesso Solr può essere utilizzato in modalità schemaless, esattamente come elasticsearch.
L’obiettivo di Solr è quello di fornire una tela su cui costruire il proprio motore di ricerca in modo abbastanza verticale, per questo è spesso utlizzato in contesti Enterprise di ricerca “classica”. In questo senso alcuni potrebbero considerarlo meno versatile rispetto ad elasticsearch, ma teniamo a sottolineare che tutto dipende dall’utilizzo che si fa dello strumento.
Elasticsearch, rilasciato per la prima volta nel 2010, è espressione diretta dell’azienda Elastic NV, che si occupa di svilupparlo e di vendere lo stack tecnologico che gli sta intorno; Elastic NV offre inoltre dei piani di deployment per elasticsearch sul proprio Elastic Cloud proprietario.
Il codice sorgente di elasticsearch è disponibile, tuttavia a seguito di un cambio di licensing lo status “open source” del progetto è dibattuto, dal momento alcuni esperti del settore non riconoscono la licenza duale sotto cui è distribuito come licenza open source.
Recentemente un team guidato da Amazon Web Services ha effettuato un fork dello stack di elasticsearch, per proseguirne lo sviluppo con licenza opensource, sotto il nome di OpenSearch.
Allo stesso modo di Solr, Elasticsearch è basato su Lucene, ed utilizza anch’esso un approccio RESTful per la consumazione delle query di ricerca da parte dei client. Elasticsearch supporta dati schemaless dalle primissime versioni rilasciate: ben prima che lo permettesse anche Solr.
Il focus del progetto non è solo quello di fornire una piattaforma di creazione di motori di ricerca Enterprise, ma anche di permettere query di tipo analitico su elevate quantità di dati e di facilitare la creazione di data visualizations, grazie alla sua integrazione con Kibana nello stack ELK. Nonostante ciò, elasticsearch può comunque essere utilizzato in contesti di ricerca più classici, come mostreremo nel seguito.
Altra caratteristica di elasticsearch molto apprezzata dalla comunità e pubblicizzata da Elastic NV, è la scalabilità orizzontale che lo contraddistingue, e che permette di gestire con relativa facilità situazioni in cui il carico operativo cambia rapidamente.
Per testare le capacità di indicizzazione delle due soluzioni utlizzeremo parte di un dataset di libri pubblicamente disponibile su Kaggle in formato csv; imposteremo sia Solr che elasticsearch in modalità schemaless, ottima per iniziare e testare il nostro indice; qualora volessimo spostarci in produzione, il consiglio è sempre quello di definire esplicitamente uno schema di dati per beneficiare delle possibili ottimizzazioni di Lucene.
Per comodità, e per evitare di sporcare il nostro filesystem, eseguiremo i due software all’interno di due container Docker, ottenuti dalle immagini ufficiali di Solr e elasticsearch.
Per indicizzare i dati in Solr, iniziamo lanciando un’istanza vuota in modalità schemaless:
docker run -p 8983:8983 -t solr solr-precreate schemaless
Procediamo dunque all’indicizzazione dei dati utilizzando cURL:
curl 'http://localhost:8983/solr/schemaless/update?commit=true' --data-binary
@GoodReads_100k_books.csv -H 'Content-type:application/csv
Utilizzando il comando curl http://localhost:8983/solr/schemaless/schema/fields possiamo verificare lo schema del nostro indice a seguito del guessing automatico effettuato da Solr, mostriamo una parte della risposta per ragioni di spazio:
{
"responseHeader":{
"status":0,
"QTime":0},
"fields":[{
"name":"_author",
"type":"text_general"},
{
"name":"_nest_path_",
"type":"_nest_path_"},
...
{
"name":"title",
"type":"text_general"},
{
"name":"totalratings",
"type":"plongs"}]}
Possiamo vedere che Solr ci fornisce informazioni sui tipi di dato, inferiti a tempo di indicizzazione. Il campo “QTime” indica i millisecondi intercorsi tra l’arrivo della richiesta e la riposta del query handler, e può essere usato per avere un’idea generale del tempo di esecuzione delle query.
Una differenza importante rispetto a Solr, è quella di dover aumentare il limite di spazio di indirizzamento virtuale del sistema operativo, nel nostro caso una istanza WSL2 Ubuntu 20.04, all’interno della quale è presente il runtime di docker. A tale scopo utilizziamo il comando sysctl-w vm.max_map_count=262144 , come suggerito dalla guida ufficiale per aumentarla Proseguiamo lanciando elasticsearch in modalità di sviluppo single node con i seguenti comandi:
docker run --name es01 --net elastic -p 9200:9200 -p 9300:9300 -it
docker.elastic.co/elasticsearch/elasticsearch:8.0.0
Elasticsearch non supporta indexing diretto da file csv, tuttavia a partire dalla versione 5.0 è presente un Ingest Node per eseguire questo tipo di operazioni. Si può anche utilizzare Logstash, per programmare una pipeline di data ingestion. Noi proseguiremo utilizzando la UI fornita da Kibana, per comodità.
Creiamo quindi un container con Kibana utilizzando docker:
docker run --name kibana --net elastic -p 5601:5601
docker.elastic.co/kibana/kibana:8.0.0
A questo punto, è possibile importare il nostro csv semplicemente dall’interfaccia web. L’approccio schemaless di elasticsearch e Kibana produce il seguente schema, abbreviato per semplicità:
{
"properties": {
"author": {
"type": "text"
},
"bookformat": {
"type": "keyword"
},
...
"title": {
"type": "text"
},
"totalratings": {
"type": "long"
}
} }
Tramite Kibana possiamo testare il nostro indice, similarmente a quanto è possibile fare con il pannello admin di Solr. Kibana usa un linguaggio di query specifico per dialogare con il server elasticsearch sottostante.
Abbiamo visto come il procedimento per l’indicizzazione dei dati presenti delle differenze e delle peculiarità proprie di ciascuno dei due software.
Grazie alla sua integrazione con Kibana, elasticsearch si dimostra estremamente versatile: esistono infatti molti plugin che permettono di effettuare le più disparate conversioni di dati e di produrre data visualizations ricche di potenza espressiva, particolarmente utili per fini di business analytics.
Solr, dal canto suo, sembra essere più votato alla business search “classica”; un suo punto di forza è senza dubbio la licenza Apache, che ne permette una facile adozione e evita problemi contrattuali in caso di vendita di software derivato.
Per quanto riguarda l’integrazione con .NET, segnalo l’esistenza di pacchetti nuget per Solr e elasticsearch che permettono di mappare le risposte della ricerca a oggetti C#.
Segui Giuneco sui social