Integrazione di componenti di intelligenza artificiale in Elasticsearch

L’integrazione di componenti di intelligenza artificiale in Elasticsearch è stata significativamente avanzata con l’introduzione del Elasticsearch Relevance Engine (ESRE). Questo motore combina algoritmi sofisticati di recupero e modelli di linguaggio di grandi dimensioni (LLM), come GPT-3 e GPT-4, fornendo agli sviluppatori un set completo di strumenti per creare applicazioni di ricerca avanzate. ESRE migliora la rilevanza delle ricerche attraverso diverse funzionalità:

1) Creare applicazioni di ricerca avanzate
2) Che cos’è ESRE e come viene utilizzato in Elasticsearch
3) Un caso concreto

Creare applicazioni di ricerca avanzate

Per creare applicazioni di ricerca avanzate tramite Elasticsearch sono a disposizione i seguenti tools:

1. Ranking Avanzato e Indici Densi: Utilizza funzionalità avanzate di ranking come BM25f e la creazione, memorizzazione e ricerca di indici densi tramite il database vettoriale di Elastic.
2. Elaborazione NLP e Integrazione con Modelli Esterni: Supporta un’ampia gamma di task di elaborazione del linguaggio naturale (NLP) e permette l’integrazione con modelli trasformativi di terze parti, come quelli di OpenAI, per riepiloghi intuitivi basati sui dati dell’utente.
3. Rilevanza e Contestualizzazione: ESRE (Elasticsearch Relevance Engine) migliora la rilevanza della ricerca integrando dati da fonti private, generando e memorizzando vettori di embedding per recuperare contesto tramite ricerca semantica.
4. Supporto alla Privacy e Sicurezza: Include il supporto per il controllo degli accessi basato su ruoli e attributi, assicurando che solo le persone autorizzate possano accedere a determinati dati.
5. Facilità d’Uso e Applicabilità: ESRE è facilmente accessibile e utilizzabile con corpus di ricerca esistenti, senza la necessità di adattamenti o addestramenti specifici.
6. Superamento delle Sfide ML: Affronta le sfide di costo, complessità e risorse richieste dal machine learning, fornendo agli sviluppatori strumenti immediatamente utilizzabili per migliorare la rilevanza della ricerca con contesto semantico.

Che cos’è ESRE e come viene utilizzato in Elasticsearch

ESRE, acronimo di Elasticsearch Relevance Engine, è una funzionalità avanzata di Elasticsearch che integra algoritmi sofisticati di recupero e grandi modelli di linguaggio (LLM) per creare applicazioni di ricerca AI altamente rilevanti. Ecco come funziona e come viene utilizzato in Elasticsearch:

Funzionalità di ESRE

Algoritmi di Recupero Avanzati: ESRE include algoritmi sofisticati come BM25f, che è un componente critico nella ricerca ibrida, migliorando la rilevanza dei risultati di ricerca.
Database Vettoriale: Utilizza un database vettoriale per creare, memorizzare e cercare embedding densi, che sono rappresentazioni numeriche di parole, frasi o documenti. Questi aiutano a comprendere i significati delle parole e le loro relazioni.
Elaborazione del Linguaggio Naturale (NLP): ESRE supporta una vasta gamma di compiti NLP, consentendo agli sviluppatori di gestire e utilizzare i propri modelli trasformativi o di integrare modelli di terze parti come GPT-3 e GPT-4.
Ricerca Potenziata da ML Senza Addestramento Specifico: Include il modello Learned Sparse Encoder di Elastic, che fornisce ricerca semantica ad alta rilevanza senza la necessità di addestramento o manutenzione specifici.
Fusione del Ranking Reciproco (RRF): Combina facilmente recupero sparso e denso usando RRF, permettendo agli sviluppatori di ottimizzare la loro ricerca AI alle esigenze specifiche.
Privacy e Sicurezza: Garantisce la privacy e la sicurezza dei dati, supportando controlli di accesso basati su ruoli e attributi.

Utilizzo in Elasticsearch

Integrazione con Dati Proprietari: ESRE rende semplice l’integrazione di dati da fonti private, migliorando la rilevanza e contestualizzazione dei risultati di ricerca.
Ricerca Semantica: I vettori di embedding migliorano il modello trasformativo, consentendo una ricerca semantica più efficace e specifica.
Supporto alla Personalizzazione: Gli sviluppatori possono integrare i propri modelli trasformativi o utilizzare modelli di terze parti per personalizzare ulteriormente la ricerca.
Ricerca Ibrida: L’uso di RRF permette una ricerca ibrida, combinando ricerca basata su parole chiave e semantica.
Risultati di Ricerca Contestualizzati: ESRE consente di fornire risultati di ricerca contestualizzati, comprendendo meglio l’intenzione dell’utente e fornendo risposte specifiche.

In sintesi, ESRE è una potente aggiunta a Elasticsearch, offrendo agli sviluppatori gli strumenti per creare esperienze di ricerca avanzate, pertinenti e personalizzate, utilizzando il potere dell’AI e del NLP

Un caso concreto

Ecco un esempio concreto che illustra come Elasticsearch e il suo Relevance Engine (ESRE) possono essere utilizzati per migliorare la ricerca di documenti in un contesto legislativo:

Scenario

Immagina di avere un sito web specializzato in documentazione legislativa. Gli utenti di questo sito, principalmente professionisti non specializzati in legge, cercano spesso informazioni specifiche su leggi, regolamenti o casi giuridici.

Obiettivo

Vuoi fornire agli utenti un modo per fare domande in linguaggio naturale e ricevere risposte precise e pertinenti basate sui documenti legislativi nel tuo database.

Implementazione con Elasticsearch e ESRE

Caricamento dei Documenti: Carichi tutti i documenti legislativi nel tuo sistema Elasticsearch. Questo include leggi, regolamenti, annotazioni, e forse anche casi giuridici rilevanti.
Utilizzo del Database Vettoriale: Utilizzi il database vettoriale di ESRE per analizzare e memorizzare questi documenti sotto forma di embedding densi. Questo processo trasforma i testi in rappresentazioni numeriche che catturano il significato e i contesti delle parole.
Integrazione con Modelli di LLM: Integri modelli di linguaggio di grandi dimensioni come GPT-3 o GPT-4 per elaborare le query in linguaggio naturale degli utenti. Questi modelli sono addestrati per comprendere e generare testi umani, il che li rende ideali per interpretare le domande degli utenti e per cercare risposte pertinenti.
Ricerca Semantica: Quando un utente fa una domanda, il sistema utilizza sia la ricerca semantica (basata sugli embedding densi) sia la ricerca basata su parole chiave per trovare i documenti più rilevanti. Questo approccio ibrido assicura che la ricerca non si basi solo sulle parole chiave, ma anche sul contesto e sul significato dietro la domanda.
Presentazione dei Risultati: I documenti ritenuti più pertinenti vengono poi presentati all’utente. Grazie all’integrazione con LLM, il sistema può anche generare un breve riepilogo o una spiegazione, rendendo i risultati più accessibili per gli utenti non specializzati.

Vantaggi

Migliore Comprensione delle Query: Grazie ai modelli LLM, il sistema comprende meglio le query in linguaggio naturale, anche se non sono formulate con termini tecnici precisi.
Risultati Più Rilevanti: L’uso di embedding densi e ricerca semantica assicura che i risultati siano rilevanti non solo a livello di parole chiave, ma anche a livello di significato.
Esperienza Utente Migliorata: Gli utenti ottengono risposte più precise e contestualizzate, migliorando la loro esperienza sul sito.

Questo esempio mostra come Elasticsearch e ESRE possono essere utilizzati per trasformare un sistema di ricerca documentale in uno strumento potente e intuitivo, particolarmente utile in campi complessi come quello legislativo.

Ovviamente, maggiori dettagli su tutto questo li potrete trovare sul sito ufficiale di Elastic.

MySolution.it

MySolutions è un un quotidiano on-line riguarda il mondo dell’imprenditoria analizzato dal lato fiscale. I membri della redazione di MySolution , che sono tutti esperti di fiscalità ciascuno secondo la sua specializzazione, analizzano e pubblicano quotidianamente centinaia di articoli, documenti e libri riguardanti la fiscalità.

Avevamo pubblicato dei dettagli sulla teconologia con cui il sistema di ricerca fosse stato riscritto, ma abbiamo preferito in seguito ritirare le informazioni precedentemente diffuse.

Questa pagine resta per mantenere efficiente la SEO di questo sito.

Vi consigliamo di leggere quancuno dei nuovi articoli che abbiamo pubblicato:

Miglioramento del recupero delle informazioni nello stack elastico: passaggi per migliorare la pertinenza della ricerca

A partire dalla versione 8.0 e dal rilascio di modelli di elaborazione del linguaggio naturale (NLP) di terze parti per l’incorporamento di testo, gli utenti di Elastic Stack hanno accesso a un’ampia varietà di modelli per incorporare i propri documenti di testo ed eseguire il recupero di informazioni basato su query utilizzando la ricerca vettoriale.

Dati tutti questi componenti e i relativi parametri, ea seconda del corpus di testo in cui si desidera effettuare la ricerca, può essere complicato scegliere quali impostazioni forniranno la migliore pertinenza della ricerca.

In questa serie di post sul blog, introdurremo una serie di test che abbiamo eseguito utilizzando vari set di dati pubblicamente disponibili e tecniche di recupero delle informazioni disponibili nello Stack elastico. Forniremo quindi consigli sulle migliori tecniche da utilizzare a seconda della configurazione.

Per dare il via a questa serie di blog, vogliamo preparare il terreno descrivendo il problema che stiamo affrontando e descrivendo alcuni metodi che approfondiremo in un articolo successivo sull’ integrazione di componenti di intelligenza artificiale in Elasticsearch.

Contesto e terminologia

BM25: un modello sparso e non supervisionato per la ricerca lessicale

Il modo classico in cui i documenti vengono classificati per rilevanza da Elasticsearch in base a una query di testo utilizza l’implementazione Lucene del modello Okapi BM25. Sebbene alcuni iperparametri di questo modello siano stati messi a punto per ottimizzare i risultati nella maggior parte degli scenari, questa tecnica è considerata non supervisionata poiché query etichettate e documenti non sono necessari per utilizzarla: è molto probabile che il modello funzionerà ragionevolmente bene su qualsiasi corpus di testo, senza basarsi su dati annotati. BM25 è noto per essere una solida linea di base nelle impostazioni di recupero a colpo zero.

Sotto il cofano, questo tipo di modello costruisce una matrice di frequenze dei termini (quante volte un termine appare in ciascun documento) e frequenze inverse dei documenti (l’inverso di quanti documenti contengono ciascun termine). Quindi assegna un punteggio a ogni termine di query per ogni documento che è stato indicizzato in base a tali frequenze. Poiché ogni documento contiene in genere una piccola frazione di tutte le parole utilizzate nel corpus, la matrice contiene molti zeri. Questo è il motivo per cui questo tipo di rappresentazione è chiamato “sparse”.

Inoltre, questo modello somma il punteggio di pertinenza di ogni singolo termine all’interno di una query per un documento, senza tener conto di alcuna conoscenza semantica (sinonimi, contesto, ecc.). Questa è chiamata ricerca lessicale (al contrario della ricerca semantica). Il suo difetto è il cosiddetto problema di mancata corrispondenza del vocabolario, che il vocabolario della query è leggermente diverso dal vocabolario del documento. Ciò motiva altri modelli di punteggio che cercano di incorporare la conoscenza semantica per evitare questo problema.

Modelli densi: un modello denso e supervisionato per la ricerca semantica

Più recentemente, i modelli basati su trasformatore hanno consentito una rappresentazione del testo densa e consapevole del contesto, affrontando le principali carenze sopra menzionate.

Per costruire tali modelli, sono necessari i seguenti passaggi:

1. Pre-formazione

Per prima cosa dobbiamo addestrare una rete neurale per comprendere la sintassi di base del linguaggio naturale.

Utilizzando un enorme corpus di testo, il modello apprende la conoscenza semantica addestrandosi su attività non supervisionate (come la previsione della parola mascherata o la previsione della frase successiva).
BERT è probabilmente l’esempio più noto di questi modelli: è stato addestrato su Wikipedia (2,5 miliardi di parole) e BookCorpus (800 milioni di parole) utilizzando Masked Word Prediction.

Questo si chiama pre-allenamento. Il modello apprende rappresentazioni vettoriali di token linguistici, che possono essere adattati per altre attività con molto meno addestramento.

Si noti che in questa fase, il modello non funzionerebbe bene nelle attività di PNL a valle.

Questo passaggio è molto costoso, ma esistono molti di questi modelli fondamentali che possono essere utilizzati immediatamente.

2. Formazione specifica per compito

Ora che il modello ha costruito una rappresentazione del linguaggio naturale, si addestrerà in modo molto più efficace su un’attività specifica come Dense Passage Retrieval (DPR) che consente la risposta alle domande.

Per fare ciò, dobbiamo adattare leggermente l’architettura del modello e quindi addestrarlo su un gran numero di istanze del compito, che, per DPR, consiste nell’abbinare un passaggio rilevante tratto da un documento rilevante.

Quindi questo richiede un set di dati etichettato, ovvero una raccolta di terzine:

