Diviser pour mieux gérer

**mister3957** · 16/01/2018, 19h21

Hello,

Je me pose une question :

On a une grosse base de données qui prend très très longtemps à construire, et malgré le tweak niveau config, la désactivation des contraintes d'intégrité et des petites astuces, y'a rien à faire c'est super long.

En revanche on a eu une idée qui consistait à "diviser" les data dans plusieurs bases de données pour les construire séparément, au même schéma bien évidemment mais se pose la question de "comment les regrouper" pour taper dans l'ensemble ?

On peut s'en sortir avec des unions et des dblink mais je n'ai même pas envie d'essayer tellement je pense que ça serait ni élégant, ni performant.

Où peut-être ce n'est pas plusieurs bases qu'il faut mais plusieurs schéma ?

Merci par avance pour vos réponses,

A bientôt

**alassanediakite** · 17/01/2018, 09h47

Salut
Que signifie "construire"

dans ...

Envoyé par mister3957

On a une grosse base de données qui prend très très longtemps à construire

@+

**mister3957** · 18/01/2018, 10h43

Hello,

En fait on part d'une base vide et on a un script qui intègre des données à cette base. Les données étant gigantesques, ils les ont décomposées en "zones". Chaque zone a la même structure, ce ne sont que des subsets de la source de données.

Le process de construction va intégrer une a une ces zones mais au fur et à mesure la base grossie et c'est de plus en plus long.

Donc je me demandait s'il n'y avait pas la possibilité d'intégrer chaque zone dans leur propre base ou schéma, et un "truc" pour les réunir virtuellement, ou une astuce de ce genre de telle manière à ce que les requêtes de consultation puissent taper dedans de manière transparente, comme s'il n'y avait qu'une base / un seul schéma ?

Merci

**ced** · 18/01/2018, 11h11

Bonjour,

J'ai l'impression que ce que vous voulez, c'est ce qu'on nomme du "sharding".
Nativement, ça n'existe pas dans PostgreSQL.
Il faudrait regarder du côté de produits comme Citus (pour rester dans le monde PostgreSQL).