Attualmente sto ricercando alcune strategie di archiviazione dei dati con ElasticSearch e mi chiedo perché per l'archiviazione dei log, questa pagina indica:
Un formato standard consiste nell'assegnare un nuovo indice per ogni giorno.
Non avrebbe più senso creare un indice (database) con un nuovo tipo un nome (tabella) al giorno?
Sto guardando questo dal punto di vista di ogni indice è legato a una diversa applicazione web.
In un altro scenario, un'app Web utilizza un indice. Uno dei tipi all'interno di tale indice viene utilizzato per la registrazione (cosa che attualmente facciamo con SQL Server). è un buon approccio?
risposte:
0 per risposta № 1Idea interessante e, sì, probabilmente potresti farloquello. Perché invece utilizzare più indici? Se avere il controllo su cose come l'allocazione da frammento a nodo (forse vuoi che tutto il 2015 sia memorizzato su un insieme di nodi, 2014, un altro), la dimensione della cache del filtro e simili è importante, perdi quella andando a un singolo indice / approccio multi-mappatura. Per le applicazioni di volume molto elevato, tale controllo potrebbe essere significativo. YMMV.
Per quanto riguarda il "ogni indice è legato a unsentiment di diverse applicazioni web, gli alias possono (e sono) utilizzati per raccogliere più indici fisici sotto un unico ombrello ricercabile; crei un indice al giorno / settimana / qualunque cosa, ad esempio, logs-20150730, logs-20150731 ... e assegnare il logs alias a tutti gli indici della serie. L'effetto netto è lo stesso di avere un unico "indice".
La bella parte dell'approccio alias è questol'eliminazione / eliminazione dei vecchi dati è banale; è sufficiente eliminare l'indice quando i suoi contenuti superano i criteri di conservazione dei dati. Con le mappature multiple, dovresti eliminare la mappatura richiesta all'interno dell'indice (fattibile, ma piuttosto I / O invadente, dal momento che probabilmente sposteresti cose all'interno di ogni frammento attraverso il quale la mappatura è stata distribuita.)