Share 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, vilket har långtgående konsekvenser för 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 till exempel arbeta i en skrivkonfiguration i flera regioner har 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 Azure Well-Architected verksamhetskritiska arbetsbelastningsserie . 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" ger 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 Volume, Velocity, Variety och Veracity 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 lagringskapaciteten och nivåindelningskraven – det är storleken på datauppsättningen.
  • Velocity: 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 är korrekt data.

Designanmärkningar

Volym

  • Befintliga (om sådana finns) 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 ändrade affärsförhållanden eller hushållningsförfaranden.

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

  • Det kan finnas en djupgående inverkan som är associerad med 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, med antingen skapande eller ändring av 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 måste 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 hantera ett stort dataflöde för läsning.
    • Vilket dataflöde krävs? Och hur förväntas dataflödet växa?
    • Vilka krav gäller för datasvarstid på P50/P99 under referensbelastningsnivåer?

  • Funktioner som att stödja en låsfri design, indexjustering och konsekvensprinciper är viktiga 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ämning av beständighet och meddelandemönster, till exempel CQRS och händelsekällor, kan användas för att ytterligare optimera dataflödet.

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

    • Flexibel skalbarhet är nyckeln till att effektivt stödja variabelt dataflöde och belastningsnivåer utan att överetablera kapacitetsnivåer.
      • Både läs- och skrivdataflöde måste skalas enligt programkrav och belastning.
      • Både vertikala 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 kommer att ske 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 (mellan regioner och mellan regioner) kan användas för att minimera svarstiderna i 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 cacheminnet måste övervägas för att optimera data senaste tiden.

Mängd olika

  • Datamodellen, datatyperna, datarelationerna och den avsedda frågemodellen påverkar dataplattformsbesluten starkt.

    • Kräver programmet en relationsdatamodell eller kan det stödja en modell för variabelschema eller icke-relationella data?
    • Hur kommer programmet att fråga efter data? Och beror frågor på begrepp på databasnivå, till exempel relationskopplingar? Eller tillhandahåller programmet sådan semantik?

  • Typen av datauppsättningar som beaktas av programmet kan varieras, från ostrukturerat innehåll som bilder och videor eller mer strukturerade filer som CSV och Parquet.

    • Arbetsbelastningar för sammansatta program har vanligtvis distinkta datauppsättningar och tillhörande krav.

  • Förutom relationsbaserade eller icke-relationella dataplattformar 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 likartade och/eller lagras och efterfrågas tillsammans men skiljer sig strukturellt åt.

  • 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 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 dataplattformsbeslut.

    • Frågeskikt 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 polyglotlagring 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 och kontinuiteten i kompetens ha stor betydelse för dataplattformens utformning och val av datateknik.

Sanningshalten

  • Flera faktorer måste övervägas för att verifiera dataprecisionen i ett program, och hanteringen av dessa faktorer kan ha stor betydelse för dataplattformens design.

    • 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 snabbast 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 som är närmast användaren och som inte återspeglar det senaste tillståndet för en annan replik? d.v.s. kan programmet stödja servering av inaktuella data?

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

    • Standardiserade principer för konfliktlösning, 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 programlagret med hjälp av kryptering på klientsidan och/eller datalagret 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 på 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älsotillstånd och dataåtkomst.

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

Designrekommendationer

Volym

  • 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änd etablerade priser för att informera om pågående kapacitetskrav.
    • Jämför aggregerade volymer och postvolymer per data med dataplattformsgränser.
    • Om det finns en risk för att gränser nås under exceptionella omständigheter bör du se till att åtgärdsåtgärder finns på plats för att förhindra avbrott 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 prestandaförseningar när replikeringen sker. Se därför till att dessa åtgärder utförs utanför kritiska kontorstider om det är möjligt.

  • Definiera programdatanivåer för att klassificera datauppsättningar baserat på användning och allvarlighetsgrad 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 "heta" data som aktivt används av programmet, medan Azure Storage används för "kalla" driftdata för analysändamål.

  • 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åindelade till sekundär lagring, eller tas bort direkt, utan att programmet påverkas negativt.
    • Avlasta icke-kritiska data till sekundär kalllagring, men underhålla dem för analysvärde och för att uppfylla granskningskraven.
    • Samla in telemetri- och användningsstatistik för dataplattformen så att DevOps-team kontinuerligt kan utvärdera krav på hushållning och "rätt storlek" för datalager.

  • I linje med en mikrotjänstprogramdesign 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 det kan vara svårt att hantera datavolymer från expansion.

