Dela via

Överväganden för dataplattform för verksamhetskritiska arbetsbelastningar i Azure

  • Artikel

Valet av en effektiv programdataplattform är ytterligare ett avgörande beslutsområde, som har långtgående konsekvenser inom andra designområden. Azure erbjuder i slutändan en mängd olika relations-, icke-relationella och analytiska dataplattformar, som skiljer sig mycket åt i funktion. Det är därför viktigt att viktiga icke-funktionella krav beaktas fullt ut tillsammans med andra beslutsfaktorer som konsekvens, driftbarhet, kostnad och komplexitet. Möjligheten att arbeta i en skrivkonfiguration i flera regioner har till exempel en viktig betydelse för lämpligheten för en globalt tillgänglig plattform.

Det här designområdet utökar programdesignen och ger viktiga överväganden och rekommendationer för att informera valet av en optimal dataplattform.

Viktigt!

Den här artikeln är en del av den verksamhetskritiska arbetsbelastningsserien Azure Well-Architected. Om du inte är bekant med den här serien rekommenderar vi att du börjar med vad som är en verksamhetskritisk arbetsbelastning?

De fyra jämfört med stordata

"Four Vs of Big Data" tillhandahåller ett ramverk för att bättre förstå nödvändiga egenskaper för en dataplattform med hög tillgänglighet och hur data kan användas för att maximera affärsvärdet. Det här avsnittet utforskar därför hur egenskaperna Volym, Hastighet, Variation och Sanningshalt kan tillämpas på konceptuell nivå för att utforma en dataplattform med hjälp av lämpliga datatekniker.

  • Volume: hur mycket data som kommer in för att informera lagringskapacitet och nivåindelningskrav – det är storleken på datauppsättningen.
  • V-elocity: den hastighet med vilken data bearbetas, antingen som batchar eller kontinuerliga strömmar – det är flödeshastigheten.
  • V-ariety: organisationen och formatet för data, insamling av strukturerade, halvstrukturerade och ostrukturerade format – det vill sig vara data i flera lager eller typer.
  • V-radering: omfattar proveniens och kuration av övervägda datauppsättningar för styrning och kvalitetssäkring av data – det vill sig vara datanoggrannhet.

Designöverväganden

Volume

  • Befintliga (om några) och förväntade framtida datavolymer baserat på prognostiserade datatillväxthastigheter i linje med affärsmål och planer.

    • Datavolymen bör omfatta själva data och index, loggar, telemetri och andra tillämpliga datauppsättningar.
    • Stora affärskritiska och verksamhetskritiska program genererar och lagrar vanligtvis stora volymer (GB och TB) dagligen.
    • Det kan finnas betydande kostnadskonsekvenser i samband med dataexpansion.

  • Datavolymen kan variera på grund av förändrade affärsförhållanden eller hushållningsprocedurer.

  • Datavolym kan ha en djupgående inverkan på dataplattformens frågeprestanda.

  • Det kan finnas en djupgående inverkan som är kopplad till att nå dataplattformens volymgränser.

    • Kommer det att leda till stilleståndstid? och i så fall, hur länge?
    • Vilka är åtgärdsprocedurerna? och kommer åtgärder att kräva programändringar?
    • Finns det risk för dataförlust?

  • Funktioner som TTL (Time to Live) kan användas för att hantera datatillväxt genom att automatiskt ta bort poster efter en förfluten tid, antingen genom att skapa eller ändra poster.

    • Azure Cosmos DB tillhandahåller till exempel en inbyggd TTL-funktion.

Hastighet

  • Den hastighet med vilken data genereras från olika programkomponenter och dataflödeskraven för hur snabbt data behöver checkas in och hämtas är avgörande för att fastställa en optimal datateknik för viktiga arbetsbelastningsscenarier.

    • Dataflödeskraven varierar beroende på arbetsbelastningsscenario, till exempel de som är läsintensiva eller skrivintensiva.
      • Till exempel behöver analytiska arbetsbelastningar vanligtvis tillgodose ett stort läsdataflöde.
    • Vilket dataflöde krävs? Och hur förväntas dataflödet växa?
    • Vilka krav gäller för datafördröjning på P50/P99 under referensbelastningsnivåer?

  • Funktioner som att stödja en låsfri design, indexjustering och konsekvensprinciper är avgörande för att uppnå högt dataflöde.

    • Att optimera konfigurationen för högt dataflöde medför kompromisser, vilket bör förstås fullt ut.
    • Belastningsutjämningspersistence och meddelandemönster, till exempel CQRS och Händelsekällor, kan användas för att ytterligare optimera dataflödet.

  • Belastningsnivåer varierar naturligt för många programscenarier, med naturliga toppar som kräver en tillräcklig elasticitet för att hantera variabel efterfrågan samtidigt som dataflödet och svarstiden bibehålls.

    • Flexibel skalbarhet är nyckeln till att effektivt stödja variabelt dataflöde och belastningsnivåer utan överetablering av kapacitetsnivåer.
      • Både läs- och skrivdataflöde måste skalas enligt programkrav och belastning.
      • Både lodräta och vågräta skalningsåtgärder kan användas för att svara på ändrade belastningsnivåer.

  • Effekten av dataflödesdippar kan variera beroende på arbetsbelastningsscenario.

    • Kommer det att uppstå anslutningsstörningar?
    • Returnerar enskilda åtgärder felkoder medan kontrollplanet fortsätter att fungera?
    • Kommer dataplattformen att aktivera begränsning och i så fall hur länge?

  • Den grundläggande rekommendationen för programdesign för användning av en aktiv-aktiv geografisk distribution medför utmaningar kring datakonsekvens.

    • Det finns en kompromiss mellan konsekvens och prestanda när det gäller fullständig ACID-transaktionssemantik och traditionellt låsbeteende.
      • Att minimera skrivfördröjningen sker på bekostnad av datakonsekvens.

  • I en skrivkonfiguration i flera regioner måste ändringar synkroniseras och sammanfogas mellan alla repliker, med konfliktlösning där det behövs, och detta kan påverka prestandanivåer och skalbarhet.

  • Skrivskyddade repliker (intra-region och mellan regioner) kan användas för att minimera svarstiden tur och retur och distribuera trafik för att öka prestanda, dataflöde, tillgänglighet och skalbarhet.

  • Ett cachelagringslager kan användas för att öka läsflödet för att förbättra användarupplevelsen och svarstiderna från slutpunkt till slutpunkt.

    • Förfallotider och principer för cachelagring måste övervägas för att optimera data senaste tid.

Mångfald

  • Datamodellen, datatyper, datarelationer och den avsedda frågemodellen påverkar dataplattformsbeslut.

    • Kräver programmet en relationsdatamodell eller kan det ha stöd för en variabel-schema- eller icke-relationsdatamodell?
    • Hur frågar programmet efter data? Och beror frågor på begrepp på databasnivå, till exempel relationskopplingar? Eller tillhandahåller programmet sådan semantik?

  • De datauppsättningar som programmet tar hänsyn till kan variera från ostrukturerat innehåll som bilder och videor eller mer strukturerade filer som CSV och Parquet.

    • Sammansatta programarbetsbelastningar har vanligtvis distinkta datauppsättningar och tillhörande krav.

  • Förutom relations- eller icke-relationsdataplattformar kan graf- eller nyckelvärdesdataplattformar också vara lämpliga för vissa dataarbetsbelastningar.

    • Vissa tekniker hanterar datamodeller med variabelt schema, där dataobjekt är semantiskt lika och/eller lagras och efterfrågas tillsammans men skiljer sig strukturellt.

  • I en mikrotjänstarkitektur kan enskilda programtjänster skapas med distinkta scenariooptimerade datalager i stället för beroende på ett enda monolitiskt datalager.

    • Designmönster som SAGA kan användas för att hantera konsekvens och beroenden mellan olika datalager.
      • Direktfrågor mellan databaser kan införa begränsningar för samplacering.
    • Användningen av flera datatekniker kommer att lägga till en viss grad av hanteringskostnader för att underhålla omfattande tekniker.

  • Funktionsuppsättningarna för varje Azure-tjänst skiljer sig åt mellan språk, SDK:er och API:er, vilket i hög grad kan påverka den konfigurationsnivå som kan tillämpas.

  • Funktioner för optimerad anpassning till datamodellen och omfattade datatyper kommer starkt att påverka beslut på dataplattformen.

    • Frågelager som lagrade procedurer och objektrelationsmappare.
    • Språkneutral frågefunktion, till exempel ett skyddat REST API-lager.
    • Funktioner för affärskontinuitet, till exempel säkerhetskopiering och återställning.

  • Analytiska datalager stöder vanligtvis flerspråkig lagring för olika typer av datastrukturer.

    • Analytiska körningsmiljöer, till exempel Apache Spark, kan ha integreringsbegränsningar för att analysera flerspråkiga datastrukturer.

  • I företagssammanhang kan användningen av befintliga processer och verktyg samt kontinuiteten i färdigheter ha stor betydelse för dataplattformens utformning och val av datateknik.

