Azures Cosmos DB er en af de bedste funktioner. En distribueret database med flere modeller giver dig et fundament til at opbygge ægte cloud-native applikationer med en række konsistensmodeller, der kan kortlægges til, hvordan din applikation fungerer. Men det er ikke let at komme i gang, og en dårligt konfigureret eller designet applikation kan hurtigt blive dyr.
Det er godt at se, at Cosmos DB nu har et gratis niveau, der kan hjælpe dig med at implementere applikationer uden for et begrænset udviklingsmiljø. Det nye niveau er ikke stort: det er baseret på minimumskonfigurationen for Cosmos DB og tilbyder 400 RU / s (anmodningsenheder pr. Sekund) og 5 GB lagerplads med så mange som 25 containere i en delt gennemløbsdatabase. Det er mere end nok til en lille applikation, der f.eks. Giver mere læsning end skrivning og ikke er afhængig af stærke konsistensmodeller.
Du skal være opmærksom på, at selvom Cosmos DB er multiregion, kan du kun køre en enkelt 400 RU / s-database i det gratis niveau. I praksis begrænser det dig til en enkelt region, da yderligere regioner hver især har brug for deres egen 400 RU / s-instans, og de vil blive opkrævet til standardpriser for disse regioner pr. Time.
Kom godt i gang med den gratis Cosmos DB
Du bliver nødt til at oprette en ny konto for at drage fordel af det gratis niveau; det er ikke tilgængeligt som faktureringsmulighed på eksisterende applikationer. Det gratis niveau 400 RU / s er det mindste beløb, der kan tilvejebringes i en Cosmos DB-database. Det giver dig omkring 1 milliard læsninger om måneden, hvilket skal være nok til at få din applikation fra jorden eller give dig mulighed for at implementere og køre en intern distribueret database som del af et pilotprojekt. Når du kommer til kanten af din gratis RU / s-tillæg, kan du tilføje mere kapacitet i blokke på 100 RU / s, faktureret med en timesats.
Det er værd at forstå, hvad en Cosmos-database RU er. RU'en er en anmodningsenhed, og den fakturerede RU / s er et mål for den klargjorte gennemstrømning af din database, der dækker alle dens operationer. Dette inkluderer læsning, skrivning, opdatering, sletning og meget mere. Microsoft antyder, at 1 RU / s svarer til en til sidst konsistent (det langsomste og mindst procesintensive konsistensniveau, der er tilgængeligt på Cosmos DB) pr. Sekund af en 1 KB-vare. At skrive det samme 1KB-emne pr. Sekund er 5 RU / s. Jo mere kompleks operationen er, jo mere RU / s bruger den.
Forståelse af forbruget af anmodningsenheder
Det er svært at sige nøjagtigt, hvor mange RU / er en applikation vil forbruge. Du kan dog tænke på Cosmos DB-begrænsninger, der kan påvirke de RU'er, der bruges af din database. Først skal du overveje størrelsen på dine varer. Jo større varen er, jo flere RU'er bruger den til at læse eller skrive. Tilsvarende forbruger indeksering RU / s, og hvis du bruger standardindekseringsmodellen, stiger de nødvendige ressourcer til at skrive emner, når du føjer mere til din database. Så er der dit valg af konsistensmodeller, hvor både stærk og afgrænset stalhed har brug for omtrent dobbelt så mange RU / s til en læsning som Cosmos DBs andre, mindre strenge modeller.
Med et begrænset antal RU'er til rådighed i det gratis niveau, vil du muligvis omgå disse begrænsninger for at holde forbruget på et minimum. En mulighed er at slå al indeksering fra for din database, men i praksis foretrækker du måske at begrænse indeksering til specifikke egenskaber på hvert gemte JSON-dokument. På samme tid skal du overveje, hvordan din applikation fungerer, og om det er bedre at bruge noget som sessionskonsistens for at forbedre brugernes opfattelse af ydeevne og samtidig reducere de anvendte RU'er.
Da RU'er er aktivitetsbaserede, kan du bruge forespørgseldesign til at holde forbruget på et minimum. Det kan medføre begrænsning af antallet af resultater pr. Forespørgsel, kontrol af mængden af data, du gemmer, eller brug af så få brugerdefinerede funktioner, lagrede procedurer og udløsere som muligt.
Opsætning af din database er let nok. Opret en ny Cosmos DB-konto i Azure Portal, og opret en ny database fra Azure Data Explorer. Start med at give det et id, og sørg derefter for dets gennemløb. Indstil dette til 400 RU / s. Højere beløb viser omkostningsestimater, men da du opretter en gratis instans, er det ikke nødvendigt at prøve dette. Du er ikke begrænset til portalen; du kan bruge Azure CLI, PowerShell eller endda programmatisk inde fra Cosmos DB SDK.
Opbygning af apps på Cosmos DBs gratis niveau
I Cosmos DB er en database et sæt containere, der bruges til at håndtere partitionering i en Azure-region og distribution over de regioner, du bruger din database i. Hver database kan konfigureres til at være en bestemt model: NoSQL (både MongoDB og Cassandra), SQL, Gremlin og tabeller. De fleste apps fungerer med det som en NoSQL-dokumentdatabase, der lagrer JSON-data.
Når du har oprettet en database og valgt en model, kan du tænke på en Cosmos DB-container som hvordan databasen skaleres. Uden for det gratis niveau kan du indstille kapacitet i RU / s på containerbasis; i det gratis niveau deler du denne gennemstrømning på tværs af alle containere i din database, så du kan ikke forudsige kapacitet for nogen specifik container. Betalte forekomster har en tilknyttet SLA, hvorfor de giver dig mulighed for at indstille kapacitet pr. Container-basis.
At arbejde på tværs af containere på denne måde svarer til at bruge en klynge i en NoSQL-database og fungerer godt til denne type arbejdsbyrde. Ved at bruge den samme partitionsnøgle på tværs af alle dine containere, vil Cosmos DB automatisk dele kapacitet på tværs af dem. Du kan bruge denne tilgang med gratis 25-containere til at reducere flaskehalse for brugerne af din applikation. Hvis du behandler den som en splittet, klynget NoSQL-database, skal du finde det relativt let at inkludere den i dine applikationer og bruge den til at være vært for markører til andet indhold snarere end selve indholdet.
Det kan være vanskeligt at arbejde med et gratis servicetilbud, men hvis du tager fornuftige forholdsregler, bør det være muligt at bruge Cosmos DBs nye niveau som en del af en applikationsbackend. Du bliver muligvis nødt til at ofre nogle af tjenestens skalerbarhedsfunktioner, men det skal ikke påvirke applikationer væsentligt, hvis du tager nøje beslutninger om designtid.
Det er vigtigt at tænke over, hvordan man drager fordel af en distribueret database som Cosmos DB i stedet for blot at porte dine eksisterende arbejdsbelastninger til den - det er usandsynligt, at de passer godt sammen. Tænk i stedet på dette som din mulighed for at opbygge en virkelig cloud-native, distribueret applikation. I dette tilfælde er 400 RU / s mere end nok til at starte en ny applikation og få den til at fungere med et rimeligt antal brugere.
