Elasticsearch e la ricerca su oltre 280.000 prodotti

Un e-commerce con oltre 280.000 prodotti a catalogo vive o muore sulla ricerca. Le categorie servono a orientarsi, ma chi ha in mente un codice, un modello di toner o un formato di carta lo scrive nel campo di ricerca e si aspetta il prodotto giusto in cima, subito. Se il risultato arriva tardi o è sbagliato, il visitatore non sfoglia: se ne va.

Su Initpc, l'e-commerce di materiale per ufficio, cancelleria, informatica e scuola che seguiamo come partner tecnico dal 2006, la ricerca è stata a lungo il punto in cui la piattaforma mostrava per prima i propri limiti. Il motore nativo di WooCommerce, pensato per negozi di dimensioni normali, su questa scala era diventato lento, impreciso e — cosa meno visibile ma più grave — un peso per il database che rallentava tutto il resto del sito. Questo approfondimento del case study Initpc racconta come l'abbiamo spostata su Elasticsearch e perché stiamo già costruendo il passo successivo.

Perché la ricerca nativa di WooCommerce collassa su un catalogo grande

La ricerca di WordPress e WooCommerce non è un motore di ricerca: è una query SQL. Quando un visitatore scrive "cartucce nere", il sito interroga la tabella dei post con una condizione LIKE '%cartucce%' su titolo e contenuto e la incrocia con la tabella dei metadati per filtrare prezzo, disponibilità e attributi. Ogni prodotto WooCommerce è un post con molte righe di metadati collegate: ogni ricerca è una join fra una tabella grande e una enorme. Con oltre 280.000 prodotti succedono più cose insieme.

Lentezza. Un LIKE con il carattere jolly all'inizio non può usare gli indici: il database scorre tutte le righe, ogni volta.

Risultati irrilevanti. SQL risponde "contiene la parola" oppure no. Non sa che un titolo che corrisponde per intero vale più di una descrizione in cui la parola compare per caso, non conosce i plurali, non tollera un refuso. Il prodotto giusto esiste, ma finisce in fondo all'elenco.

Carico sul database. È il danno nascosto. Lo stesso MariaDB che risponde alle ricerche serve pagine prodotto, carrello, checkout e le sincronizzazioni del gestionale. Ogni ricerca pesante occupa il database per tutti: durante un picco di visite, il campo di ricerca rallentava anche chi stava pagando.

La decisione: portare la ricerca fuori dal database

Ottimizzare le query native aveva un margine limitato: il problema non era una query scritta male, ma un modello di dati nato per un blog e adattato a un negozio.

La scelta è stata Elasticsearch, installato in Docker su una VM dedicata al ruolo di ricerca dentro l'infrastruttura Proxmox del cliente, ed ElasticPress come ponte con WooCommerce. Sono le stesse ragioni che guidano il resto dell'architettura dell'infrastruttura e-commerce: ogni ruolo su una macchina propria, tecnologie open, tutto sotto il nostro controllo.

Elasticsearch è un motore full-text: invece di scorrere righe consulta un indice invertito, una mappa che per ogni termine dice già in quali documenti compare e con quale peso, come l'indice analitico di un libro. ElasticPress intercetta le ricerche di WooCommerce, le riscrive nel linguaggio di Elasticsearch e restituisce a WordPress gli identificativi dei prodotti da mostrare.

	Ricerca nativa WooCommerce	Elasticsearch con ElasticPress
Dove gira	Sullo stesso database del negozio (MariaDB)	Su un servizio separato in Docker, su una VM dedicata
Come cerca	LIKE sul testo e join sui metadati, a ogni richiesta	Indice invertito già pronto, con analisi linguistica
Ordinamento	Per data o alfabetico, nessuna nozione di rilevanza	Punteggio di rilevanza per campo, peso e corrispondenza
Refusi e varianti	Nessuna tolleranza	Fuzziness, sinonimi e plurali gestiti dall'analizzatore
Con oltre 280.000 prodotti	Costo per ricerca crescente, database occupato per tutti	Costo per ricerca stabile, database libero per ordini e pagine

Indicizzazione iniziale e sincronizzazione continua

L'indicizzazione iniziale ha letto l'intero catalogo — titolo, descrizione, codice articolo, categorie, attributi, prezzo, disponibilità, marca — e ha costruito per ogni prodotto un documento nell'indice. Con oltre 280.000 prodotti non è un'operazione da lanciare dal pannello: l'abbiamo eseguita a lotti dalla riga di comando, in orari di basso traffico, perché è il database sorgente a fare il lavoro pesante.

