Solr vs. ElasticSearch [chiuso]

Quali sono le principali differenze architettoniche tra queste tecnologie?

Inoltre, quali casi d'uso sono generalmente più appropriati per ciascuno?

Aggiornare

Ora che l'ambito della domanda è stato corretto, potrei aggiungere qualcosa anche a questo proposito:

Esistono molti confronti tra Apache Solr ed ElasticSearch disponibili, quindi farò riferimento a quelli che ho trovato più utili, coprendo cioè gli aspetti più importanti:

• Bob Yoplait ha già collegato la risposta di Kim a ElasticSearch, Sphinx, Lucene, Solr, Xapian. Quale si adatta a quale utilizzo? , che riassume i motivi per cui è andato avanti e ha creato ElasticSearch , che a suo avviso offre un modello distribuito molto superiore e una facilità d'uso rispetto a Solr.

• Ricerca in tempo reale di Ryan Sonnek : Solr vs Elasticsearch fornisce un'analisi / un confronto approfondito e spiega perché è passato da Solr a ElasticSeach, nonostante sia già un felice utente Solr - lo riassume come segue:

  Solr può essere l'arma preferita quando si creano applicazioni di ricerca standard , ma Elasticsearch lo porta al livello successivo con un'architettura per la creazione di moderne applicazioni di ricerca in tempo reale . La percolazione è una funzione eccitante e innovativa che solleva da solo Solr dall'acqua. Elasticsearch è scalabile, veloce e un sogno con cui integrarsi . Adios Solr, è stato bello conoscerti. [enfasi mia]

