Vous n'êtes pas identifié(e).
Bonjour tout le monde,
J'ai effectué et continue d'effectuer des recherches dans les répertoires Installation et Optimisation de ce forum, voire même ailleurs. Cependant je n'ai pas trouvé réponse à ma question qui est la suivante:
Est-il possible de réduire le poids des tables dans PostgreSQL ?
Avant de me lancer dans le SGBD, j'avais lu un retour d'utilisateur indiquant que des données stockées dans une base de données PostgreSQL voyaient leur poids réduit.
Aujourd'hui je travaille avec un base PostgreSQL dont je découvre l'installation, faîte antérieurement à mon arrivée. Je constate que le poids des tables n'est pas moindre que lorsqu'elle se trouve sauvegardée en shape file (il s'agit de données géographiques). Le poids est même supérieur dans PostgreSQL du fait de l'index et de la table TOAST qui s'ajoutent.
Auriez-vous une solution, des points sur lesquels m'éclairer? De mes lectures j'ai relevé deux éléments importants, l'un est le tablespace. Une base avec des tablespaces bien organisés exécute les traitements avec beaucoup plus d'efficacité. Un paramètre important donc, mais il n'est pas fait allusion au poids de la donnée. Le second point est le partitionnement des tables, qui lui aussi semble améliorer les traitements.
Rémi
Hors ligne
Une solution, non, parce que ça manque de détails.
Le fait que la donnée externe soit plus ou moins grosse que la donnée interne ne veut rien dire. Pour prendre un exemple simple, si vous prenez une colonne de type integer, une valeur sera stockée de façon binaire, soit sous la forme de 4 octets alors que la donnée sur un fichier pèsera 1 ocotet si sa valeur est inférieure à 10 et pourrait peser beaucoup plus dans le cas contraire (par exemple 9 octets pour une valeur 1000000). Bref, tout dépend des représentations interne et externe.
De toute façon, par défaut, et assez logiquement, PostgreSQL essaiera de stocker les données de la façon la plus efficace.
La vraie question est plutôt : quel problème avez-vous ? manque d'espace disque ?
Guillaume.
Hors ligne
Merci pour ce premier retour.
Le problème que je rencontre est effectivement celui du manque d'espace disque. J'essaie avec la documentation de comprendre les requis à une bonne installation PostgreSQL et de savoir comment mon instance a été installée vis-à-vis de ces conseils. A cet effet j'ai exécuté la commande pg_settings, qui me semble être une première piste.
Pour reprendre votre explication ci-dessus. Si j'ai bien compris, vous voulez dire qu'on peut s'attendre à ce que la représentation de Postgre soit plus efficace que d'autres, notamment pour des données à valeurs importantes?
En examinant d'autres tables, je remarque effectivement des différences de poids entre intérieure et extérieure. La mauvaise surprise est que ces différences sont rarement en faveur de Postgre.
Hors ligne
Pour reprendre votre explication ci-dessus. Si j'ai bien compris, vous voulez dire qu'on peut s'attendre à ce que la représentation de Postgre soit plus efficace que d'autres, notamment pour des données à valeurs importantes?
Non, c'était juste un exemple pour montrer qu'on ne peut pas faire de relation entre taille des données à l'extérieur et à l'intérieur de PostgreSQL. On devrait voir le même comportement pour les autres moteurs de bases de données.
La seule raison réelle pour laquelle PostgreSQL prendrait plus de place que "normal", c'est si les tables sont fragmentées. Une défragmentation se fait un exécutant un VACUUM FULL sur la base. Attention, cette opération pose un verrou exclusif sur les objets à défragmenter, donc considérez que votre serveur ne sera pas disponible pendant l'opération. De plus, elle réécrit toutes les données. Donc 1. il faut que vous ayez la place nécessaire sur disque. 2. ça prendra du temps (d'autant plus de temps que la volumétrie est importante). Il faut donc être certain que le serveur ne sera pas utilisé plus d'un certain temps. Le résultat de cette défragmentation dépend évidemment de la fragmentation des tables et index. S'ils le sont peu, vous gagnerez peu. Et vice versa.
C'est le truc le plus simple (et certainement le plus efficace) pour récupérer de la place.
Guillaume.
Hors ligne
D'accord, je comprends. Je vais effectuer cette opération et constater les éventuels changements.
Quand vous me demandiez la raison du problème, la manque d'espace disque. Vous pensiez à un autre paramètre important que celui du Vacuum ?
Hors ligne
Non, pas particulièrement. Je cherche juste à comprendre le problème initial.
Guillaume.
Hors ligne
Vous devriez probablement mettre en place de la supervision afin de voir l'évolution de l'espace disque cans le temps, et être alerté en cas de risque de saturation.
Julien.
https://rjuju.github.io/
Hors ligne
Merci à tous les deux. Je vais prendre davantage de renseignements durant le mois. Si jamais je viens à buter sur des éléments je relancerai ce topic.
Bonne journée.
Hors ligne
Le problème est que la compression systématique des LOBs avec TOAST joue en votre défaveur sur les données spatiales, car le contenu des données spatiale est assez aléatoire ce qui fait que le volume augmente légèrement au lieu de diminuer. Et il n'y a aucun moyen de désactiver TOAST, à moins de recoder le moteur PostgreSQL… (vous pouvez le faire!!!).
De plus PostgreSQL ne supporte pas la compression des données des tables et des index que l'on trouve dans d'autres SGBDR comme Microsoft SQL Server… ce qui permettrait de réduire considérablement le volume des autres données purement relationnelles.
Bref, PostgreSQL c'est double peine ! Compression obligatoire des LOBs, parfois inutile et contre-performantes pour certaines données, et impossibilité de compresser les autres données !
A +
Dernière modification par SQLpro (16/03/2020 17:27:30)
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Le problème est que la compression systématique des LOBs avec TOAST joue en votre défaveur sur les données spatiales, car le contenu des données spatiale est assez aléatoire ce qui fait que le volume augmente légèrement au lieu de diminuer. Et il n'y a aucun moyen de désactiver TOAST, à moins de recoder le moteur PostgreSQL… (vous pouvez le faire!!!).
c'est faux
Bref, PostgreSQL c'est double peine ! Compression obligatoire des LOBs, parfois inutile et contre-performantes pour certaines données, et impossibilité de compresser les autres données !
c'est également faux.
Je vous conseille de commencer par lire le manuel avant de raconter des inepties. Merci.
Julien.
https://rjuju.github.io/
Hors ligne
