Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
GÄLLER FÖR: 
Azure Database for PostgreSQL – flexibel server
Horisontell partitionering är en teknik som används i databassystem och distribuerad databehandling för horisontell partitionering av data över flera servrar eller noder. Det innebär att dela upp en stor databas eller datauppsättning i mindre, mer hanterbara delar som kallas Shards. En shard innehåller en delmängd av data och tillsammans bildar shards hela datamängden.
Elastiska kluster i Azure Database for PostgreSQL – flexibel server erbjuder två typer av datasharding: radbaserad och schemabaserad. Varje alternativ levereras med egna kompromisser, så att du kan välja den metod som bäst överensstämmer med programmets krav.
Radbaserad horisontell partitionering
Shards-tabeller i den delade schemamodellen för enskild databas, även kallat radbaserad horisontell partitionering, klientorganisationer samexisterar som rader i samma tabell. Klientorganisationen bestäms genom att definiera en distributionskolumn, vilket gör det möjligt att dela upp en tabell vågrätt.
Radbaserad horisontell partitionering är den mest maskinvarueffektiva metoden. Klientorganisationer är tätt packade och distribuerade mellan noderna i klustret. Den här metoden kräver dock att alla tabeller i schemat har distributionskolumnen och att alla frågor i programfiltret efter den kolumnen. Radbaserad horisontell partitionering lyser i IoT-arbetsbelastningar och för att uppnå bästa möjliga marginal av maskinvaruanvändning.
Fördelar:
- Bästa prestanda.
- Bästa klienttäthet per nod.
Nackdelar:
- Kräver schemaändringar.
- Kräver programfrågeändringar.
- Kräver att alla klienter måste dela samma schema.
Schemabaserad horisontell partitionering
Schemabaserad horisontell partitionering är den delade databasen, en separat schemamodell och schemat blir den logiska fragmentet i databasen. Appar med flera klienter kan använda ett schema per klientorganisation för att enkelt fragmentera längs klientdimensionen. Frågeändringar krävs inte och programmet behöver bara en liten ändring för att ställa in rätt search_path vid växling av klientorganisationer. Schemabaserad horisontell partitionering är en idealisk lösning för mikrotjänster och för ISV:er (oberoende programvaruleverantörer) som distribuerar program som inte kan genomgå de ändringar som krävs för att registrera radbaserad horisontell partitionering.
Fördelar:
- Klienter kan ha heterogena scheman.
- Inga schemaändringar krävs.
- Inga ändringar av programfrågor krävs.
- Schemabaserad partitionering av SQL-kompatibilitet är bättre jämfört med radbaserad horisontell partitionering.
Nackdelar:
- Färre klienter per nod jämfört med radbaserad horisontell partitionering.
Kompromisser för horisontell partitionering
| Schemabaserad horisontell partitionering | Radbaserad horisontell partitionering | |
|---|---|---|
| Modell för flera innehavare | Separat schema per klientorganisation | Delade tabeller med klientorganisations-ID-kolumner |
| Citus-version | 12.0+ | Alla versioner |
| Extra steg jämfört med vanilj PostgreSQL | Ingen, endast en konfigurationsändring | Använd create_distributed_table i varje tabell för att distribuera och samplacera tabeller efter klientorganisations-ID |
| Antal klienter | 1-10k | 1-1 M+ |
| Krav för datamodellering | Inga sekundärnycklar i distribuerade scheman | Behöver inkludera en klientorganisations-ID-kolumn (en distributionskolumn, även kallad partitioneringsnyckel) i varje tabell och i primära nycklar, sekundärnycklar |
| SQL-krav för frågor med en enda nod | Använda ett enda distribuerat schema per fråga | Kopplingar och WHERE-satser bör innehålla tenant_id kolumn |
| Parallella frågor mellan klientorganisationer | Nej | Ja |
| Anpassade tabelldefinitioner per klientorganisation | Ja | Nej |
| Åtkomstkontroll | Schemabehörigheter | Schemabehörigheter |
| Datadelning mellan klienter | Ja, med hjälp av referenstabeller (i ett separat schema) | Ja, med hjälp av referenstabeller |
| Isolering av klientorganisation till shard | Varje klientorganisation har en egen fragmentgrupp per definition | Kan ge specifika klient-ID:n en egen shardgrupp via isolate_tenant_to_new_shard |