Ricerca elastica, più indici contro un indice e tipi per diversi set di dati?

Ho un'applicazione sviluppata utilizzando il modello MVC e ora vorrei indicizzarne più modelli, ciò significa che ogni modello ha una struttura dati diversa.

• È meglio usare indici multipli, uno per ciascun modello o avere un tipo all'interno dello stesso indice per ciascun modello? Entrambi i modi richiederebbero anche una diversa query di ricerca, penso. Ho appena iniziato questo.

• Ci sono differenze prestazionali tra i due concetti se il set di dati è piccolo o enorme?

Proverei io stesso la seconda domanda se qualcuno potesse consigliarmi alcuni dati di esempio a tale scopo.

Ci sono diverse implicazioni per entrambi gli approcci.

Supponendo che tu stia utilizzando le impostazioni predefinite di Elasticsearch, avere 1 indice per ogni modello aumenterà in modo significativo il numero dei tuoi frammenti poiché 1 indice utilizzerà 5 frammenti, 5 modelli di dati utilizzeranno 25 frammenti; pur avendo 5 tipi di oggetto in 1 indice continuerà a usare 5 frammenti.

Implicazioni per avere ciascun modello di dati come indice:

• Ricerca efficiente e veloce all'interno dell'indice, poiché la quantità di dati dovrebbe essere più piccola in ciascun frammento poiché viene distribuita a indici diversi.
• La ricerca di una combinazione di modelli di dati da 2 o più indici genererà un sovraccarico, poiché la query dovrà essere inviata a più frammenti tra gli indici, compilata e rispedita all'utente.
• Sconsigliato se il set di dati è piccolo poiché si dovrà sostenere più spazio di archiviazione con la creazione di ogni frammento aggiuntivo e il guadagno in termini di prestazioni è marginale.
• Consigliato se il set di dati è grande e le query impiegano molto tempo per l'elaborazione, poiché i frammenti dedicati memorizzano i tuoi dati specifici e sarà più semplice l'elaborazione di Elasticsearch.

Implicazioni per avere ciascun modello di dati come tipo di oggetto all'interno di un indice:

• Più dati verranno archiviati nei 5 frammenti di un indice, il che significa che ci sono minori problemi generali quando si esegue una query su diversi modelli di dati, ma la dimensione del frammento sarà significativamente maggiore.
• Più dati all'interno dei frammenti impiegheranno più tempo a cercare Elasticsearch poiché ci sono più documenti da filtrare.
• Non raccomandato se sai che stai attraversando 1 terabyte di dati e non stai distribuendo i tuoi dati su diversi indici o più frammenti nella tua mappatura Elasticsearch.
• Consigliato per piccoli set di dati, poiché non sprecherete spazio di archiviazione per un guadagno marginale delle prestazioni poiché ogni frammento occupa spazio nel vostro hardware.

Se stai chiedendo cosa sono troppi dati rispetto a piccoli dati? In genere dipende dalla velocità del processore e dalla RAM dell'hardware, dalla quantità di dati archiviati all'interno di ciascuna variabile nella mappatura per Elasticsearch e dai requisiti delle query; l'utilizzo di molte sfaccettature nelle query rallenterà significativamente i tempi di risposta. Non esiste una risposta diretta a questo e dovrai fare un benchmark in base alle tue esigenze.

Sebbene la risposta di Jonathan fosse corretta al momento, il mondo è andato avanti e ora sembra che le persone dietro ElasticSearch abbiano un piano a lungo termine per eliminare il supporto per più tipi:

Dove vogliamo arrivare: Vogliamo rimuovere il concetto di tipi da Elasticsearch, pur sostenendo genitore / figlio.

Pertanto, per i nuovi progetti, l'utilizzo di un solo tipo per indice renderà più semplice l'eventuale aggiornamento a ElasticSearch 6.x.

La risposta di Jonathan è ottima. Vorrei solo aggiungere alcuni altri punti da considerare:

• il numero di frammenti può essere personalizzato per soluzione selezionata. Puoi avere un indice con 15 frammenti primari o dividerlo in 3 indici per 5 frammenti - la prospettiva delle prestazioni non cambierà (supponendo che i dati siano distribuiti equamente)
• pensa all'utilizzo dei dati. Vale a dire. se usi kibana per visualizzare, è più facile includere / escludere determinati indici, ma i tipi devono essere filtrati nella dashboard
• conservazione dei dati: per i dati di registro / metrica dell'applicazione, utilizzare indici diversi se si richiede un periodo di conservazione diverso

Entrambe le risposte sopra sono fantastiche!

Sto aggiungendo un esempio di diversi tipi in un indice. Supponiamo che tu stia sviluppando un'app per cercare libri in una biblioteca. Ci sono alcune domande da porre al proprietario della Biblioteca,

Domande:

1. Quanti libri hai intenzione di conservare?

2. Che tipo di libri hai intenzione di conservare in biblioteca?

3. Come hai intenzione di cercare libri?

risposte:

1. Sto programmando di conservare libri da 50 k - a 70 k (circa)

2. Avrò 15 k -20 k di libri relativi alla tecnologia (informatica, ingegneria meccanica, ingegneria chimica e così via), 15 k di libri storici, 10 k di libri di scienze mediche. 10 k di libri correlati alla lingua (inglese, spagnolo e così via)

3. Ricerca per nome dell'autore, cognome dell'autore, anno di pubblicazione, nome dell'editore. (Questo ti dà l'idea di quali informazioni dovresti archiviare nell'indice)

Dalle risposte sopra possiamo dire che lo schema nel nostro indice dovrebbe apparire in qualche modo simile a questo.

// Questa non è la mappatura esatta, solo per esempio

            "yearOfPublish":{
                "type": "integer"
            },
            "author":{
                "type": "object",
                "properties": {
                    "firstName":{
                        "type": "string"
                    },
                    "lastName":{
                        "type": "string"
                    }
                }
            },
            "publisherName":{
                "type": "string"
            }
        }

Per ottenere quanto sopra possiamo creare un indice chiamato Libri e possiamo avere vari tipi.

Indice: libro

Tipi: Scienza, Arte

(Oppure puoi creare molti tipi come Tecnologia, Scienza medica, Storia, Lingua, se hai molti più libri)

La cosa importante da notare qui è che lo schema è simile ma i dati non sono identici. E l'altra cosa importante sono i dati totali che stai memorizzando.

Spero che quanto sopra ti aiuti quando scegliere tipi diversi in un indice, se hai schemi diversi dovresti considerare un indice diverso. Piccolo indice per meno dati. grande indice per big data :-)