Sanning

  • Flera faktorer måste beaktas för att verifiera noggrannheten för data i ett program, och hanteringen av dessa faktorer kan ha en betydande betydelse för utformningen av dataplattformen.

    • Datakonsekvens.
    • Plattformssäkerhetsfunktioner.
    • Datastyrning.
    • Ändringshantering och schemautveckling.
    • Beroenden mellan datauppsättningar.

  • I alla distribuerade program med flera datarepliker finns det en kompromiss mellan konsekvens och svarstid, vilket uttrycks i CAP- och PACELC-theorems.

    • När läsare och skrivare är tydligt distribuerade måste ett program välja att returnera antingen den snabbaste tillgängliga versionen av ett dataobjekt, även om det är inaktuellt jämfört med en just slutförd skrivning (uppdatering) av dataobjektet i en annan replik eller den senaste versionen av dataobjektet, vilket kan medföra ytterligare svarstid för att fastställa och hämta det senaste tillståndet.
    • Konsekvens och tillgänglighet kan konfigureras på plattformsnivå eller på enskild databegäransnivå.
    • Vad är användarupplevelsen om data skulle hanteras från en replik närmast användaren som inte återspeglar det senaste tillståndet för en annan replik? Det vill säga kan programmet ha stöd för att eventuellt betjäna inaktuella data?

  • I en skrivkontext för flera regioner skapas en konflikt som måste lösas när samma dataobjekt ändras i två separata skrivrepliker innan någon av ändringarna kan replikeras.

    • Standardiserade konfliktlösningsprinciper, till exempel "Senaste skrivning vinner" eller en anpassad strategi med anpassad logik kan tillämpas.

  • Implementeringen av säkerhetskrav kan påverka dataflödet eller prestandan negativt.

  • Kryptering i vila kan implementeras i programskiktet med kryptering på klientsidan och/eller dataskiktet med kryptering på serversidan om det behövs.

  • Azure stöder olika krypteringsmodeller, inklusive kryptering på serversidan som använder tjänsthanterade nycklar, kundhanterade nycklar i Key Vault eller kundhanterade nycklar på kundkontrollerad maskinvara.

    • Med kryptering på klientsidan kan nycklar hanteras i Key Vault eller på en annan säker plats.

  • MACsec-datalänkkryptering (IEEE 802.1AE MAC) används för att skydda all trafik som rör sig mellan Azure-datacenter i Microsofts stamnätverk.

    • Paket krypteras och dekrypteras på enheterna innan de skickas, vilket förhindrar fysiska "man-in-the-middle" eller snokande/avlyssningsattacker.

  • Autentisering och auktorisering till dataplanet och kontrollplanet.

    • Hur autentiserar och auktoriserar dataplattformen programåtkomst och driftåtkomst?

  • Observerbarhet genom övervakning av plattformens hälsa och dataåtkomst.

    • Hur tillämpas aviseringar för villkor utanför godtagbara driftsgränser?

Designrekommendationer

Volume

  • Se till att framtida datavolymer som är associerade med organisk tillväxt inte förväntas överskrida dataplattformsfunktionerna.

    • Prognostisera datatillväxt som är anpassade till affärsplaner och använda etablerade priser för att informera pågående kapacitetskrav.
    • Jämför aggregerade och postvolymer per data med dataplattformsgränser.
    • Om det finns en risk för att gränser nås under exceptionella omständigheter, se till att operativa åtgärder finns på plats för att förhindra driftstopp och dataförlust.

  • Övervaka datavolymen och verifiera den mot en kapacitetsmodell, med tanke på skalningsgränser och förväntad datatillväxt.

    • Se till att skalningsåtgärderna överensstämmer med kraven på lagring, prestanda och konsekvens.
    • När en ny skalningsenhet introduceras kan underliggande data behöva replikeras, vilket tar tid och sannolikt medför en prestandastraff när replikeringen sker. Se därför till att dessa åtgärder utförs utanför kritiska kontorstider om möjligt.

  • Definiera programdatanivåer för att klassificera datauppsättningar baserat på användning och kritiskhet för att underlätta borttagning eller avlastning av äldre data.

    • Överväg att klassificera datauppsättningar i nivåerna "hot", "warm" och "cold" ("arkiv").
      • Till exempel använder de grundläggande referensimplementeringarna Azure Cosmos DB för att lagra "frekventa" data som aktivt används av programmet, medan Azure Storage används för "kalla" driftdata i analyssyfte.

  • Konfigurera hushållningsprocedurer för att optimera datatillväxt och öka dataeffektiviteten, till exempel frågeprestanda och hantera dataexpansion.

    • Konfigurera TTL-förfallotid (Time-To-Live) för data som inte längre krävs och som inte har något långsiktigt analysvärde.
      • Kontrollera att gamla data på ett säkert sätt kan nivåindelas till sekundär lagring eller tas bort direkt, utan att programmet påverkas negativt.
    • Avlasta icke-kritiska data till sekundär kall lagring, men underhålla dem för analysvärde och för att uppfylla granskningskraven.
    • Samla in dataplattformens telemetri- och användningsstatistik för att göra det möjligt för DevOps-team att kontinuerligt utvärdera hushållningskrav och "rätt storlek" datalager.

  • I linje med en design för mikrotjänstprogram bör du överväga att använda flera olika datatekniker parallellt, med optimerade datalösningar för specifika arbetsbelastningsscenarier och volymkrav.

    • Undvik att skapa ett enda monolitiskt datalager där datavolymen från expansion kan vara svår att hantera.

Hastighet

  • Dataplattformen måste utformas och konfigureras för att stödja högt dataflöde, med arbetsbelastningar uppdelade i olika kontexter för att maximera prestanda med scenariooptimerade datalösningar.

    • Se till att läs- och skrivdataflödet för varje datascenario kan skalas enligt förväntade belastningsmönster, med tillräcklig tolerans för oväntad varians.
    • Avgränsa olika dataarbetsbelastningar, till exempel transaktions- och analysåtgärder, i distinkta prestandakontexter.

  • Belastningsnivå genom användning av asynkrona icke-blockerande meddelanden, till exempel med hjälp av mönster för CQRS eller händelsekällor .

    • Det kan finnas svarstider mellan skrivbegäranden och när nya data blir tillgängliga för läsning, vilket kan påverka användarupplevelsen.
      • Den här effekten måste förstås och godkännas i samband med viktiga affärskrav.

  • Se till att skalbarheten är flexibel för att stödja variabelt dataflöde och belastningsnivåer.

    • Om belastningsnivåerna är mycket instabila bör du överväga överetablering av kapacitetsnivåer för att säkerställa att dataflödet och prestandan bibehålls.
    • Testa och verifiera effekten på sammansatta programarbetsbelastningar när dataflödet inte kan upprätthållas.

  • Prioritera Azure-interna datatjänster med automatiserade skalningsåtgärder för att underlätta ett snabbt svar på volatiliteten på belastningsnivå.

    • Konfigurera automatisk skalning baserat på tjänstinterna tröskelvärden och tröskelvärden för programuppsättningar.
    • Skalning bör initieras och slutföras inom tidsramar som är förenliga med affärskraven.
    • För scenarier där manuell interaktion är nödvändig bör du upprätta automatiserade operativa "spelböcker" som kan utlösas i stället för att utföra manuella operativa åtgärder.
      • Överväg om automatiserade utlösare kan användas som en del av efterföljande tekniska investeringar.

  • Övervaka dataläsning och skrivning av programdata mot P50/P99-svarstidskrav och justera efter en programkapacitetsmodell.

  • Överflödigt dataflöde ska hanteras korrekt av dataplattformen eller programskiktet och samlas in av hälsomodellen för driftrepresentation.

  • Implementera cachelagring för frekventa datascenarier för att minimera svarstiderna.

    • Tillämpa lämpliga principer för cacheförfallotid och hushållning för att undvika skenande datatillväxt.
      • Förfalla cacheobjekt när säkerhetskopieringsdata ändras.
      • Om cacheförfallotiden är strikt TTL-baserad (Time-To-Live) måste påverkan och kundupplevelsen av att hantera inaktuella data förstås.

Mångfald

  • I enlighet med principen för en moln- och Azure-inbyggd design rekommenderar vi starkt att du prioriterar hanterade Azure-tjänster för att minska drifts- och hanteringskomplexiteten och dra nytta av Microsofts framtida plattformsinvesteringar.

  • I linje med programdesignprincipen för löst kopplade mikrotjänstarkitekturer kan enskilda tjänster använda distinkta datalager och scenariooptimerade datatekniker.

    • Identifiera vilka typer av datastruktur som programmet ska hantera för specifika arbetsbelastningsscenarier.
    • Undvik att skapa ett beroende av ett enda monolitiskt datalager.

  • Kontrollera att nödvändiga funktioner är tillgängliga för valda datatekniker.

    • Se till att du har stöd för nödvändiga språk och SDK-funktioner. Alla funktioner är inte tillgängliga för alla språk/SDK på samma sätt.

