Question de performance sur l'indexation de grandes quantités de données. J'ai une grande table (~ 30 millions de lignes), avec 4 des colonnes indexées pour permettre une recherche rapide. Actuellement, j'ai défini les index (indices?) UP, puis importer mes données. Cela prend environ 4 heures, en fonction de la vitesse du serveur DB. Serait-il plus rapide / plus efficace d'importer les données d'abord, puis effectuez un bâtiment d'index?
3 Réponses :
Insertion de données tandis que les indices sont en place, les DBM les mettent à la mettre à jour après chaque ligne. Pour cette raison, il est généralement plus rapide d'insérer d'abord les données et de créer des indices après. Surtout s'il y a beaucoup de données.
(Cependant, il est toujours possible qu'il existe des circonstances particulières qui peuvent causer des caractéristiques de performance différentes. Essayer c'est le seul moyen de savoir à coup sûr.)
@af sur quelles hypothèses votre généralisation est basée? J'ai récemment essayé les deux, et je l'ai trouvé beaucoup plus rapide d'insertion en vrac avec les index en place que de laisser tomber et de recréer après 20 minutes de plus de 20 minutes sur un ensemble de données de quelques millions de rangées.
Oui, tout dépend des données spécifiques, de l'ordre des lignes et des indices. Il est tout à fait possible que, même si le DBMS doit faire plus de travail dans l'insertion de Stuff-par-rangée, si tout se trouve dans un ordre droit, le SGBD peut simplement écrire le contenu et ne jamais finir par réorganiser des données ou équilibrer les structures de données d'index. Ces situations sont généralement des exceptions, pas la norme. Ça dépend. Habituellement, les choses ne sont pas alignées "juste juste".
Cela dépendra entièrement de votre stratégie de données et d'indexation particulière. Toute réponse que vous obtenez ici est vraiment une supposition.
Le seul moyen de savoir à coup sûr, est d'essayer les deux et de prendre des mesures appropriées, ce qui ne sera pas difficile à faire.
Je trappe la réponse de AF en disant que ce serait probablement être le cas "d'abord" d'abord, insérer après "serait plus lent" que "d'abord" Index après "où vous insérez des enregistrements dans Une table avec un index en cluster, mais ne pas insérer d'enregistrements dans l'ordre naturel de cet indice. La raison étant celle pour chaque insertion, les rangées de données elles-mêmes devraient être commandées sur disque.
À titre d'exemple, envisagez une table avec une clé primaire en cluster sur un champ uniqueIdentifier. La nature (presque) aléatoire d'un GUID signifierait qu'il est possible qu'une ligne soit ajoutée au sommet des données, ce qui entraîne mélanger toutes les données de la page actuelle (et peut-être des données dans des pages basses), mais aussi la ligne suivante ajoutée en bas. Si le clustering était sur, dites une colonne DateTime, et vous devez ajouter des lignes à la date d'ordre de date, les enregistrements seraient naturellement insérés dans le bon ordre sur le disque et les opérations de tri et de mélange de données coûteuses ne seraient pas nécessaires.
Je sauvegarderais la réponse de Winston Smith de "Cela dépend", mais suggère que votre indice en regroupement peut être un facteur important pour déterminer quelle stratégie est plus rapide pour votre situation actuelle. Vous pouvez même essayer de ne pas avoir d'index en cluster, et voyez ce qui se passe. Faites-moi savoir?
Les données qui ont été insérées étaient dans un ordre très non formé, l'indexation après l'insertion était beaucoup plus rapide. Merci pour l'explication.