• L'articolo di Wikipedia su ElasticSearch cita un confronto con la rinomata rivista iX tedesca, elencando vantaggi e svantaggi, che riassumono praticamente ciò che è già stato detto sopra:

  Vantaggi :

  • ElasticSearch è distribuito. Nessun progetto separato richiesto. Anche le repliche sono quasi in tempo reale, che si chiama "Replicazione push".
  • ElasticSearch supporta completamente la ricerca quasi in tempo reale di Apache Lucene.
  • La gestione della multi-tenancy non è una configurazione speciale, in cui con Solr è necessaria una configurazione più avanzata.
  • ElasticSearch introduce il concetto di Gateway, che semplifica i backup completi.

  Svantaggi :

  • Solo uno sviluppatore principale [non applicabile più secondo l'attuale organizzazione GitHub di elasticsearch , oltre ad avere una base di committer piuttosto attiva in primo luogo]
  • Nessuna funzione di autowarming [non più applicabile secondo la nuova API Index Warmup ]

Risposta iniziale

Sono tecnologie completamente diverse che affrontano casi d'uso completamente diversi, quindi non possono essere confrontate in alcun modo significativo:

• Apache Solr - Apache Solr offre le funzionalità di Lucene in un server di ricerca veloce e facile da usare con funzionalità aggiuntive come sfaccettatura, scalabilità e molto altro

• Amazon ElastiCache - Amazon ElastiCache è un servizio Web che semplifica l'implementazione, il funzionamento e il ridimensionamento di una cache in -memory nel cloud.

  • Tieni presente che Amazon ElastiCache è conforme al protocollo con Memcached, un sistema di memorizzazione nella cache di oggetti di memoria ampiamente adottato, quindi codice, applicazioni e strumenti popolari che utilizzi oggi con ambienti Memcached esistenti funzioneranno perfettamente con il servizio (vedi Memcached per dettagli).

[enfasi mia]

Forse questo è stato confuso con le seguenti due tecnologie correlate in un modo o nell'altro:

• ElasticSearch - È un motore di ricerca Open Source (Apache 2), distribuito, RESTful, costruito su Apache Lucene.

• Amazon CloudSearch - Amazon CloudSearch è un servizio di ricerca completamente gestito nel cloud che consente ai clienti di integrare facilmente funzionalità di ricerca veloci e altamente scalabili nelle loro applicazioni.

Le offerte Solr ed ElasticSearch sembrano sorprendentemente simili a prima vista ed entrambe utilizzano lo stesso motore di ricerca back-end, vale a dire Apache Lucene .

Mentre Solr è più vecchio, abbastanza versatile e maturo e ampiamente utilizzato di conseguenza, ElasticSearch è stato sviluppato specificamente per affrontare le carenze di Solr con i requisiti di scalabilità nei moderni ambienti cloud, che sono difficili da affrontare con Solr .

Come tale, sarebbe probabilmente più utile confrontare ElasticSearch con Amazon CloudSearch recentemente introdotto (vedi il post introduttivo Inizia la ricerca in un'ora per meno di $ 100 al mese ), perché entrambi affermano di coprire gli stessi casi d'uso in linea di principio.

Vedo che alcune delle risposte di cui sopra sono ora un po 'obsolete. Dal mio punto di vista, e lavoro quotidianamente con Solr (Cloud e non Cloud) ed ElasticSearch, ecco alcune differenze interessanti:

• Comunità: Solr ha una comunità di utenti, sviluppatori e collaboratori più grande e più matura. ES ha una comunità di utenti più piccola ma attiva e una comunità in crescita di collaboratori
• Maturità: Solr è più maturo, ma ES è cresciuto rapidamente e lo considero stabile
• Performance: difficile da giudicare. Non abbiamo effettuato benchmark di performance diretti. Una persona di LinkedIn ha confrontato Solr contro ES e Sensei una volta, ma i risultati iniziali dovrebbero essere ignorati perché hanno usato una configurazione non esperta sia per Solr che per ES.
• Design: la gente ama Solr. L'API Java è piuttosto dettagliata, ma alla gente piace come è messa insieme. Purtroppo il codice Solr non è sempre molto carino. Inoltre, ES dispone di sharding, replica in tempo reale, documenti e routing integrati. Anche se parte di questo esiste anche in Solr, sembra un po 'un ripensamento.
• Supporto: ci sono aziende che forniscono supporto tecnico e di consulenza sia a Solr che a ElasticSearch. Penso che l'unica azienda che fornisce supporto per entrambi sia Sematext (divulgazione: sono il fondatore di Sematext)
• Scalabilità: entrambi possono essere ridimensionati in cluster molto grandi. ES è più facile da scalare rispetto alla versione pre-Solr 4.0 di Solr, ma con Solr 4.0 non è più così.

Per una copertura più approfondita dell'argomento Solr vs. ElasticSearch, dai un'occhiata a https://sematext.com/blog/solr-vs-elasticsearch-part-1-overview/ . Questo è il primo post della serie di post di Sematext che fa un confronto diretto e neutro tra Solr e ElasticSearch. Divulgazione: lavoro a Sematext.

Vedo che molte persone qui hanno risposto a questa domanda su ElasticSearch vs Solr in termini di caratteristiche e funzionalità, ma non vedo molte discussioni qui (o altrove) su come si confrontano in termini di prestazioni.

Ecco perché ho deciso di condurre le mie indagini . Ho preso un micro-servizio eterogeneo di origine dati già codificato che già utilizzava Solr per la ricerca di termini. Ho cambiato Solr per ElasticSearch, quindi ho eseguito entrambe le versioni su AWS con un'applicazione di test del carico già codificata e ho acquisito le metriche delle prestazioni per l'analisi successiva.

Ecco cosa ho trovato. ElasticSearch ha registrato un throughput superiore del 13% quando si trattava di indicizzare i documenti, ma Solr era dieci volte più veloce. Quando si trattava di richiedere documenti, Solr aveva una produttività cinque volte maggiore ed era cinque volte più veloce di ElasticSearch.

Dalla lunga storia di Apache Solr, penso che un punto di forza del Solr sia il suo ecosistema . Esistono molti plugin Solr per diversi tipi di dati e scopi.

Cerca la piattaforma nei seguenti livelli dal basso verso l'alto:

• Dati
  • Scopo: rappresentare vari tipi di dati e fonti
• Costruzione di documenti
  • Scopo: creare informazioni sui documenti per l'indicizzazione
• Indicizzazione e ricerca
  • Scopo: creare e interrogare un indice di documento
• Miglioramento della logica
  • Scopo: logica aggiuntiva per l'elaborazione di query e risultati di ricerca
• Servizio piattaforma di ricerca
  • Scopo: aggiungere ulteriori funzionalità del core del motore di ricerca per fornire una piattaforma di servizio.
• Applicazione UI
  • Scopo: interfaccia o applicazioni di ricerca dell'utente finale

Articolo di riferimento: ricerca aziendale

Ho creato una tabella delle principali differenze tra elasticsearch e Solr e splunk, puoi usarlo come aggiornamento 2016:

Ho lavorato su solr ed elastico per la ricerca di applicazioni .Net. La principale differenza che ho affrontato è

Ricerca elastica:

• Più codice e meno configurazione, tuttavia ci sono API da cambiare, ma c'è ancora una modifica del codice
• per tipi complessi, digitare all'interno di tipi, cioè tipi nidificati (non è stato possibile ottenere in solr)

Solr:

• meno codice e più configurazione e quindi meno manutenzione
• per raggruppare i risultati durante l'interrogazione (molto lavoro da ottenere nella ricerca elastica in breve, non in modo diretto)

Mentre tutti i link sopra citati hanno un merito e mi hanno notevolmente giovato in passato, come linguista "esposto" a vari motori di ricerca Lucene negli ultimi 15 anni, devo dire che lo sviluppo della ricerca elastica è molto veloce in Python. Detto questo, alcuni dei codici mi sono sembrati poco intuitivi. Quindi, ho raggiunto un componente dello stack ELK, Kibana, da una prospettiva open source, e ho scoperto che avrei potuto generare molto facilmente il codice un po 'criptico di elasticsearch in Kibana. Inoltre, potrei inserire le query di Chrome Sense in Kibana. Se usi Kibana per valutare es, accelererà ulteriormente la tua valutazione. Ciò che ha richiesto ore per essere eseguito su altre piattaforme è stato installato e funzionante in JSON in Sense in cima a elasticsearch (interfaccia RESTful) in pochi minuti nel peggiore dei casi (set di dati più grandi); al massimo in pochi secondi. La documentazione per elasticsearch, sebbene più di 700 pagine, non rispondeva alle domande che normalmente sarebbero state risolte nella documentazione SOLR o altra documentazione di Lucene, che ovviamente richiedeva più tempo per l'analisi. Inoltre, potresti voler dare un'occhiata agli aggregati nella ricerca elastica, che hanno portato la sfaccettatura a un nuovo livello.

Immagine più ampia: se stai facendo scienza dei dati, analisi del testo o linguistica computazionale, elasticsearch ha alcuni algoritmi di classificazione che sembrano innovare bene nell'area di recupero delle informazioni. Se stai usando algoritmi TF / IDF, Frequenza testo / Frequenza documento inversa, elasticsearch estende questo algoritmo di questo 1960 a un nuovo livello, anche usando BM25, Best Match 25 e altri algoritmi di ranking di pertinenza. Quindi, se stai valutando o classificando parole, frasi o frasi, elasticsearch esegue questo punteggio al volo, senza il grande sovraccarico di altri approcci di analisi dei dati che richiedono ore - un altro risparmio di tempo di elasticsearch. Con es, combinando alcuni dei punti di forza del bucketing dalle aggregazioni con il punteggio e il ranking di pertinenza dei dati JSON in tempo reale, potresti trovare una combinazione vincente,

Nota: ho visto una discussione simile sulle aggregazioni sopra, ma non sulle aggregazioni e sul punteggio di pertinenza - le mie scuse per qualsiasi sovrapposizione. Divulgazione: non lavoro per l'elastico e non potrò beneficiare nel prossimo futuro del loro eccellente lavoro a causa di un diverso percorso architettonico, a meno che non faccia un lavoro di beneficenza con elasticsearch, che non sarebbe una cattiva idea

Immagina il caso d'uso:

1. Un sacco (100+) di piccoli (10 Mb-100 Mb, 1000-100000 documenti) indici di ricerca.
2. Stanno usando molte applicazioni (microservizi)
3. Ogni applicazione può utilizzare più di un indice
4. Piccolo per indice dimensionale, sì. Ma il carico enorme (centinaia di richieste di ricerca al secondo) e le richieste sono complesse (aggregazioni multiple, condizioni e così via)
5. I tempi di inattività non sono ammessi
6. Tutto ciò dura anni e continua a crescere.

L'idea di avere un'istanza ES individuale per ciascun indice - in questo caso è un enorme sovraccarico.

Sulla base della mia esperienza, questo tipo di caso d'uso è molto complesso da supportare con Elasticsearch.

Perché?

PRIMO.

Il problema principale è il mancato rispetto della compatibilità con la schiena.

I cambiamenti di rottura sono così belli! (Nota: immagina un server SQL che richiede di fare piccole modifiche in tutte le tue istruzioni SQL, quando viene aggiornato ... non riesco a immaginarlo. Ma per ES è normale)

Le deprecazioni che cadranno nella prossima versione principale sono così sexy! (Nota: sai, Java contiene alcune deprecazioni, che hanno più di 20 anni, ma che funzionano ancora nella versione Java attuale ...)

E non solo, a volte hai anche qualcosa che in nessun luogo ha documentato (personalmente mi sono imbattuto solo una volta ma ...)

Così. Se vuoi aggiornare ES (perché hai bisogno di nuove funzionalità per alcune app o vuoi ottenere correzioni di bug), sei all'inferno. Soprattutto se si tratta dell'aggiornamento della versione principale.

L'API client non tornerà compatibile. Le impostazioni dell'indice non saranno compatibili. E aggiornare tutte le app / i servizi nello stesso momento con l'aggiornamento ES non è realistico.

Ma devi farlo di volta in volta. Nessun altro modo.

Gli indici esistenti vengono aggiornati automaticamente? - Sì. Ma non ti aiuta quando dovrai cambiare alcune impostazioni del vecchio indice.

Per convivere con questo, devi costantemente investire molto potere in ... compatibilità futura delle tue app / servizi con le versioni future di ES. Oppure devi creare (e comunque supportare costantemente) una sorta di middleware tra app / servizi ed ES, che ti fornisca indietro API client compatibili. (E, non è possibile utilizzare Transport Client (perché richiede l'aggiornamento del vaso per ogni aggiornamento ES versione minore) e questo fatto non semplifica la vita)

Sembra semplice ed economico? No non lo è. Lontano da esso. La manutenzione continua di infrastrutture complesse basate su ES è troppo costosa in tutti i sensi.

SECONDO. API semplice? Beh ... no davvero. Quando stai davvero usando condizioni e aggregazioni complesse ... La richiesta JSON con 5 livelli nidificati è qualunque, ma non semplice.

Sfortunatamente, non ho esperienza con SOLR, non posso dire nulla al riguardo.

Ma Sphinxsearch è molto meglio in questo scenario, grazie a SphinxQL totalmente compatibile.

Nota: Sphinxsearch / Manticore sono davvero interessanti. Non è basato su Lucine e, di conseguenza, molto diverso. Contiene diverse funzionalità uniche dalla scatola che ES non ha e impazziscono velocemente con indici di dimensioni medio / piccole.

Se stai già utilizzando SOLR, rimani fedele. Se stai avviando, scegli la ricerca elastica.

In SOLR sono stati risolti i problemi principali massimi ed è abbastanza maturo.

Uso Elasticsearch da 3 anni e Solr da circa un mese, penso che il cluster di elasticsearch sia abbastanza facile da installare rispetto all'installazione di Solr. Elasticsearch ha un pool di documenti di aiuto con ottime spiegazioni. Uno dei casi d'uso sono rimasto bloccato con Histogram Aggregation che era disponibile in ES ma non trovato in Solr.

Uso solo la ricerca elastica. Da quando ho trovato solr è molto difficile iniziare. Funzionalità di ricerca elastica:

1. Facile da avviare, pochissime impostazioni. Anche un principiante può configurare un cluster passo dopo passo.
2. API Restful semplice che utilizza la query NoSQL. E molte librerie di lingue per un facile accesso.
3. Buon documento, puoi leggere il libro:. C'è una versione web sul sito ufficiale.

Aggiungi un documento nidificato in solr ricerca di dati molto complessi e nidificati anche molto complessi. ma Elastic Search semplifica l'aggiunta di documenti nidificati e ricerche