Sanning

  • Anta en dataplattformsdesign för flera regioner och distribuera repliker mellan regioner för maximal tillförlitlighet, tillgänglighet och prestanda genom att flytta data närmare programslutpunkter.

    • Distribuera datarepliker mellan tillgänglighetszoner (AZs) inom en region (eller använd zonredundanta tjänstnivåer) för att maximera tillgängligheten inom regionen.

  • Där konsekvenskraven tillåter det kan du använda en design för skrivdataplattform i flera regioner för att maximera den övergripande globala tillgängligheten och tillförlitligheten.

    • Överväg affärskrav för konfliktlösning när samma dataobjekt ändras i två separata skrivrepliker innan någon av ändringarna kan replikeras och därmed skapa en konflikt.
      • Använd standardiserade konfliktlösningsprinciper som "Senaste vinner" där det är möjligt
        • Om en anpassad strategi med anpassad logik krävs kontrollerar du att CI/CD DevOps-metoder tillämpas för att hantera anpassad logik.

  • Testa och validera säkerhetskopierings- och återställningsfunktioner samt redundansåtgärder genom kaostestning i kontinuerliga leveransprocesser.

  • Kör prestandamått för att säkerställa att dataflödes- och prestandakrav inte påverkas av att nödvändiga säkerhetsfunktioner inkluderas, till exempel kryptering.

    • Se till att kontinuerliga leveransprocesser överväger belastningstestning mot kända prestandamått.

  • När kryptering tillämpas rekommenderar vi starkt att du använder tjänsthanterade krypteringsnycklar som ett sätt att minska hanteringskomplexiteten.

    • Om det finns ett specifikt säkerhetskrav för kundhanterade nycklar ska du se till att lämpliga nyckelhanteringsprocedurer tillämpas för att säkerställa tillgänglighet, säkerhetskopiering och rotation av alla övervägda nycklar.

Kommentar

När du integrerar med en bredare organisationsimplementering är det viktigt att en programcentrerad metod tillämpas för etablering och drift av dataplattformskomponenter i en programdesign.

Mer specifikt, för att maximera tillförlitligheten är det viktigt att enskilda dataplattformskomponenter på lämpligt sätt svarar på programmets hälsa genom operativa åtgärder som kan omfatta andra programkomponenter. I ett scenario där ytterligare dataplattformsresurser behövs kommer det sannolikt att krävas skalning av dataplattformen tillsammans med andra programkomponenter enligt en kapacitetsmodell, eventuellt genom att ytterligare skalningsenheter etableras. Den här metoden kommer i slutändan att begränsas om det finns ett hårt beroende av ett centraliserat driftsteam för att hantera problem som rör dataplattformen isolerat.

I slutändan medför användningen av centraliserade datatjänster (dvs. central IT DBaaS) driftsflaskhalsar som avsevärt hindrar flexibiliteten genom en i stort sett okontextualiserad hanteringsupplevelse och bör undvikas i ett verksamhetskritiskt eller affärskritiskt sammanhang.

Ytterligare referenser

Ytterligare vägledning för dataplattformen finns i Azure Application Architecture Guide.

Globalt distribuerat skrivdatalager för flera regioner

För att fullt ut hantera de globalt distribuerade aktiva-aktiva ambitionerna för en programdesign rekommenderar vi starkt att du överväger en distribuerad plattform för skrivdata i flera regioner, där ändringar i separata skrivbara repliker synkroniseras och sammanfogas mellan alla repliker, med konfliktlösning där det behövs.

Viktigt!

Mikrotjänsterna kanske inte alla kräver ett distribuerat skrivdatalager för flera regioner, så hänsyn bör tas till arkitekturkontexten och affärskraven för varje arbetsbelastningsscenario.

Azure Cosmos DB tillhandahåller ett globalt distribuerat och högtillgängligt NoSQL-datalager som erbjuder skrivningar i flera regioner och justerbar konsekvens out-of-the-box. Designöverväganden och rekommendationerna i det här avsnittet fokuserar därför på optimal Användning av Azure Cosmos DB.

Utformningsbeaktanden

Azure Cosmos DB

  • Azure Cosmos DB lagrar data i containrar, som är indexerade, radbaserade transaktionslager som är utformade för att möjliggöra snabba transaktionsläsningar och skrivningar med svarstider i storleksordningen millisekunder.

  • Azure Cosmos DB stöder flera olika API:er med olika funktionsuppsättningar, till exempel SQL, Cassandra och MongoDB.

    • Azure Cosmos DB for NoSQL från första part tillhandahåller den rikaste funktionsuppsättningen och är vanligtvis det API där nya funktioner blir tillgängliga först.

  • Azure Cosmos DB har stöd för gateway- och direktanslutningslägen, där Direct underlättar anslutningen via TCP till serverdelsrepliknoder i Azure Cosmos DB för bättre prestanda med färre nätverkshopp, medan Gateway tillhandahåller HTTPS-anslutning till klientdelsgatewaynoder.

    • Direktläge är endast tillgängligt när du använder Azure Cosmos DB för NoSQL och stöds för närvarande endast på .NET- och Java SDK-plattformar.

  • I regioner som är aktiverade i tillgänglighetszonen erbjuder Azure Cosmos DB stöd för redundans för tillgänglighetszoner (AZ) för hög tillgänglighet och återhämtning till zonfel i en region.

  • Azure Cosmos DB underhåller fyra repliker av data i en enda region, och när redundans för tillgänglighetszoner (AZ) aktiveras ser Azure Cosmos DB till att datarepliker placeras över flera AZ:er för att skydda mot zonfel.

    • Paxos-konsensusprotokollet tillämpas för att uppnå kvorum mellan repliker i en region.

  • Ett Azure Cosmos DB-konto kan enkelt konfigureras för att replikera data i flera regioner för att minska risken för att en enskild region blir otillgänglig.

    • Replikering kan konfigureras med skrivningar med en region eller skrivningar i flera regioner.
      • Med skrivningar i en enda region används en primär hubbregion för att hantera alla skrivningar och om den här hubbregionen blir otillgänglig måste en redundansåtgärd utföras för att höja upp en annan region som skrivbar.
      • Med skrivningar i flera regioner kan program skriva till valfri konfigurerad distributionsregion, vilket replikerar ändringar mellan alla andra regioner. Om en region inte är tillgänglig används de återstående regionerna för att hantera skrivtrafik.

  • I en skrivkonfiguration i flera regioner kan konflikter med uppdatering (infoga, ersätt, ta bort) uppstå där skrivare samtidigt uppdaterar samma objekt i flera regioner.

  • Azure Cosmos DB innehåller två konfliktlösningsprinciper som kan tillämpas för att automatiskt hantera konflikter.

    • Last Write Wins (LWW) tillämpar ett tidssynkroniseringsklockaprotokoll med hjälp av en systemdefinierad tidsstämpelegenskap _ts som konfliktlösningssökväg. Om en konflikt uppstår blir objektet med det högsta värdet för konfliktlösningssökvägen vinnare, och om flera objekt har samma numeriska värde väljer systemet en vinnare så att alla regioner kan konvergera till samma version av det bekräftade objektet.
      • Med borttagningskonflikter vinner den borttagna versionen alltid över antingen infoga eller ersätta konflikter oavsett sökvägsvärde för konfliktlösning.
      • Senaste skrivvinster är standardprincipen för konfliktlösning.
      • När du använder Azure Cosmos DB för NoSQL kan en anpassad numerisk egenskap, till exempel en anpassad tidsstämpeldefinition, användas för konfliktlösning.
    • Anpassade lösningsprinciper gör det möjligt för programdefinierade semantik att stämma av konflikter med hjälp av en registrerad sammanslagnings lagrad procedur som anropas automatiskt när konflikter identifieras.
      • Systemet ger exakt en gång garanti för körning av en sammanslagningsprocedur som en del av åtagandeprotokollet.
      • En anpassad konfliktlösningsprincip är endast tillgänglig med Azure Cosmos DB för NoSQL och kan endast anges vid tidpunkten för containerskapande.

  • I en skrivkonfiguration för flera regioner finns det ett beroende av en enda Azure Cosmos DB-hubbregion för att utföra alla konfliktlösningslösningar, där Paxos-konsensusprotokollet tillämpas för att uppnå kvorum mellan repliker i hubbregionen.

    • Plattformen tillhandahåller en meddelandebuffert för skrivkonflikter i hubbregionen för att läsa in nivå och tillhandahålla redundans för tillfälliga fel.
      • Bufferten kan lagra några minuters skrivuppdateringar som kräver konsensus.

Den strategiska riktningen för Azure Cosmos DB-plattformen är att ta bort det här beroendet av konfliktlösning i en skrivkonfiguration för flera regioner, med hjälp av en Paxos-metod med två faser för att uppnå kvorum på global nivå och inom en region.

  • Den primära hubbregionen bestäms av den första regionen som Azure Cosmos DB har konfigurerats inom.

    • En prioritetsordning konfigureras för ytterligare satellitdistributionsregioner i redundanssyfte.

  • Datamodellen och partitioneringen mellan logiska och fysiska partitioner spelar en viktig roll för att uppnå optimal prestanda och tillgänglighet.

  • När du distribuerar med en enda skrivregion kan Azure Cosmos DB konfigureras för automatisk redundans baserat på en definierad redundansprioritet med tanke på alla repliker i läsregionen.

  • Den rto som tillhandahålls av Azure Cosmos DB-plattformen är cirka 10–15 minuter, vilket fångar upp den förflutna tiden för att utföra en regional redundansväxling av Azure Cosmos DB-tjänsten om en katastrofal katastrof påverkar hubben.

    • Denna RTO är också relevant i en skrivkontext för flera regioner med tanke på beroendet av en enda hubbregion för konfliktlösning.
      • Om hubbregionen blir otillgänglig misslyckas skrivningar till andra regioner efter att meddelandebufferten har fyllts eftersom konfliktlösning inte kan inträffa förrän tjänsten redundansväxlar och en ny hubbregion har upprättats.