Una domanda: “What is gold formed in?”
Un documento o brano tratto da un documento: “The core of large stars, especially during a nova”

Facoltativamente, un punteggio del grado di rilevanza per questa coppia (query, documento) (se non viene assegnato alcun punteggio, assumiamo che il punteggio sia binario e che tutti gli altri documenti possano essere considerati irrilevanti per la query data).
Un set di dati molto popolare e pubblicamente disponibile per eseguire tale formazione per DPR è il set di dati MS MARCO.

Questo set di dati è stato creato utilizzando le query e i migliori risultati del motore di ricerca Bing di Microsoft. Pertanto, le query e i documenti che contiene rientrano nel dominio linguistico della conoscenza generale, in contrasto con il dominio linguistico specifico (si pensi ai documenti di ricerca o al linguaggio utilizzato nella legge).

Questa nozione di dominio linguistico è importante, poiché la conoscenza semantica appresa da quei modelli sta dando loro un importante vantaggio “in-domain”: quando BERT è uscito, ha migliorato i precedenti modelli allo stato dell’arte su questo set di dati MS MARCO di un enorme margine.

3. Formazione specifica del dominio

A seconda della differenza tra i dati e il set di dati utilizzato per l’addestramento specifico dell’attività, potrebbe essere necessario addestrare il modello utilizzando un set di dati con etichetta specifico del dominio. Questo passaggio viene anche definito messa a punto per l’adattamento del dominio o “domain-adaptation”.

La buona notizia è che non è necessario un set di dati così grande come richiesto per i passaggi precedenti: alcune migliaia o decine di migliaia di istanze delle attività possono essere sufficienti.

La cattiva notizia è che queste coppie query-documento devono essere create da esperti di dominio, quindi di solito è un’opzione costosa.

L’adattamento del dominio è più o meno simile alla formazione specifica per attività.

Dopo aver introdotto queste varie tecniche, misureremo le loro prestazioni su un’ampia varietà di set di dati. Questo tipo di attività di recupero di informazioni generiche è di particolare interesse per noi. Vogliamo fornire strumenti e indicazioni per una vasta gamma di utenti, compresi quelli che non vogliono addestrare i modelli stessi per ottenere alcuni dei vantaggi che apportano alla ricerca. Nel prossimo post del blog di questa serie, descriveremo la metodologia e la suite di benchmark che utilizzeremo.

Panoramica della ricerca per somiglianza di immagini in Elasticsearch

Immagina di poter imitare l’aspetto di una celebrità con uno screenshot. Gli utenti potrebbero utilizzare l’immagine per trovare rapidamente i vestiti venduti online che corrispondono allo stile. Ma, questa non è l’esperienza di ricerca di oggi.

I clienti lottano per trovare ciò di cui hanno bisogno e se non riescono, se ne andranno. Alcuni di loro non ricordano il nome (parola chiave) di ciò che stanno cercando, ma hanno un’idea di come si presenta o dell’immagine effettiva. Con la ricerca vettoriale, una funzionalità integrata in Elasticsearch, le organizzazioni possono implementare la ricerca di immagini simili. Ciò aiuta le organizzazioni a creare un’esperienza di ricerca più intuitiva in modo che i clienti possano cercare facilmente ciò che stanno cercando con un’immagine.

Per implementare questa funzionalità in Elastic, non devi essere un esperto di machine learning per iniziare. Questo perché la ricerca vettoriale è già integrata nella nostra piattaforma scalabile e altamente performante. Sarai in grado di integrarla in framework di applicazioni, rendendo più facile la creazione di applicazioni interattive.

Ricerca semantica e ricerca di similarità – entrambe alimentate da una ricerca vettoriale.

La ricerca vettoriale sfrutta l’apprendimento automatico (ML) per catturare il significato e il contesto dei dati non strutturati. La ricerca vettoriale trova dati simili utilizzando algoritmi di vicinanza approssimativa (ANN). Rispetto alla ricerca di testo tradizionale (in Elastic, basata sul punteggio BM25), la ricerca vettoriale produce risultati più pertinenti ed esegue più velocemente (senza la necessità di estreme ottimizzazioni del motore di ricerca).

Questo approccio funziona non solo con i dati di testo ma anche con le immagini e altri tipi di dati non strutturati per i quali sono disponibili modelli di embedding generici. Per i dati di testo, è comunemente definito come ricerca semantica, mentre la ricerca di similarità è frequentemente usata nel contesto di immagini e audio.

Come si generano embedding vettoriali per le immagini?

Le rappresentazioni vettoriali sono la rappresentazione numerica dei dati e del contesto correlato immagazzinati in vettori ad alta dimensione (densi). I modelli che generano le rappresentazioni vettoriali sono di solito allenati su milioni di esempi per fornire risultati più rilevanti ed accurati.

Per dati di testo, i transformer simili a BERT sono popolari per generare embedding che funzionano con molti tipi di testo, e sono disponibili su repository pubblici come Hugging Face. I modelli di embedding, che funzionano bene con qualsiasi tipo di immagine, sono oggetto di ricerca in corso. Il modello CLIP – utilizzato dai nostri team per prototipare l’app di similarità delle immagini – viene distribuito da OpenAI e fornisce un buon punto di partenza. Per casi d’uso specializzati e utenti avanzati, potrebbe essere necessario addestrare un modello di embedding personalizzato per ottenere le prestazioni desiderate. Successivamente, è necessaria la capacità di effettuare ricerche in modo efficiente. Elastic supporta l’ampiamente adottata ricerca di vicini più prossimi approssimativa basata su HNSW.

Come la ricerca di somiglianza alimenta applicazioni innovative.

Come la ricerca di similarità alimenta l’innovazione? Nel nostro primo esempio, gli utenti potevano fare una screenshot e cercare per trovare l’outfit di una celebrità preferita.

Puoi anche usare la ricerca di similarità per:

– Suggerire prodotti simili a quelli acquistati da altri clienti.
– Trovare progetti correlati esistenti o modelli rilevanti da una libreria di elementi di design visivo.
– Trova le canzoni che potrebbero piacerti dai popolari servizi di streaming musicale in base a ciò che hai ascoltato di recente.
– Cercare attraverso enormi dataset di immagini non strutturate e non etichettate utilizzando la descrizione naturale.

Perché scegliere Elastic per la ricerca di similarità delle immagini?

Implementare la ricerca di immagini simili in Elasticsearch ti fornisce diversi vantaggi. Con Elastic, puoi…

Ridurre la complessità delle applicazioni

Con Elastic non è necessario utilizzare servizi separati per eseguire la ricerca kNN e vettorializzare l’input di ricerca. La ricerca vettoriale e i punti di inferenza NLP sono integrati all’interno di una piattaforma di ricerca scalabile. In altri framework popolari, l’applicazione di reti neurali profonde e modelli NLP avviene separatamente dal ridimensionamento delle ricerche su grandi set di dati. Ciò significa che è necessario assumere esperti, aggiungere tempo di sviluppo al progetto e destinare risorse per gestirlo nel tempo.

Scalare con velocità

In Elasticsearch, ottieni scala e velocità. I modelli vivono accanto ai nodi in esecuzione nella stessa cluster di ricerca, ciò si applica alle cluster locali e ancor di più se le distribuisci nel cloud. Elastic Cloud ti consente di scalare facilmente su e giù, a seconda del carico di lavoro di ricerca corrente.

La riduzione del numero di servizi necessari per un’applicazione ha benefici che vanno oltre lo scaling. È possibile sperimentare una semplificazione del monitoraggio delle prestazioni, una riduzione della presenza nel tempo di manutenzione e un minor numero di vulnerabilità di sicurezza, per citarne alcuni. Le future architetture serverless porteranno la semplicità dell’applicazione a un nuovo livello.

Le 7 principali considerazioni da fare quando si valuta un database NoSQL

1) Introduzione
2) Modello di dati
3) Modello di interrogazione
4) Coerenza e Modello transazionale
5) API
6) Piattaforma dati
7) Dati mobili
8) Considerazioni Finali

In alcuni casi nello sviluppo di web applications il passaggio ad un sistema ibrido con parte dell’applicazione su database SQL ed un’altra su database NoSql diventa fondamentale. Vuoi per velocizzare le ricerche full-text, vuoi per mantenere una serie di dati disponibili in modo da interrogarli con grande rapidità ed in tutta un’al tra serie di casi. Conoscere quali sono le caratteristiche di database NoSQL diventa allora fondamentale. Non è secondario tenere presente su quale framework è sviluppata l’applicazione che usufruirà della ricerca, ad esempio Laravel fornisce nativamente degli strumenti utili all’integrazione di alcuni servizi.

Introduzione

La più grande sfida che le organizzazioni devono affrontare è lavorare con i dati:

Le richieste di maggiore produttività e tempi di commercializzazione più rapidi sono frenate da rigidi modelli di dati relazionali che non corrispondono al codice moderno e impongono complessi interdipendenze tra i team di ingegneri.
Le organizzazioni non sono in grado di lavorare con, ed estrarre informazioni da, massicci aumenti del dati nuovi e in rapida evoluzione strutturati, semi-strutturati e polimorfici generati dalle applicazioni di oggi.
I database legacy monolitici e fragili inibiscono il passaggio all’ingrosso ai sistemi distribuiti e il cloud computing che offre la resilienza e la scalabilità di cui le aziende hanno bisogno, rendendolo più difficile per soddisfare i nuovi requisiti normativi per la privacy dei dati.
I carichi di lavoro transazionali, analitici, di ricerca e mobili precedentemente separati stanno convergendo per creare applicazioni avanzate e customer experience ricche e basate sui dati.
Tuttavia, ogni carico di lavoro tradizionalmente è stato alimentato dal proprio database, creando silos di dati duplicati cuciti insieme a fragili pipeline ETL accessibili da diverse API per sviluppatori.

Per affrontare queste limitazioni, sono state introdotte diverse alternative non tabulari ai database relazionali la considerazione imposta. Generalmente indicati come database NoSQL, questi sistemi scartano molto fondamento che ha reso i database relazionali così utili per generazioni di applicazioni: espressivo linguaggio di query, indici secondari e coerenza assoluta. I database NoSQL condividono diverse chiavi caratteristiche, tra cui un modello di dati più flessibile, una maggiore scalabilità e prestazioni superiori.

Sebbene il termine NoSQL sia spesso utilizzato come categoria ombrello per tutti i database non tabulari, è troppo vago e mal definito per essere un utile descrittore del modello di dati sottostante. Principalmente, esso trascura i compromessi che i database NoSQL fanno per ottenere flessibilità, scalabilità e prestazioni.

Per aiutare i responsabili delle decisioni tecnologiche a navigare nel dominio complesso e in rapida evoluzione di NoSQL e database non tabulari, in questo articolo abbiamo evidenziato le principali differenze tra loro. Esploriamo anche considerazioni critiche basate su sette dimensioni che definiscono questi sistemi: i dati modello; modello di interrogazione; consistenza e modello transazionale; API; dati mobili; piattaforma dati; e supporto commerciale, forza della comunità e libertà dal lock-in.

Modello di dati

Il modo principale in cui i database non tabulari differiscono dai database relazionali è il modello di dati. Sebbene esistano dozzine di database non tabulari, generalmente rientrano in tre categorie:
database di documenti, database di grafici e database di valori-chiave o archivi a colonne larghe.

Modello di documento

Mentre i database relazionali memorizzano i dati in righe e colonne, i database di documenti memorizzano i dati nei documenti utilizzando JavaScript Object Notation (JSON), un formato di interscambio di dati basato su testo popolare tra gli sviluppatori. I documenti forniscono un modo intuitivo e naturale per modellare i dati che è strettamente allineato con la programmazione orientata agli oggetti: ogni documento è effettivamente un oggetto che corrisponde agli oggetti con cui gli sviluppatori lavorano nel codice. I documenti contengono uno o più campi, e ogni campo contiene un valore digitato come una stringa, una data, un binario, un valore decimale o un array.

Piuttosto che distribuire un record su più colonne e tabelle collegate a foreign chiavi, ogni record viene archiviato insieme ai dati associati (ovvero correlati) in un singolo record gerarchico chiamato documento. Questo modello accelera la produttività degli sviluppatori, semplifica l’accesso ai dati e, in molti casi, elimina la necessità di costose operazioni di join e livelli di astrazione complessi come
la mappatura relazionale degli oggetti (ORM).

Lo schema di un database relazionale è definito da tabelle; in un database di documenti, la nozione di uno schema è dinamico: ogni documento può contenere diversi campi. Questa flessibilità può essere particolarmente utile per la modellazione di dati in cui le strutture possono cambiare tra ogni record, ad es. dati polimorfici. Inoltre, semplifica l’evoluzione di un’applicazione durante il suo ciclo di vita, ad esempio aggiungendo nuovi campi. Inoltre, alcuni database di documenti forniscono l’espressività delle query che gli sviluppatori si aspettano dai database relazionali. In particolare, i dati possono essere interrogatisulla base di qualsiasi combinazione di campi in un documento, con ricchi indici secondari che forniscono efficienti percorsi di accesso per supportare quasi tutti i modelli di query. Alcuni database di documenti offrono anche l’ opzione per imporre uno schema sui documenti.