La parte che conta davvero è quello che succede dopo. Il gestionale proprietario che importa listini e disponibilità da più fornitori e magazzini aggiorna prezzi e giacenze in continuazione. Ogni volta che modifica un prodotto su WooCommerce, ElasticPress intercetta il salvataggio e riscrive il documento corrispondente nell'indice: chi cerca un attimo dopo vede il prezzo nuovo e non trova più l'articolo appena esaurito, senza alcun ciclo notturno da aspettare.

Quando un listino nuovo tocca una quantità molto grande di prodotti in un colpo solo, le scritture verso Elasticsearch vengono raggruppate e inviate in blocco, così l'importazione non diventa una tempesta di richieste; un reindice completo pianificato riallinea i documenti eventualmente rimasti indietro.

Autosuggest: la ricerca comincia mentre si scrive

Il campo di ricerca di initpc.it propone i prodotti già mentre il visitatore digita. Ogni carattere manda una richiesta direttamente a Elasticsearch, attraverso un endpoint dedicato esposto sul dominio del sito, senza passare dal ciclo completo di WordPress: niente tema da caricare, niente query al database, solo il motore che risponde.

In un catalogo dove molte ricerche partono da un codice parziale o da una sigla di modello, vedere comparire il prodotto dopo poche lettere conferma che l'articolo esiste prima ancora di premere invio.

Rilevanza: campi, pesi, sinonimi ed errori di battitura

Un motore full-text assegna a ogni prodotto un punteggio e ordina di conseguenza. Il lavoro di configurazione sta nel decidere cosa fa salire quel punteggio.

I campi non valgono tutti uguale. Una corrispondenza nel titolo conta più di una nella descrizione; una nel codice articolo conta più di tutto, perché chi scrive un codice sa esattamente cosa vuole. Abbiamo assegnato pesi diversi a titolo, codice, marca, categoria e descrizione, così il prodotto giusto emerge anche quando la parola cercata compare in moltissime schede.

Le parole vengono analizzate, non confrontate. Prima di entrare nell'indice il testo passa per un analizzatore per l'italiano che porta le parole alla radice: "cartucce" e "cartuccia" diventano la stessa cosa, maiuscole e accenti smettono di contare. Un dizionario di sinonimi, costruito guardando le ricerche reali che non trovavano nulla, copre il vocabolario del settore: chi cerca "toner" può voler dire "cartuccia laser", "raccoglitore" e "registratore" sono spesso lo stesso oggetto.

I refusi sono tollerati. La ricerca fuzzy accetta una lettera sbagliata o invertita e trova comunque il prodotto. È una regolazione delicata — troppa tolleranza e "penna" trova "panna", poca e ogni refuso è un vicolo cieco — che abbiamo calibrato sui casi reali.

L'effetto sulle prestazioni e sul database

Il beneficio evidente è la ricerca stessa: risposte rapide e costanti. Il risultato più importante però è indiretto. Togliere le ricerche dal database ha restituito a MariaDB la capacità che consumavano le query più costose in assoluto: pagine prodotto, carrello, checkout e le scritture del gestionale hanno smesso di contendersi le risorse con il campo di ricerca, e i rallentamenti a catena che partivano dalla ricerca nei momenti di picco sono scomparsi.

I limiti del plugin e la ricerca proprietaria in sviluppo

ElasticPress ha portato un catalogo enorme su un motore vero senza riscrivere il negozio, ma è un plugin generalista e la sua forza è anche il suo limite. La struttura dell'indice è decisa dal plugin e rispecchia il modello post-più-metadati di WordPress; il ranking si regola entro i margini che il plugin espone, oltre servono filtri e codice personalizzato da ricontrollare a ogni aggiornamento; ogni sincronizzazione passa dal ciclo di WordPress, mentre la fonte della verità sui prodotti è il gestionale.

Per questo abbiamo in sviluppo un motore di ricerca proprietario: sempre Elasticsearch in Docker, ma con un indice progettato da noi — schema, analizzatori, campi calcolati — e un ranking scritto per il catalogo di Initpc, pensato per essere alimentato direttamente dal gestionale. Lo diciamo con chiarezza: non è in produzione. Sul sito oggi gira ElasticPress; lo raccontiamo perché è la direzione, non un risultato.

La prospettiva più interessante è l'incontro con Hector AI. Per generare le schede prodotto con Hector AI, la piattaforma distilla da ogni articolo attributi strutturati — materiale, uso, compatibilità — che oggi finiscono nel testo delle schede. Portati nell'indice come campi propri, permetterebbero di rispondere a ricerche descrittive ("carta riciclata per stampante laser") dove oggi si confrontano solo parole. È un'integrazione futura, e la costruiremo sul motore proprietario, non sul plugin.

Questo lavoro nasce dai nostri progetti di sviluppo e progettazione e-commerce e di containerizzazione dei servizi con Docker, e si appoggia sulla piattaforma Hector AI che sviluppiamo in casa.