Perché dovrei usare ElasticSearch se utilizzo già un database grafico?

Non trovo alcuna spiegazione approfondita sul web su un confronto tra ElasticSearch e i database dei grafici.

Entrambi sono ottimizzati per attraversare i dati.
ElasticSearch sembra essere ottimizzato per l'analisi.
Tuttavia Neo4j si basa anche su Lucene per gestire gli indici e alcune funzionalità full-text.

Perché dovrei usare ElasticSearch se utilizzo già un database grafico?

Nel mio caso, sto usando Neo4j per costruire un social network.
Quale reale vantaggio può apportare ElasticSearch?

AGGIORNARE ----------

Ho appena trovato questo paragrafo:

Ci sono una miriade di casi in cui elasticsearch è utile. Alcuni casi d'uso lo richiedono più chiaramente di altri. Di seguito sono elencati alcuni compiti per i quali elasticsearch è particolarmente adatto.

• Cercare un gran numero di descrizioni dei prodotti per la migliore corrispondenza per una frase specifica (dire "coltello da chef") e restituire i migliori risultati
• Dato l'esempio precedente, scomporre i vari reparti in cui appare il "coltello da chef" (vedi Sfaccettatura più avanti in questo libro)
• Ricerca nel testo di parole che suonano come "stagione"
• Completamento automatico di una casella di ricerca basata su parole parzialmente digitate basate su ricerche precedentemente emesse tenendo conto di errori di ortografia
• Archiviazione di una grande quantità di dati semi-strutturati (JSON) in modo distribuito, con un livello di ridondanza specificato su un cluster di macchine

Va notato, tuttavia, che mentre elasticsearch è eccezionale nel risolvere i suddetti problemi, non è la scelta migliore per gli altri. È particolarmente dannoso nel risolvere i problemi per i quali sono ottimizzati i database relazionali. Problemi come quelli elencati di seguito.

• Calcolo del numero di articoli rimasti nell'inventario
• Individuare la somma di tutti gli elementi pubblicitari su tutte le fatture inviate in un determinato mese
• Esecuzione di due operazioni in modo transazionale con supporto di rollback
• Creazione di record che sono garantiti come unici in più termini, ad esempio un numero di telefono e un interno
• Elasticsearch è generalmente fantastico nel fornire risposte approssimative dai dati, come il punteggio dei risultati per qualità. Mentre elasticsearch può eseguire corrispondenze esatte e calcoli statistici, il suo compito principale di ricerca è un compito intrinsecamente approssimativo.
• Trovare risposte approssimative è una proprietà che separa elasticsearch da database più tradizionali. Detto questo, i database relazionali tradizionali eccellono per precisione e integrità dei dati, per i quali elasticsearch e Lucene hanno poche disposizioni.

Posso affermare che se non avessi bisogno di risposte approssimative, allora ElasticSearch sarebbe inutile rispetto a un database grafico già utilizzato?

Esito a chiamare un database ElasticSearch. Non è un sostituto per un database, ma è una buona aggiunta per aggiungere funzionalità, in particolare la ricerca di testo avanzata, insieme al database esistente.

Vedo dove puoi confonderli. Possono effettivamente soddisfare la stessa esigenza, ma non sempre. ElasticSearch fa esattamente quello che sembra, ricerche . Un database grafico non specifica relazioni o indici, come fa ElasticSearch. Quindi fondamentalmente funzionano in modo diverso. ElasticSearch analizza i documenti con, ad esempio, l'analizzatore inglese. Che cosa farà ci vorranno parole e analizzare diverse varianti di quella parola o anche sinonimi. Ad esempio, digsarebbe analizzato come dig,digs,dug,digging,digger .... Quando esegui una query su elasticsearch, puoi anche analizzare le tue query, quindi quelle parole vengono interrogate e possono essere classificate per pertinenza.

ElasticSearch è un ottimo strumento, perché è davvero flessibile. Puoi trovare una vasta gamma di contenuti relativi, oppure puoi trovare un ago nella pila di fieno, ed è relativamente facile.

Anche i database Graph hanno il loro vantaggio. Trovare rilevanza / relazioni tra cose come ad esempio i tag hash o cose con molte relazioni mutabili. Sono grandi e interessanti pezzi di tecnologia, tuttavia dovrei dire che non è così potente come ElasticSearch. Soprattutto perché ElasticSearch è orientato verso questo genere di cose e gestisce le analisi per te in modo da poter effettuare ricerche full-text. Tuttavia, se stai cercando di utilizzare un sistema più simile alla ricerca di Twitter che si basa su tag / parole chiave predefiniti, ti conviene utilizzare il Database grafico che stai già utilizzando.

La domanda è: quanto vuoi che sia la tua ricerca? Se hai bisogno di fare ricerche a grana fine (testo completo), userei elasticsearch. Altrimenti puoi sempre implementare una ricerca relativamente facilmente su un database grafico. Una volta implementata la ricerca, non è impossibile migrare a elasticsearch se ti accorgi in seguito di aver bisogno di un motore di ricerca più robusto, implementa la tua ricerca tenendo presente questo aspetto.

Entrambi questi database hanno la loro specifica necessità di risolvere problemi specifici a un certo livello di requisiti dell'applicazione. Sebbene non abbiamo usato Graph Database. Ma stiamo usando elasticsearch con MySQL in uno dei nostri progetti degli ultimi 5 anni. Quel progetto ha una grande quantità di dati da cercare in documenti di 6 milioni e ha relazioni enormi tra quelle entità (documenti di relazioni di 10 milioni).

Caso d'uso: ad esempio cerca tra gli hotel che sono piaciuti ai miei amici e ordina tutti gli hotel con il numero di Mi piace che hanno. E se lo vedi da vicino. questo caso ha coinvolto 2 relazioni (Friend, Like). Quindi ho bisogno di cercare attraverso la nave di relazione Like tra Hotels e My Friends e gli hotel dovrebbero essere ordinati in base al numero totale di like che hanno. Quindi per tali ricerche, il database dei grafici è buono.

Elasticsearch sta facendo un ottimo lavoro per la ricerca di test completa nei documenti, ma quando si tratta di cercare relazioni come sopra non è così buono. Elenca il documento (entità) che sono i miei fan e ordinali in base al loro numero di fan. Ma questi sono profondi a un livello e quando si tratta di cercare più in profondità. Elasticsearch non è abbastanza buono.

Quindi comprendi i requisiti della tua applicazione e poi vai al database. Potrebbe essere necessario avere entrambi.