APPLICAZIONI: I database di documenti sono utili per un’ampia varietà di applicazioni dovute alla flessibilità del modello di dati, alla capacità di eseguire query su qualsiasi campo e
la mappatura naturale del modello di dati del documento agli oggetti nei moderni linguaggi di programmazione.
ESEMPI: MongoDB, Azure CosmosDB, Apache CouchDB, Algolia

Modello grafico

I database a grafo utilizzano strutture a grafo con nodi, spigoli e proprietà per rappresentare i dati. In sostanza, i dati sono modellati come una rete di relazioni tra elementi specifici. Sebbene il
il modello grafico può essere controintuitivo, può essere utile per una specifica classe di query. Il suo fascino principale è che semplifica la modellazione e la navigazione delle relazioni tra le entità in un’applicazione.

APPLICAZIONI: I database a grafo sono utili nei casi in cui lo è l’attraversamento delle relazioni core dell’applicazione, come la navigazione delle connessioni ai social network, topologie di rete o supply chain.
ESEMPI: Neo4j, Amazon Nettuno

Database di valori-chiave e Modelli a colonna larga

Dal punto di vista del modello di dati, i database chiave-valore sono il tipo più elementare di non banche dati tabular. Ogni elemento nel database viene memorizzato come nome di attributo o chiave, insieme al suo valore. Il valore, tuttavia, è completamente opaco per il sistema: i dati possono essere interrogati solo dalla chiave. Questo modello può essere utile per rappresentare dati polimorfici e non strutturati, perché il database non impone uno schema impostato su coppie chiave-valore.

Gli spazi a colonne larghe, o gli spazi a famiglie di colonne, utilizzano un ordinamento sparso, distribuito e con una mappa multidimensionale per memorizzare i dati. Ogni record può variare nel numero di colonne memorizzate. Le colonne possono essere raggruppati in famiglie di colonne o distribuiti su più famiglie. I dati vengono recuperati da chiave primaria per famiglia di colonne.

APPLICAZIONI I database chiave-valore e gli archivi a colonne larghe sono utili per a set specializzato di applicazioni che eseguono query sui dati utilizzando un singolo valore chiave. Il fascino di questi sistemi è la loro performance e scalabilità, che può essere altamente ottimizzata grazie alla semplicità del modelli di accesso ai dati e opacità dei dati stessi.
ESEMPI Redis, Amazon DynamoDB (valore-chiave); Apache HBase, Apache Cassandra (colonna larga)

Modello di interrogazione

Ogni applicazione ha i propri requisiti di query. In alcuni casi, potrebbe essere un modello di query di base appropriato, in cui l’applicazione accede ai record in base solo a una chiave primaria. Per la maggior parte delle applicazioni, tuttavia, è importante avere la possibilità di eseguire query in base a diversi valori in ogni record. Ad esempio, un’applicazione che memorizza i dati sui clienti potrebbe dover eseguire una query per nome del cliente, nome dell’azienda, dimensioni, valore delle vendite, codice postale, stato o aggregazioni di più valori.

È anche comune che le applicazioni aggiornino i record, inclusi uno o più singoli campi. A soddisfare questi requisiti, il database deve essere in grado di eseguire query basate su indici secondari. In questi casi, un database di documenti spesso sarà la soluzione più appropriata.

Banca dati dei documenti

I database di documenti generalmente forniscono la possibilità di interrogare e aggiornare qualsiasi campo all’interno di un documento, anche se le capacità in questo dominio variano. Alcuni prodotti, come MongoDB, forniscono un ricco set di opzioni di indicizzazione per ottimizzare un’ampia varietà di query e per automatizzare la gestione dei dati, incluso testo, geospaziale, composto, sparse, jolly, tempo di vita (TTL), indici univoci e altri.

Inoltre, alcuni di questi prodotti consentono analisi in tempo reale rispetto ai dati in atto senza doverlo replicare su un’applicazione di analisi dedicata o su un motore di ricerca. MongoDB, ad esempio, fornisce un framework di aggregazione per gli sviluppatori per creare pipeline di elaborazione per l’analisi dei dati e trasformazioni tramite ricerca sfaccettata, join e unioni; elaborazione geospaziale; viste materializzate; e attraversamenti di grafi. Fornisce inoltre funzionalità di visualizzazione native con i grafici MongoDB con connettori per Apache Spark e strumenti BI. Per aggiornare i dati, MongoDB fornisce espressive metodi di aggiornamento che consentono agli sviluppatori di eseguire manipolazioni complesse rispetto alla corrispondenza degli elementi di un documento, inclusi elementi incorporati in array nidificati, tutto in un unica operazione di aggiornamento transazionale. C’è anche MongoDB Atlas Search, che consente la ricerca full-text funzionalità sul top dei tuoi dati nel cloud.

Database grafico

I database a grafo forniscono ricchi modelli di query in cui è possibile creare relazioni semplici e complesse, interrogazioni per fare inferenze dirette e indirette sui dati nel sistema. Sebbene
l’analisi delle relazioni tenda ad essere efficiente, altri tipi di analisi sono meno ottimali. Di conseguenza, i database grafici raramente vengono utilizzati per applicazioni operative generiche. Piuttosto, sono spesso accoppiati con documenti o database relazionali per far emergere strutture dati e query specifiche del grafico.

Per i casi d’uso che coinvolgono più tecnologie di archiviazione, esiste un’opzione per utilizzare “multimodello” database in cui different modelli di dati e tipi di query sono disponibili all’interno di un’unica piattaforma. Ad esempio, MongoDB offre la fase di aggregazione $graphLookup per l’elaborazione del grafico nativamente all’interno del database. $graphLookup consente attraversamenti efficienti tra grafici, alberi e dati gerarchici per scoprire schemi e far emergere connessioni precedentemente non identificate.

Database di valori-chiave e Modelli a colonna larga

I database chiave-valore e gli archivi a colonne larghe offrono la possibilità di recuperare e aggiornare i dati basati solo su una gamma di chiavi singola o limitata. Per interrogare altri valori, gli utenti sono incoraggiati ar costruire e mantenere i propri indici. Alcuni prodotti forniscono un supporto limitato per indici secondari, ma con diversi avvertimenti. Per eseguire un aggiornamento in questi sistemi, possono essere necessari più round trip — prima per trovare il record, poi per aggiornarlo, e poi per aggiornare l’indice.

L’indice, pertanto, potrebbe non essere coerente con i dati di base, che possono quindi restituire dati obsoleti o cancellati, aumentando drasticamente la complessità dell’applicazione e diminuendo la precisione dei risultati delle query. In questi sistemi, l’aggiornamento può essere implementato come una riscrittura completa dell’intero record al client, indipendentemente dal fatto che sia cambiato un singolo attributo o l’intero record.

Coerenza e Modello transazionale

La maggior parte dei sistemi non tabulari conserva più copie dei dati per scopi di disponibilità e scalabilità. Questi database possono imporre garanzie diverse sulla coerenza dei dati tra le copie. I database non tabulari tendono a essere classificati come fortemente coerenti o alla fine coerenti. Con un sistema fortemente coerente, le scritture dell’applicazione sono immediatamente visibili in seguito alle interrogazioni. Con un sistema coerente alla fine, la visibilità delle scritture dipende dalla replica dei dati che sta servendo la query. Ad esempio, quando si riflettono i livelli di inventario per i prodotti in un catalogo prodotti, con un sistema coerente ogni query vedrà l’inventario corrente man mano che viene aggiornato dall’applicazione, mentre con un sistema coerente alla fine, i livelli di inventario potrebbero non essere accurati per una query in un dato momento, ma alla fine diventeranno accurati man mano che i dati vengono replicati su tutti i nodi del cluster di database.

Per questo motivo, il codice dell’applicazione tende ad essere in qualche modo diverso per i sistemi coerenti – piuttosto che aggiornare l’inventario prendendo l’inventario corrente e
sottraendo uno, ad esempio, gli sviluppatori sono incoraggiati a emettere query idempotenti che in modo esplicito impostino il livello di inventario. Gli sviluppatori devono anche creare una logica di controllo aggiuntiva nelle loro app per gestire dati potenzialmente obsoleti o cancellati. La maggior parte dei sistemi non tabulari offre garanzie di atomicità a livello di record individuale. L’ atomicità è una delle quattro proprietà di transazione che costituiscono le transazioni ACID. Le quattro proprietà in una transazione ACID sono:

Atomicità
Consistenza
Isolamento
Durabilità

Lo scopo delle transazioni ACID è garantire la validità dei dati nonostante errori, interruzioni di corrente e altri contrattempi. L’atomicità è una garanzia che le operazioni del database sono indivisibili o irriducibili in modo tale che o tutte le operazioni sono state completate o nessuna è stata completata. Perché questi database possono combinare file correlati di dati che altrimenti verrebbero modellati su tabelle padre-figlio separate in uno schema tabulare, le operazioni atomiche a record singolo forniscono una semantica di transazione che soddisfa le esigenze di integrità dei dati di la maggior parte delle applicazioni.

È importante notare che alcuni sviluppatori e amministratori di database sono stati condizionati da 40 anni di modellazione dei dati relazionali per presumere che le transazioni multirecord siano un requisito per qualsiasi database, indipendentemente dal modello di dati sottostante. Alcuni sono preoccupati che sebbene le transazioni multidocumento non sono necessarie per le loro app oggi, potrebbero esserlo in futuro. E per alcuni carichi di lavoro, è necessario il supporto per le transazioni ACID su più record. MongoDB ha aggiunto il supporto per le transazioni ACID multidocumento nel 2018 in modo che gli sviluppatori potessero farlo affrontare una gamma più ampia di casi d’uso con la familiarità di come le transazioni vengono gestite in relazione a banche dati. Attraverso l’isolamento dello snapshot, le transazioni forniscono una visione coerente dei dati e applicano l’ esecuzione tutto o niente. MongoDB è relativamente unico nell’offrire le garanzie transazionali di database relazionali tradizionali, con la flessibilità e la scalabilità che derivano dai database non tabulari.

Sistemi coerenti

Le applicazioni possono avere requisiti diversi per la coerenza dei dati. Per molte applicazioni, è imperativo che i dati siano sempre coerenti. Perché i team di sviluppo hanno lavorato sottoun modello di coerenza con i database relazionali per decenni, questo approccio è più naturale e familiare. In altri casi, l’eventuale coerenza è un compromesso accettabile per la flessibilità che consente
la disponibilità del sistema.

I database di documenti e grafici possono essere coerenti o eventualmente coerenti. MongoDB fornisce consistenza sintonizzabile. Per impostazione predefinita, i dati sono coerenti: tutte le scritture e le letture accedono alla copia primaria dei dati. Come opzione, è possibile emettere query di lettura su copie secondarie in cui potrebbero trovarsi i dati eventualmente consistente se l’operazione di scrittura non è stata ancora sincronizzata con la copia secondaria; la scelta della coerenza viene effettuata a livello di query.ling.

Sistemi finalmente coerenti

Con i sistemi finalmente coerenti, c’è un periodo di tempo durante il quale le copie dei dati non sono sincronizzate. Ciò può essere accettabile per le applicazioni di sola lettura e gli archivi dati che non cambiano spesso, come archivi storici o casi d’uso ad alta intensità di scrittura in cui il database sta acquisendo informazioni, come i registri, che verranno lette in un momento successivo, spesso dopo che sono state spostate un altro sistema che offre funzionalità di query più ricche. In genere, database chiave-valore e colonne larghe i negozi sono considerati alla fine coerenti.

I sistemi finalmente coerenti devono essere in grado di accogliere gli aggiornamenti in conflitto nei singoli record. Poiché le scritture possono essere applicate a qualsiasi copia dei dati, è possibile e non raro che le scritture siano in conflitto tra loro quando lo stesso attributo viene aggiornato su nodi diversi. Alcuni sistemi utilizzano orologi vettoriali per determinare l’ordine degli eventi e garantire che l’operazione più recente prevale in caso di conflitto. Tuttavia, è possibile che sia già stato eseguito il commit del valore precedente all’applicazione. Altri sistemi mantengono tutti i valori contrastanti e spingono la responsabilità della risoluzione conflitti all’utente. Per questi motivi, gli inserti tendono a funzionare bene in caso di coerenza finale
sistemi, ma gli aggiornamenti e le eliminazioni possono comportare compromessi che complicano notevolmente l’applicazione.

API

Non esiste uno standard per l’interfacciamento con i sistemi non tabulari. Ogni sistema presenta diverso design e funzionalità agli sviluppatori di applicazioni. La maturità dell’API può influenzare il tempo e costo necessario per lo sviluppo e la manutenzione dell’applicazione e del database.

Driver idiomatici

I linguaggi di programmazione forniscono diversi paradigmi per lavorare con dati e servizi. I driver idiomatici sono creati da team di sviluppo che sono esperti in una determinata lingua e sanno come i programmatori preferiscono lavorare all’interno di una lingua. Questo approccio può anche fornire efficienze per accedere ed elaborare i dati sfruttando funzionalità specifiche in un linguaggio di programmazione.

