Avantages et inconvénients de l'utilisation de nombreux schémas dans PostgreSQL par opposition à un seul?

Pour une grande application SAAS (soutenue par PostgreSql 9.4), avec plus de 300 000 comptes (et en pleine croissance), quels sont les avantages et les inconvénients de l'utilisation d'un schéma par compte pour partitionner les données par rapport à la mise en place de toutes les données dans un seul schéma et l'utilisation de clés étrangères pour le partitionner dans les requêtes?

Je sais que dans le passé, pg_dump était douloureusement lent lors de l'utilisation de nombreux schémas, mais je ne sais pas si c'est le cas aujourd'hui. Je suis également conscient que tout changement dans la structure de la base de données devra être effectué sur tous les schémas. Et je sais que du côté positif, le déplacement d'un schéma d'un serveur physique à un autre est facile, ainsi que la restauration d'un schéma à partir d'une sauvegarde, sans oublier qu'il est logique de partitionner les données de cette façon.

Alors, quels sont les avantages et les inconvénients qui me manquent?

— Harel
source

Aucun n'a l'air bien. Une seule table gigantesque ("croissance verticale") est difficile à gérer et un grand nombre de schémas ("croissance horizontale") sont également difficiles à gérer.

— Daniel Vérité

Je reconstruis un ancien système qui a ce nombre de comptes (et encore plus d'utilisateurs). Il utilise une approche partagée (en utilisant mySql) et fonctionne très bien en termes de performances. Mon souci est de maintenir ce niveau de performance mais d'y ajouter la maintenabilité.

— Harel

@Harel Je suis curieux, l'avez-vous essayé avec des schémas 400k ou êtes-vous passé à une autre architecture / technologie?

— sthzg

J'ai abandonné l'idée après y avoir approfondi. La quantité de schémas que j'allais créer annulerait toute utilisation pratique de cela. Je suis allé avec le bon ancien champ d'ID de compte dans chaque enregistrement. Ce que j'ai également fait, c'est de supprimer les identifiants d'incrémentation numérique en faveur des UUID, ce qui signifie que je peux facilement prendre un compte entier d'une base de données à une autre sans avoir à craindre de briser l'intégrité.

— Harel

De toute évidence, vous traitez avec les mêmes tables dans chaque schéma utilisateur. Avez-vous envisagé l' héritage pour cela? Il peut vous donner le meilleur des deux mondes pour certains cas d'utilisation. Il existe également certaines limitations . Vous pouvez avoir un schéma séparé pour chaque utilisateur et toujours rechercher toutes les tables d'utilisateurs à la fois très facilement.

En relation:

En dehors de cela, au moins l'octroi / la révocation de privilèges doit être mentionné, ce qui est beaucoup plus simple avec des schémas séparés.

— Erwin Brandstetter
source

Je vais examiner l'héritage. Cependant, ma préoccupation concerne l'échelle ici. Partout où je lis, les gens parlent de stratégie de schéma à locataires multiples mais font référence à des dizaines, des centaines ou des milliers de schémas. Un endroit a mentionné les schémas 20K. La question est - les schémas 400K sont-ils trop? Cela provoquera-t-il une folie des descripteurs de fichiers et tuera-t-il le serveur? Suis-je le pousser?

— Harel

De plus, j'avais l'intention de conserver les données des locataires (comptes et utilisateurs) dans le schéma public, tout en conservant les schémas eux-mêmes en tant que données utilisateur réelles. Ces données ne sont pas et ne seront jamais partagées entre les schémas.

— Harel

L'héritage ne m'aidera pas ici, je ne pense pas. L'approche partagée utilise un schéma unique avec des clés étrangères obligatoires pour l'utilisateur ou le locataire, donc rien à gagner de l'héritage, je le crains.

— Harel

De cet article influitive.io/… je pense que le mode multi-schéma n'est pas un bon moyen pour les locataires de grand nombre. La colonne tenant_id (l'ancienne méthode) vient mieux.

— Xiaohui Zhang