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