Poiché i driver idiomatici sono più facili da imparare e utilizzare per gli sviluppatori, riducono l’onboarding tempo necessario ai team per iniziare a lavorare con un database. Ad esempio, i driver idiomatici forniscono interfacce dirette per impostare e ottenere documenti o campi all’interno di documenti. Con altri tipi di interfacce, potrebbe essere necessario recuperare e analizzare interi documenti e passare a specifici valori per impostare o ottenere un campo.

MongoDB supporta driver idiomatici in più di una dozzina di lingue tra cui Java, .NET, Ruby, Node.js, Python, PHP per lo sviluppo con Laravel, C, C++, C#, JavaScript, Go, Rust e Scala. Dozzine di altri drivers sono
supportati dalla comunità degli sviluppatori.

API RESTful

Alcuni sistemi forniscono interfacce RESTful (Representational State Transfer). Questo approccio ha il fascino di semplicità e familiarità, ma si basa sulle latenze intrinseche associate a HTTP. Esso sposta anche l’onere di costruire un’interfaccia per gli sviluppatori. Si noti che è probabile che questa interfaccia puo’ essere incoerente con altre interfacce di programmazione. Vedi il nostro articolo sull’ integrazione di API di terze parti

API simili a SQL

Alcuni database non relazionali hanno tentato di aggiungere un livello di accesso simile a SQL al database in la speranza che ciò riduca la curva di apprendimento per sviluppatori e amministratori di database già esperti in SQL. è importante valutare queste implementazioni prima che inizi uno sviluppo serio. Considera quanto segue:

La maggior parte di queste implementazioni non è all’altezza rispetto alla potenza e all’espressività di SQL
e richiederà che gli utenti SQL imparino un dialetto della lingua con funzionalità limitate.
Gli strumenti BI, reporting ed ETL basati su SQL non saranno compatibili con un’applicazione personalizzata
Implementazione SQL.
Sebbene parte della sintassi possa essere familiare agli sviluppatori SQL, la modellazione dei dati non lo sarà
essere. Il tentativo di imporre un modello relazionale su qualsiasi database non tabulare avrà effetti negativi
conseguenze per le prestazioni e la manutenzione delle applicazioni.

Visualizzazione e reportistica

Molte aziende eseguono la visualizzazione, l’analisi e il reporting dei dati utilizzando piattaforme BI basate su SQL che non si integrano nativamente con tecnologie non tabulari. Per risolvere questo problema, le organizzazioni si rivolgono a un’interfaccia Open Database Connectivity, o driver ODBC, per fornire connettività standard del settore tra i loro database non tabulari e strumenti di analisi di terze parti.

Ad esempio, MongoDB Connector for BI consente ad analisti, data scientist e utenti aziendali di visualizzare semi-strutturati e dati non strutturati gestiti in MongoDB insieme ai dati tradizionali dai loro database SQL utilizzando i più diffusi strumenti di BI. MongoDB Charts consente agli utenti di creare e condividere visualizzazioni dei propri Dati MongoDB in tempo reale, senza la necessità di spostare i dati in altri sistemi o sfruttare strumenti di terze parti. Poiché Charts comprende in modo nativo il modello di documento MongoDB, gli utenti possono creare grafici da dati che variano in forma o contengono documenti nidificati e matrici senza bisogno di prima mappare i dati in una struttura piatta e tabulare.

Dati mobili

Le prestazioni delle applicazioni mobili sono importanti tanto quanto le prestazioni delle applicazioni basate su architetture server. Ma le app mobili introducono l’ulteriore sfida di non essere sempre connesse al network. Gli sviluppatori di applicazioni mobili hanno bisogno di una soluzione per conservare tutte le app dei loro clienti sincronizzate con il database di back-end, indipendentemente da dove si trovino nel mondo e dal tipo di rete di connessione che hanno. La soluzione deve anche scalare facilmente e rapidamente man mano che più utenti scaricano un’app e per supportare l’avanguardia delle tecnologie di sviluppo mobile man mano che si evolvono.

I Database NoSQL, sono progettati per scalare su richiesta sfruttando meno costosi hardware di base o infrastruttura cloud: sono ideali per le esigenze aggiuntive poste
dal back-end e dalle applicazioni mobili che si sincronizzano con esso.

Flessibilità dello schema

I database relazionali limitano lo sviluppo a causa dei loro schemi fissi. Perché le nuove funzionalità sono sempre aggiunto nelle app mobili, apportando modifiche ai database relazionali per nuove situazioni le relazioni diventano sempre più dispendiose in termini di tempo. Anche le applicazioni mobili presentano un maggiore utilizzo per i casi casi che i database relazionali sono progettati per gestire, inclusi il tipo di dispositivo, il sistema operativo, firmware e posizione. Per i database NoSQL, aggiunta di funzionalità o aggiornamento di oggetti di cui tenere conto nuovi casi d’uso è semplicemente una questione di inserire nuove righe di codice.

Anche i database NoSQL sono ideali per la gestione degli aggiornamenti frequenti delle applicazioni che costituiscono una parte continua del ciclo di vita di sviluppo delle app. Non è necessario rivedere la logica solo per correggere un bug. E apportare modifiche in una parte del file è improbabile che il database influisca su altre parti dell’applicazione.
MongoDB Realm è un database mobile che consente ai clienti di archiviare dati su telefoni cellulari o sui dispositivi all’edge. Il suo modello di dati è simile a MongoDB in quanto consente agli sviluppatori mobili di farlo memorizzare oggetti simili a dati nel loro codice. Il Realm Mobile Database funziona anche su più piattaforme, che significa che gli utenti non devono fare affidamento su una tecnologia per Android e un’altra per iOS

Sincronizzazione edge-to-cloud

MongoDB Realm Sync consente ai clienti di mantenere i dati sincronizzati tra i dispositivi mobili e il database back-end, nonostante la connettività intermittente. Tutte le modifiche ai dati vengono memorizzate in una cronologia unificata e vengono uniti automaticamente tramite timestamp e trasformazione operativa. Questo edge-to-cloud ,il servizio di sincronizzazione, viene fornito con la risoluzione dei conflitti integrata e risolve uno dei più difficili ostacoli alla creazione di grandi esperienze mobili. I dati alla fine sono sempre coerenti e l’affidabilità è garantita. Quando gli utenti finali non dispongono di una connessione, possono comunque utilizzare le proprie app perché hanno i loro dati archiviati localmente nel Realm Mobile Database. Quando la loro connessione
viene ristabilita, i loro dati sul dispositivo locale vengono aggiornati con gli aggiornamenti dal back-end database nel cloud e viceversa.

Piattaforma dati

I database relazionali hanno una storia lunga e di successo nell’esecuzione con software proprietario e hardware come parte di un ecosistema locale di applicazioni, server ed endpoint. Ma attualmente l’infrastruttura è passata al cloud. I carichi di lavoro del server sono ampiamente distribuiti su più cloud architetture che espandono continuamente i confini della rete ben oltre i confini tradizionali degli ambienti locali. I carichi di lavoro ampiamente distribuiti pongono requisiti elevati sui database che devono svolgere il proprio ruolo di unica fonte di verità, dove la verità si misura in microsecondi.

La semplicità dei database NoSQL li rende più adatti alla velocità e al volume delle moderne transazioni di dati. E la loro portabilità consente alle organizzazioni di trasformare il tradizionale sistema centralizzato di repository di dati in una piattaforma dati altamente flessibile e reattiva in grado di distribuire i carichi di lavoro più vicino a dove le applicazioni ne hanno bisogno.

Man mano che le normative sulla privacy dei dati si espandono per includere i requisiti di sovranità dei dati e l’applicazione locale i server richiedono che i dati più rilevanti siano vicini per garantire letture e scritture a bassa latenza, le organizzazioni hanno bisogno di un maggiore controllo su dove distribuiscono i propri dati. MongoDB Atlas è un database completamente cloud gestitosul cloud che offre alle organizzazioni questo livello di controllo su dove distribuiscono i propri dati, sia a fini normativi che prestazionali.

I dati e l’ Innovation recurring tax (DIRT)

Lavorare con i dati è una parte fondamentale della creazione e dell’evoluzione delle applicazioni. Sebbene gli sviluppatori stiano trovando sempre nuovi modi per creare applicazioni, la maggior parte continua a utilizzare gli stessi dati sottostanti ,infrastrutture in uso da decenni. I database relazionali legacy possono inibire l’innovazione dovuta alla natura rigida delle strutture tabulari, che tendono a scontrarsi con i dati moderni e i tipi di dati degli oggetti con cui gli sviluppatori sono abituati a lavorare . Ciò rende più difficile la sperimentazione e l’iterazione delle applicazioni.

Ci riferiamo a questo come Data and Innovation Recurring Tax (DIRT) e può portare a una frammentazione dell’ esperienza dello sviluppatore, sforzi significativi di integrazione dei dati e duplicazione dei dati non necessaria.

Il superset di tutti i modelli di dati

Il modo per eliminare DIRT è utilizzare una piattaforma di dati applicativi che consente di semplificare e accelerare il modo in cui si creano applicazioni con i dati. MongoDB Atlas è flessibile e utilizza datidi tipo oggetto, che corrispondono al modo in cui gli sviluppatori pensano e codificano. Questo lo rende una piattaforma ideale su cui costruire.

I documenti sono un superset di altri modelli di dati, quindi non c’è bisogno di NoSQL di nicchia aggiuntivo ad altre banche dati. Con Atlas, puoi utilizzare un’unica interfaccia unificata per lavorare con qualsiasi dato generato da applicazioni moderne.

Atlas consente la ricerca full-text completamente integrata, eliminando la necessità di un motore di ricerca separato. Il datastore locale flessibile offre una perfetta sincronizzazione edge-to-cloud per dispositivi mobili e IoT. Puoi eseguire analisi sul posto e in tempo reale con l’isolamento del carico di lavoro e la visualizzazione nativa dei dati. Puoi eseguire anche query federate su database operativi o transazionali e storage di oggetti cloud. E consente la distribuzione globale dei dati per la sovranità dei dati e un accesso più rapido ai dati perché risiede più vicino a dove viene utilizzato.

Considerazioni Finali

Un database è un investimento importante. Una volta che un’applicazione è stata creata su un determinato database, è costoso, impegnativo e rischioso migrarlo in un altro database. Le aziende di solito investono in a un numero limitato di tecnologie di base in modo che possano sviluppare competenze, integrazioni e best practice che può essere ammortizzato in molti progetti. I database non tabulari sono ancora relativamente emergenti come tecnologia. Sebbene ci siano molte nuove opzioni sul mercato, solo un sottoinsieme di tecnologie resisteranno alla prova del tempo.

Supporto commerciale

Considerare l’integrità del fornitore o del prodotto durante la valutazione di un database. È importante non solo che il prodotto continui ad esistere, ma anche che si evolva e aggiunga nuove funzionalità secondo le esigenze che utenti dettano. Avere un’organizzazione di supporto forte ed esperta in grado di fornire servizi globalmente è un’altra considerazione rilevante.

Forza della comunità

Ci sono vantaggi significativi nell’avere una forte comunità attorno a una tecnologia, in particolare per le banche dati. Un database con una forte comunità di utenti rende più facile trovare e assumere sviluppatori che hanno familiarità con il prodotto. Semplifica la ricerca di best practice, documentazione e codice, che riducono tutti i rischi nei nuovi progetti. Aiuta anche le organizzazioni a conservare i dati tecnici chiave e talento. Infine, una comunità forte incoraggia altri fornitori di tecnologia a sviluppare integrazioni e partecipare all’ecosistema

Libertà dal blocco

Molte organizzazioni sono state scottate dal lock-in del database e da pratiche commerciali abusive. L ‘uso di software open source e hardware di base ha fornito una via di fuga per molti, ma
le organizzazioni temono anche che, passando al cloud, potrebbero finire per scambiare una forma di lock-in per un altro.

È importante valutare la licenza e la disponibilità di qualsiasi nuovo importante investimento software. Anche fondamentale è avere la flessibilità di eseguire il database ovunque sia necessario, sia che provenga da a laptop dello sviluppatore nella fase iniziale di adozione, sulla tua infrastruttura mentre entri in produzione, o nel cloud in base a un modello di consumo di database come servizio.

MongoDB Atlas è un database multi-cloud distribuito a livello globale che consente di distribuire i dati in tutto AWS, Google Cloud e Microsoft Azure in più di 80 regioni. Inoltre, puoi creare un file
cluster multi-cloud per abilitare le applicazioni che utilizzano due o più cloud contemporaneamente. Atlas include anche Atlas Search, che è profondamente integrato con l’aggregazione MongoDB
framework e costruito su Apache Lucene, la libreria standard del settore per la ricerca full-text. MongoDB Realm ti consente di fornire le migliori applicazioni mobili con un database mobile intuitivo, sincronizzati con MongoDB Atlas e beneficia della risoluzione dei conflitti integrata. Con Atlas Data Lake, tu può interrogare e analizzare i dati presenti su Amazon S3 e sui tuoi clienti Atlas. MongoDB offre inoltre agli sviluppatori e ai team DevOps la libertà di scaricare ed eseguire il database sulla proprio propria infrastruttura. Ovunque tu scelga di eseguire MongoDB, utilizza la stessa base di codice, API e strumenti di gestione.

I migliori motori di ricerca interni per eCommerce evoluti

