Recherche élastique, index multiples par rapport à 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 indice de multiples modèles, cela signifie que chaque modèle a une autre structure de données.

  • est-il préférable d'utiliser des index multiples, un pour chaque modèle ou d'avoir un type à l'intérieur du 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 sur ce.

  • Sont là différences de performance entre les deux concepts si l'ensemble de données est petit ou énorme?

je testerais la deuxième question moi-même si quelqu'un pouvait me recommander quelques bonnes données d'échantillon à cette fin.

143
demandé sur burzum 2013-01-22 22:40:36

4 réponses

les deux approches ont des implications différentes.

en supposant que vous utilisez les paramètres par défaut D'Elasticsearch, avoir un indice pour chaque modèle augmentera de manière significative le nombre de vos fragments car 1 Indice utilisera 5 fragments, 5 modèles de données utiliseront 25 fragments; alors que d'avoir 5 types d'objet dans 1 index va toujours utiliser 5 fragments.

Implications pour chaque modèle de données de l'index:

  • efficace et rapide à rechercher dans index, car la quantité de données devrait être plus petite dans chaque fragment car il est distribué à des indices différents.
  • 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, parce que la requête devra être envoyée à plus de fragments à travers les indices, compilé et envoyé à l'utilisateur.
  • Non recommandé si votre ensemble de données est petit car vous devrez effectuer plus de stockage avec chaque fragment supplémentaire créé et le gain de performance est marginal.
  • recommandé si votre ensemble de données est important et que le traitement de vos requêtes prend beaucoup de temps, étant donné que les fragments dédiés stockent vos données spécifiques et Qu'il sera plus facile pour Elasticsearch de les traiter.

Implications pour chaque modèle de données comme un type d'objet dans un indice:

  • plus de données seront stockées dans les 5 fragments d'un indice, ce qui signifie qu'il y a moins les problèmes de frais généraux lorsque vous interrogez à travers différents modèles de données, mais votre taille de fragment sera beaucoup plus grand.
  • plus de données dans les fragments va prendre un plus long temps pour Elasticsearch de rechercher à travers car il ya plus de documents à filtrer.
  • Non recommandé si vous savez que vous êtes en train de parcourir 1 téraoctets de données et que vous ne distribuez pas vos données à travers différents indices ou plusieurs fragments dans votre cartographie Elasticsearch.
  • recommandé pour les petits ensembles de données, parce que vous ne perdrez pas d'espace de stockage pour un gain de performance marginal car chaque Éclat occupe de l'espace dans votre matériel.

si vous demandez ce qui est trop de données vs de petites données? Typiquement 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 dans votre mapping pour Elasticsearch et vos besoins de requête; l'utilisation de nombreuses facettes dans vos requêtes va ralentir réduisez votre temps de réponse de façon significative. Il n'y a pas de réponse simple à cette question et vous devrez établir des points de repère en fonction de vos besoins.

172
répondu Jonathan Moo 2017-03-20 21:48:19

bien que la réponse de Jonathan ait été correcte à l'époque, le monde est passé à autre chose et il semble maintenant que les gens derrière ElasticSearch ont un plan à long terme pour laisser tomber le soutien pour les types multiples:

où nous voulons aller: nous voulons supprimer le concept de types de Elasticsearch, tout en soutenant encore parent/enfant.

ainsi, pour les nouveaux projets, en utilisant seulement un type unique par index fera la mise à niveau finale vers ElasticSearch 6.x être plus facile.

30
répondu Danack 2017-03-13 11:27:47

la réponse de Jonathan est excellente. Je voudrais juste ajouter quelques autres points à considérer:

  • nombre de fragments peuvent être personnalisés par solution que vous sélectionnez. Vous pouvez avoir un indice de 15 primaire éclats, ou de le diviser à 3 indices pour 5 éclats de point de vue des performances ne changent pas (en supposant que les données sont distribuées de manière égale)
  • pensez à l'utilisation des données. IE. si vous utilisez kibana pour visualiser, il est plus facile d'inclure/exclure certains index, mais types doit être filtré dans le tableau de bord
  • conservation des données: pour les données log/métrique de l'application, utilisez des index différents si vous avez besoin d'une période de conservation différente
13
répondu Marcel Matus 2015-07-28 11:29:22

les deux réponses ci-dessus sont grandes!

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,

Questions:

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

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

  3. Comment allez-vous chercher des livres?

Réponses:

  1. j'ai l'intention de stocker 50 k – à 70 k livres (environ)

  2. je vais avoir 15 k -20 k livres liés à la technologie (informatique, Génie Mécanique, Génie Chimique et ainsi de suite), 15 k de livres historiques, 10 k de sciences médicales livre. 10 k de livres en rapport avec la langue (anglais, espagnol et ainsi de suite)

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

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

//Ce n'est pas exactement la cartographie, 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: Les Sciences, Les 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)

chose Importante à noter ici est le schéma est similaire, mais les données ne sont pas identiques. Et l'autre chose importante est le total des données que vous stockez.

espérons que ce qui précède aide quand aller pour différents types dans un Index, si vous avez un schéma différent, vous devriez considérer l'index différent. Petit indice pour le moins de données . gros indice pour le big data :-)

0
répondu Sourav 2017-02-21 16:01:38