Shardingmodelle
GILT FÜR: 
Azure Cosmos DB for PostgreSQL (unterstützt von der Citus-Datenbankerweiterung auf PostgreSQL)
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.
Azure Cosmos DB for PostgreSQL bietet zwei Arten von Datensharding: zeilenbasiert und schemabasiert. Jede Option verfügt bietet einen eigenen Sharding-Kompromiss, sodass Sie den Ansatz auswählen können, der den Anforderungen Ihrer Anwendung am besten entspricht.
Zeilenbasiertes Sharding
Die traditionelle Art und Weise, in der Azure Cosmos DB for PostgreSQL Tabellen in Shards aufteilt, ist die einzelne Datenbank, das gemeinsam genutzte Schemamodell, 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.
Zeilenbasiert ist die hardwareeffizientste Art des Shardings. 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:
- Beste Leistung
- Beste Mandantendichte pro Knoten
Nachteile:
- Erfordert Schemaänderungen
- Erfordert Anwendungsabfrageänderungen
- Alle Mandanten müssen dasselbe Schema gemeinsam nutzen
Schemabasiertes Sharding
Verfügbar mit Citus 12.0 in Azure Cosmos DB for PostgreSQL. Schemabasiertes sharding ist die freigegebene Datenbank, das separate Schemamodell; 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 ISVs, die Anwendungen bereitstellen und sich nicht mit den für zeilenbasierte Sharding erforderlichen Änderungen befassen können.
Vorteile:
- Mandanten können heterogene Schemas haben
- Keine Schemaänderungen erforderlich
- Erfordert keine Anwendungsabfrageänderungen
- 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 |