La ricerca nei siti di e-commerce ha il potere di migliorare l’esperienza dei visitatori, fidelizzare i clienti e aumentare i tassi di conversione on-site. Secondo uno studio, i visitatori che utilizzano la ricerca possono generare circa il 30-60% di tutte le entrate del sito di e-commerce.

Nonostante il potenziale impatto del miglioramento della ricerca on-site, solo il 15% delle aziende dispone di risorse dedicate all’ottimizzazione.

La ricerca nei siti di e-commerce è complessa. In questo articolo parleremo di alcune delle sfide per la ricerca dei prodotti, delle opportunità di miglioramento e delle soluzioni disponibili.

Abbiamo scritto questa guida per marchi, rivenditori e mercati di aziende B2C o B2B, frutto della nostra esperienza come sviluppatori di soluzioni di ricerca su e-commerce. Qualsiasi tipo di attività di e-commerce con un catalogo di prodotti di grandi dimensioni può trarre vantaggio dalla ricerca sul sito ad alte prestazioni per fornire una migliore esperienza del cliente.

Inoltre abbiamo anche messo a disposizione una guida per comprendere le caratteristiche fondamendali dei database NoSql.

Tassi di conversione di Amazon.com e degli altri e-commerce in generale

I tassi di conversione on-site si aggirano intorno al 3% a seconda del settore, ma Amazon.com gode di un tasso di conversione cinque volte superiore alla media del settore (è ancora più alto per i membri Prime). La ricerca è fondamentale nel mercato più grande del mondo per trovare qualsiasi cosa, quindi naturalmente Amazon ha investito molto nell’ingegneria della ricerca per 20 anni e oggi ha 2000 persone che lavorano alla ricerca sul sito.

Che voi siate un marketplace, un rivenditore o un marchio che compete direttamente con Amazon, ci sono buone notizie: non è necessario assumere 1.500 ingegneri di ricerca. La moderna tecnologia dei motori di ricerca e-commerce di oggi può darti un vantaggio senza spendere troppo.

Lo stack di e-commerce moderno

Nel 2021, circa il 50% dei rivenditori ha dichiarato di voler dedicare più tempo allo sviluppo delle proprie capacità di ricerca sul sito.

Le soluzioni di ricerca più recenti possono sostituire il motore di ricerca predefinito fornito con il software di e-commerce o consentire di creare ricerche da zero su una nuova piattaforma di e-commerce headless. In entrambi i casi, i motori di ricerca possono essere facilmente inseriti in uno stack tecnologico altamente interdipendente che può includere una combinazione di:

– Piattaforma di e-commerce/CMS: il motore principale della tua soluzione di e-commerce rivolta ai clienti che aiuta a gestire tutto, dalla progettazione della pagina del prodotto alle valutazioni dei clienti.
– PIM: sistema di gestione delle informazioni di prodotto per la gestione e la condivisione dei contenuti tra i sistemi.
– Tagging: le soluzioni di tagging dei prodotti possono arricchire i metadati per una ricerca più accurata.
– Inventario: la gestione dell’inventario è spesso gestita con una soluzione ERP.
– CRM: indipendentemente dal fatto che tu abbia acquistato o creato il tuo CRM, hai bisogno di un posto centrale in cui archiviare le informazioni sui clienti in tutti i punti di contatto e le interazioni.
– Pagamenti: una soluzione di elaborazione dei pagamenti online.

Per essere efficace, la ricerca deve funzionare sui diversi sistemi che compongono la tua attività di e-commerce. Deve essere in grado di eseguire ricerche nel catalogo dei prodotti, controllare l’inventario per gli articoli esauriti, sfruttare le caratteristiche dei visitatori dal CRM e visualizzare informazioni sui prezzi aggiornate. Inoltre, deve fare tutte queste cose in millisecondi.

Funzionalità del motore di ricerca e-commerce

Una ricerca di successo nell’e-commerce richiede un prodotto e un approccio multiforme. Di seguito, ho delineato alcuni dei problemi più grandi che i rivenditori devono affrontare insieme ai tipi di soluzioni ampiamente disponibili oggi.

Come sottolinea questo studio di Baymard Research, anche molti dei più grandi rivenditori e marchi del mondo non hanno ancora risolto alcune sfide di ricerca più basilari come il controllo ortografico. Ci sono molte altre funzionalità di base e avanzate necessarie per una ricerca di successo. Tocchiamo alcuni di questi argomenti qui e abbiamo altre guide a cui potreste essere interessati come i nostri 12 suggerimenti per aumentare i tassi di conversione di ricerca e scoperta dell’e-commerce.

Le sfide della ricerca interna negli e-commerce

Il moderno stack di e-commerce è multilivello e include sistemi per l’elaborazione dei pagamenti, i resi, la gestione dell’inventario, la gestione delle informazioni sui prodotti (PIM) e altro ancora! Fornire contenuti di alta qualità, ad alta conversione e aggiornati al minuto con risultati di ricerca forniti istantaneamente è un atto difficile da fare bene. Abbiamo compilato un elenco di funzionalità che le aziende dovrebbero considerare – e chiedere al proprio fornitore – quando selezionano una soluzione di ricerca.

Indicizzazione istantanea

Quando si lancia un nuovo prodotto, collezione, vendita o campagna, il tempo è essenziale.

Di recente abbiamo incontrato il responsabile dell’e-commerce di un’azienda di moda. Ci ha detto che la loro nuovissima soluzione di ricerca sul sito, implementata meno di 12 mesi prima, impiega 30 minuti o più per aggiornarsi ogni volta che aggiungono nuovi prodotti o aggiornano elenchi esistenti.

Peggio ancora, alcuni sistemi impiegano fino a 24 ore per l’aggiornamento dell’indice.

Con l’indicizzazione istantanea, qualsiasi nuovo contenuto che pubblichi o aggiorni sul tuo sito verrà aggiunto immediatamente al tuo indice o raccolta di ricerca. Allo stesso modo, ogni volta che elimini contenuti o contrassegni una pagina con un codice di errore 404 valido, un motore di ricerca dovrebbe rimuovere automaticamente questa pagina dal tuo sito o dalla tua raccolta.

I motori di ricerca indicizzeranno un sito in due modi: tramite un web crawler o tramite API. I crawler funzionano bene per i siti Web statici più piccoli, ma le API sono la strada da percorrere per gli stack tecnologici di e-commerce in cui i dati provengono da una varietà di sistemi e necessitano di aggiornamenti immediati.

Intelligenza artificiale (AI)

La pertinenza – cercare di far corrispondere la query dell’utente con i migliori risultati – è difficile. Molti rivenditori scrivono dozzine di regole e sinonimi per abbinare le query di ricerca al contenuto giusto. Questo può funzionare in una certa misura, ma può essere estremamente difficile, dispendioso in termini di tempo e costoso da mantenere.

I modelli di apprendimento dell’IA noti come “vettori” vengono utilizzati per codificare set di dati in rappresentazioni matematiche che possono essere utilizzate per fornire risultati eccezionalmente rilevanti.

I vettori eliminano effettivamente la necessità di scrivere sinonimi o creare regole. In confronto, le ricerche per parole chiave (come funziona oggi la maggior parte dei motori di ricerca) non funzionano in modo efficiente quando le query sono vaghe. I vettori offrono ai motori di ricerca dell’e-commerce un modo per sfruttare l’IA per trovare corrispondenze più vicine in meno tempo. Tuttavia, i vettori hanno un problema: sono lenti e costosi. Fortunatamente, in alcuni motori esiste una soluzione che accelera enormemente i vettori offrendo allo stesso tempo la potenza della ricerca basata su parole chiave.

Potenziamento del segnale

Nel 2019, se avessi cercato “maschera viso” su Amazon.com otterresti principalmente un elenco di creme antietà e maschere da notte. Nel 2022, per essere efficace, quella stessa ricerca dovrebbe includere le maschere facciali monouso N-95 per la protezione da Covid-19.

Il flusso e riflusso in cui vengono introdotti nuovi prodotti o nuove tendenze rendono essenziale che i rivenditori dispongano di una soluzione pronta per l’uso.

Il potenziamento del segnale è il processo mediante il quale i motori di ricerca sfruttano il comportamento degli utenti come clic e conversioni per ottimizzare il ranking dei risultati di ricerca. Man mano che i clienti effettuano più ricerche, i modelli di machine learning possono utilizzare i segnali (clic, conversioni) per classificare automaticamente i contenuti.

L’apprendimento della classificazione e l’apprendimento per rinforzo sono due tecniche che aiutano le soluzioni di ricerca a regolare le classifiche dei risultati in modo continuo e automatico.

Anche se non puoi sempre prevedere perfettamente la prossima tendenza, un motore di ricerca con apprendimento automatico può aiutarti apportando modifiche per te.

Personalizzazione e merchandising

I commercianti di mattoni e malta hanno imparato a massimizzare ogni centimetro di proprietà immobiliare – dai corridoi ai camerini alla fila alla cassa – dove possono essere venduti articoli simili e offerte confezionate.

È diverso per i venditori online. Per un po’, le soluzioni di raccomandazione hanno guadagnato una certa popolarità per aiutare i rivenditori a suggerire prodotti simili ai clienti. Se ti piace X, potrebbe piacerti Y. Il problema è che questi consigli erano mediocri, non personalizzati o fuori luogo.

Fino al 43% degli acquirenti utilizzerà la casella di ricerca del tuo sito, quindi personalizzare i risultati e mostrare i prodotti correlati può essere un modo migliore per fare merchandising.

La ricerca personalizzata include risultati di ricerca personalizzati per ogni individuo in base al suo profilo, che possono includere cronologia delle ricerche passate, cronologia degli acquisti, preferenza del marchio, posizione (geografica), valutazioni dei prodotti, sesso e altro ancora.

La personalizzazione inizia con i dati. Più dati demografici e psicografici si possono raccogliere su clienti e visitatori, più sofisticata può essere la personalizzazione.

Velocità di ricerca

Amazon ha dimostrato che i ritardi di millisecondi possono costare milioni di dollari in mancate entrate. La ricerca nei negozi di e-commerce deve essere veloce per fornire un’esperienza utente ottimale e ridurre l’abbandono del sito.

Quando si tratta di ricerca di prodotti, la velocità conta. Per un’usabilità ideale, è meglio:

– Aggiungere il suggerimento automatico (chiamato anche completamento automatico) alla barra di ricerca per visualizzare i risultati mentre gli utenti digitano le loro query
– Offerta di ricerca istantanea (con immagini del prodotto)
– Aggiornare dinamicamente i risultati quando gli utenti selezionano diversi filtri e facet (visualizzando l’elenco dei filtri selezionati in modo che anche le persone possano deselezionare le loro opzioni)

Tutto quanto sopra presuppone che tu abbia una soluzione di ricerca in grado di fornire risultati in millisecondi, anche durante il Black Friday.

I migliori motori di ricerca eCommerce

Algolia

Algolia è un altro strumento di ricerca per i siti di e-commerce. Funziona con tutte le principali piattaforme di e-commerce, fornendo 11 API e 4 SDK mobili. È veloce, facile da usare e flessibile. Inoltre, Algolia è una soluzione altamente sicura. Supporta tutte le lingue predefinite e fornisce filtri aggiornati durante la digitazione. C’è anche la possibilità di utilizzare la ricerca geo-ottimizzata con Algolia. Ultimo ma non meno importante è il prezzo: Algolia non costa pochissimo. Esiste anche una soluzione aziendale con funzionalità personalizzabili e tassi variabili. Prima scelta.

Typesense

Del tutto simile ad Algolia a livello di funzionalità, ma meno costoso. Forniscono meno SDK di integrazione, cosa che rende necessario utilizzare del tempo di sviluppo per la scrittura delle integrazioni. A differenza di Algolia puo’ essere hostato su proprie macchine. Seconda scelta.

Elasticsearch

Elasticsearch è uno dei motori di ricerca più popolari, utilizzato dai migliori siti di e-commerce. Essendo basato su Lucene Elasticsearch offre funzionalità di ricerca multi-tenant. Utilizza documenti JSON privi di schemi e un’interfaccia web RESTful. In quanto motore di ricerca e-commerce, Elasticsearch fornisce ricerche in tempo reale. Inoltre, il sistema è altamente scalabile. Man mano che la vostra azienda cresce, dovrete solo aggiungere qualche nodo in più per fornire al cluster la possibilità di sfruttare l’hardware aggiuntivo. Ottima soluzione la cui potenza è forse piu’ adatta ad altri tipi di ricerca piuttosto che per l’ecommerce. Scelta solo in condizioni particolari.

Apache Solr

Apache Solr è una piattaforma di ricerca open source basata su Lucene. Come il summenzionato Elasticsearch, Solr offre anche funzionalità come la ricerca full-text e l’indicizzazione in tempo reale e utilizza HTTP/XML e API JSON simili a REST. Questo motore di ricerca supporta l’evidenziazione, il clustering dinamico, la ricerca sfaccettata, l’integrazione con il database e le funzionalità NoSQL. Inoltre, otterrai una ricca gestione dei documenti con l’aiuto di Solr. Un altro aspetto importante è un’architettura di plugin, che offre ampie capacità e personalizzazioni aggiuntive. Nota che Apache Solr è il motore di ricerca di classe enterprise più popolare.

Sphinx

