Recherche élastique, index multiples par rapport à un index et types pour différents jeux de données?

Les deux approches ont des implications différentes.

En supposant que vous utilisez les parameters par défaut d’Elasticsearch, avoir 1 index pour chaque modèle augmentera considérablement le nombre de vos fragments, car 1 index utilisera 5 fragments, 5 modèles de données utiliseront 25 fragments; tout en ayant 5 types d’objects dans 1 index va toujours utiliser 5 fragments.

Implications pour avoir chaque modèle de données comme index:

• Efficace et rapide à rechercher dans index, la quantité de données devant être plus petite dans chaque partition car elle est dissortingbuée dans différents index.
• La recherche d’une combinaison de modèles de données à partir de deux index ou plus va générer une surcharge, car la requête devra être envoyée à davantage de partitions à travers les index, compilée et renvoyée à l’utilisateur.
• Non recommandé si votre jeu de données est petit, car vous devrez engager davantage de stockage avec chaque fragment supplémentaire créé et le gain de performances sera marginal.
• Recommandé si votre dataset est volumineux et que vos requêtes sont longues à traiter, car les fragments dédiés stockent vos données spécifiques et seront plus faciles à traiter pour Elasticsearch.

Implications pour avoir chaque modèle de données en tant que type d’object dans un index:

• Plus de données seront stockées dans les 5 fragments d’un index, ce qui signifie qu’il y a moins de problèmes généraux lorsque vous interrogez différents modèles de données, mais que votre taille de fragment sera considérablement plus grande.
• Elasticsearch aura besoin de plus de temps pour parcourir plus de données, car il y a plus de documents à filtrer.
• Non recommandé si vous savez que vous parcourez 1 téraoctet de données et que vous ne dissortingbuez pas vos données entre différents index ou plusieurs fragments dans votre mappage Elasticsearch.
• Recommandé pour les petits ensembles de données, car vous ne perdrez pas d’espace de stockage pour un gain de performance marginal, car chaque fragment occupe de l’espace dans votre matériel.

Si vous demandez quelles sont trop de données par rapport à de petites données? En général, cela dépend de la vitesse du processeur et de la mémoire vive de votre matériel, de la quantité de données que vous stockez dans chaque variable de votre mappage pour Elasticsearch et de vos exigences de requête. L’utilisation de nombreuses facettes dans vos requêtes ralentira considérablement votre temps de réponse. Il n’y a pas de réponse simple à cela et vous devrez effectuer un benchmark en fonction de vos besoins.

Bien que la réponse de Jonathan ait été correcte à l’époque, le monde a évolué et il semble maintenant que les personnes à l’origine d’ElasticSearch aient un plan à long terme pour abandonner le support pour plusieurs types:

Où nous voulons aller: Nous voulons supprimer le concept de types d’Elasticsearch, tout en prenant en charge les parents / enfants.

Ainsi, pour les nouveaux projets, l’utilisation d’un seul type par index facilitera la mise à niveau éventuelle d’ElasticSearch 6.x.

La réponse de Jonathan est géniale. Je voudrais juste append quelques autres points à considérer:

• Le nombre de fragments peut être personnalisé par solution sélectionnée. Vous pouvez avoir un index avec 15 fragments primaires, ou le diviser en 3 index pour 5 fragments – la perspective de performance ne changera pas (en supposant que les données sont dissortingbuées de manière égale)
• penser à l’utilisation des données. C’est à dire. Si vous utilisez kibana pour visualiser, il est plus facile d’inclure / exclure des index particuliers, mais les types doivent être filtrés dans le tableau de bord
• Conservation des données: pour les données de journal / mésortingque d’application, utilisez différents index si vous avez besoin d’une période de conservation différente

Les deux réponses ci-dessus sont géniales!

Je ajoute un exemple de plusieurs types dans un index. Supposons que vous développiez une application pour rechercher des livres dans une bibliothèque. Il y a peu de questions à poser au propriétaire de la bibliothèque,

Des questions:

1. Combien de livres prévoyez-vous stocker?

2. Quel genre de livres allez-vous stocker dans la bibliothèque?

3. Comment allez-vous chercher des livres?

Réponses:

1. Je prévois de stocker de 50 à 70 k livres (environ)

2. J’aurai 15 à 20 k livres sur la technologie (informatique, génie mécanique, génie chimique, etc.), 15 k de livres historiques, 10 k de livres de sciences médicales. 10 k de livres sur les langues (anglais, espagnol, etc.)

3. Recherche par prénoms auteurs, nom de l’auteur, année de publication, nom de l’éditeur. (Cela vous donne l’idée de savoir quelles informations stocker dans l’index)

À partir des réponses ci-dessus, nous pouvons dire que le schéma de notre index devrait ressembler à ceci.

// Ce n’est pas le mappage exact, juste pour l’exemple

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

Pour atteindre ce qui précède, nous pouvons créer un index appelé Books et avoir différents types.

Index: Livre

Types: Science, Arts

(Ou vous pouvez créer de nombreux types tels que la technologie, la science médicale, l’histoire, la langue, si vous avez beaucoup d’autres livres)

Une chose importante à noter est que le schéma est similaire mais que les données ne sont pas identiques. Et l’autre chose importante est le nombre total de données que vous stockez.

J’espère que ce qui précède vous aidera à choisir différents types dans un index, si vous avez un schéma différent, vous devriez envisager un index différent. Petit index pour moins de données. gros index pour le big data 🙂