Postgre/hibernate: une base avec 2 schemas ou 2 bases avec 1 schema ?

Le
Lionel
Bonjour,

J'ai une appli web java/hibernate qui attaque une base de données postgre
8.3 contenant env 10millions de lignes par an (150Mo/dump).
Je vais devoir faire une autre base possédant exactement la meme structure
mais contenant d'autres données (volumétrie identique) et attaquer l'une ou
l'autre de ces bases selon le login de l'utilisateur.

Seule contrainte: la gestion de tous les utilisateurs doit se faire dans une
seule base.

Je vois 2 possibilités:

1) deux bases de données

Je configure 2 datasources différents pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le
hibernate.connection.datasource
et je choisis le bon en fonction du login à chaque requete http.
avantages: impossible de se tromper de schema lorsque l'on lance une
requete, dump/restore d'une seule base à la fois, rien à faire si un jour il
fallait séparer les 2 bases (une simple recopie des utilisateurs)
inconvenient: 2 bases à gérer, obligation de faire une verrue pour la
gestion des utilisateurs car le 2e datasource verra une table d'utilisateurs
vide.

2) une base de données avec 2 schemas

Je configure un seul datasource pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le
hibernate.default_schema et je choisis le bon en fonction du login à chaque
requete http.
avantage: un seul pool de connexion, une seule base à gérer
(dump/restore,), il me suffit de forcer le schema public sur la table des
utilisateurs pour que leur gestion soit transparente depuis l'appli
inconvénient: perf des dump/restore vu que je suis obligé de travailler sur
les 2 bases en meme temps.


D'après vous, quelle est la meilleure solution tant d'un point de vue SGBD
que java ?

Suivi positionné sur fcas.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fred Brouard - SQLpro
Le #21893011
Lionel a écrit :
Bonjour,

J'ai une appli web java/hibernate qui attaque une base de données postgre
8.3 contenant env 10millions de lignes par an (150Mo/dump).
Je vais devoir faire une autre base possédant exactement la meme structure
mais contenant d'autres données (volumétrie identique) et attaquer l'une ou
l'autre de ces bases selon le login de l'utilisateur.

Seule contrainte: la gestion de tous les utilisateurs doit se faire dans une
seule base.

Je vois 2 possibilités:

1) deux bases de données

Je configure 2 datasources différents pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le
hibernate.connection.datasource
et je choisis le bon en fonction du login à chaque requete http.
avantages: impossible de se tromper de schema lorsque l'on lance une
requete, dump/restore d'une seule base à la fois, rien à faire si un jour il
fallait séparer les 2 bases (une simple recopie des utilisateurs)
inconvenient: 2 bases à gérer, obligation de faire une verrue pour la
gestion des utilisateurs car le 2e datasource verra une table d'utilisateurs
vide.

2) une base de données avec 2 schemas

Je configure un seul datasource pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le
hibernate.default_schema et je choisis le bon en fonction du login à chaque
requete http.
avantage: un seul pool de connexion, une seule base à gérer
(dump/restore,...), il me suffit de forcer le schema public sur la table des
utilisateurs pour que leur gestion soit transparente depuis l'appli
inconvénient: perf des dump/restore vu que je suis obligé de travailler sur
les 2 bases en meme temps.


D'après vous, quelle est la meilleure solution tant d'un point de vue SGBD
que java ?

Suivi positionné sur fcas.



Difficile à dire sans donner une volumétrie... Si l'on reste dans la
catégorie des petites bases, c'est à dire moins de 100 Go, alors une
seule base sera plus intéressant car cela va minimiser le cache. En
effet chaque base ouverte consomme du cache afin de monter en mémoire
des objets systèmes : table des tables, des colonnes, des vues, des
utilisateurs, des privlèges... Et deux bases cela veut dire un cache
plus encombré...

D'un autre côté deux bases permet de séparer physiquement les données
dans 2 fichiers différents et si le volume est important de mettre la
seconde base sur un autre serveur.
C'est ce que je ferais si nous somme dans le cas de bases pouvant
évoluer à la grosse base (entre 100 Go et 1 To).

Cela dit, il me semble que PostGreSQL sait depuis peu gérer différents
espaces de stockage des données ce qui fait que vous pouvez utiliser une
solution qui consiste à associer aux deux schémas SQL deux espaces de
stockage différents. Inestiguer dans cette voie, car sur les gros SGBD
comme SQL Server, oracle ou IBM DB2 il est possible de faire des
sauvegardes partielles des espaces de stockage et donc de ne plus avoir
"d'effet convoi" dans le cas de la sauvegarde/restauration.


A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
helios services
Le #21893001
Fred Brouard - SQLpro a écrit :
Lionel a écrit :
Bonjour,

J'ai une appli web java/hibernate qui attaque une base de données
postgre 8.3 contenant env 10millions de lignes par an (150Mo/dump).
Je vais devoir faire une autre base possédant exactement la meme
structure mais contenant d'autres données (volumétrie identique) et
attaquer l'une ou l'autre de ces bases selon le login de l'utilisateur.

Seule contrainte: la gestion de tous les utilisateurs doit se faire
dans une seule base.

Je vois 2 possibilités:

1) deux bases de données

Je configure 2 datasources différents pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le
hibernate.connection.datasource
et je choisis le bon en fonction du login à chaque requete http.
avantages: impossible de se tromper de schema lorsque l'on lance une
requete, dump/restore d'une seule base à la fois, rien à faire si un
jour il fallait séparer les 2 bases (une simple recopie des utilisateurs)
inconvenient: 2 bases à gérer, obligation de faire une verrue pour la
gestion des utilisateurs car le 2e datasource verra une table
d'utilisateurs vide.

2) une base de données avec 2 schemas

Je configure un seul datasource pour tomcat.
J'initialise 2 sessionFactories hibernate en changeant juste le
hibernate.default_schema et je choisis le bon en fonction du login à
chaque requete http.
avantage: un seul pool de connexion, une seule base à gérer
(dump/restore,...), il me suffit de forcer le schema public sur la
table des utilisateurs pour que leur gestion soit transparente depuis
l'appli
inconvénient: perf des dump/restore vu que je suis obligé de
travailler sur les 2 bases en meme temps.


D'après vous, quelle est la meilleure solution tant d'un point de vue
SGBD que java ?

Suivi positionné sur fcas.



Difficile à dire sans donner une volumétrie... Si l'on reste dans la
catégorie des petites bases, c'est à dire moins de 100 Go, alors une
seule base sera plus intéressant car cela va minimiser le cache. En
effet chaque base ouverte consomme du cache afin de monter en mémoire
des objets systèmes : table des tables, des colonnes, des vues, des
utilisateurs, des privlèges... Et deux bases cela veut dire un cache
plus encombré...




grande découverte que 2 c'est plus que 1 ; c'est vrai que quand on
prétend arriver à mettre plus que 65536 valeurs dans deux octets c'est
une grande découverte que 2 est plus grand que 1


D'un autre côté deux bases permet de séparer physiquement les données
dans 2 fichiers différents et si le volume est important de mettre la
seconde base sur un autre serveur.



autre grande découverte que 2 c'est deux fois 1 bientot on va pouvoir
aborder un concept plus difficile le 3 :-)


--
Dr Thierry HOLZ
HELIOS SERVICES
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Publicité
Poster une réponse
Anonyme