Kommentar
Å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.
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 datamängd 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 på Azure Database for PostgreSQL flexibla servrar erbjuder två typer av datasharding: radbaserad och schemabaserad. Varje alternativ har sina egna kompromisser, så att du kan välja den metod som bäst överensstämmer med programmets krav.
Radbaserad partitionering
I shardingstabeller i modellen med delat schema i en enda databas, även känd som radbaserad shardning, samexisterar klienter som rader i samma tabell. Du definierar en distributionskolumn för att avgöra klientorganisationen, vilket delar upp en tabell horisontellt.
Radbaserad horisontell partitionering är den mest maskinvarueffektiva metoden. Klusternoderna packar tätt och fördelar klienter. Den här metoden kräver dock att alla tabeller i schemat har distributionskolumnen och att alla frågor i programmet filtrerar efter den kolumnen. Radbaserad horisontell partitionering fungerar bra i IoT-arbetsbelastningar och för att uppnå bästa möjliga marginal för maskinvaruanvändning.
Benefits:
- Bästa prestanda.
- Bästa klienttäthet per nod.
Nackdelar:
- Kräver schemaändringar.
- Kräver programfrågeändringar.
- Kräver att alla hyresgäster delar samma schema.
Schemabaserad horisontell partitionering
Schemabaserad horisontell partitionering använder en delad databas och en separat schemamodell. Varje schema fungerar som en logisk shard i databasen. Appar med flera klientorganisationer kan använda ett schema för varje klientorganisation för att enkelt partitionera utifrån klientdimensionen. Du behöver inte ändra frågor, och applikationen behöver bara en mindre ändring för att ange rätt search_path när du byter klientorganisation. 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.
Benefits:
- Klienter kan ha heterogena scheman.
- Inga schemaändringar krävs.
- Inga ändringar av programfrågor krävs.
- SQL-kompatibiliteten är bättre för schemabaserad partitionering än för radbaserad partitionering.
Nackdelar:
- Färre klienter per nod jämfört med radbaserad horisontell partitionering.
Kompromisser för horisontell partitionering
| Schemabaserad horisontell partitionering | Radbaserad 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 utländska nycklar i distribuerade scheman | Behöver inkludera en hyresgäst-ID-kolumn (en distributionskolumn, även kallad partitioneringsnyckel) i varje tabell och i primära nycklar, utländska nycklar |
| 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 kolumnen tenant_id |
| Parallella sökfrågor mellan hyresgäster | Nej | Yes |
| Anpassade tabelldefinitioner per klientorganisation | Yes | 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 hyresgäst har en egen fragmentgrupp per definition | Kan ge specifika klient-ID:n en egen shardgrupp via isolate_tenant_to_new_shard |