Den strategiska riktningen för Azure Cosmos DB-plattformen är att minska RTO till ~5 minuter genom att tillåta redundans på partitionsnivå.

  • Mål för återställningspunkter (RPO) och mål för återställningstid (RTO) kan konfigureras via konsekvensnivåer, med en kompromiss mellan datahållbarhet och dataflöde.

    • Azure Cosmos DB ger en lägsta RTO på 0 för en avslappnad konsekvensnivå med skrivningar i flera regioner eller ett RPO på 0 för stark konsekvens med en skrivregion.

  • Azure Cosmos DB erbjuder ett serviceavtal på 99,999 % för både läs- och skrivtillgänglighet för databaskonton som konfigurerats med flera Azure-regioner som skrivbara.

    • Serviceavtalet representeras av den månatliga drifttidsprocenten, som beräknas som 100 % – genomsnittlig felfrekvens.
    • Genomsnittlig felfrekvens definieras som summan av felfrekvenser för varje timme under faktureringsmånaden dividerat med det totala antalet timmar i faktureringsmånaden, där felfrekvensen är det totala antalet misslyckade begäranden dividerat med totalt antal begäranden under ett visst entimmesintervall.

  • Azure Cosmos DB erbjuder ett serviceavtal på 99,99 % för dataflöde, konsekvens, tillgänglighet och svarstid för databaskonton som är begränsade till en enda Azure-region när de konfigureras med någon av de fem konsekvensnivåerna.

    • Ett serviceavtal på 99,99 % gäller även för databaskonton som sträcker sig över flera Azure-regioner som konfigurerats med någon av de fyra avslappnade konsekvensnivåerna.

  • Det finns två typer av dataflöde som kan etableras i Azure Cosmos DB, standard och autoskalning, som mäts med hjälp av enheter för begäranden per sekund (RU/s).

    • Standarddataflödet allokerar resurser som krävs för att garantera ett angivet RU/s-värde.
      • Standard faktureras varje timme för etablerat dataflöde.
    • Autoskalning definierar ett maximalt dataflödesvärde och Azure Cosmos DB skalas automatiskt upp eller ned beroende på programbelastning, mellan det maximala dataflödesvärdet och minst 10 % av det maximala dataflödesvärdet.
      • Autoskalning faktureras varje timme för maximalt förbrukat dataflöde.

  • Statiskt etablerat dataflöde med en variabel arbetsbelastning kan leda till begränsningsfel, vilket påverkar den upplevda programtillgängligheten.

    • Autoskalning skyddar mot begränsningsfel genom att göra det möjligt för Azure Cosmos DB att skalas upp efter behov, samtidigt som kostnadsskyddet bibehålls genom att minska belastningen när belastningen minskar.

  • När Azure Cosmos DB replikeras mellan flera regioner debiteras de etablerade enheter för begäran (RU: er) per region.

  • Det finns ett betydande kostnadsdelta mellan en konfiguration för skrivning i flera regioner och en region, vilket i många fall kan göra en Azure Cosmos DB-dataplattform med flera masterkostnader oöverkomlig.

Läs-/skrivbehörighet för enskild region Skrivning i en region – Läs med dubbla regioner Läs/skriv med dubbla regioner
1 RU 2 RU 4 RU

Deltat mellan enskild region-skrivning och multi-region-write är faktiskt mindre än 1:2-förhållandet som återspeglas i tabellen ovan. Mer specifikt finns det en avgift för dataöverföring mellan regioner som är associerad med skrivuppdateringar i en konfiguration med en enda skrivning, som inte samlas in inom RU-kostnaderna som med skrivkonfigurationen för flera regioner.

  • Förbrukad lagring faktureras som en fast ränta för den totala mängden lagringsutrymme (GB) som förbrukas för värddata och index under en viss timme.

  • Session är standard och den mest använda konsekvensnivån eftersom data tas emot i samma ordning som skrivningar.

  • Azure Cosmos DB stöder autentisering via antingen en Microsoft Entra-identitet eller Azure Cosmos DB-nycklar och resurstoken, vilket ger överlappande funktioner.

