|
Å utvikle applikasjoner med Redis er en hyggelig prosess, men som med all teknologi er det noen ting du må huske på når du designer applikasjoner basert på Redis. Du har kanskje vært kjent med hele rutinen for utvikling av relasjonsdatabaser før, og Redis-basert applikasjonsutvikling har mange likheter, men du må huske på følgende to ting – Redis er en minnedatabase og den er enkelttrådet. Derfor må du være oppmerksom på følgende punkter når du bruker Redis: 1. Kontrollere alle taster lagret i Redis Hovedfunksjonen til en database er å lagre data, men det er normalt at utviklere ignorerer noe data lagret i databasen på grunn av endringer i applikasjonskrav eller databruksmetoder, og det samme gjelder i Redis. Du kan overse visse nøkler som utløper, eller du kan glemme dataene fordi en modul i applikasjonen din er utdatert. I begge tilfeller lagrer Redis noen data som ikke lenger er i bruk, og tar opp plass uten grunn. Redis' svakt strukturerte datamønster gjør det vanskelig å finne ut hva som lagres sentralt med mindre du bruker en svært moden nomenklatur for nøkler. Å bruke riktig navnemetode vil forenkle databasehåndteringen din, og når du oppretter et navnerom for nøkler gjennom applikasjonen eller tjenesten din (vanligvis ved å bruke kolon for å dele nøkkelnavn), kan du enkelt identifisere data når du migrerer, konverterer eller sletter dem. Et annet vanlig brukstilfelle for Redis er som et sekundært datalager for hot data-elementer, hvor mesteparten av dataene lagres i andre databaser, som PostgreSQL eller MongoDB. I disse brukstilfellene glemmer utviklere ofte å slette tilsvarende data i Redis når data fjernes fra primærlagring. I slike tilfeller kreves vanligvis kaskadesletting, og da kan det oppnås ved å lagre alle identifikatorer for et spesifikt dataelement i Redis-konfigurasjonen, slik at etter at dataene er slettet i primærdatabasen, tilkalles en renser for å slette alle relevante kopier og informasjon. 2. Kontrollere lengden på alle nøkkelnavn Som vi sa over, brukte vi passende navnekonvensjoner og la til prefikser for å identifisere hvor dataene går, så dette ser ut til å gå imot det. Men ikke glem at Redis er en database i minnet, og jo kortere nøklene er, desto mindre plass trenger du. Naturligvis, når det finnes millioner eller milliarder av nøkler i en database, vil lengden på nøkkelnavnet ha stor betydning. For eksempel, på en 32-bits Redis-server, hvis du lagrer én million nøkler med en lengde på 32 tegn, vil den bruke omtrent 96 MB plass når du bruker et nøkkelnavn på 6 tegn, men hvis du bruker et nøkkelnavn på 12 tegn, vil plassforbruket øke til omtrent 111 MB. Med flere nøkler vil den ekstra 15 % overheaden ha betydelig innvirkning. 3. Bruk riktig datastruktur Enten det gjelder minnebruk eller ytelse, kan datastrukturer noen ganger ha stor innvirkning, her er noen beste praksiser å referere til: I stedet for å lagre data som tusenvis (eller millioner) av separate strenger, bør du vurdere å bruke hashede datastrukturer for å gruppere relaterte data. Hashtabeller er svært effektive og kan redusere minnebruket ditt; Samtidig er hashing også mer gunstig for detaljabstraksjon og kodelesbarhet. Når det er hensiktsmessig, bruk liste i stedet for 'sett'. Hvis du ikke trenger å bruke Set-funksjonen, kan List gi raskere hastigheter enn Set, samtidig som du bruker mindre minne. Sorterte sett er de dyreste datastrukturene, både når det gjelder minneforbruk og kompleksiteten i grunnleggende operasjoner. Hvis du bare trenger en måte å spørre poster på og ikke bryr deg om å sortere slike egenskaper, anbefales det sterkt å bruke hashtabeller. En ofte oversett funksjon i Redis er bitmaps eller bitsett (etter V2.2). Bitsets lar deg utføre flere bitnivåoperasjoner på Redis-verdier, som for eksempel lett analyse. 4. Ikke bruk nøkkelen når du bruker SCAN Fra og med Redis v2.8 er SCAN-kommandoen allerede tilgjengelig, som gjør det mulig å hente nøkler fra nøkkelområdet ved hjelp av markøren. Sammenlignet med KEYS-kommandoen, selv om SCAN ikke kan returnere alle matchende resultater samtidig, unngår den den høye risikoen for å blokkere systemet, slik at noen operasjoner kan utføres på hovednoden. Det er viktig å merke seg at SCAN-kommandoen er en markørbasert iterator. Hver gang SCAN-kommandoen kalles, vil en ny markør bli returnert til brukeren, og brukeren må bruke denne nye markøren som markørparameter for SCAN-kommandoen i neste iterasjon, for å fortsette forrige iterasjon. Samtidig kan brukere med SCAN også justere kommandoer ved å bruke tastenavnsmodus og tellingsalternativer. SCAN-relaterte kommandoer inkluderer også SSCAN-kommandoer, HSCAN-kommandoer og ZSCAN-kommandoer, som brukes for samlinger, hash-nøkler og oppfølgere, henholdsvis. 5. Bruk serverside Lua-skript I prosessen med å bruke Redis gir støtten til Lua-skript utvilsomt utviklerne et svært vennlig utviklingsmiljø, og frigjør dermed brukernes kreativitet betydelig. Når de brukes riktig, kan Lua-skript gi betydelige forbedringer i ytelse og ressursforbruk. I stedet for å sende data til CPU-en, lar skript deg utføre logikk nærmest dataene, noe som reduserer nettverkslatens og redundant dataoverføring. I Redis er et veldig klassisk brukstilfelle for Lua datafiltrering eller aggregering av data i en applikasjon. Ved å kapsle inn prosesseringsflyten i et skript, kan du enkelt kalle det for å få et mindre svar med få ressurser på kortere tid. Profftips:Lua er flott, men har også noen problemer, som vanskeligheter med å rapportere og håndtere feil. En smart tilnærming er å bruke Redis' Pub/Sub-funksjon og la skriptet sende loggmeldinger over en dedikert kanal. Deretter oppretter du en abonnentprosess og behandler den deretter.
| 
Publisert på 29.12.2015 12:22:28
|
|
|