Sphinx è meno popolare dei precedenti server di ricerca open source, ma è ancora utilizzato dai migliori siti Web come Craigslist, Groupon e Living Social. Sphinx offre prestazioni rapide, qualità di ricerca di prim’ordine e semplice integrazione. Questo motore di ricerca funziona su tutte le principali piattaforme e sistemi. Sphinx è in grado di cercare sia file semplici che dati in un database SQL o in un archivio NoSQL. Offre molte funzioni di elaborazione del testo e supporta la personalizzazione.

Usare Elasticsearch come motore di ricerca interno di un e-commerce

Anche se spesso sottovalutato e lasciato in un angolo, il motore di ricerca interno risulta uno strumento di cruciale importanza per proprietari di e-commerce (e blog ma anche di aziende) che vogliono posizionarsi in modo efficacie su motori di ricerca e canali digitali.

In questo articolo parleremo dei principali motivi che rendono il motore di ricerca interno un investimento utile e che faciliterà la vita non solo agli utenti finali dei siti web, ma anche ai proprietari, sopratutto se la scelta sarà quella di affidarsi ad Elasticsearch.

Motore di ricerca interno e User Experience

Cercare specifici prodotti ed informazioni sul web è diventata un’attività ormai comune e quotidiana per chiunque abbia a disposizione un dispositivo con accesso ad Internet.

C’è anche da dire che l’attività di ricerca risulta appagante per un utente solamente quando è rapida e permette di trovare facilmente il risultato desiderato. Infatti, quasi la metà degli utenti cominciano la navigazione su un e-commerce digitando ciò che cercano direttamente sulla barra di ricerca.

Ma un e-commerce con un motore di ricerca interno non ottimizzato potrebbe proporre risultati non corrispondenti o poco coerenti con quanto realmente voluto dall’utente.

Il problema è che, nel 98% dei casi, se il visitatore non trova il prodotto al terzo tentativo abbandona il sito con il rischio di non tornarci mai più. Il risultato è la perdita di un potenziale cliente e di conseguenza di fatturato.

Utilizzare un motore di ricerca avanzata come Elasticsearch (di cui parleremo in seguito in questo articolo) permette di ovviare a questi inconvenienti, rendendo la User Experience piacevole e semplice.

La User Experience è un fattore così importante, che persino Google ha deciso di considerarla per determinate il ranking delle pagine web.

Un motore di ricerca ottimizzato per la UX deve essere:
• Intuitivo
• Sempre ben visibile e facile da localizzare nelle pagine dell’e-commerce
• in grado di rispondere in modo esaustivo ad ogni query

Motore di ricerca interno ed Analytics

Collegare il motore di ricerca interno ad un CMS o allo stesso Google Analytics, permette di estrapolare dati utili a comprendere meglio comportamenti e desideri di clienti e potenziali clienti.

Lo stesso Google cita testuali parole
“Guarda in che modo gli utenti eseguono ricerche sul sito.
Con Ricerca su sito, puoi sapere in che misura gli utenti utilizzano la funzione di ricerca del tuo sito, quali termini di ricerca inseriscono e con quale efficacia i risultati di ricerca creano un coinvolgimento più profondo con il tuo sito”

L’analisi di tali dati risulta estremamente utile per:
• strategie di marketing online o offline
• strategie di crescita aziendale
• stabilire obiettivi strategici relativi alla SEO
• concentrare energie e risorse a disposizione su prodotti, servizi e contenuti che sono più rilevanti per l’audience di riferimento.

Perchè usare Elasticsearch

Potresti non aver mai sentito parlare di Elasticsearch, ma avrai sicuramente goduto almeno una volta delle sue potenzialità come motore di ricerca avanzata interno.
Infatti, Elasticsearch è uno strumento molto apprezzato ed utilizzato da big come Netflix, Quora, tinder e Etsy.
Andando più nello specifico, la ricerca avanzata è uno strumento molto potente quando implementata in e-commerce con cataloghi molto ampi e ricchi di dettagli tecnici e codici.
Vediamo perché, analizzando insieme alcune delle sue caratteristiche.

• È basato su Lucene, un API open source che permette il recupero di informazioni offrendo una delle più potenti funzionalità di ricerca full-text
• Ricerca full-text Elasticsearch cerca le parole in tutto il testo grazie a funzionalità come lo stemming personalizzato e la ricerca faccettata
• Completamento automatico della ricerca: mentre l’utente digita nella barra di ricerca, Elasticsearch cerca di prevedere cosa l’utente vuole trovare basandosi sulla cronologia delle ricerche e suggerendo in automatico la keyword corretta.
• Gestione errori di ortografia e battitura: Elasticsearch riconosce le parole anche se digitate in modo scorretto
• Scalabilità orizzontale: Elasticsearch asseconda le tue esigenze di crescita, basta aggiungere un nuovo nodo al tuo cluster
• Velocità: Elasticsearch è veloce anche quando si tratta di eseguire query complesse
• Record dati: ogni modifica effettuata viene propagata su tutti i nodi riducendo il rischio di perdere dati rilevanti
• Elasticsearch e multi-tenancy il che permette di gestire raccolte separate di documenti appartenenti a diversi utenti

Queste sono solo alcune delle eccezionali funzionalità di Elasticsearch!
Per scoprirle tutte dai un’occhiata al sito ufficiale https://www.elastic.co/elasticsearch/features

Riepilogando, l’utilizzo di un motore interno di ricerca avanzata come Elasticsearch in un e-commerce porterà alla tua attività due enormi vantaggi:
1. Una user experience invidiabile! I tuoi utenti saranno appagati riuscendo sempre a trovare in modo semplice, veloce e preciso ciò che cercano… e si sa, un cliente felice è un cliente che torna.
2. Nuovi dati da analizzare per rendere più efficaci strategie di marketing, SEO rendendo più performante il business.

Migrazione da Algolia verso Elasticsaerch

Quando si parla di ricerca full-text su siti o applicazioni e specialmetnte come motore di ricerca per l’ e-commerce Algolia è sicuramente il miglior servizio disponibile, ma sicuramente costoso quando il numero delle ricerche comincia ad aumentare. Elasticsearch puo’ essere un’ottima soluzione di ripiego, sicuramente piu’ economica anche se con prestazioni diverse. In questo articolo invece analizziamo le caratteristiche principali dei database NoSql.

Le funzionalità di Algolia

Parlando di web-applications, le funzionalità che Algolia mette a disposizione sono strabilianti. Questo sopratutto grazie alle librerie client che Algolia stessa rilascia per l’integrazione sulle varie piattaforme. Queste librerie permettono una ricerca in tempo reale su database di milioni di records, rendendo inegualgliabile l’esperienza di ricerca sui documenti per precisione e velocità.

Un punto negativo di Algolia è invece il prezzo: siccome le tariffe sono tarate sulla quantità di ricerche effettuate, maggiore è il numero di ricerche sul sito, maggiore è il prezzo, cosa che ne rende l’adozione difficile per tutte quell imprese che non hanno l’intenzione di investire un migliaio di euro al mese per il servizio di ricerca.

La migrazione verso un servizio di ricerca alternativo

Nel nostro caso, il cliente aveva chiesto, data la necessità di ridurre i costi della ricerca per privilegiare altri tipi di sviluppo, di poter utilizzare un servizio alternativo. La loro indicazione era quella di testare in ogni caso la ricerca sul database MySQL della web-application, un installazione Laravel datata qualche annetto.

Le problematiche da risolvere nell’attività di migrazione del database Algolia

Le fasi delicate da affrontare nella migrazione dei dati contenuti nel database di Algolia, circa 1 milione e mezzo di record, erano:
– la realizzazione di uno script che esportasse i records da Algolia e li importasse nella nuova soluzione
– la realizzazione in Laravel di un servizio di query sulla nuova soluzione che riproducesse il piu’ possibile le caratteristiche di Algolia sia come velocità che come intelligenza nella ricerca full-text in lingua italiana
– la sostituzione delle funzionaità di caricamento dei dati su Algolia con funzionalità per il nuovo servizio.

La migrazione da Algolia a MySql

Una cosa molto positiva che si puo’ dire di Algolia è che il procedimento di esportazione dei dati è molto chiaro ed efficiente: attraverso una chiamata api ‘browse’ si ottiene l’eportazione di tutto il database ad una velocità strabiliante.

Peccato che lo stesso non si possa dire di MySql:un volta riprodotta la struttura di tabelle (con indicizzazione fulltext, inno-db), lo script di migrazione che estraeva i dati da Algolia per inserirli nelle nuove tabelle andava a rilento e quasi sempre vero i 300.000 records falliva, killato dallo stesso sistema operativo (Ubuntu 20, un istanza Digital Ocean con 2 processori ed 8Gb di memoria).

Abbiamo dovuto creare uno script che potesse caricare solo 100.000 records alla volta, ed in questo modo in un tempo di ca 6/7 ore l’intera esportazione poteva adare a buon termine.

Qui pero’ cominciavano i guai seri, perchè la query MySql fultext (match…against) su una tabella di una decina di Gb risultava essere molto lenta oltre che imprecisa (la durata dell’esecuzione oltretutto aumentava con l’aumentare delle parone nella stringa ricercata).

Verificata l’inefficienza di MySql in questo tipo di attività, abbiamo proposto al cliente l’adozione di Elasticsearch.

La migrazione da Algolia a Elasticsearch

Abbiamo quindi installato Elasticsearch tramite Docker su un’istanza EC2 Small Amazon Aws. La migrazione è risultata molto rapida grazie alle api bulk di Elasticsearch.

La ricerca sul motore Lucene di Elasticsearch è risultata molto precisa e veloce. L’unica differenza alla fine dell’attività è stata la mancanza della ricerca in tempo reale fornità da Algolia, ma nel complesso Elasticsearch si rivela essere un competitor di alto livello con prezzi concorreziali.

Come potenziare la ricerca su WordPress con Elasticsearch

In alcuni casi avere un efficente motore di ricerca interno al sito puo’ essere fondamentale per aumentare l’engagement di un utente. Sopratutto gli e-commerce, oppure i siti con elevato volume di contenuti, rischiano di perdere l’utente qualora il tempo di ricerca di un determinato prodotto o soggetto si protragga per troppo tempo. L’utente non è per sua natura paziente, e pretende risposte precise ed immediate.

In questo articolo cercheremo di riassumere alcuni concetti fondamentali riguardanti il motore di ricerca di WordPress (e quindi di WooCommerce) ed una soluzione per migliorare notevolmente le prestazioni di ricerca utilizzando Elasticsearch, un motore di ricerca distribuito per tutti i tipi di dati basato su Apache Lucene.

Le nuove versioni di Elasticsearch inoltre migliorano notevolmente il lavoro sulle intenzioni di ricerca grazie a componenti di intelligenza artificiale.

1) La ricerca full-text su MySql
2) La ricerca su WordPress e Woocommerce
3) Installazione ambiente di test
4) Abilitazione del log delle slow query su MySql
5) Analisi di una query di ricerca su WordPress
6) La stessa query eseguita su Elasticsearch
7) Conclusioni

1. La ricerca full-text su MySql

La ricerca “full-text” (FTS) è la ricerca classica che facciamo, su Google o su qualsiasi altro motore di ricerca quando ricerchiamo una determinata parola o una frase. Questo tipo di ricerca è una tecnica per trovare documenti che possono non corrispondere esattamente ai criteri di ricerca.

Possiamo per esempio cercare le parole “Sole e Mare” e la FTS potrà restituire documenti che contengono sia esclusivamente ciascuna delle due sinole parole, “Sole” o “Mare”, oppure risultati che contengono entrambe le parole sia nellordine esatto che in un altro ordine, per esempio “Sole e Mare” oppure “Mare e Sole”.

Parlando tecnicamente, MySql supporta le ricerche di testo parziali utilizzando l’operatore “LIKE” e le regular expressions. Questo tipo di ricerca ha pero’ diversi limiti man mano che aumentano le dimesioni del campo di testo in cui la ricerca viene fatta, oppure aumenta il numero dei records nella tabella in cui si cerca.

I limiti principali sono:
1) una scarsa performance, perchè MySql deve cercare i termini in tutti i campi della tabella prima di restituire i risultati
2) una scarsa flessibilità nella ricerca, in quanto diventa difficile trovare risultati che escludano uno dei termini della ricerca (per esempio “Mare” ma non “Sole”)
3) l’impossibilità di avere un punteggio di rilevanza nei risultati ottenuti

A causa di queste limitazioni, MySql, a partire dalla versione 5.6 ha introdotto un indice apposito per le ricerche full-text.

2. La ricerca su WordPress e Woocommerce

Sfortunatamente la struttura del database MySql che arriva con l’installer di wordpress non utilizza le nuove funzionalità introdotte in MySQL. Nella tabella ‘wp_posts’ per esempio possiamo notare come l’indicizzazione usata sia quella standard, ossia la ‘BTREE’.

Senza stare ad addentrarsi nelle dinamiche del funzionamento di questo tipo di indice, si puo’ dire semplicemente che tale indice permette di effettuare delle ricerche con operatori di uguaglianza (= oppure <=>),operatori che diano risultati all’interno di un range (>, <, >=, <=, BETWEEN), oppure l’operatore LIKE.

