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. Es umfasst das Aufteilen einer großen Datenbank oder eines Datasets in kleinere, verwaltbare Teile, die als Shards bezeichnet werden. Ein Shard enthält eine Teilmenge der Daten, und zusammen bilden die Shards den vollständigen Datensatz.
Elastische Cluster auf flexiblen Servern von Azure Database for PostgreSQL bieten zwei Arten von Daten-Sharding: zeilenbasiertes und schemabasiertes. Jede Option verfügt über eigene Kompromisse, sodass Sie den Ansatz auswählen können, der den Anforderungen Ihrer Anwendung am besten entspricht.
Zeilenbasiertes Sharding
Shard-Tabellen im gemeinsamen Singleton-Schemamodell, auch bekannt als zeilenbasiertes Sharding, koexistieren Mandanten als Zeilen innerhalb derselben Tabelle. Sie definieren eine Verteilungsspalte, um den Mandanten zu bestimmen, der eine Tabelle horizontal aufteilt.
Zeilenbasiertes Sharding ist die hardwareeffizientste Methode. Die Knoten im Cluster packen dicht und verteilen Mandanten. Bei diesem Ansatz muss jedoch sichergestellt werden, dass alle Tabellen im Schema über die Verteilungsspalte und alle Abfragen im Anwendungsfilter nach dieser Spalte verfügen. Zeilenbasiertes Sharding funktioniert gut bei IoT-Workloads und um die Hardware bestmöglich auszulasten.
Vorteile:
- Beste Leistung.
- Beste Mandantendichte pro Knoten.
Nachteile:
- Erfordert Schemamodifikationen.
- Erfordert Anwendungsabfrage-Modifikationen.
- Erfordert, dass alle Mandanten dasselbe Schema verwenden.
Schemabasiertes Sharding
Schemabasiertes Sharding verwendet eine freigegebene Datenbank und ein separates Schemamodell. Jedes Schema fungiert als logischer Shard innerhalb der Datenbank. Multitenant-Apps können für jeden Mandanten ein Schema verwenden, um problemlos entlang der Mandantendimension zu shardieren. Sie müssen keine Abfragen ändern, und die Anwendung benötigt nur eine kleine Änderung, um beim Wechseln von Mandanten die richtige search_path Einstellung festzulegen. Schemabasiertes Sharding ist eine ideale Lösung für Microservices und für ISVs (Independent Software Vendors, Unabhängige Softwareanbieter), die Anwendungen bereitstellen, die nicht die für das zeilenbasierte Sharding erforderlichen Änderungen vornehmen können.
Vorteile:
- Mandanten können heterogene Schemata haben.
- Es sind keine Schemamodifikationen erforderlich.
- Es sind keine Anwendungsabfrage-Modifikationen erforderlich.
- Die SQL-Kompatibilität von schemabasiertem Sharding ist im Vergleich zum zeilenbasierten 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 anhand der Mandanten-ID zu verteilen und zu kolokalisieren. |
| Anzahl der Mieter | 1-10.000 | 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 | Yes |
| Benutzerdefinierte Tabellendefinitionen pro Mandant | Yes | Nein |
| Zugriffskontrolle | 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 über isolate_tenant_to_new_shard eine eigene Shard-Gruppe zuweisen |