Delen via

Distributiekolommen kiezen in Azure Cosmos DB for PostgreSQL

  • Artikel

VAN TOEPASSING OP: Azure Cosmos DB for PostgreSQL (mogelijk gemaakt door de Citus-database-extensie naar PostgreSQL)

De distributiekolom van elke tabel kiezen, is een van de belangrijkste modelleringsbeslissingen die u moet nemen. In Azure Cosmos DB for PostgreSQL worden rijen opgeslagen in shards op basis van de waarde van de distributiekolom van de rijen.

De juiste keuzegroepen gerelateerde gegevens op dezelfde fysieke knooppunten, waardoor query's snel worden uitgevoerd en ondersteuning wordt toegevoegd voor alle SQL-functies. Een onjuiste keuze maakt dat het systeem langzaam wordt uitgevoerd.

Algemene tips

Hier volgen vier criteria voor het kiezen van de ideale distributiekolom voor uw gedistribueerde tabellen.

  1. Kies een kolom die een centraal onderdeel is van de workload van de toepassing.

    U kunt deze kolom beschouwen als het 'hart', 'centraal stuk' of 'natuurlijke dimensie' voor het partitioneren van gegevens.

    Voorbeelden:

    • device_id in een IoT-workload
    • security_id voor een financiële app die effecten bijhoudt
    • user_id in gebruikersanalyse
    • tenant_id voor een SaaS-toepassing met meerdere tenants

  2. Kies een kolom met fatsoenlijke kardinaliteit en een gelijkmatige statistische verdeling.

    De kolom moet veel waarden hebben en grondig en gelijkmatig verdelen tussen alle shards.

    Voorbeelden:

    • Kardinaliteit meer dan 1000
    • Kies geen kolom met dezelfde waarde voor een groot percentage rijen (scheeftrekken van gegevens)
    • In een SaaS-workload kan het hebben van één tenant veel groter zijn dan de rest, waardoor gegevens scheeftrekken. Voor deze situatie kunt u tenantisolatie gebruiken om een toegewezen shard te maken voor het afhandelen van de tenant.

  3. Kies een kolom die van uw bestaande query's profiteert.

    Voor een transactionele of operationele workload (waarbij de meeste query's slechts een paar milliseconden duren), kiest u een kolom die wordt weergegeven als filter in WHERE componenten voor ten minste 80% van de query's. Bijvoorbeeld de device_id kolom in SELECT * FROM events WHERE device_id=1.

    Voor een analytische workload (waarbij de meeste query's 1-2 seconden duren), kiest u een kolom waarmee query's kunnen worden geparallelliseerd tussen werkknooppunten. Een kolom die vaak voorkomt in GROUP BY-componenten of die meerdere waarden tegelijk heeft opgevraagd.

  4. Kies een kolom die aanwezig is in de meeste grote tabellen.

    Tabellen van meer dan 50 GB moeten worden gedistribueerd. Als u dezelfde distributiekolom voor alle kolommen kiest, kunt u gegevens voor die kolom op werkknooppunten samen zoeken. Co-locatie maakt het efficiënt om JOINs en rollups uit te voeren en refererende sleutels af te dwingen.

    De andere (kleinere) tabellen kunnen lokale of referentietabellen zijn. Als de kleinere tabel JOIN met gedistribueerde tabellen nodig heeft, maakt u deze een referentietabel.

Use-casevoorbeelden

We hebben algemene criteria gezien voor het kiezen van de distributiekolom. Laten we nu eens kijken hoe ze van toepassing zijn op veelvoorkomende use cases.

Apps met meerdere tenants

De architectuur met meerdere tenants maakt gebruik van een vorm van hiërarchische databasemodellering om query's over knooppunten in het cluster te verdelen. De bovenkant van de gegevenshiërarchie wordt de tenant-id genoemd en moet worden opgeslagen in een kolom in elke tabel.

Azure Cosmos DB for PostgreSQL inspecteert query's om te zien welke tenant-id ze gebruiken en zoekt de overeenkomende tabelshard. Hiermee wordt de query gerouteerd naar één werkknooppunt dat de shard bevat. Het uitvoeren van een query met alle relevante gegevens die op hetzelfde knooppunt worden geplaatst, wordt colocatie genoemd.

In het volgende diagram ziet u colocatie in het gegevensmodel met meerdere tenants. Het bevat twee tabellen, accounts en campagnes, elk gedistribueerd door account_id. De gearceerde vakken vertegenwoordigen shards. Groene shards worden samen opgeslagen op één werkknooppunt en blauwe shards worden opgeslagen op een ander werkknooppunt. U ziet hoe een joinquery tussen accounts en campagnes alle benodigde gegevens op één knooppunt bevat wanneer beide tabellen worden beperkt tot dezelfde account_id.

Multitenantcolocation

Als u dit ontwerp wilt toepassen in uw eigen schema, identificeert u wat een tenant in uw toepassing is. Veelgebruikte exemplaren zijn onder andere bedrijf, account, organisatie of klant. De kolomnaam zal er ongeveer als volgt uitzien company_id of customer_id. Controleer al uw query's en vraag het uzelf af, of het werkt als er meer WHERE-componenten zijn om alle tabellen die betrokken zijn te beperken tot rijen met dezelfde tenant-id? Query's in het model met meerdere tenants zijn gericht op een tenant. Query's op verkoop of voorraad worden bijvoorbeeld binnen een bepaald archief geplaatst.

Aanbevolen procedures

  • Tabellen distribueren op een gemeenschappelijke tenant_id kolom. In een SaaS-toepassing waar tenants bedrijven zijn, is de tenant_id waarschijnlijk de company_id.
  • Converteer kleine tabellen tussen tenants naar referentietabellen. Wanneer meerdere tenants een kleine tabel met gegevens delen, distribueert u deze als referentietabel.
  • Beperk alle toepassingsquery's op tenant_id. Elke query moet informatie aanvragen voor één tenant tegelijk.

Lees de zelfstudie voor meerdere tenants voor een voorbeeld van het bouwen van dit type toepassing.

Realtime-apps

De architectuur met meerdere tenants introduceert een hiërarchische structuur en maakt gebruik van gegevenscolocatie om query's per tenant te routeren. Realtime architecturen zijn daarentegen afhankelijk van specifieke distributie-eigenschappen van hun gegevens om zeer parallelle verwerking te bereiken.

We gebruiken 'entiteits-id' als een term voor distributiekolommen in het realtime-model. Typische entiteiten zijn gebruikers, hosts of apparaten.

Realtime-query's vragen doorgaans om numerieke aggregaties gegroepeerd op datum of categorie. Azure Cosmos DB for PostgreSQL verzendt deze query's naar elke shard voor gedeeltelijke resultaten en verzamelt het uiteindelijke antwoord op het coördinatorknooppunt. Query's worden het snelst uitgevoerd wanneer zoveel mogelijk knooppunten bijdragen en wanneer er geen enkel knooppunt een onevenredige hoeveelheid werk moet uitvoeren.

Aanbevolen procedures

  • Kies een kolom met een hoge kardinaliteit als de distributiekolom. Ter vergelijking is een veld Status in een ordertabel met de waarden Nieuw, Betaald en Verzonden een slechte keuze uit de distributiekolom. Er wordt uitgegaan van slechts die paar waarden, waarmee het aantal shards wordt beperkt dat de gegevens kan bevatten en het aantal knooppunten dat deze kan verwerken. Bij kolommen met een hoge kardinaliteit is het ook handig om die kolommen te kiezen die vaak worden gebruikt in group-by-componenten of als joinsleutels.
  • Kies een kolom met gelijkmatige distributie. Als u een tabel op een kolom vertekend naar bepaalde gemeenschappelijke waarden distribueert, verzamelen gegevens in de tabel zich meestal in bepaalde shards. De knooppunten die deze shards bevatten, werken uiteindelijk meer dan andere knooppunten.
  • Feiten- en dimensietabellen verdelen over hun gemeenschappelijke kolommen. Uw feitentabel kan slechts één distributiesleutel hebben. Tabellen die worden samengevoegd op een andere sleutel, worden niet gekoppeld aan de feitentabel. Kies één dimensie die u wilt instellen op basis van hoe vaak deze wordt samengevoegd en de grootte van de samenvoegingsrijen.
  • Wijzig enkele dimensietabellen in referentietabellen. Als een dimensietabel niet kan worden gekoppeld aan de feitentabel, kunt u de queryprestaties verbeteren door kopieën van de dimensietabel te distribueren naar alle knooppunten in de vorm van een verwijzingstabel.

Lees de zelfstudie voor realtime dashboards voor een voorbeeld van het bouwen van dit type toepassing.

Tijdreeksgegevens

In een tijdreeksworkload doorzoeken toepassingen recente informatie terwijl ze oude informatie archiveren.

De meest voorkomende fout bij het modelleren van tijdreeksgegevens in Azure Cosmos DB for PostgreSQL is het gebruik van de tijdstempel zelf als een distributiekolom. Een hashdistributie op basis van tijd verdeelt tijd schijnbaar willekeurig in verschillende shards in plaats van tijdbereiken bij elkaar te houden in shards. Query's die betrekking hebben op tijdsbereiken die betrekking hebben op tijdsbereiken, bijvoorbeeld de meest recente gegevens. Dit type hash-distributie leidt tot netwerkoverhead.

Aanbevolen procedures

  • Kies geen tijdstempel als distributiekolom. Kies een andere distributiekolom. Gebruik in een app met meerdere tenants de tenant-id of gebruik in een realtime-app de entiteits-id.
  • Gebruik in plaats daarvan PostgreSQL-tabelpartitionering voor tijd. Gebruik tabelpartitionering om een grote tabel met tijd geordende gegevens te splitsen in meerdere overgenomen tabellen, waarbij elke tabel verschillende tijdsbereiken bevat. Als u een postgres-gepartitioneerde tabel distribueert, worden shards gemaakt voor de overgenomen tabellen.

Volgende stappen

  • Meer informatie over hoe colocatie tussen gedistribueerde gegevens helpt bij het snel uitvoeren van query's.
  • Ontdek de distributiekolom van een gedistribueerde tabel en andere nuttige diagnostische query's.