Hastighet

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

    • Se till att dataflödet för läsning och skrivning för varje datascenario kan skalas enligt förväntade belastningsmönster, med tillräcklig tolerans för oväntad varians.
    • Separera 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 uppstå 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 accepteras i samband med viktiga affärskrav.

  • Säkerställ flexibel skalbarhet för att stödja variabelt dataflöde och belastningsnivåer.

    • Om belastningsnivåerna är mycket instabila bör du överväga att överetablera kapacitetsnivåer för att säkerställa att dataflödet och prestandan upprätthålls.
    • Testa och verifiera påverkan 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änst interna tröskelvärden och tröskelvärden för programuppsättningar.
    • Skalning bör initieras och slutföras i tidsramar som är förenliga med affärskraven.
    • För scenarier där manuell interaktion är nödvändig upprättar du 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 tillämpas som en del av efterföljande tekniska investeringar.

  • Övervaka läs- och skrivdataflöde för programdata mot P50/P99-svarstidskrav och anpassa dem till en programkapacitetsmodell.

  • Överflödigt dataflöde bör hanteras på ett smidigt sätt av dataplattformen eller programlagret och samlas in av hälsomodellen för driftsrepresentation.

  • 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örfaller cacheobjekt när säkerhetskopieringsdata ändras.
      • Om cachens giltighetstid är strikt TTL-baserad (Time-To-Live) måste påverkan och kundupplevelsen av att betjäna inaktuella data förstås.

Mängd olika

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

  • I enlighet 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 hanterar för specifika arbetsbelastningsscenarier.
    • Undvik att skapa ett beroende för 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 de språk och SDK-funktioner som krävs. Alla funktioner är inte tillgängliga för alla språk/SDK på samma sätt.

Sanningshalten

  • 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 över Tillgänglighetszoner (AZ) 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 plattformsdesign för skrivdata 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 och redundansväxlingsåtgärder genom kaostestning i processer för kontinuerlig leverans.

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

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

  • När du tillämpar kryptering 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 kontrollerar du att lämpliga nyckelhanteringsprocedurer tillämpas för att säkerställa tillgänglighet, säkerhetskopiering och rotation av alla övervägda nycklar.

Anteckning

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 krävs förmodligen skalning av dataplattformen tillsammans med andra programkomponenter enligt en kapacitetsmodell, eventuellt genom etablering av ytterligare skalningsenheter. 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) flaskhalsar i driften 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 arkitekturguiden för Azure Application.

Globalt distribuerat datalager för skrivning i flera regioner

För att fullständigt hantera de globalt distribuerade aktiva-aktiva ambitionerna för en programdesign rekommenderar vi starkt att du överväger en distribuerad plattform för skrivning i flera regioner, där ändringar i separata skrivbara repliker synkroniseras och slås samman 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 direkt. Designöverväganden och rekommendationerna i det här avsnittet fokuserar därför på optimal Användning av Azure Cosmos DB.

Designöverväganden

