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

J'ai une application développée en utilisant le modèle MVC et je voudrais maintenant indexer plusieurs modèles de celui-ci, cela signifie que chaque modèle a une structure de données différente.

• Vaut-il mieux utiliser plusieurs index, un pour chaque modèle ou avoir un type dans le même index pour chaque modèle? Les deux méthodes nécessiteraient également une requête de recherche différente, je pense. Je viens de commencer là-dessus.

• Existe-t-il des différences de performances 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.

Les deux approches ont des implications différentes.

En supposant que vous utilisez les paramètres 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'objets dans 1 index va encore utiliser 5 fragments.

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

• Recherche efficace et rapide dans l'index, car la quantité de données doit être plus petite dans chaque partition car elle est distribuée à différents index.
• La recherche d'une combinaison de modèles de données à partir de 2 indices ou plus va générer des frais généraux, car la requête devra être envoyée à plus de fragments dans les index, compilée et renvoyée à l'utilisateur.
• Non recommandé si votre ensemble de données est petit, car vous encourrez plus de stockage avec chaque partition supplémentaire créée et le gain de performances est marginal.
• Recommandé si votre ensemble de données est volumineux et que vos requêtes prennent beaucoup de temps à traiter, car des partitions dédiées stockent vos données spécifiques et il sera plus facile pour Elasticsearch de traiter.

Implications pour avoir chaque modèle de données comme type d'objet 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 de frais généraux lorsque vous interrogez différents modèles de données, mais la taille de votre partition sera considérablement plus grande.
• Il faudra plus de temps à Elasticsearch pour rechercher davantage 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 entre différents index ou plusieurs fragments dans votre mappage Elasticsearch.
• Recommandé pour les petits ensembles de données, car vous ne gaspillerez pas d'espace de stockage pour un gain de performances marginal puisque chaque partition occupe de l'espace dans votre matériel.

Si vous demandez ce qu'est trop de données par rapport à de petites données? Cela dépend généralement 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 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 soit correcte à l'époque, le monde a évolué et il semble maintenant que les personnes derrière ElasticSearch aient un plan à long terme pour abandonner la prise en charge de plusieurs types:

Où nous voulons en arriver: Nous voulons supprimer le concept de types d'Elasticsearch, tout en prenant en charge le parent / enfant.

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

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 que vous sélectionnez. Vous pouvez avoir un index avec 15 fragments primaires ou le diviser en 3 index pour 5 fragments - la perspective des performances ne changera pas (en supposant que les données soient distribuées de manière égale)
• pensez à l'utilisation des données. C'est à dire. si vous utilisez kibana pour visualiser, il est plus facile d'inclure / d'exclure des index particuliers, mais les types doivent être filtrés dans le tableau de bord
• conservation des données: pour le journal d'application / les données métriques, utilisez des index différents si vous avez besoin d'une période de conservation différente

Les deux réponses ci-dessus sont excellentes!

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 quelques 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 rechercher des livres?

Réponses:

1. Je prévois de stocker entre 50 000 et 70 000 livres (environ)

2. J'aurai 15 k à 20 k livres liés à 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 liés aux langues (anglais, espagnol, etc.)

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

D'après les 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": "string"
                    },
                    "lastName":{
                        "type": "string"
                    }
                }
            },
            "publisherName":{
                "type": "string"
            }
        }

Afin d'atteindre ce qui précède, nous pouvons créer un index appelé Livres et peut avoir différents types.

Index: Livre

Types: Sciences, 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 plus 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 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. big index pour le big data :-)