Åtkomstfunktioner i Azure Cosmos DB

  • Det går att inaktivera resurshanteringsåtgärder med hjälp av nycklar eller resurstoken för att begränsa nycklar och resurstoken endast till dataåtgärder, vilket möjliggör detaljerad resursåtkomstkontroll med hjälp av rollbaserad åtkomstkontroll i Microsoft Entra (RBAC).

    • Om du begränsar åtkomsten till kontrollplanet via nycklar eller resurstoken inaktiveras kontrollplansåtgärder för klienter som använder Azure Cosmos DB-SDK:er och bör därför utvärderas och testas noggrant.
    • Inställningen disableKeyBasedMetadataWriteAccess kan konfigureras via ARM Template IaC-definitioner eller via en inbyggd Azure-princip.

  • Microsoft Entra RBAC-stöd i Azure Cosmos DB gäller för hanteringsåtgärder för konto- och resurskontrollplan.

    • Programadministratörer kan skapa rolltilldelningar för användare, grupper, tjänstens huvudnamn eller hanterade identiteter för att bevilja eller neka åtkomst till resurser och åtgärder på Azure Cosmos DB-resurser.
    • Det finns flera inbyggda RBAC-roller som är tillgängliga för rolltilldelning, och anpassade RBAC-roller kan också användas för att bilda specifika behörighetskombinationer.
      • Cosmos DB-kontoläsaren ger skrivskyddad åtkomst till Azure Cosmos DB-resursen.
      • DocumentDB-kontodeltagare möjliggör hantering av Azure Cosmos DB-konton, inklusive nycklar och rolltilldelningar, men aktiverar inte dataplansåtkomst.
      • Cosmos DB-operator, som liknar DocumentDB-kontodeltagare, men inte ger möjlighet att hantera nycklar eller rolltilldelningar.

  • Azure Cosmos DB-resurser (konton, databaser och containrar) kan skyddas mot felaktig ändring eller borttagning med hjälp av resurslås.

    • Resurslås kan anges på konto-, databas- eller containernivå.
    • Ett resurslås som anges på på en resurs ärvs av alla underordnade resurser. Till exempel ärvs en resurslåsuppsättning på Azure Cosmos DB-kontot av alla databaser och containrar i kontot.
    • Resurslås gäller endast för kontrollplansåtgärder och förhindrar inte dataplansåtgärder, till exempel att skapa, ändra eller ta bort data.
    • Om åtkomsten till kontrollplanet inte är begränsad med disableKeyBasedMetadataWriteAccesskan klienterna utföra kontrollplansåtgärder med hjälp av kontonycklar.

  • Azure Cosmos DB-ändringsflödet ger en tidsbeställd feed med ändringar av data i en Azure Cosmos DB-container.

    • Ändringsflödet innehåller endast infognings- och uppdateringsåtgärder till Azure Cosmos DB-källcontainern. Den innehåller inte borttagningar.

  • Ändringsflödet kan användas för att underhålla ett separat datalager från den primära containern som används av programmet, med pågående uppdateringar av måldatalagret som matas av ändringsflödet från källcontainern.

    • Ändringsflödet kan användas för att fylla i ett sekundärt lager för ytterligare redundans för dataplattformen eller för efterföljande analysscenarier.

  • Om borttagningsåtgärder rutinmässigt påverkar data i källcontainern blir det arkiv som matas av ändringsflödet felaktigt och inte störande för borttagna data.

    • Ett mönster för mjuk borttagning kan implementeras så att dataposter inkluderas i ändringsflödet.
      • I stället för att explicit ta bort dataposter uppdateras dataposter genom att ange en flagga (t.ex. IsDeleted) som anger att objektet anses vara borttaget.
      • Alla måldatalager som matas av ändringsflödet måste identifiera och bearbeta objekt med en borttagen flagga inställd på Sant. I stället för att lagra mjukt borttagna dataposter måste den befintliga versionen av dataposten i mållagret tas bort.
    • En kort TTL (Time-To-Live) används vanligtvis med mönstret för mjuk borttagning så att Azure Cosmos DB automatiskt tar bort utgångna data, men först efter att de återspeglas i ändringsflödet med den borttagna flaggan inställd på Sant.
      • Utför den ursprungliga borttagnings avsikten samtidigt som borttagningen sprids via ändringsflödet.

  • Azure Cosmos DB kan konfigureras som ett analysarkiv, vilket tillämpar ett kolumnformat för optimerade analysfrågor för att hantera de komplexitets- och svarstidsutmaningar som uppstår med de traditionella ETL-pipelines.

  • Azure Cosmos DB säkerhetskopierar automatiskt data med jämna mellanrum utan att påverka prestanda eller tillgänglighet, och utan att använda RU/s.

  • Azure Cosmos DB kan konfigureras enligt två distinkta säkerhetskopieringslägen.

    • Periodisk är standardläget för säkerhetskopiering för alla konton, där säkerhetskopior görs med jämna mellanrum och data återställs genom att skapa en begäran med supportteamet.
      • Standardperioden för periodisk kvarhållning av säkerhetskopior är åtta timmar och standardintervallet för säkerhetskopiering är fyra timmar, vilket innebär att endast de två senaste säkerhetskopiorna lagras som standard.
      • Säkerhetskopieringsintervallet och kvarhållningsperioden kan konfigureras i kontot.
        • Den maximala kvarhållningsperioden sträcker sig till en månad med ett minsta säkerhetskopieringsintervall på en timme.
        • En rolltilldelning till Azure "Cosmos DB Account Reader Role" krävs för att konfigurera redundans för lagring av säkerhetskopior.
      • Två säkerhetskopior ingår utan extra kostnad, men ytterligare säkerhetskopior medför ytterligare kostnader.
      • Som standard lagras periodiska säkerhetskopior i separat geo-redundant lagring (GRS) som inte är direkt åtkomlig.
        • Lagring av säkerhetskopior finns i den primära hubbregionen och replikeras till den kopplade regionen via underliggande lagringsreplikering.
        • Redundanskonfigurationen för det underliggande lagringskontot för säkerhetskopiering kan konfigureras till zonredundant lagring eller lokalt redundant lagring.
      • För att utföra en återställningsåtgärd krävs en supportbegäran eftersom kunderna inte kan utföra en återställning direkt.
        • Innan du öppnar ett supportärende bör kvarhållningsperioden för säkerhetskopiering ökas till minst sju dagar inom åtta timmar efter dataförlusthändelsen.
      • En återställningsåtgärd skapar ett nytt Azure Cosmos DB-konto där data återställs.
        • Ett befintligt Azure Cosmos DB-konto kan inte användas för återställning
        • Som standard används ett nytt Azure Cosmos DB-konto med namnet <Azure_Cosmos_account_original_name>-restored<n> .
          • Det här namnet kan justeras, till exempel genom att återanvända det befintliga namnet om det ursprungliga kontot togs bort.
      • Om dataflödet etableras på databasnivå sker säkerhetskopiering och återställning på databasnivå
        • Det går inte att välja en delmängd av containrar som ska återställas.
    • Läget för kontinuerlig säkerhetskopiering möjliggör en återställning till valfri tidpunkt under de senaste 30 dagarna.
      • Återställningsåtgärder kan utföras för att återgå till en viss tidpunkt (PITR) med en sekunds kornighet.
      • Det tillgängliga fönstret för återställningsåtgärder är upp till 30 dagar.
        • Det går också att återställa till resursens instansieringstillstånd.
      • Kontinuerliga säkerhetskopieringar görs inom varje Azure-region där Azure Cosmos DB-kontot finns.
        • Kontinuerliga säkerhetskopior lagras i samma Azure-region som varje Azure Cosmos DB-replik med hjälp av lokalt redundant lagring (LRS) eller zonredundant lagring (ZRS) i regioner som stöder tillgänglighetszoner.
      • En självbetjäningsåterställning kan utföras med hjälp av Azure-portalen eller IaC-artefakter som ARM-mallar.
      • Det finns flera begränsningar med kontinuerlig säkerhetskopiering.
        • Läget för kontinuerlig säkerhetskopiering är för närvarande inte tillgängligt i en skrivningskonfiguration för flera regioner.
        • Endast Azure Cosmos DB för NoSQL och Azure Cosmos DB för MongoDB kan konfigureras för kontinuerlig säkerhetskopiering just nu.
        • Om en container har TTL konfigurerats kan återställde data som har överskridit TTL tas bort omedelbart
      • En återställningsåtgärd skapar ett nytt Azure Cosmos DB-konto för återställning till tidpunkt.
      • Det finns en extra lagringskostnad för kontinuerliga säkerhetskopieringar och återställningsåtgärder.

  • Befintliga Azure Cosmos DB-konton kan migreras från Periodiska till Kontinuerliga, men inte från Kontinuerlig till Periodisk. migrering är enkelriktad och inte reversibel.

  • Varje Azure Cosmos DB-säkerhetskopiering består av själva data och konfigurationsinformation för etablerat dataflöde, indexeringsprinciper, distributionsregioner och TTL-inställningar för containrar.

  • Det är möjligt att implementera en anpassad säkerhetskopierings- och återställningsfunktion för scenarier där periodiska och kontinuerliga metoder inte passar bra.

    • En anpassad metod medför betydande kostnader och ytterligare administrativa kostnader, vilket bör förstås och utvärderas noggrant.
      • Vanliga återställningsscenarier bör modelleras, till exempel skada eller borttagning av ett konto, en databas, en container eller ett dataobjekt.
      • Hushållningsförfaranden bör genomföras för att förhindra utbredning av säkerhetskopior.
    • Azure Storage eller en alternativ datateknik kan användas, till exempel en alternativ Azure Cosmos DB-container.
      • Azure Storage och Azure Cosmos DB tillhandahåller interna integreringar med Azure-tjänster som Azure Functions och Azure Data Factory.

  • Azure Cosmos DB-dokumentationen anger två möjliga alternativ för att implementera anpassade säkerhetskopior.

    • Azure Cosmos DB-ändringsflöde för att skriva data till en separat lagringsanläggning.
      • En Azure-funktion eller motsvarande programprocess använder ändringsflödesprocessorn för att binda till ändringsflödet och bearbeta objekt till lagring.
    • Både kontinuerliga eller periodiska (batchbaserade) anpassade säkerhetskopior kan implementeras med hjälp av ändringsflödet.
    • Azure Cosmos DB-ändringsflödet återspeglar ännu inte borttagningar, så ett mönster för mjuk borttagning måste tillämpas med hjälp av en boolesk egenskap och TTL.
      • Det här mönstret krävs inte när ändringsflödet ger uppdateringar med fullständig återgivning.
    • Azure Data Factory Connector för Azure Cosmos DB (Azure Cosmos DB för NoSQL - eller MongoDB API-anslutningsappar ) för att kopiera data.
      • Azure Data Factory (ADF) stöder manuell körning och schema, rullande fönster och händelsebaserade utlösare.
        • Ger stöd för både Storage och Event Grid.
      • ADF är främst lämpligt för periodiska implementeringar av anpassad säkerhetskopiering på grund av dess batchorienterade orkestrering.
        • Det är mindre lämpligt för kontinuerliga säkerhetskopieringsimplementeringar med frekventa händelser på grund av orkestreringskörningen.
      • ADF stöder Azure Private Link för scenarier med hög nätverkssäkerhet

Azure Cosmos DB används i utformningen av många Azure-tjänster, så ett betydande regionalt avbrott för Azure Cosmos DB kommer att ha en sammanhängande effekt för olika Azure-tjänster inom den regionen. Den exakta effekten på en viss tjänst beror i hög grad på hur den underliggande tjänstdesignen använder Azure Cosmos DB.

Designrekommendationer

Azure Cosmos DB

  • Använd Azure Cosmos DB som den primära dataplattformen där kraven tillåter.

  • För scenarier med verksamhetskritiska arbetsbelastningar konfigurerar du Azure Cosmos DB med en skrivreplik i varje distributionsregion för att minska svarstiden och ge maximal redundans.

    • Konfigurera programmet så att det prioriterar användningen av den lokala Azure Cosmos DB-repliken för skrivningar och läsningar för att optimera programbelastning, prestanda och regional RU/s-förbrukning.
    • Skrivningskonfigurationen för flera regioner kostar mycket och bör endast prioriteras för arbetsbelastningsscenarier som kräver maximal tillförlitlighet.

  • För mindre kritiska arbetsbelastningsscenarier prioriterar du användningen av en regionskrivningskonfiguration (när du använder tillgänglighetszoner) med globalt distribuerade läsrepliker, eftersom detta erbjuder en hög nivå av dataplattformstillförlitlighet (99,999 % serviceavtal för läs-, 99,995 % SLA för skrivåtgärder) till en mer övertygande prispunkt.

    • Konfigurera programmet så att det använder den lokala Azure Cosmos DB-läsrepliken för att optimera läsprestanda.

  • Välj en optimal "hubb"-distributionsregion där konfliktlösningen sker i en skrivkonfiguration för flera regioner och alla skrivningar utförs i en skrivkonfiguration med en region.

    • Överväg avstånd i förhållande till andra distributionsregioner och tillhörande svarstid när du väljer en primär region och nödvändiga funktioner, till exempel stöd för tillgänglighetszoner.

  • Konfigurera Azure Cosmos DB med redundans för tillgänglighetszoner (AZ) i alla distributionsregioner med AZ-stöd för att säkerställa återhämtning till zonfel inom en region.

  • Använd Azure Cosmos DB för NoSQL eftersom det erbjuder den mest omfattande funktionsuppsättningen, särskilt när det gäller prestandajustering.

    • Alternativa API:er bör främst övervägas för migrering eller kompatibilitetsscenarier.
      • När du använder alternativa API:er kontrollerar du att nödvändiga funktioner är tillgängliga med det valda språket och SDK:et för att säkerställa optimal konfiguration och prestanda.

  • Använd direktanslutningsläget för att optimera nätverksprestanda via direkt TCP-anslutning till serverdelsnoder i Azure Cosmos DB, med ett minskat antal "hopp i nätverket".