Azure Cosmos DB

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

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

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

  • Azure Cosmos DB stöder gateway- och direktanslutningslägen, där Direct underlättar anslutningen via TCP till Serverdelens Azure Cosmos DB-repliknoder 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 tillgänglighetszonaktiverade regioner erbjuder Azure Cosmos DB redundansstöd för tillgänglighetszoner (AZ) för hög tillgänglighet och återhämtning vid zonfel i en region.

  • Azure Cosmos DB underhåller fyra datarepliker inom en enda region, och när redundans för tillgänglighetszoner (AZ) är aktiverat ser Azure Cosmos DB till att datarepliker placeras över flera tillgänglighetszoner för att skydda mot zonindelade fel.

    • Konsensusprotokollet Paxos 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 över flera regioner för att minska risken för att en enda region blir otillgänglig.

    • Replikering kan konfigureras med skrivningar i en enda region eller skrivningar i flera regioner.
      • Med skrivningar i en enda region används en primär "hubb"-region 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 det uppstå uppdateringskonflikter (infoga, ersätt, ta bort) där skrivarna 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 programdefinierad semantik att stämma av konflikter med hjälp av en registrerad sammanslagnings lagrad procedur som automatiskt anropas 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 bara anges när containern skapas.

  • I en skrivkonfiguration i flera regioner finns det ett beroende av en enda Azure Cosmos DB-hubbregion för att utföra alla konfliktlö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 för konfliktlösning i en skrivkonfiguration i flera regioner, med hjälp av en 2-fass Paxos-metod för att uppnå kvorum på global nivå och i en region.

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

    • 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 azure Cosmos DB distribueras med en enda skrivregion kan det 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 ~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 katastrof som påverkar navregionen.

    • Denna RTO är också relevant i en skrivkontext för flera regioner med tanke på beroendet av en enda "hubb"-region för konfliktlösning.
      • Om hubbregionen blir otillgänglig misslyckas skrivningar som görs till andra regioner när meddelandebufferten har fyllts eftersom konfliktlösningen 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.
    • Den genomsnittliga felfrekvensen definieras som summan av felfrekvenser för varje timme i 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 omfattar 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 programbegäran per sekund (RU/s).

    • Standarddataflödet allokerar resurser som krävs för att garantera ett angivet RU/s-värde.
      • Standard debiteras 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 debiteras varje timme för det maximala dataflödet som förbrukas.

  • Statiskt etablerat dataflöde med en variabel arbetsbelastning kan resultera i 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 igen.

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

  • Det finns ett betydande kostnadsdelta mellan en skrivningskonfiguration för flera regioner och en region som 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 skrivning mellan en region och skrivning i flera regioner är faktiskt mindre än förhållandet 1:2 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 enkel skrivning, som inte samlas in inom RU-kostnaderna som med skrivkonfigurationen för flera regioner.

  • Förbrukad lagring faktureras som en fast avgift för den totala mängden lagringsutrymme (GB) som förbrukas för att vara värd för data 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, som ger överlappande funktioner.

