Elasticsearch
Différence entre les indices et les types

Il est facile de voir les type comme une table dans une base de données SQL, où l' index est la base de données SQL. Cependant, ce n’est pas un bon moyen d’aborder le type s.

Tout sur les types

En fait, les types sont littéralement un champ de métadonnées ajouté à chaque document par Elasticsearch: _type . Les exemples ci-dessus ont créé deux types: my_type et my_other_type . Cela signifie que chaque document associé aux types a un champ supplémentaire défini automatiquement comme "_type": "my_type" ; Ceci est indexé avec le document, ce qui en fait un champ de recherche ou de filtrage , mais cela n’a pas d’impact sur le document brut lui-même, votre application n’a donc pas besoin de s’en préoccuper.

Tous les types vivent dans le même index, et donc dans les mêmes fragments collectifs de l'index. Même au niveau du disque, ils vivent dans les mêmes fichiers. La seule séparation fournie par la création d'un second type est une séparation logique. Chaque type, qu'il soit unique ou non, doit exister dans les mappages et tous ces mappages doivent exister dans votre état de cluster. Cela consomme de la mémoire et, si chaque type est mis à jour de manière dynamique, il réduit les performances à mesure que les mappages changent.

En tant que tel, il est recommandé de ne définir qu'un seul type, sauf si vous avez réellement besoin d'autres types. Il est courant de voir des scénarios où plusieurs types sont souhaitables. Par exemple, imaginez que vous avez un index de voiture. Il peut vous être utile de le décomposer en plusieurs types:

• BMW
• chevy
• honda
• Mazda
• mercedes
• nissan
• rangerover
• toyota
• ...

De cette façon, vous pouvez rechercher toutes les voitures ou les limiter par fabricant à la demande. La différence entre ces deux recherches est aussi simple que:

GET /cars/_search

et

GET /cars/bmw/_search

Ce qui n'est pas évident pour les nouveaux utilisateurs d'Elasticsearch, c'est que la seconde forme est une spécialisation de la première forme. Il est littéralement réécrit pour:

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

Il filtre simplement tout document non indexé avec un champ _type dont la valeur était bmw . Comme chaque document est indexé avec son type en tant _type champ _type , cela sert de filtre assez simple. Si une recherche réelle avait été fournie dans l'un ou l'autre exemple, le filtre serait alors ajouté à la recherche complète, le cas échéant.

Ainsi, si les types sont identiques, il est préférable de fournir un seul type (par exemple, le manufacturer dans cet exemple) et de l'ignorer efficacement. Ensuite, dans chaque document, fournissez explicitement un champ appelé make ou quel que soit le nom que vous préférez et filtrez-le manuellement chaque fois que vous souhaitez vous y limiter. Cela réduira la taille de vos mappages à 1/n où n est le nombre de types séparés. Il ajoute un autre champ à chaque document, au profit d'une cartographie autrement simplifiée.

Dans Elasticsearch 1.x et 2.x, un tel champ doit être défini comme

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

1. Le nom est arbitraire.
2. Le nom est arbitraire et il pourrait correspondre au nom du type si vous le vouliez également.

Dans Elasticsearch 5.x, ce qui précède fonctionnera toujours (il est obsolète), mais le meilleur moyen est d'utiliser:

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

1. Le nom est arbitraire.
2. Le nom est arbitraire et il pourrait correspondre au nom du type si vous le vouliez également.

Les types doivent être utilisés avec parcimonie dans vos index, car ils gonflent les mappages d'index, généralement sans grand bénéfice. Vous devez en avoir au moins un, mais rien ne dit que vous devez en avoir plus d’un.

Questions courantes

• Que se passe-t-il si j'ai deux types (ou plus) qui sont pour la plupart identiques, mais qui ont quelques champs uniques par type?

Au niveau de l'index, il n'y a pas de différence entre un type utilisé avec quelques champs peu utilisés et entre plusieurs types partageant un groupe de champs non fragmentés avec quelques champs non partagés (ce qui signifie que l'autre type n'utilise même pas le champ (s)).

Dit différemment: un champ peu utilisé est rare à travers l'index indépendamment des types . La rareté ne profite pas - ou ne fait vraiment pas mal - l’indice simplement parce qu’il est défini dans un type distinct.

Vous devez simplement combiner ces types et ajouter un champ de type distinct.

• Pourquoi des types distincts doivent-ils définir des champs exactement de la même manière?

Parce que chaque champ n'est réellement défini qu'une seule fois au niveau Lucene, quel que soit le nombre de types. Le fait que les types existent du tout est une caractéristique d'Elasticsearch et ne constitue qu'une séparation logique.

• Puis-je définir des types séparés avec le même champ défini différemment?

Non. Si vous parvenez à trouver un moyen de le faire dans ES 2.x ou version ultérieure, vous devez alors ouvrir un rapport de bogue . Comme indiqué dans la question précédente, Lucene les considère tous comme un seul champ, il n'y a donc aucun moyen de faire en sorte que cela fonctionne correctement.

ES 1.x en a fait une exigence implicite, ce qui permettait aux utilisateurs de créer des conditions dans lesquelles les correspondances d'une partition dans un index différaient réellement d'une autre partition du même index. C'était effectivement une condition de course et cela pouvait entraîner des problèmes imprévus.

Exceptions à la règle

• Les documents parent / enfant nécessitent des types distincts à utiliser dans le même index.
  • Le parent vit dans un type.
  • L'enfant vit dans un type distinct (mais chaque enfant vit dans le même fragment que son parent).
• Des cas d'utilisation extrêmement complexes où la création de tonnes d'indices est indésirable et l'impact de champs rares est préférable à l'alternative.
  • Par exemple, le plug-in de surveillance Elasticsearch, Marvel (1.x et 2.x) ou X-Pack Monitoring (5.x +) surveille Elasticsearch lui-même pour détecter les modifications dans le cluster, les nœuds, les index, les index spécifiques (le niveau d'index), et même des éclats. Il pourrait créer plus de 5 index chaque jour pour isoler les documents ayant des correspondances uniques ou aller à l'encontre des meilleures pratiques pour réduire la charge du cluster en partageant un index (note: le nombre de mappages définis est le même, mais le nombre d'index créés est réduit de n à 1).
  • Ceci est un scénario avancé, mais vous devez tenir compte des définitions de champs partagés entre les types!