Serviceavtalet för Azure Cosmos DB beräknas genom i genomsnitt misslyckade begäranden, som kanske inte direkt överensstämmer med en felbudget på 99,999 % tillförlitlighetsnivå. När du utformar för 99,999 % SLO är det därför viktigt att planera för att azure Cosmos DB-skrivotillgängligheten för regionala och flera regioner ska vara otillgänglig, vilket säkerställer att en reservlagringsteknik placeras om ett fel uppstår, till exempel en kvarhållen meddelandekö för efterföljande återspelning.

  • Definiera en partitioneringsstrategi för både logiska och fysiska partitioner för att optimera datadistributionen enligt datamodellen.

    • Minimera frågor mellan partitioner.
    • Iterativt testa och validera partitioneringsstrategin för att säkerställa optimala prestanda.

  • Välj en optimal partitionsnyckel.

    • Det går inte att ändra partitionsnyckeln när den har skapats i samlingen.
    • Partitionsnyckeln ska vara ett egenskapsvärde som inte ändras.
    • Välj en partitionsnyckel som har hög kardinalitet med ett stort antal möjliga värden.
    • Partitionsnyckeln bör sprida RU-förbrukning och datalagring jämnt över alla logiska partitioner för att säkerställa även RU-förbrukning och lagringsdistribution mellan fysiska partitioner.
    • Kör läsfrågor mot den partitionerade kolumnen för att minska RU-förbrukningen och svarstiden.

  • Indexering är också avgörande för prestanda, så se till att indexundantag används för att minska RU/s och lagringskrav.

    • Indexera endast de fält som behövs för filtrering i frågor. designindex för de mest använda predikaten.

  • Utnyttja de inbyggda funktionerna för felhantering, återförsök och bredare tillförlitlighet i Azure Cosmos DB SDK.

  • Använd tjänsthanterade krypteringsnycklar för att minska hanteringskomplexiteten.

    • Om det finns ett specifikt säkerhetskrav för kundhanterade nycklar ska du se till att lämpliga nyckelhanteringsprocedurer tillämpas, till exempel säkerhetskopiering och rotation.

  • Inaktivera skrivåtkomst för azure Cosmos DB-nyckelbaserade metadata genom att tillämpa den inbyggda Azure Policy.

  • Aktivera Azure Monitor för att samla in nyckelmått och diagnostikloggar, till exempel etablerat dataflöde (RU/s).

    • Dirigera driftdata för Azure Monitor till en Log Analytics-arbetsyta som är dedikerad till Azure Cosmos DB och andra globala resurser inom programdesignen.
    • Använd Azure Monitor-mått för att avgöra om programtrafikmönster är lämpliga för autoskalning.

  • Utvärdera programtrafikmönster för att välja ett optimalt alternativ för etablerade dataflödestyper.

    • Överväg automatisk skalning av etablerat dataflöde för att automatiskt utjämna efterfrågan på arbetsbelastningar.

  • Utvärdera Microsofts prestandatips för Azure Cosmos DB för att optimera konfigurationen på klientsidan och serversidan för bättre svarstid och dataflöde.

  • När du använder AKS som beräkningsplattform: För frågeintensiva arbetsbelastningar väljer du en AKS-nod-SKU som har accelererat nätverk aktiverat för att minska svarstiden och CPU-jitter.

  • För distributioner av en enda skrivregion rekommenderar vi starkt att du konfigurerar Azure Cosmos DB för automatisk redundans.

  • Belastningsnivå genom användning av asynkrona icke-blockerande meddelanden i systemflöden, som skriver uppdateringar till Azure Cosmos DB.

  • Konfigurera Azure Cosmos DB-kontot för kontinuerliga säkerhetskopieringar för att få en fin kornighet av återställningspunkter under de senaste 30 dagarna.

    • Överväg att använda Azure Cosmos DB-säkerhetskopior i scenarier där inneslutna data eller Azure Cosmos DB-kontot tas bort eller skadas.
    • Undvik att använda en anpassad säkerhetskopieringsmetod om det inte är absolut nödvändigt.

  • Vi rekommenderar starkt att du övar återställningsprocedurer på icke-produktionsresurser och data som en del av standardförberedelser för affärskontinuitet.

  • Definiera IaC-artefakter för att återupprätta konfigurationsinställningar och funktioner för en återställning av Azure Cosmos DB-säkerhetskopiering.

  • Utvärdera och tillämpa kontrollvägledningen för Azure Security Baseline för Säkerhetskopiering och återställning av Azure Cosmos DB.

  • För analytiska arbetsbelastningar som kräver tillgänglighet i flera regioner använder du Azure Cosmos DB Analytical Store, som tillämpar ett kolumnformat för optimerade analysfrågor.

Relationsdatatekniker

För scenarier med en mycket relationell datamodell eller beroenden av befintliga relationstekniker kanske användningen av Azure Cosmos DB i en skrivkonfiguration i flera regioner inte är direkt tillämplig. I sådana fall är det viktigt att använda relationstekniker utformas och konfigureras för att upprätthålla aktiv-aktiva ambitioner för flera regioner i en programdesign.

Azure tillhandahåller många hanterade relationsdataplattformar, inklusive Azure SQL Database och Azure Database för vanliga OSS-relationslösningar, inklusive MySQL, PostgreSQL och MariaDB. Designöverväganden och rekommendationerna i det här avsnittet fokuserar därför på optimal användning av Azure SQL Database- och Azure Database OSS-smaker för att maximera tillförlitligheten och den globala tillgängligheten.

Utformningsbeaktanden

  • Relationsdatatekniker kan konfigureras för att enkelt skala läsåtgärder, men skrivningar är vanligtvis begränsade till att gå igenom en enda primär instans, vilket innebär en betydande begränsning av skalbarhet och prestanda.

  • Horisontell partitionering kan användas för att distribuera data och bearbetning över flera identiska strukturerade databaser och partitionera databaser vågrätt för att navigera i plattformsbegränsningar.

    • Till exempel tillämpas horisontell partitionering ofta på SaaS-plattformar med flera klientorganisationer för att isolera grupper av klienter till distinkta dataplattformskonstruktioner.

Azure SQL Database

  • Azure SQL Database tillhandahåller en fullständigt hanterad databasmotor som alltid körs på den senaste stabila versionen av SQL Server-databasmotorn och det underliggande operativsystemet.

    • Innehåller intelligenta funktioner som prestandajustering, hotövervakning och sårbarhetsbedömningar.

  • Azure SQL Database ger inbyggd regional hög tillgänglighet och nyckelfärdig geo-replikering för att distribuera skrivskyddade repliker i Azure-regioner.

    • Med geo-replikering förblir sekundära databasrepliker skrivskyddade tills en redundansväxling initieras.
    • Upp till fyra sekundärfiler stöds i samma eller olika regioner.
    • Sekundära repliker kan också användas för skrivskyddad frågeåtkomst för att optimera läsprestanda.
    • Redundansväxling måste initieras manuellt men kan omslutas i automatiserade driftprocedurer.

  • Azure SQL Database tillhandahåller automatiska redundansgrupper som replikerar databaser till en sekundär server och möjliggör transparent redundans vid ett fel.

    • Grupper för automatisk redundans stöder geo-replikering av alla databaser i gruppen till endast en sekundär server eller instans i en annan region.
    • Grupper för automatisk redundans stöds för närvarande inte på tjänstnivån Hyperskala.
    • Sekundära databaser kan användas för att avlasta lästrafik.

  • Premium- eller affärskritiska tjänstnivådatabasrepliker kan distribueras mellan tillgänglighetszoner utan extra kostnad.

    • Kontrollringen dupliceras också i flera zoner som tre gatewayringar (GW).
      • Routningen till en specifik gatewayring styrs av Azure Traffic Manager.
    • När du använder nivån Affärskritisk är zonredundant konfiguration endast tillgänglig när Gen5-beräkningsmaskinvaran har valts.

  • Azure SQL Database erbjuder ett serviceavtal för baslinje 99,99 % tillgänglighet på alla tjänstnivåer, men ger ett högre serviceavtal på 99,995 % för nivåerna Affärskritisk eller Premium i regioner som stöder tillgänglighetszoner.

    • Azure SQL Database Business Critical- eller Premium-nivåer som inte har konfigurerats för zonredundanta distributioner har ett tillgänglighets-SLA på 99,99 %.

  • När den konfigureras med geo-replikering tillhandahåller Azure SQL Database Business Critical-nivån ett mål för återställningstid (RTO) på 30 sekunder under 100 % av de distribuerade timmarna.

  • När den konfigureras med geo-replikering har Azure SQL Database Business Critical-nivån ett mål för återställningspunkt (RPO) på 5 sekunder i 100 % av de distribuerade timmarna.

  • Azure SQL Database Hyperscale-nivån, när den konfigureras med minst två repliker, har ett tillgänglighets-SLA på 99,99 %.

  • Beräkningskostnader som är associerade med Azure SQL Database kan minskas med hjälp av en reservationsrabatt.

    • Det går inte att använda reserverad kapacitet för DTU-baserade databaser.

  • Återställning till tidpunkt kan användas för att returnera en databas och inneslutna data till en tidigare tidpunkt.

  • Geo-återställning kan användas för att återställa en databas från en geo-redundant säkerhetskopia.