Adesso viene pero’ il bello perchè andremo a strutturare un ambiente per misurare l’effettivo carico delle query di ricerca su WordPress ed esaminarne la struttura.

3. Installazione ambiente di test

Per poter effettuare il nostro benchmarch e capire quale sia veramente il costo delle query di ricerca su WordPress ed avere un termine di paragone con una query eseguita su Elasticsearch abbiamo:

1) Installato un’istanza di WordPress
Per eseguire questo passaggio in velocità abbiamo approfittato delle istanze ready to run sul marketplace di Digital Ocean. Per dare un po’ di brillantezza alla ricerca abbiamo optato per una configurazione con 2 CPU dedicate e 8GB di memoria. Se ce ne fosse bisogno potrete rinfrescare la vostra conoscenza leggendo l’articolo “Cos’è e come finziona WordPress”

2) Installato un’istanza di Elasticsearch
Utilizzando un container Docker su Amazon AWS, in questo caso la potenza dell’istanza è minima: una T2.small con 1CPU e 2GB di ram

3) Inserito una serie di dati dummy per poter fare ricerche full-text su un database consistente

Per utilizzare le api-rest di WordPress in maniera veloce, ma non sicura, abbiamo installato un plugin che permetta un’autenticazione di tipo Basic. Questa pratica è ovvimante sconsigliata all’utilizzo in produzione.

Lato Elasticsearch abbiamo creato un index che riporoducesse i campi full-text del database MySql di WordPress in modo da poter effettuare parallelamente la stessa ricerca sui due database.

Utilizzando il servizio api Loripsum abbiamo inserito 11.000 articoli sul nostro WordPress con titoli e contenuti random.

Questo il sorgente del file che ha effettuato il caricamento dei dati:

function wp_insert($title,$content){
$username = 'xxxxxxx';
$password = 'yyyyyyyyyyy';
$rest_api_url = "https://my.test.site/wp-json/wp/v2/posts";

$data_string = json_encode([
    'title'    => $title,
    'content'  => $content,
    'status'   => 'publish',
]);

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $rest_api_url);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data_string);

curl_setopt($ch, CURLOPT_HTTPHEADER, [
    'Content-Type: application/json',
    'Content-Length: ' . strlen($data_string),
    'Authorization: Basic ' . base64_encode($username . ':' . $password),
]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

$result = curl_exec($ch);

curl_close($ch);
return json_decode($result);
}
function dbg($s){
	echo "\n";
	print_r($s);
	echo "\n";
}
function es_insert($title,$content,$link){
	$topost = array(
		"link" => $link,
		"title" => $title,
		"description" => $content,
		"pubdate" => date("Y-m-d H:i:s"),
		"author" => "Admin"
	);
	$data = json_encode($topost,JSON_PRETTY_PRINT);
	$ch = curl_init();

	curl_setopt($ch, CURLOPT_URL, 'elasticearch.host.ip:9200/post/_doc/?pretty');
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
	curl_setopt($ch, CURLOPT_POST, 1);
	curl_setopt($ch, CURLOPT_POSTFIELDS, $data);

	$headers = array();
	$headers[] = 'Content-Type: application/json';
	curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

	$result = curl_exec($ch);
	if (curl_errno($ch)) {
	    echo 'Error:' . curl_error($ch);
	}
	curl_close($ch);
	return json_decode($result);
}

function li_get($wich){

        $ch = curl_init();
        curl_setopt($ch, CURLOPT_URL, $wich);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        $output = curl_exec($ch);
        curl_close($ch);
        return $output;      
}


for($i=0;$i<10000;$i++){ $title = li_get("https://loripsum.net/api/1/short"); $incipit = "Lorem ipsum dolor sit amet, consectetur adipiscing elit."; $title = str_replace($incipit, "", $title); $title = substr(trim($title),0,100); $title = strip_tags($title); $title = preg_replace('/\[.*\]/', '', $title); dbg($title); if($title == "") die('aaaaargh'); $content = li_get("https://loripsum.net/api/20/verylong/headers"); $wp = wp_insert($title,$content); if(isset($wp->link)){
		dbg($wp->link);
		$uno = strip_tags($content);
		$testo = preg_replace('/\[.*\]/', '', $uno);
		
		$es = es_insert($title,$testo,$wp->link);
		dbg($es);
	}
}

Proviamo a misurare il volume del database che abbiamo creato:

mysql> SELECT
    ->   TABLE_NAME AS `Table`,
    ->   ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024) AS `Size (MB)`
    -> FROM
    ->   information_schema.TABLES
    -> WHERE
    ->     TABLE_SCHEMA = "wordpress"
    ->   AND
    ->     TABLE_NAME = "wp_posts"
    -> ORDER BY
    ->   (DATA_LENGTH + INDEX_LENGTH)
    -> DESC;
+----------+-----------+
| Table    | Size (MB) |
+----------+-----------+
| wp_posts |       366 |
+----------+-----------+
1 row in set (0.01 sec)

Sono 366 Mb, nemmeno tanti…. 🙂

4. Abilitazione del log delle slow query su MySql

Per poter misurare correttamente il tempo di esecuzione delle query di ricerca di WordPress abbiamo ancora bisogno di istruire MySql affinchè scriva in un file di log i dettagli delle query la cui esecuzione superi un certo periodo di tempo.

Per fare questo andiamo ad aggiungere alcune istruzioni nel file di configurazione di MySql. Apriamo con un editor il file di configurazione:

nano /etc/mysql/mysql.conf.d/mysqld.cnf

ed aggiungiamo queste linee:

 slow_query_log         = 1
 slow_query_log_file    = /var/log/mysql/slow.log
 long_query_time = 1
 log-queries-not-using-indexes = ON

Poi creiamo il file di log e lo rendiamo scrivibile (quest’ultima istruzione è da evitare in produzione ma bisogna attribuire all’utente mysql la proprietà del file):

touch /var/log/mysql/slow.log
chmod 777 /var/log/mysql/slow.log

Ora facciamo ripartire MySql con la nuova configurazione:

/etc/init.d/mysql restart

5. Analisi di una query di ricerca su WordPress

Abbiamo ora tutti gli elementi per poter testare una query di ricerca su WordPress. Abbiamo 11.000 post riempiti di Lorem Ipsum, possiamo scegliere 2 termini a caso che sappiamo presenti in un articolo, inserirli nella form di ricerca e vedere come si comporta WordPress.

La ricerca che io ho scelto di fare è sui termini “Cicero cognoscere”. Eseguo la ricerca. Vado a leggere nel log delle slow query cosa è successo.

Questa è la query che WordPress ha fatto:

SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts  WHERE 1=1  
AND (((wp_posts.post_title LIKE '%Cicero%') 
OR (wp_posts.post_excerpt LIKE '%Cicero%') 
OR (wp_posts.post_content LIKE '%Cicero%')) 
AND ((wp_posts.post_title LIKE '%cognoscere%') 
OR (wp_posts.post_excerpt LIKE '%cognoscere%') 
OR (wp_posts.post_content LIKE '%cognoscere%')))  
AND wp_posts.post_type IN ('post', 'page', 'attachment') 
AND (wp_posts.post_status = 'publish' OR wp_posts.post_author = 1 AND wp_posts.post_status = 'private')  
ORDER BY (CASE WHEN wp_posts.post_title LIKE '%Cicero cognoscere%' THEN 1 WHEN wp_posts.post_title LIKE '%Cicero%' AND wp_posts.post_title LIKE '%cognoscere%' THEN 2 WHEN wp_posts.post_title LIKE '%Cicero%' OR wp_posts.post_title LIKE '%cognoscere%' THEN 3 WHEN wp_posts.post_excerpt LIKE '%Cicero cognoscere%' THEN 4 WHEN wp_posts.post_content LIKE '%Cicero cognoscere%' THEN 5 ELSE 6 END), wp_posts.post_date DESC LIMIT 0, 10;

Ossia, WordPress ha cercato singolarmente le due parole richieste nei campi titolo, excerpt e content della tabella posts ove il tipo di post fosse un artcolo, una pagina o un attachment (ossia un immagine).

Li ha poi ordinati come importanza a seconda che nel titolo vi fosse la stringa completa o uno dei due termini e con lo stesso criterio a seguire e disponendoli a seconda della data di creazione in maniera discendente ed in numero di 10.

E poi:

# Query_time: 3.922342  Lock_time: 0.000138 Rows_sent: 10  Rows_examined: 12734

L’effettuazione della query ha preso 3,9 secondi per cercare in 12734 records.

Considerando la potenza della macchina ed il fatto che questa query fosse l’unica attività in corso in quel momento, la prestazione non sembra in effetti molto brillante. Altri test fatti su macchine meno performanti hanno dato, ovviamente, risultati decisamente peggiori.

Ma sopratutto il criterio lascia perplessi, in quanto come si puo’ osservare dagli id dei post ottenuti in risposta alla query

+-------+
| ID    |
+-------+
| 11465 |
| 11459 |
| 11452 |
| 11451 |
| 11443 |
| 11442 |
| 11437 |
| 11434 |
| 11432 |
| 11416 |
+-------+

sono stati selezionati esclusivamente post molto recenti, il che non è una garanzia per l’ottimizzazione del risultato di ricerca.

E’ necessario anche sottolineare il fatto che tutti i plugin che esistono per implementare diversi modi di ricerca per Worpress o WooCommerce possono migliorare il dettaglio del risultato ma non certo la prestazione che anzi, quasi sempre, peggiorano.

6. La stessa query eseguita su Elasticsearch

Andiamo ora ad implementare la ricerca verso Elasticsearch che, come abbiamo detto, risiede su un’altra macchina, non molto performante, su un altro cloud, le due macchine sono comunque nella stessa regione US-EAST.

Per amor di brevità prenderemo una scorciatoia, ovvio che questa implementazione dovrebbe essere fatta diversamente. Da notare che esistono dei plugin per integrare WordPress con Elasticsearch, ma, ahimè, non funzionano 😉

Creiamo quindi una pagina con slug /elasticsearch-search

Creiamo poi un template di pagina, lo chiamiamo “Elastic Page Search”. Dentro il template creiamo una form che abbia un input di testo per la rcerca e la action allo slug della nostra pagina. Inseriamo poi, dopo la form, questo codice:

if(isset($_POST['string']) && $_POST['string'] != ""){
$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, 'my.elasticsearch.ip:9200/post/_search?pretty');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, "\n{\n  \"query\": {\n    \"multi_match\" : {\n      \"query\":    \"".$_POST['string']."\", \n      \"fields\": [ \"title^2\", \"description\" ] \n    }\n  },\n   \"fields\": [\"title\", \"link\"],\n   \"_source\": false\n}\n");

$headers = array();
$headers[] = 'Content-Type: application/json';
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

$result = curl_exec($ch);
if (curl_errno($ch)) {
echo 'Error:' . curl_error($ch);
}
curl_close($ch);
}

$res = json_decode($result);
print_r($result);

Analizziamo in particolare il JSON con cui andiamo ad interrogare Elasticsearch:

{
  "query": {
    "multi_match" : {
      "query":    "Cicero cognoscere", 
      "fields": [ "title^2", "description" ] 
    }
  },
   "fields": ["title", "link"],
   "_source": false
}

Praticamente, noi cerchiamo la nostra frase nel titolo e nella descrizione del post, specificando che qual’ora venisse ritrovato nel titolo uno dei termini, questo verrebbe valutato doppio nell’attribuzione del ranking di Elasticsearch, e ci facciamo restituire solo il titolo e lo slug dell’articolo. Otteniamo questi risultati:

{
  "took" : 846,
  "timed_out" : false,
  "_shards" : {
    "total" : 3,
    "successful" : 3,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 876,
      "relation" : "eq"
    },
    "max_score" : 3.5842853,
    "hits" : [
      {
        "_index" : "post",
        "_type" : "_doc",
        "_id" : "KIuDyXYBaPVcgdaTjmHU",
        "_score" : 3.5842853,
        "fields" : {
          "link" : [
            "https://awswp.pipozzi.site/quae-diligentissime-contra-aristonem-dicuntur-a-chryippo-scrupulum-inquam-abeunti-contemnit/"
          ],
          "title" : [
            " Quae diligentissime contra Aristonem dicuntur a Chryippo. Scrupulum, inquam, abeunti; Contemnit "
          ]
        }
      },
      {
        "_index" : "post",
        "_type" : "_doc",
        "_id" : "8YuJyXYBaPVcgdaTLmEi",
        "_score" : 3.572124,
        "fields" : {
          "link" : [
            "https://awswp.pipozzi.site/post-enim-chrysippum-eum-non-sane-est-disputatum-duo-reges-constructio-interrete-nihil-illinc/"
          ],
          "title" : [
            " Post enim Chrysippum eum non sane est disputatum. Duo Reges: constructio interrete. Nihil illinc"
          ]
        }
      },

....

Traducendo i messaggi piu’ importanti che Elasticsearch ci manda, otteniamo che:
1) la query è stata eseguita in 0,846 secondi (“took” : 846)
2) sono stati trovati 876 documenti contenenti la nostra chiave (hits->total->value = 876)
3) Elasticsearch ci ha restituito 10 risultati ( avremmo potuto scegliere il numero) ordinati secondo il punteggio ( “_score” : 3.572124 ) che lui ha calcolato utilizzando il suo sofisticato sistema di indicizzazione.

