Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je suis en 4ème année à polytech'Nantes et pour notre projet transversal nous avons à développer une base de donnée spatiale. Nous avons donc utilisé PostGIS et pour créer l'architecture de la base nous avons plusieurs questions :
- Quelles sont les limites des tables postgre (nombre de lignes, nombre de colonnes, taille de la base) ?
- Est-il préférable (au niveau du temps d'execution des requètes) d'avoir une table contenant des millions voire des milliards d'enregistrements ou bien de fractionner cette table en plusieurs centaines (voire des milliers) de tables (en sachant que l'on devra accèder à la plupart des tables pour certaines requètes). En gros est-ce que le partitionnement de tables affecte le temps d'éxécution ?
merci d'avance
Hors ligne
- Quelles sont les limites des tables postgre (nombre de lignes, nombre de colonnes, taille de la base) ?
La taille d'une base est illimitée. Le nombre de lignes est illimité.
Par contre, le nombre de colonne dépend du type des colonnes. Cela varie généralement entre 250 et 1600.
Voici les limites connues (d'après la FAQ de PostgreSQL) :
* Taille maximum pour une base de données : illimitée (il existe des bases de 32 To)
* Taille maximum pour une table : 32 To
* Taille maximum pour une ligne : 1,6 To
* Taille maximum pour un champ : 1 Go
* Nombre maximum de lignes dans une table : illimité
* Nombre maximum de colonnes dans une table : de 250 à 1600, selon le type de colonnes
* Nombre maximum d'index sur une table : illimité
- Est-il préférable (au niveau du temps d'execution des requètes) d'avoir une table contenant des millions voire des milliards d'enregistrements ou bien de fractionner cette table en plusieurs centaines (voire des milliers) de tables (en sachant que l'on devra accèder à la plupart des tables pour certaines requètes). En gros est-ce que le partitionnement de tables affecte le temps d'éxécution ?
Il l'affecte à coup sûr. Mais plutôt dans le bon sens, vu que l'optimiseur sait quand il peut parcourir que certaines des tables. Par contre, un fractionnement sur plusieurs milliers de tables n'a aucun sens, quelque soit le SGBD considéré. Pourquoi autant de tables ?
Guillaume.
Hors ligne
On va sauvegarder dans les tables les positions des personnes, machines, etc... à des temps réguliers (de l'ordre de la seconde, minute, on ne sais pas encore). Donc au bout de quelques jours, mois, années, on obtiendra beaucoup d'enregistrements.
Si on considère un bâtiment qui contient des centaines de personnes et autant de machines, si on enregistre chaque position de chaque objet dans une seule table cela donnera une table gigantesque, sinon si on crée une table pour chaque objet, on obtient plus d'une centaines de table.
Mais il peut y avoir des requêtes du style : "afficher la position de tous les objets avant hier à telle heure" et là du coup on doit accéder à toutes les tables si on a partitionné.
On a aussi pensé à créer des tables non pas pour chaque objet mais plutôt des tables par types d'objet, ici ça nous reviendrais à deux tables (personnes, machines).
Donc qu'est-ce qui est plus performant ?
- Un nombre de tables réduites, avec les objets organisés par type, en sachant qu'il y aura beaucoup d'enregistrements dans chaque table
- Une table par objets, avec beaucoup moins d'enregistrements dans chacune d'elles, mais avec parfois des requêtes qui auront besoin d'accéder à tous les objets
Hors ligne
Pour améliorer des performances, il s'agit principalement d'améliorer la rapidité des requêtes les plus fréquentes. Donc si vous avez une majorité de requêtes qui filtrent par rapport à une heure, il vaut mieux faire la partition par rapport à la date et l'heure de l'événement. Si par contre vous avez une majorité de requêtes qui filtrent par type d'objet, il y a de fortes chances qu'une partition par type d'objet est plus adéquate. Etc.
Ensuite, l'échelle du partitionnement (c'est-à-dire, prenons l'exemple du cas de la date et l'heure de l'évenement, faut-il partitionner par jour/semaine/mois/trimestre/année/etc), ça dépend du volume de données considéré. Et ce volume se mesure, non pas en nombre de lignes, mais en taille disque. Une partition de 10 Go doit être considérée comme un maximum à éviter.
Guillaume.
Hors ligne
Pages : 1
