Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je suis en train d'écrire le MCD d'un site qui sera sur PostgreSql (une première pour moi)
J'ai une table qui sera conséquente, je souhaite donc faire du partionnement vertical.
Je ne trouve pas la meilleure solution à appliquer.
Dois-je le faire identiquement à du partionnement horizontal ? (une table maître vide avec des sous tables ayant chacune des colonnes propres)
Ou dois-je utiliser l'héritage ? (une table maître avec certaines données et une table fils avec le reste des données)
Ou encore, peut-être qu'il existe une autre notion sous postgre dont je n'ai pas connaissance ?
Merci de votre aide
Hors ligne
Le partitionnement avec PostgreSQL passe par l'héritage.
Cependant, qu'est-ce que vous appelez "conséquent" ? quelle volumétrie aurait-elle ? en nombre de lignes et en octets ?
Guillaume.
Hors ligne
Le partitionnement avec PostgreSQL passe par l'héritage.
Cependant, qu'est-ce que vous appelez "conséquent" ? quelle volumétrie aurait-elle ? en nombre de lignes et en octets ?
Je vais me permettre de vous retourner la question 
A partir de combien de Go est-il intéressant de passer sur du partionning ?
Si ça dépends, etc... je vais calculer tout ça...
Hors ligne
Le partitionnement est surtout intéressant quand la clé de partitionnement est utilisée sur la très grande majorité des requêtes. Sans vraie clé de partitionnement, peu importe la volumétrie.
Guillaume.
Hors ligne
Voilà le contexte :
J'ai une table d'utilisateurs avec une vingtaine de colonnes, on table sur 2M d'enregistrements.
Ce qui m'embête c'est d'avoir à taper dans cette lorsque l'on ira vérifier le password ou que l'on récupérera les informations de session. Je voulais donc créer une table annexe "légère" avec 4 colonnes, cette table sera utilisée pour 90% des requêtes utilisateurs.
Hors ligne
Les optimisations préventives sont rarement adéquates. De plus, 2 millions d'enregistrements, c'est rien. Pour vérifier le mot de passe, vous passerez selon toute probabilité par un index unique (clé primaire par exemple), donc il n'y a pas de raison que cela soit lent.
Mon conseil : n'envisagez pas le partitionnement tant que vous n'avez pas la preuve d'en avoir réellement besoin.
Guillaume.
Hors ligne
M c'est pour millions ou milliards ?
Avez vous essayé d'estimer sa taille en octets ?
Ramener un enregistrement coûtera à peu près pareil que l'enregistrement soit gros ou petit: il faudra aller lire un (ou plusieurs) blocs d'index, et un bloc de données. Si un enregistrement est tellement gros qu'il dépasse un bloc, le moteur, de lui même, stocke les grosses colonnes hors de la table principale (c'est un mécanisme appelé TOAST sous Postgres).
Donc le seul intérêt de sortir les données de la table, c'est si vous voulez être sûr que la table d'utilisateurs tienne en très grande partie en cache, afin d'éliminer les entrées/sorties disque. Mais vous êtes en train d'optimiser et de complexifier avant d'avoir mal, à mon avis.
Marc.
Hors ligne
Pages : 1
