Changeset 47 for trunk/workshop-foss4g/indexing.rst
- Timestamp:
- 27/09/2011 16:44:49 (13 years ago)
- File:
-
- 1 edited
-
trunk/workshop-foss4g/indexing.rst (modified) (10 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/workshop-foss4g/indexing.rst
r40 r47 4 4 ================================= 5 5 6 Rapellez-vous que l es indexes spatiaux sont l'une des trois fonctionnalités clés d'une base de données spatiales. Les indexes rendent possible l'utilisation de grandes quantités de données dans une base. Sans indexation, chaque recherche d'une entité nécessitera d'accéder séquentiellement à tout les enregistrement de la base de données. L'indexation rend plus rapideles recherche en organisant les données dans des arbres de recherche qui peuvent être parcouru efficacement pour retrouver une entité particuliÚre.6 Rapellez-vous que l'indexation spatiale est l'une des trois fonctionnalités clés d'une base de données spatiales. Les indexes permettent l'utilisation de grandes quantités de données dans une base. Sans l'indexation, chaque recherche d'entité nécessitera d'accéder séquentiellement à tout les enregistrements de la base de données. L'indexation accélÚres les recherche en organisant les données dans des arbres de recherche qui peuvent être parcouru efficacement pour retrouver une entité particuliÚre. 7 7 8 L es indexes spatiaux sont l'un des plus grands atouts de PostGIS. Dans les exemples précédents, nous construissions nos jointures spatiales en comparant la totalité des tables. Ceci peut s'averrer trÚs coûteux : réaliser la jointure de deux tables de 10000 enregistrements sans index nécessitera de comparer 100000000 valeurs, avec les indexes les comparaisons requises seront 20000.8 L'indexation spatiale l'un des plus grands atouts de PostGIS. Dans les exemples précédents, nous avons construit nos jointures spatiales en comparant la totalité des tables. Ceci peut parfois s'averrer trÚs coûteux : Réaliser la jointure de deux tables de 10000 enregistrements sans indexation nécessitera de comparer 100000000 valeurs, les comparaisons requises ne seront plus que 20000 avec l'indexation. 9 9 10 10 Lorsque nous avons chargé la table ``nyc_census_blocks``, l'outils pgShapeLoader crée automatiquement un indexe spatial appelé ``nyc_census_blocks_the_geom_gist``. … … 12 12 Pour démontrer combien il est important d'indexer ses données pour la performance des requêtes, essayons de requêter notre table ``nyc_census_blocks`` **sans** utiliser notre indexe. 13 13 14 La premiÚre étap t consiste asupprimer l'index.14 La premiÚre étape consiste à supprimer l'index. 15 15 16 16 .. code-block:: sql … … 22 22 La commande ``DROP INDEX`` supprime un index existant de la base de données. Pour de plus amples informations à ce sujet, consultez la `documentation officielle de PostgreSQL <http://docs.postgresql.fr/9.1/sql-dropindex.html>`_. 23 23 24 Maintenant, regardons le temps d'exécution dans le coin en bas à droite de l'interface de requêtage de pgAdmin etlançons la commande suivante. Notre requête recherche les blocs de la rue Broad.24 Maintenant, regardons le temps d'exécution dans le coin en bas à droite de l'interface de requêtage de pgAdmin, puis lançons la commande suivante. Notre requête recherche les blocs de la rue Broad. 25 25 26 26 .. code-block:: sql … … 40 40 La table ``nyc_census_blocks`` est trÚs petite (seulement quelque millier d'enregistrements) donc même sans l'index, la requête prends **55 ms** sur l'ordinateur de test. 41 41 42 Maintenant remettons en place l'index eet lançons de nouveau la requête.42 Maintenant remettons en place l'index et lançons de nouveau la requête. 43 43 44 44 .. code-block:: sql … … 46 46 CREATE INDEX nyc_census_blocks_the_geom_gist ON nyc_census_blocks USING GIST (the_geom); 47 47 48 .. note:: l'utilisation de la clause ``USING GIST`` spécifie à PostgreSQL de créer une structure (GIST) pour cet index e. Si vous recevez un message d'erreur ressemblant à ``ERROR: index row requires 11340 bytes, maximum size is 8191`` lors de la création, cela signifie sans doute que vous avez omis la clause ``USING GIST``.48 .. note:: l'utilisation de la clause ``USING GIST`` spécifie à PostgreSQL de créer une structure (GIST) pour cet index. Si vous recevez un message d'erreur ressemblant à ``ERROR: index row requires 11340 bytes, maximum size is 8191`` lors de la création, cela signifie sans doute que vous avez omis la clause ``USING GIST``. 49 49 50 50 Sur l'rdinateur de test le temps d'exécution se réduit à **9 ms**. Plus votre table est grande, plus la différence de temps d'exécution pour une requête utilisant les indexes augmentera. … … 53 53 ----------------------------------------- 54 54 55 Les indexes des base de données standards crée un arbre hierarchique basé sur les valeurs de la colonneà indexer. Les indexes spatiaux sont un peu différents - ils ne sont pas capables d'indexer des entités géométriques elles-même mais indexe leur étendues.55 Les indexes des base de données standards créent des arbres hierarchiques basés sur les valeurs des colonnes à indexer. Les indexes spatiaux sont un peu différents - ils ne sont pas capables d'indexer des entités géométriques elles-même mais indexe leur étendues. 56 56 57 57 .. image:: ./indexing/bbox.png … … 59 59 Dans la figure ci-dessus, le nombre de lignes qui intersectent l'étoile jaune est *unique*, la ligne rouge. Mais l'étendue des entités qui intersectent la boîte jaune sont *deux*, la boîte rouge et la boîte bleue. 60 60 61 La maniÚre dont les bases de données répondent de maniÚre efficace s à la questions "quelle ligne intersectent l'étoile jaune ?" correspond à d'abort répondre à question ; "quelle étendue intersecte l'étendue jaune" en utilisant les indexes (ce qui est trÚs rapide) puis réalise le calcul exacte de "quelles lignes intersectent l'étoile jaune" **seulement en utilisant les entités retourné par le premier test**.61 La maniÚre dont les bases de données répondent de maniÚre efficace à la question "Quelles lignes intersectent l'étoile jaune ?" correspond premiÚrement à répondre à la question "Quelle étendue intersecte l'étendue jaune" en utilisant les indexes (ce qui est trÚs rapide) puis à calculer le résultat exact de la question "Quelles lignes intersectent l'étoile jaune ?" **seulement en utilisant les entités retourné par le premier test**. 62 62 63 63 Pour de grandes tables, il y a un systÚme en "deux étapes" d'évaluation en utilisant dans un premier temps l'approximation à l'aide d'indexes, puis en réalisant le test exact sur une quantité bien moins importante de données ce qui réduit drastiquement le temps de calcul nécessaire à cette deuxiÚme étape. … … 74 74 Pour utiliser une recherche par étendue utilisant les indexes (et pas de filtres), vous pouvez utiliser l'opérateur :command:`&&`. Pour les géométries, l'opérateur :command:`&&` signifie "l'étendue recouvre ou touche" de la même maniÚre que l'opérateur :command:`=` sur des entiers signifie que les valeurs sont égales. 75 75 76 Essayons de comparer une requête avec seulement un indexe pour la population du quartier 'West Village'. En utilisant la commande :command:`&&` notre requête ressemble à ce qui suit:76 Essayons de comparer une requête avec seulement un indexe pour la population du quartier 'West Village'. En utilisant la commande :command:`&&` notre requête ressemble à cela : 77 77 78 78 .. code-block:: sql … … 102 102 27141 103 103 104 Un plus faible nombre de résultats ! La premiÚre requête nous renvoit tout les blo qcs qui intersectent l'étendue du quartier, la seconde nous renvoit seulement les blocs qui intersectent le quartier lui-même.104 Un plus faible nombre de résultats ! La premiÚre requête nous renvoit tout les blocs qui intersectent l'étendue du quartier, la seconde nous renvoit seulement les blocs qui intersectent le quartier lui-même. 105 105 106 106 Analyse … … 126 126 Le nettoyage des données est tellement important pour une utilisation efficace du serveur de base de données PostgreSQL qu'il existe maintenant une option "autovacuum". 127 127 128 Activée par défaut, le processus autovacuum à la fois nettoit (récupÚre l'espace libre) et analyse (met à jour les statistiques) de vos tables suivant un interval donnée déterminé par l'activité des bases de données. Bien que cela soit pourles bases de données hautement transactionnelles, il n'est pas supportable de devoir attendre que le processus autovacuum se lance lors de la mise à jour ou la suppression massive de données. Dans ce cas, il faut lancer la commande ``VACUUM`` manuellement.128 Activée par défaut, le processus autovacuum nettoie (récupÚre l'espace libre) et analyse (met à jour les statistiques) vos tables suivant un interval donné déterminé par l'activité des bases de données. Bien que cela fonctionne avec les bases de données hautement transactionnelles, il n'est pas supportable de devoir attendre que le processus autovacuum se lance lors de la mise à jour ou la suppression massive de données. Dans ce cas, il faut lancer la commande ``VACUUM`` manuellement. 129 129 130 Le nettoyage et l'analyse de la base de données peut être réalisé séparément si nécessaire. Utiliser la commande ``VACUUM`` ne mettra pas à jour les statistiques alors que lancer la commande ``ANALYZE`` ne récupÚrera pas l'espace libre des lignes d'une table. Chacune de ces commandes peut être lancé sur l'intégralité de la base de données, sur une table ou sur une seule colonne.130 Le nettoyage et l'analyse de la base de données peut être réalisé séparément si nécessaire. Utiliser la commande ``VACUUM`` ne mettra pas à jour les statistiques alors que lancer la commande ``ANALYZE`` ne récupÚrera pas l'espace libre des lignes d'une table. Chacune de ces commandes peut être lancée sur l'intégralité de la base de données, sur une table ou sur une seule colonne. 131 131 132 132 .. code-block:: sql
Note: See TracChangeset
for help on using the changeset viewer.