Azure Database For PostgreSQL

  • Azure Database For PostgreSQL erbjuds i tre olika distributionsalternativ:

    • Enskild server, SLA 99,99 %
    • Flexibel server, som erbjuder redundans i tillgänglighetszonen, SLA 99,99 %
    • Hyperskala (Citus), SLA 99,95 % när läget för hög tillgänglighet är aktiverat.

  • Hyperskala (Citus) ger dynamisk skalbarhet genom horisontell partitionering utan programändringar.

    • Att distribuera tabellrader över flera PostgreSQL-servrar är nyckeln för att säkerställa skalbara frågor i Hyperskala (Citus).
    • Flera noder kan samla in mer data än en traditionell databas och kan i många fall använda arbets-PROCESSORer parallellt för att optimera kostnaderna.

  • Autoskalning kan konfigureras via Runbook Automation för att säkerställa elasticitet som svar på ändrade trafikmönster.

  • Flexibel server ger kostnadseffektivitet för icke-produktionsarbetsbelastningar genom möjligheten att stoppa/starta servern och en burstbar beräkningsnivå som är lämplig för arbetsbelastningar som inte kräver kontinuerlig beräkningskapacitet.

  • Det tillkommer ingen extra kostnad för lagring av säkerhetskopior för upp till 100 % av den totala allokerade serverlagringen.

    • Ytterligare förbrukning av lagring av säkerhetskopior debiteras enligt förbrukad GB/månad.

  • Beräkningskostnader som är associerade med Azure Database for PostgreSQL kan minskas med antingen en rabatt på en enskild serverreservation eller hyperskala (Citus) reservationsrabatt.

Designrekommendationer

  • Överväg att partitionera relationsdatabaser baserat på olika program- och datakontexter, vilket hjälper dig att navigera i plattformsbegränsningar, maximera skalbarhet och tillgänglighet samt felisolering.

    • Den här rekommendationen är särskilt vanlig när programdesignen tar hänsyn till tre eller fler Azure-regioner eftersom begränsningar för relationsteknik avsevärt kan hindra globalt distribuerade dataplattformar.
    • Horisontell partitionering är inte lämpligt för alla programscenarier, så en kontextualiserad utvärdering krävs.

  • Prioritera användningen av Azure SQL Database där det finns relationskrav på grund av dess mognad på Azure-plattformen och ett brett utbud av tillförlitlighetsfunktioner.

Azure SQL Database

  • Använd tjänstnivån Affärskritisk för att maximera tillförlitligheten och tillgängligheten, inklusive åtkomst till viktiga återhämtningsfunktioner.

  • Använd den vCore-baserade förbrukningsmodellen för att underlätta det oberoende valet av beräknings- och lagringsresurser som är skräddarsydda för arbetsbelastningens volym- och dataflödeskrav.

    • Se till att en definierad kapacitetsmodell används för att informera beräknings- och lagringsresurskraven.

  • Konfigurera den zonredundanta distributionsmodellen för att sprida affärskritiska databasrepliker inom samma region mellan tillgänglighetszoner.

  • Använd Active Geo-Replication för att distribuera läsbara repliker i alla distributionsregioner (upp till fyra).

  • Använd automatiska redundansgrupper för att tillhandahålla transparent redundans till en sekundär region, där geo-replikering används för att tillhandahålla replikering till ytterligare distributionsregioner för läsoptimering och databasredundans.

    • För programscenarier som är begränsade till endast två distributionsregioner bör användningen av automatiska redundansgrupper prioriteras.

  • Överväg automatiserade driftutlösare, baserat på aviseringar som är anpassade till programmets hälsomodell, för att utföra redundansväxlingar till geo-replikerade instanser om ett fel påverkar den primära och sekundära i gruppen för automatisk redundans.

Viktigt!

För program som överväger fler än fyra distributionsregioner bör du allvarligt överväga partitionering av programomfattningar eller omstrukturera programmet för att stödja skrivtekniker i flera regioner, till exempel Azure Cosmos DB. Men om detta inte är möjligt i scenariot för programarbetsbelastning rekommenderar vi att du höjer en region inom ett enskilt geografiskt område till en primär status som omfattar en geo-replikerad instans till en jämnare distribuerad läsåtkomst.

  • Konfigurera programmet för att fråga replikinstanser för läsfrågor för att optimera läsprestanda.

  • Använd Azure Monitor och Azure SQL Analytics för driftinsikter i nästan realtid i Azure SQL DB för identifiering av tillförlitlighetsincidenter.

  • Använd Azure Monitor för att utvärdera användningen för alla databaser för att avgöra om de har storleksanpassats på rätt sätt.

    • Se till att CD-pipelines överväger belastningstestning under representativa belastningsnivåer för att verifiera lämpligt dataplattformsbeteende.

  • Beräkna ett hälsomått för databaskomponenter för att observera hälsa i förhållande till affärskrav och resursanvändning, med hjälp av övervakning och aviseringar för att köra automatiserade operativa åtgärder där det är lämpligt.

    • Se till att viktiga frågeprestandamått införlivas så att snabba åtgärder kan vidtas när tjänstförsämring inträffar.

  • Optimera frågor, tabeller och databaser med hjälp av Query Performance Insights och vanliga prestandarekommendationer från Microsoft.

  • Implementera omprövningslogik med hjälp av SDK för att minimera tillfälliga fel som påverkar Azure SQL Database-anslutningen.

  • Prioritera användningen av tjänsthanterade nycklar när du tillämpar transparent datakryptering på serversidan (TDE) för vilande kryptering.

    • Om kundhanterade nycklar eller kryptering på klientsidan (AlwaysEncrypted) krävs kontrollerar du att nycklarna är korrekt motståndskraftiga med säkerhetskopior och automatiserade rotationsanläggningar.

  • Överväg att använda återställning till tidpunkt som en driftsspelbok för att återställa från allvarliga konfigurationsfel.

Azure Database For PostgreSQL

  • Flexibel server rekommenderas att använda den för affärskritiska arbetsbelastningar på grund av dess stöd för tillgänglighetszoner.

  • När du använder Hyperskala (Citus) för affärskritiska arbetsbelastningar aktiverar du läget hög tillgänglighet för att få 99,95 % SLA-garanti.

  • Använd serverkonfigurationen Hyperskala (Citus) för att maximera tillgängligheten över flera noder.

  • Definiera en kapacitetsmodell för programmet för att informera om kraven på beräknings- och lagringsresurser inom dataplattformen.

    • Överväg reservationsrabatten för Hyperskala (Citus) för att tillhandahålla potentiella kostnadsoptimeringar.

Cachelagring för frekventa data

Ett minnesinternt cachelagringslager kan användas för att förbättra en dataplattform genom att avsevärt öka läsdataflödet och förbättra svarstiderna från slutpunkt till slutpunkt för datascenarier på frekvent nivå.

Azure tillhandahåller flera tjänster med tillämpliga funktioner för cachelagring av nyckeldatastrukturer, med Azure Cache for Redis positionerat för att abstrahera och optimera läsåtkomst för dataplattformen. Det här avsnittet fokuserar därför på den optimala användningen av Azure Cache for Redis i scenarier där ytterligare läsprestanda och dataåtkomst hållbarhet krävs.

Designöverväganden

  • Ett cachelagringslager ger ytterligare hållbarhet för dataåtkomst eftersom även om ett avbrott påverkar de underliggande datateknikerna kan en ögonblicksbild av programdata fortfarande nås via cachelagringslagret.

  • I vissa arbetsbelastningsscenarier kan minnesintern cachelagring implementeras på själva programplattformen.

Azure Cache for Redis

  • Redis Cache är ett NoSQL-nyckelvärde för noSQL-lagringssystem med öppen källkod.

  • Enterprise- och Enterprise Flash-nivåerna kan distribueras i en aktiv-aktiv konfiguration mellan tillgänglighetszoner i en region och olika Azure-regioner via geo-replikering.

    • När den distribueras i minst tre Azure-regioner och tre eller fler tillgänglighetszoner i varje region, med aktiv geo-replikering aktiverad för alla cacheinstanser, tillhandahåller Azure Cache for Redis ett serviceavtal på 99,999 % för anslutning till en regional cacheslutpunkt.
    • När det distribueras över tre tillgänglighetszoner i en enda Azure-region tillhandahålls ett serviceavtal för 99,99 % anslutning.

  • Enterprise Flash-nivån körs på en kombination av RAM-minne och flash-lagring med icke-flyktigt minne, och även om detta medför en liten prestandaavgift möjliggör den även mycket stora cachestorlekar, upp till 13 TB med klustring.

  • Med geo-replikering gäller även avgifter för dataöverföring mellan regioner utöver de direkta kostnader som är associerade med cacheinstanser.

  • Funktionen Schemalagda uppdateringar innehåller inte Azure-uppdateringar eller uppdateringar som tillämpas på det underliggande operativsystemet för virtuella datorer.

  • Processoranvändningen ökar under en utskalningsåtgärd medan data migreras till nya instanser.

Designrekommendationer

  • Överväg ett optimerat cachelagringslager för "frekventa" datascenarier för att öka läsdataflödet och förbättra svarstiderna.

  • Använd lämpliga principer för cacheförfallotid och hushållning för att undvika skenande datatillväxt.

    • Överväg att ta bort cacheobjekt när säkerhetskopieringsdata ändras.

