Azure’s Cosmos DB er en av de beste funksjonene. En multimodell distribuert database, den gir deg et grunnlag for å bygge virkelig sky-native applikasjoner med en serie konsistensmodeller som kan tilordnes til hvordan applikasjonen din fungerer. Men det er ikke lett å komme i gang, og et dårlig konfigurert eller designet program kan fort bli dyrt.
Det er godt å se at Cosmos DB nå har et gratis nivå som kan hjelpe deg med å begynne å distribuere applikasjoner utenfor et begrenset utviklingsmiljø. Det nye nivået er ikke stort: det er basert på minimumskonfigurasjonen for Cosmos DB, og tilbyr 400 RU / s (forespørselenheter per sekund) og 5 GB lagringsplass, med så mange som 25 containere i en delt gjennomstrømningsdatabase. Det er mer enn nok for et lite program som for eksempel gir flere lesninger enn skrivinger, og som ikke er avhengig av sterke konsistensmodeller.
Du må være oppmerksom på at selv om Cosmos DB er multiregion, kan du bare kjøre en enkelt 400 RU / s-database i gratisnivået. I praksis begrenser du deg til en enkelt region, da flere regioner hver vil trenge sin egen 400 RU / s-forekomst, og de vil bli belastet til standardpriser for disse regionene, per time.
Komme i gang med gratis Cosmos DB
Du må opprette en ny konto for å dra nytte av gratis nivået; den er ikke tilgjengelig som faktureringsalternativ for eksisterende applikasjoner. Gratisnivået på 400 RU / s er det minste beløpet som kan tildeles i en Cosmos DB-database. Det gir deg rundt 1 milliard avlesninger i måneden, noe som burde være nok til å få søknaden din fra bakken eller la deg distribuere og kjøre en intern distribuert database som en del av et pilotprosjekt. Når du kommer til kanten av din gratis RU / s-kvote, kan du legge til mer kapasitet i blokker på 100 RU / s, fakturert med timepris.
Det er verdt å forstå hva en Cosmos-database RU er. RU er en forespørselenhet, og den fakturerte RU / er er et mål på den klargjorte gjennomstrømningen i databasen din, som dekker alle dens operasjoner. Dette inkluderer leser, skriver, oppdaterer, sletter og mer. Microsoft antyder at 1 RU / s tilsvarer en til slutt konsistent (det tregeste og minst prosesseringskrevende konsistensnivået tilgjengelig på Cosmos DB) per sekund av et 1KB-element. Å skrive det samme 1KB-elementet per sekund er 5 RU / s. Jo mer kompleks operasjonen er, jo mer RU / er bruker den.
Forståelse av forbruket av forespørselenheter
Det er vanskelig å si nøyaktig hvor mange RU / er en applikasjon vil forbruke. Du kan imidlertid tenke på Cosmos DB-begrensningene som kan påvirke RU / ene som brukes av databasen din. Først må du vurdere størrelsen på varene dine. Jo større varen er, desto flere RU / er bruker den til å lese eller skrive. Tilsvarende bruker indeksering RU / s, og hvis du bruker standard indekseringsmodell, vil ressursene som kreves for å skrive varer øke når du legger til mer i databasen. Deretter er det ditt valg av konsistensmodeller, med både sterk og avgrenset stalhet som trenger omtrent dobbelt så mange RU / s for å lese som Cosmos DBs andre, mindre strenge modeller.
Med et begrenset antall RU / er tilgjengelig i gratis nivået, kan det være lurt å omgå disse begrensningene for å holde forbruket på et minimum. Et alternativ er å slå av all indeksering for databasen, men i praksis foretrekker du å begrense indeksering til spesifikke egenskaper på hvert lagrede JSON-dokument. Samtidig må du vurdere hvordan applikasjonen din fungerer, og om det er bedre å bruke noe som økt konsistens for å forbedre brukeropplevelsen av ytelse og samtidig redusere RU / ene som brukes.
Ettersom RU / er er aktivitetsbaserte, kan du bruke spørringsdesign for å holde forbruket på et minimum. Det kan innebære å begrense antall resultater per spørring, kontrollere datamengden du lagrer, eller bruke så få brukerdefinerte funksjoner, lagrede prosedyrer og utløsere som mulig.
Det er enkelt å sette opp databasen. Opprett en ny Cosmos DB-konto i Azure Portal, og opprett en ny database fra Azure Data Explorer. Begynn med å gi den en ID og sørg deretter for gjennomstrømningen. Sett dette til 400 RU / s. Høyere beløp viser kostnadsoverslag, men når du oppretter en gratis forekomst, er det ikke nødvendig å prøve dette. Du er ikke begrenset til portalen; du kan bruke Azure CLI, PowerShell eller til og med programmatisk fra innsiden av Cosmos DB SDK.
Bygger apper på Cosmos DBs gratis nivå
I Cosmos DB er en database et sett med containere som brukes til å håndtere partisjonering i en Azure-region og distribusjon over regionene du bruker databasen din i. Hver database kan konfigureres til å være en spesifikk modell: NoSQL (både MongoDB og Cassandra), SQL, Gremlin og tabeller. De fleste apper fungerer med den som en NoSQL-dokumentdatabase som lagrer JSON-data.
Når du har satt opp en database og valgt en modell, kan du tenke på en Cosmos DB-container som hvordan databasen skaleres. Utenfor gratisnivået kan du angi gjennomstrømning i RU / s på containerbasis; i det gratis nivået deler du gjennomstrømningen over alle containerne i databasen din, slik at du ikke kan forutsi gjennomstrømning for en bestemt container. Betalte forekomster har en tilknyttet SLA, og det er derfor de lar deg angi gjennomstrømning per container.
Å jobbe på tvers av containere på denne måten tilsvarer å bruke en klynge i en NoSQL-database og fungerer bra for denne typen arbeidsmengde. Ved å bruke den samme partisjonsnøkkelen over alle containerne dine, vil Cosmos DB automatisk dele gjennomstrømningen over dem. Du kan bruke denne tilnærmingen med gratisbeholders 25 containere for å redusere flaskehalser for brukerne av applikasjonen din. Hvis du behandler den som en splittet, gruppert NoSQL-database, bør du finne det relativt enkelt å inkludere den i applikasjonene dine, og bruke den til å være vert for pekere til annet innhold i stedet for selve innholdet.
Det kan være vanskelig å jobbe med et gratis tjenestetilbud, men hvis du tar fornuftige forholdsregler, bør det være mulig å bruke Cosmos DBs nye nivå som en del av en applikasjonsbakside. Du må kanskje ofre noen av tjenestens skalerbarhetsfunksjoner, men det bør ikke påvirke applikasjoner betydelig hvis du tar nøye beslutninger om designtid.
Det er viktig å tenke på hvordan du kan dra nytte av en distribuert database som Cosmos DB, i stedet for å bare portere eksisterende arbeidsmengder til den - de vil sannsynligvis ikke matche godt. Tenk i stedet på dette som din mulighet til å bygge et virkelig skyinnfødt, distribuert program. I dette tilfellet er 400 RU / s mer enn nok til å starte en ny applikasjon og få den til å fungere med et rimelig antall brukere.