Azure Cosmos DB-åtkomstfunktioner

  • 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 Microsoft Entra rollbaserad åtkomstkontroll (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-mall-IaC-definitioner eller via en inbyggd Azure Policy.

  • 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 för rolltilldelning, och anpassade RBAC-roller kan också användas för att skapa specifika privilegier.
      • 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-operatör, 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 i 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 lagret som matas av ändringsflödet felaktigt och inte manuellt för borttagna data.

    • Ett mönster för mjuk borttagning kan implementeras så att dataposter ingår i ändringsflödet.
      • I stället för att uttryckligen ta bort dataposter uppdateras dataposter genom att ange en flagga (t.ex. IsDeleted) som anger att objektet betraktas som 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 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.

    • Periodiskt är standardläget för säkerhetskopiering för alla konton, där säkerhetskopieringar 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 senaste två 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 säkerhetskopieringslagring.
      • Två säkerhetskopior ingår utan extra kostnad, men ytterligare säkerhetskopior medför ytterligare kostnader.
      • Som standard lagras periodiska säkerhetskopior i separata Geo-Redundant Storage (GRS) som inte är direkt åtkomliga.
        • 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 Locally-Redundant Storage.
      • 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äkerhetskopior ö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 har tagits 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 i varje Azure-region där Azure Cosmos DB-kontot finns.
        • Kontinuerliga säkerhetskopieringar lagras i samma Azure-region som varje Azure Cosmos DB-replik med hjälp av Locally-Redundant Storage (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 Portal- 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 for NoSQL och Azure Cosmos DB for MongoDB kan konfigureras för kontinuerlig säkerhetskopiering för tillfället.
        • Om en container har TTL konfigurerats kan återställde data som har överskridit TTL-gränsen tas bort omedelbart
      • En återställningsåtgärd skapar ett nytt Azure Cosmos DB-konto för återställning till tidpunkt.
      • Det tillkommer 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 kontinuerliga till periodiska. 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 går 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 omkostnader, som 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 spridning 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 beskriver två möjliga alternativ för att implementera anpassade säkerhetskopior.

    • Azure Cosmos DB-ändringsflöde för att skriva data till en separat lagringsplats.
    • Både kontinuerliga eller periodiska (batchbaserade) anpassade säkerhetskopieringar 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 for 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 anpassade implementeringar av säkerhetskopiering på grund av dess batchorienterade orkestrering.
        • Det är mindre lämpligt för implementeringar av kontinuerlig säkerhetskopiering 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 i den regionen. Den exakta påverkan 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 verksamhetskritiska arbetsbelastningsscenarier 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.
    • Konfigurationen för skrivning mellan flera regioner medför en betydande kostnad 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 skrivrepliker, eftersom detta ger en hög nivå av dataplattformstillförlitlighet (99,999 % serviceavtal för läs-, 99,995 % SLA för skrivåtgärder) vid en mer övertygande prispunkt.

    • Konfigurera programmet att använda den lokala Azure Cosmos DB-skrivskyddade repliken för att optimera läsprestanda.

  • Välj en optimal "hubb"-distributionsregion där konfliktlösningen kommer att uppstå i en skrivningskonfiguration för flera regioner och alla skrivningar utförs i en konfiguration med en enda region-skrivning.

    • Överväg avståndet 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 som Tillgänglighetszoner support.

  • Konfigurera Redundans för Azure Cosmos DB med tillgänglighetszon (AZ) i alla distributionsregioner med AZ-stöd för att säkerställa återhämtning vid zonfel i 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 migrerings- 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 Serverdelens Azure Cosmos DB-noder, med ett minskat antal "hopp i nätverket".

Serviceavtalet för Azure Cosmos DB beräknas genom genomsnittligt antal misslyckade begäranden, som kanske inte direkt överensstämmer med en felbudget på 99,999 % för tillförlitlighetsnivå. När du utformar för 99,999 % servicenivåmål är det därför viktigt att planera för att azure Cosmos DB-skrivotillgänglighet i region och flera regioner ska vara otillgängligt, vilket säkerställer att en återställningslagringsteknik placeras om ett fel uppstår, till exempel en beständig meddelandekö för efterföljande återuppspelning.

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

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

  • Välj en optimal partitionsnyckel.

    • Partitionsnyckeln kan inte ändras 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 brett utbud av 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 över fysiska partitioner.
    • Kör läsfrågor mot den partitionerade kolumnen för att minska RU-förbrukningen och svarstiden.

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

    • 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 kontrollerar du att lämpliga nyckelhanteringsprocedurer tillämpas, till exempel säkerhetskopiering och rotation.

  • Inaktivera skrivåtkomst till nyckelbaserade metadata i Azure Cosmos DB genom att använda den inbyggda Azure Policy.

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

    • Dirigera Azure Monitor-driftdata 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 att automatiskt skala etablerat dataflöde för att automatiskt jämna ut 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 med 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 kontinuerlig säkerhetskopiering för att få en fin kornighet för å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örberedelserna för verksamhetskontinuitet.

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

  • Utvärdera och tillämpa vägledningen för azure-säkerhetsbaslinjekontroll för säkerhetskopiering och återställning i Azure Cosmos DB.

  • För analytiska arbetsbelastningar som kräver tillgänglighet i flera regioner använder du Azure Cosmos DB Analytical Store, som använder 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 de aktiva-aktiva ambitionerna 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ägandena och rekommendationerna i det här avsnittet fokuserar därför på optimal användning av Azure SQL Database och Azure Database OSS-varianter för att maximera tillförlitligheten och den globala tillgängligheten.

Designöverväganden

  • Även om relationsdatatekniker kan konfigureras för att enkelt skala läsåtgärder, är skrivningar 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, partitionera databaser vågrätt för att navigera plattformsbegränsningar.

    • Till exempel används 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 har 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 mellan 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ärskritisk databasrepliker på tjänstnivå kan distribueras över Tillgänglighetszoner utan extra kostnad.

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

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

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

  • När Azure SQL Database Affärskritisk-nivån konfigureras med geo-replikering får du ett mål för återställningstid (RTO) på 30 sekunder i 100 % av de distribuerade timmarna.

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

  • Azure SQL Hyperskala-nivå för databas, 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 innehålla 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, serviceavtal 99,99 %
    • Flexibel server, som erbjuder redundans för tillgänglighetszoner, 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 kostar inget extra 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 för en 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 utbredd när programdesignen tar hänsyn till tre eller flera 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 Business-Critical för att maximera tillförlitligheten och tillgängligheten, inklusive åtkomst till kritiska återhämtningsfunktioner.

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

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

  • Konfigurera Zone-Redundant distributionsmodellen för att sprida Affärskritisk databasrepliker inom samma region över 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 att automatiserade driftsutlösare, baserat på aviseringar som är anpassade till programmets hälsomodell, utför 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 att partitionera 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 med programarbetsbelastningen 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änsten försämras.

  • 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.

Cachelagring för frekventa data

Ett cachelagringslager i minnet 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 viktiga datastrukturer, med Azure Cache for Redis positionerade för att abstrahera och optimera läsåtkomst för dataplattformen. Det här avsnittet fokuserar därför på optimal användning av Azure Cache for Redis i scenarier där ytterligare läsprestanda och dataåtkomst krävs.

Designanmärkningar

  • Ett cachelagringslager ger ytterligare dataåtkomsthållbarhet eftersom även om ett avbrott påverkar underliggande datatekniker 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 öppen källkod NoSQL-lagringssystem med nyckelvärde i minnet.

  • Enterprise- och Enterprise Flash-nivåerna kan distribueras i en aktiv-aktiv konfiguration över 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 och flash icke-flyktig minneslagring, och även om detta medför en liten prestandaförstöring möjliggör den också mycket stora cachestorlekar, upp till 13 TB med klustring.

  • Med geo-replikering kommer avgifter för dataöverföring mellan regioner också att tillämpas utöver de direkta kostnader som är associerade med cacheinstanser.

  • Funktionen Schemalagd 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äsflö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 upphöra att använda 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 övervägas.
    • För scenarier där endast passiv geo-replikering krävs kan Premium-nivån också övervägas.

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

  • Se till att replikinstanser distribueras över 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ärskrav 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å cachen.

Analysscenarier

Det blir allt vanligare att verksamhetskritiska program överväger analysscenarier som ett sätt att driva ytterligare värde 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.

Analys- och transaktionsarbetsbelastningar kräver olika dataplattformsfunktioner och optimeringar för acceptabel prestanda i sina respektive kontexter.

Description Analytisk Stöder transaktioner
Användningsfall Analysera mycket stora datavolymer ("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ällan för posten för programmet
– 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 Azure Synapse och Azure Cosmos DB-användning för analysscenarier.

Designanmärkningar

  • 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 transaktionsbelastningens prestanda.
    • 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-pipelineutveckling och underhållskostnader ö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 eller på plats ändringar på analysdata. Var och en av dessa metoder har derivatpåverkan, till exempel återskapande eller uppdatering av index.

Azure Cosmos DB

  • Analysfrågor som körs på Azure Cosmos DB-transaktionsdata aggregeras vanligtvis över partitioner över stora mängder data, 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ärderna 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 efterfrå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 hjälp av Azure Synapse Link kan Azure Cosmos DB-analysarkivet frågas direkt från Azure Synapse. Detta möjliggör ingen 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 Analytical Store partitioneras inte som standard.

    • För vissa frågescenarier förbättras prestandan genom att partitionera analyslagerdata 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 synapse-partitionerat lager 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-dataramkombinationer 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 butiker eller träna AIOps Machine Learning-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 tidsserieanalyser.

    • 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 aktiviteten Kopiera 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å efterfrågas på plats i externa lager som stöds, vilket undviker omkostnader 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 Katalogdata och metadata för Synapse-arbetsytan. Konfigurera den med hierarkisk namnrymd 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.

Nästa steg

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

Nätverk och anslutning