Reduserer tid til verdi i NoSQL-dummies

Tid til verdi er hvor mye tid som kreves fra å starte et IT-prosjekt for å kunne realisere forretningsfordeler. Dette kan være konkrete fordeler med kostnadsreduksjon eller evnen til å drive ny virksomhet eller immaterielle fordeler som å gi bedre kundeservice eller produkter.

Nøkkelverdier er de enkleste NoSQL-databasene med hensyn til datamodell. Så du kan raskt bygge applikasjoner, spesielt hvis du bruker noen sentrale prinsipper, inkludert å se hvordan du administrerer datastrukturer.

Bruke enkle strukturer

Nøkkeltall butikker er mer fleksible enn relasjonsdatabaser når det gjelder formatet av data. Bruk denne fleksibiliteten til din fordel for å maksimere hastigheten på programmets gjennomstrømning. Hvis du for eksempel lagrer kartfliser, lagrer du dem i hex-format slik at de kan gjengis umiddelbart i en nettleser.

Lagre brukervennlige strukturer som ikke krever antall behandlingstider, i søknaden din. Disse strukturene kan være enkle egentlige typer som heltall, strenger og datoer, eller mer sofistikerte strukturer som lister, sorterte sett eller JSON-dokumenter lagret som en streng.

Fordi det kan tolkes direkte av et JavaScript-webprogram, bruker du JSON for enkel webappstatus eller preferanseoppbevaring. Hvis du lagrer loggdata, lagrer du det i formatet som er best egnet for gjenfinning og analyse.

Bruk den mest hensiktsmessige strukturen for søknaden din, ikke din databaseadministrator. Vurder også effekten av tid på databasen. Vil du endre data strukturer i fremtiden for å støtte nye funksjoner?

Datastrukturene endres over tid. Et fleksibelt JSON-dokument er bedre enn en CSV-datafil eller en datafil med fast bredde fordi JSON-strukturer lett kan variere over tid uten å måtte vurdere nye eller slettede egenskaper. Endre en kolonne i en CSV-fil som er lagret i en nøkkelverdibutikk, og du må oppdatere hele programmets kode! Dette er ikke tilfelle med et JSON-dokument, der eldre koden bare ignorerer nye egenskaper.

Kompleks strukturhåndtering

Hvis du har komplekse interrelaterte datasett, bør du nøye tenke på datastrukturene i nøkkelverdibutikken din. Lagre datasett på en måte som muliggjør enkel henting. Snarere enn å lagre åtte elementer separat som vil kreve åtte leser, deormalisere dataene - skriv dataene til samme plate ved inntakstidspunktet - slik at bare en lesing trengs senere.

Dette betyr at noen data vil bli lagret flere ganger. Et eksempel er å lagre kundenavn i et bestillingsdokument.Selv om dette lagrer kundenavnet på tvers av mange bestillinger, betyr det når du viser et sammendrag av bestillingen du ikke trenger å oppdage at verdien customer_number = 12 betyr Mr A Fowler - forebygging en ekstra leseforespørsel.

Denormalisering forbruker mer diskplass enn relasjonsdatabaser normal form , men øker søkemessig kraftig. Det er NoSQL-ekvivalenten av en materialisert visning i en relasjonsdatabase. Du ofrer lagringsplass for fart - den klassiske informatikkutvekslingen.

For datavitenskapere av en bestemt generasjon anses det kjetteri å beholde flere kopier av de samme dataene. Det er ganske enkelt ineffektivt. Relasjonsdatabase forelesere vil spise deg til frokost!

Men med dagens lave kostnader for lagring og de økende kravene til moderne applikasjoner, er det mye bedre å ofre lagring for hastighet i lese data. Så betrakt denormalisering som en venn.