View a markdown version of this page

SaaS-Datenpartitionierungsmodelle - AWS Präskriptive Leitlinien

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.

SaaS-Datenpartitionierungsmodelle

Eine der Herausforderungen für SaaS-Entwickler besteht darin, Architekturmuster für die Darstellung und Organisation von Daten in einer Mehrmandantenumgebung zu entwerfen. Diese mehrinstanzenfähigen Speichermechanismen und -muster werden in der Regel als Datenpartitionierung bezeichnet.

In einer SaaS-Umgebung mit mehreren Mandanten ist es wichtig, zwischen Datenpartitionierung und Mandantenisolierung zu unterscheiden. Diese Konzepte sind zwar verwandt, aber nicht synonym. Datenpartitionierung bezieht sich auf die Methode zum Speichern von Daten für jeden Mandanten. Die Partitionierung allein garantiert jedoch keine Mandantenisolierung. Zusätzliche Maßnahmen sind erforderlich, um sicherzustellen, dass die Daten eines Mandanten für einen anderen unzugänglich bleiben.

Die drei gängigen Datenpartitionierungsmodelle in SaaS-Systemen mit mehreren Mandanten sind Silo, Pool und Hybrid. Die Wahl eines Modells hängt von Faktoren wie den folgenden ab:

  • -Compliance

  • Laute Nachbarn

  • Zuweisungsstrategie

  • Betriebliche Anforderungen

  • Anforderungen an die Isolierung von Mietern

Darüber hinaus bietet jeder Datenbanktyp, der auf verfügbar ist, AWS in der Regel eine einzigartige Sammlung von Modellen zur Datenpartitionierung und Mandantenisolierung. Wenn Sie sich ansehen, wie Mandantendiagramme so organisiert werden können, dass sie die verschiedenen Anforderungen Ihrer Lösung unterstützen, sollten Sie die Modelle berücksichtigen, die Amazon Neptune bietet.

Viele ISVs beginnen ihr Design auf Neptune mit einer der folgenden Behauptungen:

  • Die ISV Lösung erfordert eine physische Trennung der Kunden über separate Cluster.

  • Die ISV Lösung erfordert Konstrukte wie benannte Datenbanken oder Schemas, die in herkömmlichen relationalen Datenbankmanagementsystemen zu finden sind.

Nach reiflicher Überlegung sollten Sie sich darüber im ISVs Klaren sein, dass diese Behauptungen nicht zutreffen, da bei fast allen Workloads jeder Kunde ein unzusammenhängendes Diagramm in seiner Datenbank hat. Durch die Implementierung der in diesem Dokument erörterten Richtlinien zur Datenmodellierung und zum Zugriff wird verhindert, dass diese Datengrenzen überschritten werden, und der Datenschutz der Kunden wird gewahrt.

In diesem Leitfaden werden sowohl das Silo-Modell als auch das Pool-Modell beschrieben. Die meisten ISVs entscheiden sich jedoch aus Gründen der Kosten und der betrieblichen Effizienz für das Pool-Modell. In diesem Leitfaden wird kurz auf ein Hybridmodell eingegangen, das Aspekte von Silo- und Poolmodellen kombiniert. Einige Unternehmen ISVs verwenden für ihre größten Kunden ein Hybridmodell, um regulatorischen oder Compliance-Anforderungen in der Größenordnung eines Diagramms gerecht zu werden.