Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Sharding oder horizontales Partitionieren ist eine Technik, die in Datenbanksystemen und verteilten Computing verwendet wird, um Daten horizontal auf mehreren Servern oder Knoten zu partitionieren. Die Technik umfasst das Aufteilen einer großen Datenbank oder eines Datasets in kleinere, verwaltbare Teile namens Shards. Ein Shard enthält eine Teilmenge der Daten, und zusammen bilden Shards das vollständige Dataset.
Elastische Cluster auf Azure Database für PostgreSQL Flexible Server-Instanzen bieten zwei Arten von Datensharding: zeilenbasiert und schemabasiert. Jede Option verfügt bietet eigene Kompromisse, sodass Sie den Ansatz auswählen können, der den Anforderungen Ihrer Anwendung am besten entspricht.
Zeilenbasiertes Sharding
Shardtabellen im gemeinsam genutzten Schemamodell der einzelnen Datenbank werden auch als zeilenbasiertes Sharding bezeichnet; Mandanten koexistieren als Zeilen innerhalb derselben Tabelle. Der Mandant wird durch Definieren einer Verteilungsspaltebestimmt, was die horizontale Aufteilung einer Tabelle ermöglicht.
Zeilenbasiertes Sharding ist die hardwareeffizientste Methode. Mandanten sind dicht gepackt und werden zwischen den Knoten im Cluster verteilt. Bei diesem Ansatz muss jedoch sichergestellt werden, dass alle Tabellen im Schema über die Verteilungsspalte und alle Abfragen innerhalb der Anwendung entsprechend filtern. Zeilenbasiertes Sharding eignet sich besonders für IoT-Workloads und für die optimale Hardwarenutzung.
Vorteile:
- Bestleistung.
- Beste Mandantendichte pro Knoten.
Nachteile:
- Erfordert Schemaänderungen.
- Erfordert Anwendungsabfrageänderungen.
- Alle Mandanten müssen dasselbe Schema gemeinsam nutzen.
Schemabasiertes Sharding
Schemabasiertes Sharding ist die freigegebene Datenbank, ein separates Schemamodell, und das Schema wird zum logischen Shard innerhalb der Datenbank. Mehrmandanten-Apps können ein Schema pro Mandant verwenden, um problemlos in der Mandantendimension zu sharden. Abfrageänderungen sind nicht erforderlich, und die Anwendung benötigt nur eine kleine Änderung, um die Variable „search_path“ beim Wechseln von Mandanten richtig festzulegen. Schemabasiertes Sharding ist eine ideale Lösung für Microservices und für unabhängige Softwareanbieter (Independent Software Vendors, ISVs), die Anwendungen bereitstellen, die nicht die für zeilenbasiertes Sharding erforderlichen Änderungen durchlaufen können.
Vorteile:
- Mandanten können heterogene Schemas haben.
- Es sind keine Schemaänderungen erforderlich.
- Es sind keine Anwendungsabfrageänderungen erforderlich.
- Die SQL-Kompatibilität von schemabasiertem Sharding ist im Vergleich zu zeilenbasiertem Sharding besser.
Nachteile:
- Weniger Mandanten pro Knoten im Vergleich zum zeilenbasierten Sharding.
Sharding-Kompromisse
| Schemabasiertes Sharding | Zeilenbasiertes Sharding | |
|---|---|---|
| Mehrmandantenmodell | Separates Schema für jeden Mandanten | Freigegebene Tabellen mit Mandanten-ID-Spalten |
| Citus-Version | 12.0+ | Alle Versionen |
| Zusätzliche Schritte im Vergleich zu standardmäßigem PostgreSQL | Keine, nur eine Konfigurationsänderung | Verwenden Sie „create_distributed_table“ für jede Tabelle, um Tabellen nach Mandanten-ID zu verteilen und zusammenzustellen. |
| Anzahl der Mandanten | 1-10k | 1-1 M+ |
| Anforderungen für die Datenmodellierung | Keine Fremdschlüssel über verteilte Schemas hinweg | Muss eine Mandanten-ID-Spalte (eine Verteilungsspalte, auch als Sharding-Schlüssel bezeichnet) in jeder Tabelle und in Primärschlüsseln sowie Fremdschlüsseln enthalten |
| SQL-Anforderung für einzelne Knotenabfragen | Verwenden eines einzelnen verteilten Schemas pro Abfrage | Verknüpfungen und WHERE-Klauseln sollten die Spalte „tenant_id“ enthalten |
| Parallele mandantenübergreifende Abfragen | Nein | Ja |
| Benutzerdefinierte Tabellendefinitionen pro Mandant | Ja | Nein |
| Zugriffssteuerung | Schemaberechtigungen | Schemaberechtigungen |
| Datenfreigabe zwischen Mandanten | Ja, mit Verweistabellen (in einem separaten Schema) | Ja, mit Verweistabellen |
| Isolierung von Mandant und Shard | Jeder Mandant verfügt per Definition über eine eigene Shardgruppe | Kann bestimmten Mandanten-IDs eigene Shardgruppen über isolate_tenant_to_new_shard zuweisen |