Sharding-modellen
VAN TOEPASSING OP: 
Azure Cosmos DB for PostgreSQL (mogelijk gemaakt door de Citus-database-extensie naar PostgreSQL)
Sharding is een techniek die wordt gebruikt in databasesystemen en gedistribueerde computing om gegevens horizontaal te partitioneren op meerdere servers of knooppunten. Het omvat het opsplitsen van een grote database of gegevensset in kleinere, beter beheerbare onderdelen, Shards genoemd. Een shard bevat een subset van de gegevens en shards vormen samen de volledige gegevensset.
Azure Cosmos DB for PostgreSQL biedt twee typen gegevenssharding, namelijk op rij en schema gebaseerd. Elke optie wordt geleverd met eigen Sharding-compromissen, zodat u de methode kunt kiezen die het beste aansluit bij de vereisten van uw toepassing.
Op rij gebaseerde sharding
De traditionele manier waarop Azure Cosmos DB for PostgreSQL-shards-tabellen de individuele database, het gedeelde schemamodel ook wel bekend als sharding op basis van rijen, tenants naast elkaar bestaan als rijen in dezelfde tabel. De tenant wordt bepaald door een distributiekolom te definiëren, waardoor een tabel horizontaal kan worden gesplitst.
Op rij gebaseerd is de meest efficiënte manier van sharding. Tenants zijn dicht verpakt en verdeeld over de knooppunten in het cluster. Deze aanpak vereist echter dat alle tabellen in het schema de distributiekolom hebben en dat alle query's in het toepassingsfilter erop zijn gefilterd. Op rij gebaseerde sharding schijnt in IoT-workloads en voor het bereiken van de beste marge van hardwaregebruik.
Voordelen:
- Beste prestaties
- Beste tenantdichtheid per knooppunt
Nadelen:
- Schemawijzigingen vereist
- Vereist wijzigingen in toepassingsquery's
- Alle tenants moeten hetzelfde schema delen
Op schema gebaseerde sharding
Beschikbaar met Citus 12.0 in Azure Cosmos DB for PostgreSQL, op schema gebaseerde sharding is de gedeelde database, een afzonderlijk schemamodel, het schema wordt de logische shard binnen de database. Apps met meerdere tenants kunnen een schema per tenant gebruiken om eenvoudig de tenantdimensie te sharden. Querywijzigingen zijn niet vereist en de toepassing heeft slechts een kleine wijziging nodig om de juiste search_path in te stellen bij het schakelen tussen tenants. Sharding op basis van schema's is een ideale oplossing voor microservices en voor ISV's die toepassingen implementeren die niet de wijzigingen kunnen ondergaan die nodig zijn voor het onboarden van sharding op basis van rijen.
Voordelen:
- Tenants kunnen heterogene schema's hebben
- Er zijn geen schemawijzigingen vereist
- Er zijn geen wijzigingen in de toepassingsquery vereist
- Sql-compatibiliteit op basis van schema's is beter vergeleken met sharding op basis van rijen
Nadelen:
- Minder tenants per knooppunt vergeleken met sharding op basis van rijen
Sharding-compromissen
| Op schema gebaseerde sharding | Op rij gebaseerde sharding | |
|---|---|---|
| Multitenancymodel | Afzonderlijk schema per tenant | Gedeelde tabellen met tenant-id-kolommen |
| Citus-versie | 12.0+ | Alle versies |
| Extra stappen vergeleken met vanille PostgreSQL | Geen, alleen een configuratiewijziging | Gebruik create_distributed_table voor elke tabel om tabellen per tenant-id te distribueren en te colocate |
| Aantal tenants | 1-10k | 1-1 M+ |
| Vereiste voor gegevensmodellering | Geen refererende sleutels in gedistribueerde schema's | Moet een tenant-id-kolom (een distributiekolom, ook wel een sharding-sleutel genoemd) opnemen in elke tabel en in primaire sleutels, refererende sleutels |
| SQL-vereiste voor query's met één knooppunt | Eén gedistribueerd schema per query gebruiken | Joins en WHERE-componenten moeten tenant_id kolom bevatten |
| Parallelle query's voor meerdere tenants | Nr. | Ja |
| Aangepaste tabeldefinities per tenant | Ja | Nr. |
| Toegangsbeheer | Schemamachtigingen | Schemamachtigingen |
| Gegevens delen tussen tenants | Ja, met behulp van referentietabellen (in een afzonderlijk schema) | Ja, met behulp van referentietabellen |
| Tenant naar shard-isolatie | Elke tenant heeft een eigen shardgroep per definitie | Kan specifieke tenant-id's hun eigen shardgroep geven via isolate_tenant_to_new_shard |