Bienvenue sur PostGIS.fr

Bienvenue sur PostGIS.fr , le site de la communauté des utilisateurs francophones de PostGIS.

PostGIS ajoute le support d'objets géographique à la base de données PostgreSQL. En effet, PostGIS "spatialise" le serverur PostgreSQL, ce qui permet de l'utiliser comme une base de données SIG.

Maintenu à jour, en fonction de nos disponibilités et des diverses sorties des outils que nous testons, nous vous proposons l'ensemble de nos travaux publiés en langue française.


Ignore:
Timestamp:
17/03/2012 00:49:40 (12 years ago)
Author:
thomasg
Message:

Fin correction typo et orthographe V2 du document

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/workshop-foss4g/indexing.rst

    r47 r62  
    44================================= 
    55 
    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. 
     6Rapellez-vous que l'indexation spatiale est l'une des trois fonctionnalités clés d'une base de données spatiales. Les index 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 à tous les enregistrements de la base de données. L'indexation accélÚre les recherches en organisant les données dans des arbres de recherche qui peuvent être parcourus efficacement pour retrouver une entité particuliÚre. 
    77 
    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. 
     8L'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'avérer 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. 
    99 
    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``. 
     10Lorsque nous avons chargé la table  ``nyc_census_blocks``, l'outil pgShapeLoader crée automatiquement un index spatial appelé ``nyc_census_blocks_the_geom_gist``. 
    1111 
    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. 
     12Pour 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 index. 
    1313 
    1414La premiÚre étape consiste à supprimer l'index. 
     
    1717 
    1818  DROP INDEX nyc_census_blocks_the_geom_gist; 
    19    
     19 
    2020.. note:: 
    2121 
    2222   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 
    2424Maintenant, 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. 
    2525 
     
    3131  ON ST_Contains(blocks.the_geom, subways.the_geom) 
    3232  WHERE subways.name = 'Broad St'; 
    33    
     33 
    3434:: 
    3535 
    36        blkid       
     36       blkid 
    3737 ----------------- 
    3838  360610007003006 
    39    
    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. 
     39 
     40La table ``nyc_census_blocks`` est trÚs petite (seulement quelque milliers d'enregistrements) donc même sans l'index, la requête prends **55 ms** sur l'ordinateur de test. 
    4141 
    4242Maintenant remettons en place l'index et lançons de nouveau la requête. 
     
    4848.. 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``. 
    4949 
    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. 
     50Sur l'ordinateur 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 index augmentera. 
    5151 
    52 Comment les indexes spatiaux fonctionnent 
    53 ----------------------------------------- 
     52Comment les index spatiaux fonctionnent 
     53--------------------------------------- 
    5454 
    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. 
     55Les index des bases de données standards créent des arbres hiérarchiques basés sur les valeurs des colonnes à indexer. Les index spatiaux sont un peu différents - ils ne sont pas capables d'indexer des entités géométriques elles-même mais ils indexent leur étendues. 
    5656 
    5757.. image:: ./indexing/bbox.png 
     
    5959Dans 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. 
    6060 
    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**. 
     61La 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 index (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ées par le premier test**. 
    6262 
    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. 
     63Pour 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'index, 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. 
    6464 
    6565PotGIS et Oracle Spatial partage la même notion d'index structuré sous la forme "d'arbres R" [#RTree]_. Les arbres R classent les données sous forme de rectangles, de sous-rectangles etc. Cette structure d'index gÚre automatiquement la densité et la taille des objets. 
     
    6767.. image:: ./indexing/index-01.png 
    6868 
    69 Requête avec seulement des indexes 
    70 ---------------------------------- 
     69Requête avec seulement des index 
     70-------------------------------- 
    7171 
    72 La plupart des fonctions utilisées par PostGIS (:command:`ST_Contains`, :command:`ST_Intersects`, :command:`ST_DWithin`, etc) prennent en compte les indexes automatiquement. Mais certaines fonctions (comme par exemple : :command:`ST_Relate`) ne les utilisent pas. 
     72La plupart des fonctions utilisées par PostGIS (:command:`ST_Contains`, :command:`ST_Intersects`, :command:`ST_DWithin`, etc) prennent en compte les index automatiquement. Mais certaines fonctions (comme par exemple : :command:`ST_Relate`) ne les utilisent pas. 
    7373 
    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. 
     74Pour utiliser une recherche par étendue utilisant les index (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. 
    7575 
    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 : 
     76Essayons de comparer une requête avec seulement un index pour la population du quartier 'West Village'. En utilisant la commande :command:`&&` notre requête ressemble à cela : 
    7777 
    7878.. code-block:: sql 
    7979 
    80   SELECT Sum(popn_total)  
     80  SELECT Sum(popn_total) 
    8181  FROM nyc_neighborhoods neighborhoods 
    8282  JOIN nyc_census_blocks blocks 
    8383  ON neighborhoods.the_geom && blocks.the_geom 
    8484  WHERE neighborhoods.name = 'West Village'; 
    85    
     85 
    8686:: 
    8787 
    8888  50325 
    89    
     89 
    9090Maintenant essayons la même requête en utilisant la fonction plus précise :command:`ST_Intersects`. 
    9191 
    9292.. code-block:: sql 
    9393 
    94   SELECT Sum(popn_total)  
     94  SELECT Sum(popn_total) 
    9595  FROM nyc_neighborhoods neighborhoods 
    9696  JOIN nyc_census_blocks blocks 
    9797  ON ST_Intersects(neighborhoods.the_geom, blocks.the_geom) 
    9898  WHERE neighborhoods.name = 'West Village'; 
    99    
     99 
    100100:: 
    101101 
    102102  27141 
    103103 
    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. 
     104Un plus faible nombre de résultats ! La premiÚre requête nous renvoie tous les blocs qui intersectent l'étendue du quartier, la seconde nous renvoie seulement les blocs qui intersectent le quartier lui-même. 
    105105 
    106106Analyse 
    107107--------- 
    108108 
    109 Le plannificateur de requête de PostgreSQL choisit intelligemment d'utiliser ou non les indexes pour réaliser une requête. Il n'est pas toujours plus rapide d'utiliser un index pour réaliser une recherche : si la recherche doit renvoyer l'ensemble des enregistrements d'une table, parcourir l'index pour récupérer chaque valeur sera plus lent que de parcourir linéairement l'ensemble de la table. 
     109Le planificateur de requête de PostgreSQL choisit intelligemment d'utiliser ou non les index pour réaliser une requête. Il n'est pas toujours plus rapide d'utiliser un index pour réaliser une recherche : si la recherche doit renvoyer l'ensemble des enregistrements d'une table, parcourir l'index pour récupérer chaque valeur sera plus lent que de parcourir linéairement l'ensemble de la table. 
    110110 
    111 Afin de savoir dans quelle situation il est nécessaire d'utiliser les idexes (lire une petite partie de la table plutÃŽt qu'une grande partie), PostgreSQL conserve des statistiques relatives à la distribution des données dans chaque colonne indexée. Par défaut, PostgreSQL rassemble les statistiques sur une base réguliÚre. Nénamoins, si vous changez dramatiquement le contenu de vos tables dans une période courte, les statisuqes ne seront alors plus à jour. 
     111Afin de savoir dans quelle situation il est nécessaire d'utiliser les index (lire une petite partie de la table plutÃŽt qu'une grande partie), PostgreSQL conserve des statistiques relatives à la distribution des données dans chaque colonne indexée. Par défaut, PostgreSQL rassemble les statistiques sur une base réguliÚre. Néanmoins, si vous changez dramatiquement le contenu de vos tables dans une période courte, les statistiques ne seront alors plus à jour. 
    112112 
    113 Pour vous assurez que les statistiques correspondent bien au contenu de la table actuelle, il est courrant d'utiliser la commande ``ANALYZE`` aprÚs un grand nombre de modifications ou de suppression de vos données. Cela force le systÚme de gestion des statistiques à récupérer l'ensemble des données des colonnes indexées. 
     113Pour vous assurez que les statistiques correspondent bien au contenu de la table actuelle, il est courant d'utiliser la commande ``ANALYZE`` aprÚs un grand nombre de modifications ou de suppression de vos données. Cela force le systÚme de gestion des statistiques à récupérer l'ensemble des données des colonnes indexées. 
    114114 
    115 La commande ``ANALYZE`` demande à PostgreSQL de parcourir la table et de mettre à jour les statistiques utilisées par le plannificateur de requêtes (la plannification des requêtes sera traité utiltérieurement). 
     115La commande ``ANALYZE`` demande à PostgreSQL de parcourir la table et de mettre à jour les statistiques utilisées par le planificateur de requêtes (la planification des requêtes sera traité ultérieurement). 
    116116 
    117117.. code-block:: sql 
    118118 
    119119   ANALYZE nyc_census_blocks; 
    120     
     120 
    121121Néttoyage 
    122122--------- 
    123123 
    124 Il est souvent stressant de constater que la simple création d'un indexe n'est pas suffisant pour que PostgreSQL l'utilise efficacement. Le nettoyage doit être réalisé aprÚs qu'un indexe soit créé ou aprÚs un grand nombre de requêtes UDATE, INSERT ou DELETE est été réalisé sur une table. La commande ``VACUUM`` demande à PostgreSQL de récupérer chaque espace non utilisé dans les pages de la table qui sont laissé en l'état lors des requêtes UPDATE ou DELETE à cause du modÚle d'estapillage multi-versions. 
     124Il est souvent stressant de constater que la simple création d'un index n'est pas suffisant pour que PostgreSQL l'utilise efficacement. Le nettoyage doit être réalisé aprÚs qu'un index soit créé ou aprÚs un grand nombre de requêtes UDATE, INSERT ou DELETE ait été réalisé sur une table. La commande ``VACUUM`` demande à PostgreSQL de récupérer chaque espace non utilisé dans les pages de la table qui sont laissées en l'état lors des requêtes UPDATE ou DELETE à cause du modÚle d'estampillage multi-versions. 
    125125 
    126126Le 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". 
    127127 
    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. 
     128Activée par défaut, le processus autovacuum nettoie (récupÚre l'espace libre) et analyse (met à jour les statistiques) vos tables suivant un intervalle 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. 
    129129 
    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. 
     130Le nettoyage et l'analyse de la base de données peuvent être réalisés 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. 
    131131 
    132132.. code-block:: sql 
     
    137137------------------- 
    138138 
    139 `geometry_a && geometry_b <http://postgis.org/docs/ST_Geometry_Overlap.html>`_: retourne TRUE si l'étendue de A cheuvauche celle de B. 
     139`geometry_a && geometry_b <http://postgis.org/docs/ST_Geometry_Overlap.html>`_: retourne TRUE si l'étendue de A chevauche celle de B. 
    140140 
    141141`geometry_a = geometry_b <http://postgis.org/docs/ST_Geometry_EQ.html>`_: retourne TRUE si l'étendue de A est la même que celle de B. 
    142142 
    143 `ST_Intersects(geometry_a, geometry_b) <http://postgis.org/docs/ST_Intersects.html>`_: retourne TRUE si l'objet Geometrie/Geography "intersecte spatiallement" - (ont une partie en commun) et FALSE sinon (elles sont dijointes).  
     143`ST_Intersects(geometry_a, geometry_b) <http://postgis.org/docs/ST_Intersects.html>`_: retourne TRUE si la géométrie *a* "intersecte spatialement" la géométrie '*b*- (si elles ont une partie en commun) et FALSE sinon (elles sont disjointes). 
    144144 
    145 .. rubric:: Footnotes 
     145.. rubric:: Notes de bas de page 
    146146 
    147147.. [#RTree] http://postgis.org/support/rtree.pdf 
Note: See TracChangeset for help on using the changeset viewer.