web-dev-qa-db-fra.com

Recherche élastique, plusieurs index contre un index et types pour différents ensembles de données?

J'ai une application développée à l'aide du modèle MVC et j'aimerais en indexer maintenant plusieurs modèles, ce qui signifie que chaque modèle a une structure de données différente.

  • Est-il préférable d'utiliser plusieurs index, un pour chaque modèle ou un type dans le même index pour chaque modèle? Je pense que les deux méthodes nécessiteraient également une requête de recherche différente. Je viens de commencer à ce sujet.

  • Existe-t-il des différences de performance entre les deux concepts si l'ensemble de données est petit ou énorme?

Je testerais moi-même la deuxième question si quelqu'un pouvait me recommander de bons exemples de données à cette fin.

databasesearchelasticsearch
146
burzum

Les deux approches ont des implications différentes. 

En supposant que vous utilisiez les paramètres par défaut d’Elasticsearch, le fait d’avoir un index pour chaque modèle augmenterait considérablement le nombre de vos fragments, 1 index utilisant 5 fragments, 5 modèles de données utilisant 25 fragments; tout en ayant 5 types d'objets dans 1 index, il utilisera encore 5 fragments.

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

  • Efficace et rapide pour rechercher dans l'index, car la quantité de données doit être plus petite dans chaque fragment, car elle est distribuée à différents index.
  • La recherche d'une combinaison de modèles de données à partir de 2 ou plusieurs index va générer une surcharge, car la requête devra être envoyée à plus de fragments, compilée et indexée, puis renvoyée à l'utilisateur.
  • Non recommandé si votre ensemble de données est petit, car chaque disque supplémentaire créé crée davantage de stockage et le gain de performance est marginal.
  • Recommandé si votre ensemble de données est volumineux et que le traitement de vos requêtes est long, car des fragments dédiés stockent vos données spécifiques et qu’il sera plus facile pour Elasticsearch de le traiter.

Implications pour que chaque modèle de données soit un type d'objet dans un index:

  • Plus de données seront stockées dans les 5 fragments d'un index, ce qui signifie que les interrogations sur différents modèles de données entraînent moins de frais généraux, mais que la taille de votre fragment est considérablement plus grande.
  • Elasticsearch mettra plus de temps à rechercher plus de données dans les fragments, 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 distribuez pas vos données sur 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 performances marginal, car chaque fragment occupe de l'espace dans votre matériel.

Si vous demandez ce qui est trop de données par rapport à de petites données? En règle générale, cela dépend de la vitesse du processeur et de la RAM 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 en matière de requête. L'utilisation de nombreuses facettes dans vos requêtes va considérablement ralentir votre temps de réponse. Il n’ya pas de réponse simple à cette question et vous devrez procéder à une évaluation en fonction de vos besoins.

174
Jonathan Moo

Bien que la réponse de Jonathan soit correcte à l'époque, le monde a évolué et il semble maintenant que les personnes derrière ElasticSearch ont 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 maintenant le support parent/enfant.

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

36
Danack

La réponse de Jonathan est excellente. Je voudrais juste ajouter 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 principaux, ou le diviser en 3 index pour 5 fragments - la perspective de performance ne changera pas (en supposant que les données sont distribuées également)
  • penser à l'utilisation des données. C'est à dire. Si vous utilisez kibana pour visualiser, il est plus facile d'inclure/exclure un ou plusieurs index (s) particulier (s), mais les types doivent être filtrés dans le tableau de bord.
  • conservation des données: pour les données de journal d'application/métrique, utilisez des index différents si vous souhaitez une période de conservation différente
13
Marcel Matus

Les deux réponses ci-dessus sont super! 

J'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 de 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 environ 50 à 70 000 livres.

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

  3. Recherche par auteurs prénom, nom de famille de l'auteur, année de publication, nom de l'éditeur. (Cela vous donne une idée de l'information que vous devriez stocker dans l'index)

D'après les réponses ci-dessus, nous pouvons dire que le schéma de notre index devrait ressembler un peu à ceci.

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

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

Afin de réaliser ce qui précède, nous pouvons créer un index appelé Livres et avoir différents types.

Index: Livre

Types: Science, Arts

(Ou vous pouvez créer plusieurs types tels que Technologie, Science médicale, Histoire, Langue, si vous avez beaucoup de livres)

Il est important de noter ici que le schéma est similaire mais que les données ne sont pas identiques. Et l’autre chose importante est le total des données que vous stockez. 

J'espère que ce qui précède vous aide à choisir différents types dans un index. Si vous avez un schéma différent, vous devez envisager un index différent. Petit index pour moins de données. Big Index pour Big Data :-)

0
Sourav