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 Cosmos DB for PostgreSQL (drivs av Citus-databastillägget till PostgreSQL)
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.
Azure Cosmos DB for PostgreSQL erbjuder två typer av datasharding, nämligen radbaserad och schemabaserad. Varje alternativ kommer med sina egna kompromisser för horisontell partitionering, så att du kan välja den metod som bäst passar dina programkrav.
Radbaserad partitionering
Det traditionella sättet som Azure Cosmos DB för PostgreSQL-sharding av tabeller gör det, är modellen med en enda databas och delat schema, även känd som radbaserad uppdelning, där hyresgäster samexisterar som rader i samma tabell. Hyresgästen bestäms genom att definiera en distributionskolumn, vilket möjliggör en horisontell uppdelning av en tabell.
Radbaserad är det mest maskinvarueffektiva sättet att partitionera. 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 programmet filtrerar efter den. Radbaserad horisontell partitionering utmärker sig i IoT-belastningar och för att uppnå optimal maskinvaruanvändning.
Fördelar:
- Bästa prestanda
- Bästa klienttäthet per nod
Nackdelar:
- Kräver schemaändringar
- Kräver programfrågeändringar
- Alla klienter måste dela samma schema
Schemabaserad horisontell partitionering
Tillgänglig med Citus 12.0 i Azure Cosmos DB för PostgreSQL, schemabaserad partitionering innebär en delad databas med separata scheman, där varje schema blir en logisk del i databasen. Appar med flera klienter kan använda ett schema per klientorganisation för att enkelt fragmentera längs klientdimensionen. Inga frågeändringar krävs, och programmet behöver bara en liten modifiering för att ange rätt search_path när man byter klientorganisationer. Schemabaserad horisontell partitionering är en idealisk lösning för mikrotjänster och för ISV:er 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 programfrågeändringar krävs
- Schemabaserad SQL-kompatibilitet med horisontell partitionering ä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 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 | 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 hyresgäst har en egen fragmentgrupp per definition | Kan ge specifika klient-ID:n en egen shardgrupp via isolate_tenant_to_new_shard |