Azure Cache for Redis

  • Använd Premium- eller Enterprise SKU för att maximera tillförlitlighet och prestanda.

    • För scenarier med extremt stora datavolymer bör Enterprise Flash-nivån beaktas.
    • För scenarier där endast passiv geo-replikering krävs kan Premium-nivån också beaktas.

  • Distribuera replikinstanser med geo-replikering i en aktiv konfiguration i alla övervägd distributionsregioner.

  • Se till att replikinstanser distribueras mellan tillgänglighetszoner inom varje azure-region.

  • Använd Azure Monitor för att utvärdera Azure Cache for Redis.

    • Beräkna en hälsopoäng för regionala cachekomponenter för att observera hälsa i förhållande till affärsbehov och resursanvändning.
    • Observera och varna för viktiga mått, till exempel hög CPU-användning, hög minnesanvändning, hög serverbelastning och borttagna nycklar för insikter när cachen ska skalas.

  • Optimera anslutningens motståndskraft genom att implementera omprövningslogik, tidsgränser och använda en singleton-implementering av Redis-anslutnings multiplexern.

  • Konfigurera schemalagda uppdateringar för att ange de dagar och tider som Redis Server-uppdateringar tillämpas på cacheminnet.

Analysscenarier

Det blir allt vanligare att verksamhetskritiska program överväger analysscenarier som ett sätt att öka värdet från omfattande dataflöden. Analysscenarier för program och drift (AIOps) utgör därför en viktig aspekt av en mycket tillförlitlig dataplattform.

Analytiska och transaktionella arbetsbelastningar kräver olika funktioner och optimeringar av dataplattformen för godtagbara prestanda i respektive kontext.

beskrivning Analytisk Transaktion
Användningsfall Analysera mycket stora mängder data ("stordata") Bearbeta mycket stora volymer av enskilda transaktioner
Optimerat för Läsa frågor och aggregeringar över många poster Crud-frågor (Create/Read/Update/Delete) i nära realtid över några poster
Viktiga egenskaper – Konsolidera från datakällor för posten
– Kolumnbaserad lagring
– Distribuerad lagring
– Parallell bearbetning
– Avnormaliserad
– Läsningar och skrivningar med låg samtidighet
– Optimera för lagringsvolym med komprimering		 – Datakälla för post för program
– Radbaserad lagring
- Sammanhängande lagring
- Symmetrisk bearbetning
-Normaliserade
– Läsningar och skrivningar med hög samtidighet, indexuppdateringar
– Optimera för snabb dataåtkomst med minnesintern lagring

Azure Synapse tillhandahåller en analysplattform för företag som sammanför relationsdata och icke-relationella data med Spark-tekniker, med inbyggd integrering med Azure-tjänster som Azure Cosmos DB för att underlätta stordataanalys. Designöverväganden och rekommendationerna i det här avsnittet fokuserar därför på optimal Användning av Azure Synapse och Azure Cosmos DB för analysscenarier.

Designöverväganden

  • Traditionellt underlättas storskaliga analysscenarier genom att extrahera data till en separat dataplattform som är optimerad för efterföljande analysfrågor.
    • ETL-pipelines (Extract, Transform, and Load) används för att extrahera data som förbrukar dataflöde och påverkar prestanda för transaktionella arbetsbelastningar.
    • Om du kör ETL-pipelines sällan för att minska dataflödet och prestandapåverkan resulterar det i analysdata som är mindre aktuella.
    • ETL-pipelineutvecklingen och underhållskostnaderna ökar i takt med att datatransformeringar blir mer komplexa.
      • Om källdata till exempel ändras eller tas bort ofta måste ETL-pipelines ta hänsyn till dessa ändringar i måldata för analysfrågor via en additiv/versionsbaserad metod, dumpa och läsa in ändringar på plats på analysdata. Var och en av dessa metoder kommer att ha derivatpåverkan, till exempel återskapande av index eller uppdatering.

Azure Cosmos DB

  • Analysfrågor som körs på Azure Cosmos DB-transaktionsdata aggregeras vanligtvis över partitioner över stora datavolymer, vilket förbrukar betydande ru-dataflöde (Request Unit), vilket kan påverka prestandan för omgivande transaktionsarbetsbelastningar.

  • Azure Cosmos DB Analytical Store tillhandahåller ett schematiserat, fullständigt isolerat kolumnorienterat datalager som möjliggör storskalig analys av Azure Cosmos DB-data från Azure Synapse utan att påverka azure Cosmos DB-transaktionsarbetsbelastningar.

    • När en Azure Cosmos DB-container är aktiverad som ett analysarkiv skapas ett nytt kolumnlager internt från driftdata i containern. Det här kolumnarkivet sparas separat från det radorienterade transaktionsarkivet för containern.
    • Åtgärder för att skapa, uppdatera och ta bort på driftdata synkroniseras automatiskt till analysarkivet, så ingen ändringsfeed eller ETL-bearbetning krävs.
    • Datasynkronisering från driften till analysarkivet förbrukar inte dataflödesenheter (RU:er) som etablerats i containern eller databasen. Det finns ingen prestandapåverkan på transaktionsarbetsbelastningar. Analysarkivet kräver inte allokering av ytterligare RU:er på en Azure Cosmos DB-databas eller container.
    • Automatisk synkronisering är den process där ändringar av driftdata synkroniseras automatiskt till analysarkivet. Svarstiden för automatisk synkronisering är vanligtvis mindre än två (2) minuter.
      • Svarstiden för automatisk synkronisering kan vara upp till fem (5) minuter för en databas med delat dataflöde och ett stort antal containrar.
      • Så snart automatisk synkronisering har slutförts kan de senaste data frågas från Azure Synapse.
    • Analytical Store Storage använder en förbrukningsbaserad prismodell som debiterar för datavolym och antal läs- och skrivåtgärder. Prissättningen för analysarkivet är separat från prissättningen för transaktionslager.

  • Med Azure Synapse Link kan Azure Cosmos DB-analysarkivet frågas direkt från Azure Synapse. Detta möjliggör no-ETL, Hybrid Transactional-Analytical Processing (HTAP) från Synapse, så att Azure Cosmos DB-data kan efterfrågas tillsammans med andra analytiska arbetsbelastningar från Synapse nästan i realtid.

  • Azure Cosmos DB-analysarkivet är inte partitionerat som standard.

    • För vissa frågescenarier förbättras prestandan genom partitionering av analysarkivdata med hjälp av nycklar som ofta används i frågepredikat.
    • Partitionering utlöses av ett jobb i Azure Synapse som kör en Spark-notebook-fil med Synapse Link, som läser in data från Azure Cosmos DB Analytical Store och skriver dem till det Synapse-partitionerade lagret i synapse-arbetsytans primära lagringskonto.

  • Azure Synapse Analytics SQL Serverless-pooler kan köra frågor mot analysarkivet via automatiskt uppdaterade vyer eller via SELECT / OPENROWSET kommandon.

  • Azure Synapse Analytics Spark-pooler kan köra frågor mot analysarkivet via automatiskt uppdaterade Spark-tabeller eller spark.read kommandot.

  • Data kan också kopieras från Azure Cosmos DB Analytical Store till en dedikerad Synapse SQL-pool med Spark, så att etablerade Azure Synapse SQL-poolresurser kan användas.

  • Azure Cosmos DB Analytical Store-data kan efterfrågas med Azure Synapse Spark.

    • Spark-notebook-filer gör det möjligt för Spark-dataramskombinationer att aggregera och transformera Azure Cosmos DB-analysdata med andra datamängder och använda andra avancerade Synapse Spark-funktioner, inklusive att skriva transformerade data till andra lager eller träna AIOps Mašinsko učenje modeller.

Azure Cosmos DB Analytical Column Store

Azure Synapse

  • Azure Synapse samlar analysfunktioner som SQL-datalager, Spark-stordata och Data Explorer för logg- och tidsserieanalys.

    • Azure Synapse använder länkade tjänster för att definiera anslutningar till andra tjänster, till exempel Azure Storage.
    • Data kan matas in i Synapse Analytics via kopieringsaktivitet från källor som stöds. Detta tillåter dataanalys i Synapse utan att påverka källdatalagret, men lägger till tid, kostnad och svarstid på grund av dataöverföring.
    • Data kan också frågas på plats i externa lager som stöds, vilket undviker kostnader för datainmatning och förflyttning. Azure Storage med Data Lake Gen2 är ett arkiv som stöds för Synapse och Log Analytics-exporterade data kan efterfrågas via Synapse Spark.

  • Azure Synapse Studio förenar inmatnings- och frågeuppgifter.

    • Källdata, inklusive Azure Cosmos DB Analytical Store-data och Log Analytics-exportdata, efterfrågas och bearbetas för att stödja business intelligence och andra aggregerade analysanvändningsfall.

Azure Synapse Analytics

Designrekommendationer

  • Se till att analytiska arbetsbelastningar inte påverkar transaktionsbaserade programarbetsbelastningar för att upprätthålla transaktionsprestanda.

Programanalys

AIOps och Operational Analytics

  • Skapa en enda Azure Synapse-arbetsyta med länkade tjänster och datauppsättningar för varje Azure Storage-källkonto där driftdata från resurser skickas till.

  • Skapa ett dedikerat Azure Storage-konto och använd det som primärt lagringskonto för arbetsytan för att lagra Data och metadata för Synapse-arbetsytans katalog. Konfigurera det med hierarkiskt namnområde för att aktivera Azure Data Lake Gen2.

    • Upprätthålla separation mellan källanalysdata och Synapse-arbetsytedata och metadata.
      • Använd inte något av de regionala eller globala Azure Storage-konton där driftdata skickas.

Gå vidare

Granska övervägandena för nätverksöverväganden.

Nätverk och anslutning