Connaissance de vos données
Lorsque vous créez une solution point-in-polygon, il est important de comprendre comment vos données affecteront les performances et la sélection de l'opération Spectrum à utiliser, ainsi que certains des facteurs de limitation de vos données.
Où se trouvent vos données ? Il est important de savoir où se trouvent vos données et le type de données dont vous allez disposer pour votre solution. Par exemple, le fait d'avoir des fichiers TAB sur le système de fichiers ou des données dans un DBMS modifie les performances de votre opération. Spectrum délègue le traitement de certaines opérations (jointures spatiales) à la base de données (par exemple, Oracle ou SQL Server), ce qui améliore vos performances. Par exemple, des opérations comme la suivante :
Select a.id, b.id from flood_plane a, customers b where MI_Contains(a.geom, b.geom)Quel est le format de géométrie ? Il existe une différence de performances lors de l'utilisation d'un format de géométrie natif MapInfo et celle d'un fichier au format x/y (par exemple, un fichier CSV avec des valeurs de lat/long). Pour améliorer les performances, pensez à utiliser un format x/y au lieu de format de géométrie natif MapInfo.
Vos données sont-elles statiques ou changent-elles ? Si vous savez que (tout ou partie de) vos données ne changent pas et que vous utilisez l'opération Query Spatial Data, il existe une option de configuration lors de la création de vos ressources nommées qui peut considérablement améliorer les performances. Dans Spectrum, on l'appelle la volatilité. Par défaut, la volatilité de toutes les ressources est définie sur true. Cela signifie que Spectrum part du principe que toutes les données peuvent changer à tout moment et qu'il doit vérifier les données chaque fois qu'il y a accès, pour déterminer si elles ont changé et décider s'il est nécessaire de charger les nouvelles données.
Comment la volatilité affecte-t-elle les opérations point-in-polygon ? Si la volatilité est définie sur true, et même si la source de données n'a pas changé, le simple fait de vérifier la ressource a un impact négatif sur les performances. Si vous savez que vos données ne vont pas changer et que vous avez besoin d'un système performant, désactivez la volatilité. Si les performances sont un problème, et que vous savez qu'une partie de vos données vont changer (par exemple, des listes de clients ou des points de sondage), mais que d'autres ne vont pas changer (par exemple, des parcelles, des terrains ou des secteurs commerciaux), assurez-vous que la volatilité est désactivée sur autant de données statistiques que possible. Cela augmente les performances. Pour plus d'informations sur la volatilité et sur la façon de modifier ce paramètre pour les ressources, reportez-vous à la section Volatilité de la source de données.
Utilisez-vous des fichiers TAB ? Lorsque vous utilisez des fichiers TAB, vous avez la possibilité de conserver un pool de descripteurs de fichiers ouverts afin d'éviter les frais d'ouverture et de réouverture à chaque lecture de fichier. Spectrum Spatial utilise le pool de descripteurs de fichiers pour les fichiers TAB natifs dont le paramètre de volatilité est défini sur false. Les fichiers TAB natifs incluent les fichiers TAB natifs Extended et Seamless. Toutes les tables du référentiel Spectrum Spatial sont, par défaut, volatiles (true). La volatilité des fichiers TAB natifs signifie que le schéma peut changer à tout moment. Pour tirer parti de cette amélioration des performances, définissez le paramètre de volatilité sur false dans Spatial Manager. En règle générale, la définition du paramètre de volatilité sur false est recommandée si les données sont modifiées uniquement à des périodes connues ou si elles ne le sont pas du tout.
Le pool de descripteur de fichiers est activé par défaut. Pour le désactiver, accédez à \server\modules\spatial\pool-tab.properties et définissez tab.cache.enabled sur false. Pour le paramètre prenne effet, vous devez redémarrer le serveur.
Configuration du pool de descripteur de fichier est effectuée via le fichier tab-fichier-handle-pool.properties, également situé dans le dossier \server\modules\spatial. Parmi les propriétés figurent le nombre maximal de descripteurs pouvant être alloués au pool (maxTotal), le nombre maximal de descripteurs alloués par fichier (maxTotalPerKey) et la durée minimale pendant laquelle un descripteur de fichier peut résider dans le pool sans être utilisé avant d'être fermé (minEvictableIdleTimeMillis).
Pour les tables logiques, il existe une formule générale pour maximiser les performances du pool de descripteurs de fichiers. Plus précisément, vous devez calculer le nombre maximal de descripteurs à allouer au pool (maxTotal). Pour calculer la valeur maxTotal, procédez comme suit :
- Recherchez la table logique contenant le plus grand nombre de sous-tables et notez le nombre de sous-tables (#ofsub-tables).
- Déterminez le nombre de threads que vous utilisez (#ofthreads).
- La formule est (3 + (3 x #ofsub-tables)) x #ofthreads = maxTotal. Si vos tables logiques ne comportent pas de fichiers .ind, la formule est (2 + (2 x #ofsub-tables)) x #ofthreads = maxTotal.
Par exemple, si vous utilisez la table USA logique toute entière, il existe des fichiers .ind, 54 sous-tables et vous utilisez 8 threads. Le calcul de maxTotal est (3 + (3 x 54)) x 8 = 1320.