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.
Viktigt!
Azure Cosmos DB for PostgreSQL stöds inte längre för nya projekt. Använd inte den här tjänsten för nya projekt. Använd i stället en av dessa två tjänster:
Använd Azure Cosmos DB för NoSQL för en distribuerad databaslösning som är utformad för storskaliga scenarier med ett serviceavtal på 99,999% tillgänglighet , omedelbar autoskalning och automatisk redundans i flera regioner.
Använd funktionen Elastiska kluster i Azure Database For PostgreSQL för fragmenterad PostgreSQL med citus-tillägget med öppen källkod.
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 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 |