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

12

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à fulltext.

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

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

UPDATE ----------

Ho appena trovato questo paragrafo:

There are myriad cases in which elasticsearch is useful. Some use cases more clearly call for it than others. Listed below are some tasks which for which elasticsearch is particularly well suited.

  • Searching a large number of product descriptions for the best match for a specific phrase (say “chef’s knife”) and returning the best results
  • Given the previous example, breaking down the various departments where “chef’s knife” appears (see Faceting later in this book)
  • Searching text for words that sound like “season”
  • Auto-completing a search box based on partially typed words based on previously issued searches while accounting for mis-spellings
  • Storing a large quantity of semi-structured (JSON) data in a distributed fashion, with a specified level of redundancy across a cluster of machines

It should be noted, however, that while elasticsearch is great at solving the aforementioned problems, it’s not the best choice for others. It’s especially bad at solving problems for which relational databases are optimized. Problems such as those listed below.

  • Calculating how many items are left in the inventory
  • Figuring out the sum of all line-items on all the invoices sent out in a given month
  • Executing two operations transactionally with rollback support
  • Creating records that are guaranteed to be unique across multiple given terms, for instance a phone number and extension
  • Elasticsearch is generally fantastic at providing approximate answers from data, such as scoring the results by quality. While elasticsearch can perform exact matching and statistical calculations, its primary task of search is an inherently approximate task.
  • Finding approximate answers is a property that separates elasticsearch from more traditional databases. That being said, traditional relational databases excel at precision and data integrity, for which elasticsearch and Lucene have few provisions.

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

    
posta Mik378 08.08.2014 - 20:17
fonte

2 risposte

13

Esito a chiamare ElasticSearch un database. Non è un sostituto per un database, ma è una buona aggiunta per aggiungere funzionalità, in particolare ricerche di testo avanzate, accanto al tuo database esistente.

Vedo dove puoi farli confondere. Possono effettivamente adattarsi allo stesso bisogno, ma non sempre. ElasticSearch fa esattamente ciò che sembra, ricerche . Un database grafico non specifica relazioni o indici, come fa ElasticSearch. Quindi fondamentalmente funzionano in modo molto diverso. ElasticSearch analizza i documenti con, ad esempio, l'analizzatore inglese. Ciò che farà prenderà parole e analizzerà diverse varianti di quella parola o anche dei sinonimi. Ad esempio, dig , verrebbe analizzato come dig,digs,dug,digging,digger ... . Quando si esegue una query su elasticsearch, è possibile analizzare anche le query, quindi tali parole vengono interrogate e possono essere valutate 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 grafici hanno il loro vantaggio. Trovare rilevanza / relazioni tra cose come i tag hash, per esempio, o cose con molte relazioni mutevoli. Sono fantastici e interessanti pezzi di tecnologia, tuttavia dovrei dire che non è potente come ElasticSearch. Principalmente perché ElasticSearch è orientato verso questo tipo di cose e gestisce le analisi per te in modo da poter eseguire ricerche full-text. Tuttavia, se stai cercando di utilizzare un sistema più simile alla ricerca di twitter basata su tag / parole chiave predefinite, allora ti conviene utilizzare il database grafico che usi già.

La domanda è quanto robusto vuoi che la tua ricerca sia? Se hai bisogno di fare ricerche a grana fine (testo completo) userei elasticsearch. In caso contrario, è sempre possibile implementare una ricerca relativamente facilmente su un database grafico. Una volta implementata la ricerca, non è impossibile migrare a elasticsearch se in seguito ti servirà un motore di ricerca più affidabile, implementa la tua ricerca con questo in mente.

    
risposta data 10.10.2014 - 00:35
fonte
1

Entrambi questi database hanno il loro specifico bisogno di risolvere problemi specifici a determinati livelli di requisiti applicativi. Sebbene non abbiamo usato il Database grafico. Ma stiamo usando elasticsearch con MySQL in uno dei nostri progetti degli ultimi 5 anni. Quel progetto ha una massa di dati da cercare attraverso documenti di 6 metri e ha enormi relazioni tra queste entità (documenti di 10 m).

Use Case: Come cercare negli hotel che sono piaciuti ai miei amici e ordinare 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 Like relais tra Hotel e My Friends e quindi gli hotel dovrebbero essere ordinati per numero totale di Mi piace che hanno. Quindi per tali ricerche, il database grafico è buono.

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

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

    
risposta data 01.03.2017 - 01:37
fonte

Leggi altre domande sui tag