Delen via


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 voor PostgreSQL tabellen verdeelt, is het model van een enkele database en gedeeld schema, dat ook bekend staat als rijgebaseerde sharding. Tenants bestaan naast elkaar als rijen in dezelfde tabel. De tenant wordt bepaald door een distributiekolom te definiëren, waardoor een tabel horizontaal kan worden gesplitst.

Een rij-gebaseerde aanpak is de meest hardware-efficiënte manier van het verdelen van gegevens. 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. Rij-gebaseerde sharding is effectief bij IoT-workloads en voor het maximaliseren van de gebruikswaarde van hardware.

Voordelen:

  • Beste prestaties
  • Beste tenantdichtheid per knooppunt

Nadelen:

  • Schemawijzigingen vereist
  • Vereist aanpassingen aan applicatiequery'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 huurders per knooppunt in vergelijking met sharding op basis van rijen

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 voor elke tabel om tabellen per tenant-id te distribueren en te colocate
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 Ja
Aangepaste tabeldefinities per klant Ja 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 Kan specifieke tenant-ID's een eigen shardgroep geven via isolate_tenant_to_new_shard