7. Conclusioni

Possiamo concludere il nostro tutorial affermando che in tutte le web applications gestite con WordPress, e quindi con WooCommerce, in cui venga gestito un grande volume di dati, soppiantare il sistema di ricerca nativo con un sistema parallelo basato su Elasticsearch porta indiscutibilmente una serie di vantaggi fondamentali:

1) Esecuzione della ricerca con velocità almeno 4 volte superiore
2) Maggiore precisione nella ricerca
3) Maggiore consistenza dei risultati ottenuti grazie al sistema di ranking di Elasticsearch

6 concetti fondamentali per capire Elasticsearch

Elasticsearch è un motore di ricerca sempre più diffuso anche nelle aziende medie e piccole. Benchè sia utilizzato da grandi players come Netflix, Microsoft, eBay, Facebook e altri, le sue funzionalità possono miglirare moltissimo le performance di qualsiasi impresa.Molto utilizzato anche come motore di ricerca interno nell’ e-commerce ,in questo articolo condividiamo sei concetti fondamentali di Elasticsearch che vale la pena conoscere prima di utilizzarlo nei propri sistemi. In un altro articolo abbiamo spiegato in breve che cosa è Elasticsearch.

In questo artcolo invece vi proponiamo 6 concetti non banali utili alla comprensione di Elastisearch:

1) Elastic Stack
2) Due tipi di data set
3) Il punteggio di ricerca
4) Il modello di dati
5) Pianificazione degli shards
6) Tipi di nodo

1. Elastic Stack

Elasticsearch è stato inizialmente sviluppato come prodotto indipendente. Il suo unico ruolo era fornire un motore di ricerca scalabile, che fosse utilizzabile tramite qualsiasi linguaggio. Così è stato creato con un modello distribuito al centro con un’interfaccia API REST per la comunicazione.

Dopo una fase di prima adozione, sono stati inventati nuovi strumenti per lavorare con Elasticsearch. È arrivato Kibana, per la visualizzazione e l’analisi dei dati, e Logstash, per la raccolta dei files di registro. Attualmente ci sono una serie di strumenti che sono tutti sviluppati sotto la cura dell’azienda produttrice Elastic:

Elasticsearch – per la ricerca,
Kibana – analisi e visualizzazione dei dati,
Logstash: pipeline di elaborazione dati lato server,
Beats: caricatori di dati monouso,
Elastic Cloud: hosting di cluster Elasticsearch,
Machine Learning: per scoprire modelli di dati,
APM – Monitoraggio delle prestazioni delle applicazioni,
Swiftype: ricerca nel sito con un clic.

Il numero di strumenti cresce ogni anno, il che consente alle aziende di raggiungere nuovi obiettivi e creare nuove opportunità.

2. Due tipi di data set

Fondamentalmente in Elasticsearch si può indicizzare (cioè memorizzare) qualsiasi tipo di dato. Ma in realtà ce ne sono due classi, che hanno un forte impatto sulla configurazione e gestione del cluster: dati statici e serie di dati temporali.

I dati statici sono set di dati che possono crescere o cambiare lentamente. Come un catalogo o un inventario di articoli. Si possono pensare come i dati che si archiviano nei database regolari. Post di blog, libri della biblioteca, ordini, ecc. Si indicizzano questi dati in Elasticsearch per consentire ricerche velocissime, che ridicolizzano le prestazioni dei normali database SQL.

D’altra parte, si possono memorizzare set di dati temporali. Questi possono essere eventi associati a un momento nel tempo che in genere cresce rapidamente, come file di registro o metriche. Fondamentalmente si indicizzano in Elasticsearch per l’analisi dei dati, la scoperta di modelli e il monitoraggio dei sistemi.

A seconda del tipo di dati archiviati, è necessario modellare il cluster in modo diverso. Per i dati statici si dovrebbero scegliere un numero fisso di indici e shards. Non cresceranno molto velocemente e si potrà sempre cercare in tutti i documenti nel set di dati.

Per le serie di dati temporali è necessario scegliere indici a rotazione con limiti di tempo. Saranno i dati recenti ad essere interrogati piu’ spessoe alla fine si renderà necessario eliminare, o almeno archiviare i documenti obsoleti per risparmiare spazio sulle macchine.

3. Il punteggio di ricerca (search score)

Lo scopo principale di Elasticsearch è fornire un motore di ricerca. L’obiettivo è fornire i migliori documenti corrispondenti. Ma come fa effettivamente Elasticsearch a sapere quali sono?

Per ogni query di ricerca Elasticsearch calcola un punteggio di pertinenza. Il punteggio si basa sull’algoritmo tf-idf, che sta per Term Frequency – Inverse Document Frequency.

Fondamentalmente due valori vengono calcolati in questo algoritmo. Il primo, la frequenza dei termini, indica la frequenza con cui un determinato termine viene utilizzato in un documento. Il secondo – frequenza del documento inversa – dice quanto sia unico un dato termine in tutti i documenti.

Ad esempio, se abbiamo due documenti:

1) To be or not to be, that is the question.
2) To be. I am. You are. He, she is.

Il TF per il termine “question” è

1) per il documento 1: 1/10 (1 occorrenza su 10 termini)
2) per il documento 2: 0/9 (0 occorrenze su 9 termini).

D’altra parte l’IDF viene calcolato come un singolo valore per un intero set di dati. È un rapporto tra tutti i documenti e i documenti contenenti il termine cercato.
Nel nostro caso è:

log(2/1) = 0.301

(2 – numero di tutti i documenti, 1 – numero di documenti contenenti il termine ‘question’).

Infine il punteggio tf-idf per entrambi i documenti viene calcolato come prodotto di entrambi i valori:

documento 1: 1/10 x 0,301 = 0,1 * 0,301 = 0,03
documento 2: 0/9 x 0,301 = 0 * 0,301 = 0,00

Ora vediamo che il documento 1 ha una rilevanza di valore 0,03, mentre il documento 2 ha ottenuto 0,00. Pertanto il documento 1 verrà pubblicato più in alto nell’elenco dei risultati.

Potrete leggere la descrizione di un esempio pratico di utilizzo del ‘search score’ in quest’articolo che riguarda Elasticsearch e WordPress .

4. Modello di dati

Elasticsearch ha due vantaggi in termini di prestazioni. È scalabile orizzontalmente e molto veloce. Da dove viene quest’ultima caratteristica? E’ dovuta al modo in cui i dati vengono archiviati.

Quando si indicizza un documento, questo attraversa tre passaggi: filtri dei caratteri, un tokenizer e filtri dei token. Sono usati per normalizzare il documento. Ad esempio un documento:

To be or not to be, that is the question.

viene effettivamente memorizzato come:

to be or not to be that is the question

se i segni di punteggiatura vengono rimossi e tutti i termini sono resi minuscoli.

Ma questa non è tutto. Può essere memorizzato anche come

question

se viene applicato il filtro delle parole non significative che rimuove tutti i termini del linguaggio comune come: to, be, or, not, that, is, the. Vi sono elenchi di cosiddette ‘stop words’ in moltissimi linguaggi, incluso l’Italiano.

Questa è la parte dell’indicizzazione. Ma gli stessi passaggi vengono applicati durante la ricerca di documenti. La query viene anche filtrata per i caratteri, tokenizzata e filtrata per i token. Quindi Elasticsearch cerca documenti con i termini normalizzati. I campi in Elasticsearch sono memorizzati in una struttura di indice invertita e rende la raccolta dei documenti corrispondenti molto veloce.

È possibile definire filtri specifici per ogni campo. Le definizioni sono raggruppate in strutture chiamate analizzatori (analyzers). Un campo può essere analizzato con più analizzatori per raggiungere obiettivi diversi. Quindi in una fase di ricerca si può definire quale tipo di campo si vuole scansionare per ottenere i risultati desiderati.

Applicando queste modalità, ElasticSearch può fornire risultati molto più velocemente rispetto ai database normali.

5. Pianificazione degli shards

Una delle domande più frequenti dei neofiti di Elasticsearch è: quanti shards e indici è consigliato avere? Questa domanda sorge perchè il numero di frammenti può essere impostato solo all’inizio della creazione dell’indice.

Quindi la risposta dipende davvero dal set di dati che si intende indicizzare. La regola pratica è che gli shards dovrebbero essere costituiti da 20–40 GB di dati.Il concetto di ‘shard’ proviene da Apache Lucene (che è il motore di ricerca utilizzato sotto il cofano di Elasticsearch). Tenendo presente tutte le strutture ed i costi macchina generali che Apache Lucene utilizza per gli indici invertiti e le ricerche veloci, non ha senso avere piccoli frammenti, come 100 MB o 1 GB.

20–40 GB è la dimensione consigliata dai consulenti Elastic. Bisogna avere presente che un frammento non può essere ulteriormente suddiviso e risiede sempre su un singolo nodo. Lo shard di tali dimensioni può essere facilmente spostato su altri nodi o replicato, se necessario, all’interno di un cluster. Avere questa capacità di sharding offre un compromesso consigliato tra velocità e consumo di memoria.

Ovviamente in ogni caso particolare, le metriche delle prestazioni possono mostrare qualcosa di diverso, quindi bisogna tenere presente che questa è solo una raccomandazione ma è sempre possibile raggiungere altri obiettivi di rendimento.

Per sapere quanti shards per indice si dovrebbero avere, è possibile semplicemente stimarlo, indicizzando un numero di documenti in un indice temporaneo e vedere quanta memoria stanno consumando e quanti di di questi ci si aspetti di avere in un periodo di tempo (in un set di dati di una serie temporale) o globalmente (in un set di dati statici).

Non bisogna dimenticare che anche se si configura in modo errato il numero di shards o di indici, è sempre possibile reindicizzare i dati in un nuovo indice con un numero diverso di shards impostato.

Ultimo, ma non per importanza. Si possono sempre eseguire query per più indici contemporaneamente. Ad esempio, si possono avere indici a rotazione per i dati basati sui log con conservazione giornaliera e semplicemente chiedere risultati per tutti i giorni del mese scorso in una query. L’interrogazione di 30 indici con 1 shards ha lo stesso impatto sulle prestazioni dell’interrogazione di 1 indice con 30 shards.

6. Tipi di nodo

I nodi di Elasticsearch possono svolgere più ruoli. Per impostazione predefinita, il che è positivo per i piccoli cluster, possono servirli tutti. I ruoli di cui sto scrivendo sono:

1) master node,
2) data node,
3) ingest node,
4) coordinating-only node.

Ogni ruolo ha le sue conseguenze. I nodi principali sono responsabili delle impostazioni e delle modifiche a livello di cluster, come la creazione o l’eliminazione di indici, l’aggiunta o la rimozione di nodi e l’allocazione di shards ai nodi.

Ogni cluster dovrebbe essere composto da almeno 3 nodi idonei per il master e in realtà non è necessario averne altri. Di tutti i nodi idonei per il master, uno viene scelto come nodo master e il suo ruolo è eseguire azioni a livello di cluster. Gli altri due nodi sono necessari esclusivamente per l’alta disponibilità. I nodi master hanno requisiti bassi su CPU, RAM e memoria su disco.

I nodi di dati (data nodes) vengono utilizzati per l’archiviazione e la ricerca dei dati. Quindi hanno requisiti elevati su tutte le risorse: CPU, RAM e disco. Più dati hai, maggiori sono le aspettative riguardo all’allocazione di risorse.

I nodi di importazione (ingest nodes) vengono utilizzati per la pre-elaborazione dei documenti prima che avvenga l’effettiva indicizzazione. Intercettano le query bulk e di indice, applicano le trasformazioni e quindi ritrasmettono i documenti alle API di indice o bulk. Richiedono poco disco, RAM media e CPU alta.

I nodi di solo coordinamento (coordinating-only nodes) viene utilizzato come bilanciatore del carico per le richieste dei client. Sanno dove possono risiedere documenti specifici e servono le richieste di ricerca solo a quei nodi. Quindi eseguono azioni scatter & gatter sui risultati ricevuti. I requisiti per loro sono: poco disco, RAM media o alta e CPU media o alta.

Ogni nodo può svolgere uno o più dei ruoli sopra elencati. Il ruolo di coordinamento è svolto da qualsiasi tipo di nodo. Per avere un nodo di solo coordinamento devi disabilitare su di esso tutti gli altri ruoli nella configurazione.

Ecco qualche consiglio sulla maniera piu’ comune di configurare un cluster:

1) tre nodi principali, non esposti al mondo e che mantengono lo stato del cluster e le impostazioni del cluster,
2) un paio di nodi di solo coordinamento: ascoltano le richieste esterne e agiscono come bilanciatori intelligenti del carico per l’intero cluster,
3) un numero di nodi di dati, a seconda delle esigenze del set di dati,
4) un paio di nodi di importazione (facoltativamente) – se si esegue una pipeline di importazione e si desidera alleviare gli altri nodi dall’impatto della pre-elaborazione dei documenti.

I numeri specifici dipendono dal proprio particolare caso d’uso e devono essere dimensionati in base ai test delle prestazioni.

Ovviamente, maggiori dettagli su tutto questo li potrete trovare sul sito ufficiale di Elastic.