Share via

Välj distributionskolumner i Azure Cosmos DB för PostgreSQL

  • Artikel

GÄLLER FÖR: Azure Cosmos DB for PostgreSQL (drivs av Citus-databastillägget till PostgreSQL)

Att välja distributionskolumn för varje tabell är ett av de viktigaste besluten om modellering. Azure Cosmos DB for PostgreSQL lagrar rader i shards baserat på värdet för radernas distributionskolumn.

Rätt val grupperar relaterade data på samma fysiska noder, vilket gör frågor snabba och lägger till stöd för alla SQL-funktioner. Ett felaktigt val gör att systemet körs långsamt.

Allmänna tips

Här är fyra kriterier för att välja den perfekta distributionskolumnen för dina distribuerade tabeller.

  1. Välj en kolumn som är en central del i programarbetsbelastningen.

    Du kanske tänker på den här kolumnen som "hjärta", "central del" eller "naturlig dimension" för partitionering av data.

    Exempel:

    • device_id i en IoT-arbetsbelastning
    • security_id för en finansiell app som spårar värdepapper
    • user_id i användaranalys
    • tenant_id för ett SaaS-program för flera innehavare

  2. Välj en kolumn med anständig kardinalitet och en jämn statistisk fördelning.

    Kolumnen bör ha många värden och distribueras noggrant och jämnt mellan alla shards.

    Exempel:

    • Kardinalitet över 1 000
    • Välj inte en kolumn som har samma värde på en stor procentandel rader (datasnedställning)
    • I en SaaS-arbetsbelastning kan en klientorganisation som är mycket större än resten orsaka datasnedvridning. I det här fallet kan du använda klientisolering för att skapa en dedikerad shard för att hantera klientorganisationen.

  3. Välj en kolumn som gynnar dina befintliga frågor.

    För en transaktions- eller driftarbetsbelastning (där de flesta frågor bara tar några millisekunder) väljer du en kolumn som visas som ett filter i WHERE satser för minst 80 % av frågorna. Till exempel device_id kolumnen i SELECT * FROM events WHERE device_id=1.

    För en analytisk arbetsbelastning (där de flesta frågor tar 1–2 sekunder) väljer du en kolumn som gör att frågor kan parallelliseras mellan arbetsnoder. Till exempel en kolumn som ofta förekommer i GROUP BY-satser eller efterfrågas över flera värden samtidigt.

  4. Välj en kolumn som finns i de flesta stora tabeller.

    Tabeller över 50 GB ska distribueras. Genom att välja samma distributionskolumn för alla kan du samplaceera data för kolumnen på arbetsnoder. Samplacering gör det effektivt att köra JOIN:er och sammanslagningar och framtvinga sekundärnycklar.

    De andra (mindre) tabellerna kan vara lokala tabeller eller referenstabeller. Om den mindre tabellen behöver KOPPLA med distribuerade tabeller gör du den till en referenstabell.

Användningsfallsexempel

Vi har sett allmänna kriterier för att välja distributionskolumnen. Nu ska vi se hur de gäller för vanliga användningsfall.

Appar för flera klienter

Arkitekturen för flera klientorganisationer använder en form av hierarkisk databasmodellering för att distribuera frågor mellan noder i klustret. Överst i datahierarkin kallas klientorganisations-ID:t och måste lagras i en kolumn i varje tabell.

Azure Cosmos DB for PostgreSQL inspekterar frågor för att se vilket klient-ID de involverar och hittar matchande tabellshard. Den dirigerar frågan till en enda arbetsnod som innehåller fragmentet. Att köra en fråga med alla relevanta data som placeras på samma nod kallas colocation.

Följande diagram illustrerar samlokalisering i datamodellen för flera klientorganisationer. Den innehåller två tabeller, Konton och kampanjer, som var och en distribueras av account_id. De skuggade rutorna representerar shards. Gröna shards lagras tillsammans på en arbetsnod och blå shards lagras på en annan arbetsnod. Observera hur en kopplingsfråga mellan konton och kampanjer innehåller alla nödvändiga data på en nod när båda tabellerna är begränsade till samma account_id.

Multi-tenantcolocation

