Postgre/hibernate: une base avec 2 schemas ou 2 bases avec 1 schema ?
2 réponses
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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred Brouard - SQLpro
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 *************************
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 *************************
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
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
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
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
