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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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:

1. Atomicità
2. Consistenza
3. Isolamento
4. 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:

1. 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.
2. Gli strumenti BI, reporting ed ETL basati su SQL non saranno compatibili con un’applicazione personalizzata
   Implementazione SQL.
3. 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.