Quand ne devez-vous PAS utiliser un index spatial?

Je pose cette question parce que je travaillais principalement avec Oracle mais depuis un an j'ai doublé avec PostGIS et SQLServer 2008. La plupart des fonctions spatiales d'Oracle ne fonctionneront pas sans un index spatial renvoyant l'erreur ORA-13226:

13226, 00000, "interface non prise en charge sans index spatial" // * Cause: la table de géométrie n'a pas d'index spatial. // * Action: Vérifiez que la table de géométrie référencée dans l'opérateur spatial possède un index spatial.

Pour moi, cela a du sens. Vous exécutez une requête spatiale = vous devez avoir un index spatial. Mais d'après ce que je comprends, ni PostGIS ni SQL Serve ne l'exigent. PostGIS semble même avoir des fonctions (_ * par exemple _STContains) qui EXPLICITEMENT n'utiliseront pas l'index spatial.

La question est donc: y a-t-il des cas où vous ne devriez PAS utiliser d'index spatial?. Pas nécessairement s'il s'agit d'une approche «à prendre ou à laisser», c'est-à-dire que cela ne fera aucune différence, mais où NE PAS utiliser l'indice spatial améliorera les performances? Pour moi, la dernière phrase est une contradiction en termes, mais sinon pourquoi PostGIS fournirait ces fonctions?

mapoholic,

De manière générale, il n'y a aucune raison de faire une requête spatiale sans index spatial, sauf si vous avez affaire à de très petites tables. Bien que vous utilisiez le ST_ qui n'utilise pas d'index mais qui a les opérateurs de boîte de court-circuit indexables &&. les fonctions commençant par _ST ne sont pas destinées à être utilisées par les utilisateurs finaux. La raison pour laquelle ils existent est qu'ils doivent le faire. Les index spatiaux PostGIS utilisent l'incrustation SQL pour forcer l'utilisation de l'index - le _ST est généralement effectué par GEOS et le && est l'index qui peut être réorganisé. Les _ST sont donc vraiment un artefact d'implémentation.

donc en bref, ce n'est pas une fonction pour que l'opération d'index puisse être réorganisée pour se produire en une seule fois avant la vérification spatiale plus intense.

Si votre jeu de données est souvent ajouté et mis à jour, les instructions INSERT, DELETE et UPDATE qui provoquent la reconstruction de l'index peuvent ralentir la base de données.

Pour les insertions en masse, telles que le chargement de l'ensemble de données OSM dans une base de données, il peut être plus rapide de supprimer les index et de les recréer par la suite.

S'il est plus efficace d'ignorer un index (par exemple, la table est suffisamment petite pour être chargée en mémoire), le processeur de requêtes de base de données doit le faire automatiquement.

Je m'attends à ce que la raison principale pour autoriser l'exécution de requêtes sans index spatial est de mesurer les avantages de performances que vous obtenez en utilisant un index, sans avoir à le supprimer.

Enfin, si vous souhaitez augmenter considérablement les performances des requêtes et des affichages de cartes, vous souhaiterez peut-être retarder la création d'index à un moment opportun dans le développement du système ...

Je pense que cela est implicite, mais je n'utiliserais PAS d'index spatial pour une requête lorsque j'avais un index non spatial que je pourrais utiliser à la place. Par exemple, j'ai 2 113 450 points qui couvrent les États-Unis chargés dans une table. Si je voulais extraire tous les points qui se trouvaient dans l'état de l'Alaska, je pouvais soit faire une requête spatiale qui utilisait l'index GIST sur les géométries de points pour comparer avec la géométrie de l'état de l'Alaska, OR, je pourrais simplement utiliser le champ "state_alpha" dans les données de point (qui est également indexé) pour retourner tous les points qui ont "state_alpha" = 'AK'.

"Où est la partie spatiale de cela", demandez-vous? Eh bien, si j'ai besoin de faire une analyse spatiale supplémentaire sur les Alaska_points après les avoir collectés, il est plus rapide de rassembler ces géométries de points en utilisant d'abord une requête non spatiale. Cela signifie également que pour les ensembles de données vraiment volumineux, vous bénéficiez de l'ajout d'un champ de recherche (ou table). Encore une fois, je sais que cela est probablement évident pour tout le monde déjà, je ne le mentionne que parce que je l'ai rencontré dans le passé avec des ensembles de données globales qui n'étaient indexées que spatialement, et où une requête commune était "toutes les fonctionnalités d'un pays". Nous avons gagné beaucoup de performances en ajoutant un champ country_fips indexé.

Voici quelques résultats de EXPLAIN ANALYZE qui prouvent le point. (REMARQUE: j'ai essayé de rendre la requête spatiale aussi efficace que possible en utilisant une requête BBOX. L'utilisation des contours d'état ne l'aurait fait que plus lentement.)

# explain analyze select count(*) from gnis_names where state_alpha = 'AK';
Aggregate  (cost=57359.45..57359.46 rows=1 width=0) (actual time=76.606.. 76.607 rows=1 loops=1)
<snip>
Total runtime: 76.676 ms

# explain analyze select count(*) from gnis_names where the_geom && GeomFromText('POLYGON((-179.14734 51.219862,-179.14734 71.3525606439998,179.77847 71.3525606439998,179.77847 51.219862,-179.14734 51.219862))',4326);
Aggregate  (cost=27699.86..27699.87 rows=1 width=0) (actual time=86.523..86.524 rows=1 loops=1)
<snip>
Total runtime: 86.584 ms 

Je viens de remarquer cette déclaration

Pour moi, cela a du sens. Vous exécutez une requête spatiale = vous devez avoir un index spatial

Pour moi, cela n'a aucun sens et je pense que SQL Server et Postgis font un meilleur travail ou du moins ne vous dérangent pas avec les détails des performances. En fait, SQL Server et Postgis n'utilisent parfois même pas du tout l'index spatial (revenir à l'analyse complète de la table).

Pour Oracle, vous devez créer l'index et, par conséquent, vous devez remplir user_sdo_geom_metadata.

Il suffit de comparer cela avec des index alphanumériques, ils sont là pour des raisons de performances, votre instruction SQL devrait fonctionner avec et sans elle.

Dans une base de données Oracle, supprimez l'index et vous obtiendrez de nombreuses erreurs et applications qui ne pourront pas utiliser les requêtes spatiales, donc ne fonctionneront pas.