Om du vill använda den här designen i ditt eget schema identifierar du vad som utgör en klientorganisation i ditt program. Vanliga instanser är företag, konto, organisation eller kund. Kolumnnamnet blir något i stil med company_id eller customer_id. Granska var och en av dina frågor och fråga dig själv, skulle det fungera om det hade fler WHERE-satser för att begränsa alla tabeller som ingår i rader med samma klientorganisations-ID? Frågor i modellen med flera klientorganisationer är begränsade till en klientorganisation. Frågor om försäljning eller inventering är till exempel begränsade i ett visst lager.

Bästa praxis

  • Distribuera tabeller med en gemensam tenant_id kolumn. I ett SaaS-program där klientorganisationer är företag är tenant_id till exempel sannolikt company_id.
  • Konvertera små tabeller mellan klientorganisationer till referenstabeller. När flera klienter delar en liten tabell med information distribuerar du den som en referenstabell.
  • Begränsa filtreringen av alla programfrågor efter tenant_id. Varje fråga bör begära information för en klient i taget.

Läs självstudien för flera klientorganisationer för ett exempel på hur du skapar den här typen av program.

Realtidsappar

Arkitekturen för flera klientorganisationer introducerar en hierarkisk struktur och använder datasamlokalisering för att dirigera frågor per klientorganisation. Däremot är realtidsarkitekturer beroende av specifika distributionsegenskaper för sina data för att uppnå mycket parallell bearbetning.

Vi använder "entitets-ID" som en term för distributionskolumner i realtidsmodellen. Typiska entiteter är användare, värdar eller enheter.

Realtidsfrågor frågar vanligtvis efter numeriska aggregeringar grupperade efter datum eller kategori. Azure Cosmos DB for PostgreSQL skickar dessa frågor till varje shard för partiella resultat och sammanställer det slutliga svaret på koordinatornoden. Frågor körs snabbast när så många noder bidrar som möjligt, och när ingen enskild nod måste utföra en oproportionerlig mängd arbete.

Bästa praxis

  • Välj en kolumn med hög kardinalitet som distributionskolumn. Som jämförelse är ett statusfält i en ordertabell med värdena New, Paid och Shipped ett dåligt val av distributionskolumn. Det förutsätter bara de få värdena, vilket begränsar antalet shards som kan lagra data och antalet noder som kan bearbeta dem. Bland kolumner med hög kardinalitet är det också bra att välja de kolumner som ofta används i grupp-by-satser eller som kopplingsnycklar.
  • Välj en kolumn med jämn fördelning. Om du distribuerar en tabell i en kolumn som är skev till vissa vanliga värden, tenderar data i tabellen att ackumuleras i vissa shards. Noderna som innehåller dessa shards gör mer arbete än andra noder.
  • Distribuera fakta- och dimensionstabeller på sina vanliga kolumner. Faktatabellen kan bara ha en distributionsnyckel. Tabeller som ansluter till en annan nyckel kommer inte att samplaceeras med faktatabellen. Välj en dimension att samplacera baserat på hur ofta den är ansluten och storleken på de sammanfogande raderna.
  • Ändra vissa dimensionstabeller till referenstabeller. Om en dimensionstabell inte kan samplaceeras med faktatabellen kan du förbättra frågeprestanda genom att distribuera kopior av dimensionstabellen till alla noder i form av en referenstabell.

Läs självstudien för instrumentpanelen i realtid för ett exempel på hur du skapar den här typen av program.

Tidsseriedata

I en tidsseriearbetsbelastning frågar program efter aktuell information medan de arkiverar gammal information.

Det vanligaste misstaget vid modellering av tidsserieinformation i Azure Cosmos DB for PostgreSQL är att använda själva tidsstämpeln som distributionskolumn. En hash-fördelning baserat på tid distribuerar tider till synes slumpmässigt till olika shards i stället för att hålla ihop tidsintervall i shards. Frågor som omfattar tid refererar vanligtvis till tidsintervall, till exempel de senaste data. Den här typen av hash-distribution leder till nätverksomkostnader.

Bästa praxis

  • Välj inte en tidsstämpel som distributionskolumn. Välj en annan distributionskolumn. I en app för flera innehavare använder du klientorganisations-ID:t, eller i en realtidsapp använder du entitets-ID:t.
  • Använd PostgreSQL-tabellpartitionering för tid i stället. Använd tabellpartitionering för att dela upp en stor tabell med tidsbeställda data i flera ärvda tabeller med varje tabell som innehåller olika tidsintervall. När du distribuerar en Postgres-partitionerad tabell skapas shards för de ärvda tabellerna.

Nästa steg