Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 samen vormen shards de volledige gegevensset.
Elastische clusters op flexibele servers van Azure Database for PostgreSQL bieden twee soorten gegevenspartitionering: rijgebaseerde en schemagebaseerde. Elke optie wordt geleverd met eigen compromissen, zodat u de methode kunt kiezen die het beste aansluit bij de vereisten van uw toepassing.
Op rij gebaseerde sharding
In shardtabellen in het gedeelde-schemamodel met één database, ook wel row-based sharding genoemd, bestaan tenants als rijen binnen dezelfde tabel. U definieert een distributiekolom om de tenant te bepalen, die een tabel horizontaal splitst.
Sharding op basis van rijen is de meest hardware-efficiënte methode. De knooppunten in het cluster plaatsen tenants dicht op elkaar en verdelen ze. Deze aanpak vereist echter dat alle tabellen in het schema de distributiekolom hebben en dat alle query's in de toepassing op die kolom worden gefilterd. Rijgebaseerde sharding werkt goed bij IoT-workloads en om hardware optimaal te benutten.
Voordelen:
- Beste prestaties.
- Beste tenantdichtheid per knooppunt.
Nadelen:
- Vereist schemawijzigingen.
- Vereist wijzigingen in applicatiequery’s.
- Vereist dat alle tenants hetzelfde schema delen.
Op schema gebaseerde sharding
Op schema gebaseerde sharding maakt gebruik van een gedeelde database en een afzonderlijk schemamodel. Elk schema fungeert als een logische shard binnen de database. Apps met meerdere tenants kunnen een schema voor elke tenant gebruiken om eenvoudig sharding uit te voeren in de tenantdimensie. U hoeft geen query's te wijzigen en de toepassing hoeft alleen maar een kleine wijziging in te stellen om het 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 (Onafhankelijke softwareleveranciers) 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 dan bij rijgebaseerde sharding.
Sharding-compromissen
| Op schema gebaseerde sharding | Op rij gebaseerde sharding | |
|---|---|---|
| Model voor multitenancy | 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 op elke tabel om tabellen te distribueren en te co-lokaliseren op tenant-ID |
| Aantal huurders | 1.000-10.000 | 1-1 M+ |
| Vereiste voor gegevensmodellering | Geen vreemde sleutels in gedistribueerde schema's | Moet een tenant-id-kolom (een distributiekolom, ook wel een sharding-sleutel genoemd) bevatten in elke tabel en in primaire en refererende sleutels. |
| SQL-vereiste voor query's met één knooppunt | Eén gedistribueerd schema per query gebruiken | Joins en WHERE-clausules moeten de tenant_id-kolom bevatten |
| Parallele query's voor meerdere tenants | Nee. | Yes |
| Aangepaste tabeldefinities per klant | Yes | Nee. |
| Toegangsbeheer | Schemamachtigingen | Schemamachtigingen |
| Gegevens delen tussen tenants | Ja, met behulp van referentietabellen (in een afzonderlijk schema) | Ja, met behulp van referentietabellen |
| Isolatie van tenant naar shard | Elke tenant heeft een eigen shardgroep per definitie | U kunt specifieke tenant-ID's een eigen shardgroep toewijzen via isolate_tenant_to_new_shard |