Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Modèle de silo PostgreSQL
Le modèle de silo est mis en œuvre en fournissant une instance PostgreSQL pour chaque locataire d'une application. Le modèle de silo excelle en termes de performance des locataires et d'isolation en matière de sécurité, et élimine complètement le phénomène des voisins bruyants. Le phénomène du voisinage bruyant se produit lorsque l'utilisation d'un système par un locataire affecte les performances d'un autre locataire. Le modèle de silo vous permet d'adapter les performances spécifiquement à chaque locataire et de limiter éventuellement les pannes au silo d'un locataire spécifique. Cependant, ce qui motive généralement l'adoption d'un modèle de silo, ce sont les contraintes réglementaires et de sécurité strictes. Ces contraintes peuvent être motivées par les clients SaaS. Par exemple, les clients SaaS peuvent exiger que leurs données soient isolées en raison de contraintes internes, et les fournisseurs SaaS peuvent proposer un tel service moyennant des frais supplémentaires.
Bien que le modèle de silo puisse être nécessaire dans certains cas, il présente de nombreux inconvénients. Il est souvent difficile d'utiliser le modèle de silo de manière rentable, car la gestion de la consommation de ressources sur plusieurs instances de PostgreSQL peut s'avérer complexe. En outre, la nature distribuée des charges de travail des bases de données dans ce modèle rend plus difficile le maintien d'une vue centralisée de l'activité des locataires. La gestion d'un si grand nombre de charges de travail indépendantes augmente les frais opérationnels et administratifs. Le modèle en silo complique également l'intégration des locataires et leur fait perdre du temps, car vous devez fournir des ressources spécifiques aux locataires. En outre, l'ensemble du système SaaS peut être plus difficile à faire évoluer, car le nombre toujours croissant d'instances PostgreSQL spécifiques aux locataires demandera plus de temps opérationnel à administrer. Une dernière considération est qu'une application ou une couche d'accès aux données devra maintenir un mappage des locataires avec leurs instances PostgreSQL associées, ce qui complique encore la mise en œuvre de ce modèle.
