Database necessario con elasticsearch?

Question

Ho fatto molte ricerche in materia di elasticsearch e mi sembra di inciampare sulla questione se sia necessario o meno un database.

corrente Hibernate-Search e relazionale design

La mia applicazione corrente è scritto in Java utilizzando hibernate, hibernate-ricerca, e un database mysql. La ricerca in ibernazione si basa su lucene e gestisce automaticamente i miei indici per me durante le transazioni del database. Hibernate-search eseguirà la ricerca anche nell'indice e quindi estrarrà i record completi dal database in base ai pks memorizzati anziché dover memorizzare l'intero modello di dati nell'indice. Questo ha funzionato magnificamente, tuttavia con l'aumentare della mia applicazione, ho continuamente riscontrato problemi di ridimensionamento e costi legati al fatto che gli indici di Lucene devono vivere su ogni server delle applicazioni e quindi è necessaria un'altra libreria per sincronizzare gli indici insieme. L'altro problema con questo design è che richiede più memoria su tutti i server delle applicazioni poiché gli indici vengono replicati e archiviati con l'applicazione.

database o No Database

Provenendo dalla scuola hibernate-ricerca di pensiero, io sono confuso su se il vostro supponiamo di memorizzare l'intero modello di dati in elasticsearch e farla finita con il database tradizionale o se si suppone di memorizzare i propri dati di ricerca negli indici e di nuovo come hibernate-search restituire le chiavi primarie per estrarre i record completi dal proprio database relazionale.

gestione degli indici,

1. Se la vostra utilizzando gli indici con un db, si dovrebbe essere manualmente loro mantenimento durante le transazioni? Ho visto un progetto jdbc chiamato river, ma sembra essere deprecato e sconsigliato per l'uso di produzione , c'è una libreria in grado di gestire automaticamente le tue transazioni per te? ?
2. Se gli indici non sono sincronizzati con il db, esiste un metodo consigliato per ricostruirli?

Hibernate-Search API

Ho anche visto quanto segue nella tabella di marcia hibernate-ricerca API/SPI per backend alternativi http://hibernate.org/search/roadmap/

Define API/SPI abstraction to allow for future external backends integrations such as Apache Solr and Elastic Search. 

mi chiedo se qualcuno ha qualche input su questo? Hibernate-search è in grado di gestire automaticamente gli indici di ricerca elastici come per la configurazione nativa?

Se No Database

Quale sarebbe l'inconveniente di non utilizzando un database per la ricerca tutto ciò che riguarda?

Answer 1

Ho affrontato un problema simile prima, su una configurazione elasticsearch con un mysql con i dati. La soluzione era quella di archiviare solo i dati che erano necessari per la ricerca su elasticsearch, con un riferimento al database relazionale. Se i dati su elasticsearch erano sufficienti per la richiesta, ho restituito solo il record elasticsearch. In caso contrario, sono andato al database relazionale e ho restituito quel record.

Mi sono diviso in questi due processi a causa del ritardo introdotto dal database relazionale (era un'API per un servizio Web ad alta richiesta, elasticsearch era più veloce). Questo ha introdotto un problema di sincronizzazione, ma non è stato fondamentale per la mia applicazione e abbiamo tirato periodicamente i dati dal db relazionale e reindicizzato solo il set di dati modificati su elasticsearch. Elasticsearch può reindicizzare solo un sottoinsieme di records.

Abbiamo considerato di non utilizzare un db e di archiviare tutto nel motore di ricerca, ma dipende dall'importanza dei dati. Se non puoi rischiare di perdere parte dei tuoi dati, non memorizzarli solo su elasticsearch. Abbiamo sempre considerato i dati in elasticsearch deperibili e che gli indici di ricerca potrebbero essere ricostruiti dal database.

Answer 2

Provenendo dalla scuola hibernate-ricerca di pensiero, io sono confuso su se il vostro supponiamo di memorizzare l'intero modello di dati in elasticsearch e farla finita con il database tradizionale o se il vostro supponiamo di memorizzare i tuoi dati di ricerca negli indici e ancora come hibernate-search restituiscono le chiavi primarie per estrarre i record completi dal tuo database relazionale .

È possibile memorizzare tutto, ma si otterrà una migliore scalabilità se si memorizzano solo i campi che devono essere cercati. Più piccoli sono i record, più piccolo è l'indice e più è adatto a una determinata quantità di RAM.

Se si utilizzano gli indici con un db, si dovrebbe essere manualmente mantenerli durante le transazioni? Ho visto un progetto jdbc chiamato river, ma sembra essere deprecato e sconsigliato per l'uso di produzione , è disponibile una libreria in grado di gestire automaticamente le tue transazioni per le tue transazioni? ?

Sto utilizzando la sincronizzazione delle transazioni di primavera per questo. Fondamentalmente attivando la reindicizzazione asincrona dopo il commit della transazione.

Quale sarebbe lo svantaggio di non utilizzare un database per qualsiasi ricerca correlata?

ES non è un database e non supporta le operazioni transazionali tra i documenti.

Answer 3

Nota che l'integrazione Hibernate Search/elasticsearch è quasi pronto ormai, e facendo progressi rapidamente:

• http://in.relation.to/2016/05/24/ElasticsearchintegrationReachesBeta1/