Elasticsearch
Differenza tra indici e tipi

È facile vedere i type come una tabella in un database SQL, in cui l' index è il database SQL. Tuttavia, non è un buon modo per avvicinarsi ai type .

Tutto sui tipi

In effetti, i tipi sono letteralmente solo un campo di metadati aggiunto a ogni documento da Elasticsearch: _type . Gli esempi precedenti hanno creato due tipi: my_type e my_other_type . Ciò significa che ogni documento associato ai tipi ha un campo extra definito automaticamente come "_type": "my_type" ; questo è indicizzato con il documento, rendendolo quindi un campo ricercabile o filtrabile , ma non ha alcun impatto sul documento stesso, quindi l'applicazione non deve preoccuparsi di ciò.

Tutti i tipi vivono nello stesso indice e quindi negli stessi frammenti collettivi dell'indice. Anche a livello di disco, vivono negli stessi file. L'unica separazione che crea un secondo tipo fornisce è logica. Ogni tipo, sia esso univoco o meno, deve esistere nei mapping e tutti questi mapping devono esistere nello stato del cluster. Questo consuma memoria e, se ogni tipo viene aggiornato dinamicamente, consuma le prestazioni man mano che cambiano i mapping.

Pertanto, è consigliabile definire un solo tipo, a meno che non sia effettivamente necessario un altro tipo. È comune vedere scenari in cui sono desiderabili più tipi. Ad esempio, immagina di avere un indice di auto. Potrebbe essere utile per scomporlo con più tipi:

• BMW
• chevy
• honda
• mazda
• mercedes
• nissan
• Rangerover
• toyota
• ...

In questo modo è possibile cercare tutte le auto o limitarlo per produttore su richiesta. La differenza tra queste due ricerche è semplice come:

GET /cars/_search

e

GET /cars/bmw/_search

Ciò che non è ovvio ai nuovi utenti di Elasticsearch è che il secondo modulo è una specializzazione del primo modulo. Viene letteralmente riscritto in:

GET /cars/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "term" : {
            "_type": "bmw"
          }
        }
      ]
    }
  }
}

Filtra semplicemente qualsiasi documento che non è stato indicizzato con un campo _type cui valore era bmw . Poiché ogni documento è indicizzato con il suo tipo come il campo _type , questo serve da filtro piuttosto semplice. Se in entrambi gli esempi è stata fornita una ricerca effettiva, il filtro verrà aggiunto alla ricerca completa secondo necessità.

Pertanto, se i tipi sono identici, è molto meglio fornire un singolo tipo (ad esempio, manufacturer in questo esempio) ed ignorarlo efficacemente. Quindi, all'interno di ciascun documento, fornisci esplicitamente un campo chiamato make o nome che preferisci e filtra manualmente su di esso ogni volta che vuoi limitarlo. Questo ridurrà la dimensione dei tuoi mapping a 1/n dove n è il numero di tipi separati. Aggiunge un altro campo a ciascun documento, a vantaggio di una mappatura altrimenti semplificata.

In Elasticsearch 1.xe 2.x, tale campo deve essere definito come

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "string",
        "index": "not_analyzed"
      }
    }
  }
}

1. Il nome è arbitrario.
2. Il nome è arbitrario e potrebbe corrispondere al nome del tipo, se lo si desidera anche.

In Elasticsearch 5.x, quanto sopra funzionerà ancora (è deprecato), ma il modo migliore è usare:

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "keyword"
      }
    }
  }
}

1. Il nome è arbitrario.
2. Il nome è arbitrario e potrebbe corrispondere al nome del tipo, se lo si desidera anche.

I tipi dovrebbero essere usati con moderazione all'interno dei vostri indici perché gonfiano le mappature degli indici, di solito senza troppi benefici. Devi averne almeno uno, ma non c'è nulla che dice che devi averne più di uno.

Domande comuni

• Cosa succede se ho due (o più) tipi che sono per lo più identici, ma che hanno alcuni campi univoci per tipo?

A livello di indice, non vi è alcuna differenza tra un tipo usato con pochi campi scarsamente usati e tra più tipi che condividono un gruppo di campi non sparsi con pochi non condivisi (il che significa che l'altro tipo non usa mai il campo (S)).

Detto in modo diverso: un campo scarsamente usato è scarso nell'indice indipendentemente dai tipi . La sparsità non avvantaggia, o fa davvero male, l'indice solo perché è definito in un tipo separato.

Dovresti semplicemente combinare questi tipi e aggiungere un campo di testo separato.

• Perché i tipi separati devono definire i campi nello stesso modo?

Perché ogni campo viene definito solo una volta a livello di Lucene, indipendentemente da quanti tipi ci sono. Il fatto che i tipi esistano è una caratteristica di Elasticsearch ed è solo una separazione logica.

• Posso definire tipi separati con lo stesso campo definito in modo diverso?

No. Se riesci a trovare un modo per farlo in ES 2.xo versioni successive, dovresti aprire una segnalazione di bug . Come notato nella domanda precedente, Lucene li vede tutti come un singolo campo, quindi non c'è modo di fare questo lavoro in modo appropriato.

ES 1.x lo ha lasciato come requisito implicito, che ha consentito agli utenti di creare condizioni in cui le mappature di un frammento in un indice in realtà differivano da un altro frammento nello stesso indice. Questa era effettivamente una condizione di gara e poteva portare a problemi imprevisti.

Eccezioni alla regola

• I documenti padre / figlio richiedono tipi separati da utilizzare all'interno dello stesso indice.
  • Il genitore vive in un tipo.
  • Il bambino vive in un tipo separato (ma ogni bambino vive nella stessa scheggia del genitore).
• Casi di utilizzo estremamente di nicchia in cui creare tonnellate di indici è indesiderabile e l'impatto dei campi sparsi è preferibile all'alternativa.
  • Ad esempio, il plug-in di monitoraggio Elasticsearch, Marvel (1.xe 2.x) o X-Pack Monitoring (5.x +), monitora Elasticsearch stessa per le modifiche nel cluster, i nodi, gli indici, gli indici specifici (il livello dell'indice), e anche frammenti. Potrebbe creare più di 5+ indici ogni giorno per isolare quei documenti che hanno mappature univoche o potrebbe andare contro le migliori pratiche per ridurre il carico del cluster condividendo un indice (nota: il numero di mappature definite è effettivamente lo stesso, ma il numero di indici creati è ridotto da n a 1).
  • Questo è uno scenario avanzato, ma è necessario considerare le definizioni dei campi condivise tra i tipi!