Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
PostgreSQL-Silomodell
Das Silomodell wird implementiert, indem für jeden Mandanten in einer Anwendung eine PostgreSQL-Instanz bereitgestellt wird. Das Silomodell zeichnet sich durch die Leistung der Mieter und die Sicherheitsisolierung aus und eliminiert das Phänomen der lauten Nachbarn vollständig. Das Phänomen Noise Neighbor tritt auf, wenn die Nutzung eines Systems durch einen Mieter die Leistung eines anderen Mieters beeinträchtigt. Mit dem Silomodell können Sie die Leistung speziell auf jeden Mandanten zuschneiden und Ausfälle möglicherweise auf das Silo eines bestimmten Mandanten begrenzen. Was jedoch im Allgemeinen die Einführung eines Silomodells vorantreibt, sind strenge Sicherheits- und regulatorische Einschränkungen. Diese Einschränkungen können durch SaaS-Kunden motiviert werden. Beispielsweise könnten SaaS-Kunden aufgrund interner Einschränkungen verlangen, dass ihre Daten isoliert werden, und SaaS-Anbieter könnten einen solchen Service gegen eine zusätzliche Gebühr anbieten.
Obwohl das Silomodell in bestimmten Fällen notwendig sein kann, hat es viele Nachteile. Es ist oft schwierig, das Silomodell kostengünstig zu verwenden, da die Verwaltung des Ressourcenverbrauchs über mehrere PostgreSQL-Instanzen hinweg kompliziert sein kann. Darüber hinaus macht es die verteilte Natur der Datenbank-Workloads in diesem Modell schwieriger, einen zentralen Überblick über die Mandantenaktivitäten zu behalten. Die Verwaltung so vieler unabhängig betriebener Workloads erhöht den betrieblichen und administrativen Aufwand. Das Silomodell macht das Onboarding von Mandanten auch komplizierter und zeitaufwändiger, da Sie mandantenspezifische Ressourcen bereitstellen müssen. Darüber hinaus kann es schwieriger sein, das gesamte SaaS-System zu skalieren, da die ständig steigende Anzahl mandantenspezifischer PostgreSQL-Instanzen mehr Betriebszeit für die Verwaltung erfordern wird. Eine letzte Überlegung ist, dass eine Anwendung oder eine Datenzugriffsebene eine Zuordnung der Mandanten zu ihren zugeordneten PostgreSQL-Instanzen verwalten muss, was die Implementierung dieses Modells noch komplexer macht.
