|
At udvikle applikationer med Redis er en behagelig proces, men som med enhver teknologi er der nogle ting, du skal huske på, når du designer Redis-baserede applikationer. Du har måske været bekendt med hele rutinen for udvikling af relationelle databaser før, og Redis-baseret applikationsudvikling har mange ligheder, men du skal huske følgende to ting – Redis er en in-memory database og er single-threaded. Derfor skal du være opmærksom på følgende punkter, når du bruger Redis: 1. Kontroller alle taster, der er lagret i Redis Hovedfunktionen for en database er at gemme data, men det er normalt, at udviklere ignorerer nogle data, der er gemt i databasen, på grund af ændringer i applikationskrav eller dataanvendelsesmetoder, og det samme gælder i Redis. Du kan overse visse nøgler, der udløber, eller du kan glemme dataene, fordi en modul i din applikation er forældet. I begge tilfælde gemmer Redis nogle data, der ikke længere er i brug, og optager plads uden grund. Redis' svagt strukturerede datamønster gør det svært at finde ud af, hvad der gemmes centralt, medmindre man bruger en meget moden nomenklatur for nøgler. At bruge den rigtige navngivningsmetode vil forenkle din databaseadministration, og når du opretter et navnerum for nøgler gennem din applikation eller service (normalt ved at bruge kolon til at opdele nøglenavne), kan du nemt identificere data, når du migrerer, konverterer eller sletter dem. Et andet almindeligt brugstilfælde for Redis er som en anden datalager for hot data-elementer, hvor det meste af dataene gemmes i andre databaser, såsom PostgreSQL eller MongoDB. I disse brugstilfælde glemmer udviklere ofte at slette de tilsvarende data i Redis, når data fjernes fra primærlageret. I dette tilfælde kræves cascade-sletning normalt, hvilket kan opnås ved at gemme alle identifikatorer for et specifikt dataelement i Redis-konfigurationen, så det sikres, at efter dataslettelsen i den primære database tilkaldes en cleaner for at slette alle relevante kopier og information. 2. Kontroller længden af alle nøglenavne Som vi sagde ovenfor, brugte vi passende navngivningskonventioner og tilføjede præfikser for at identificere, hvor dataene skal hen, så det ser ud til at gå imod det. Men glem ikke, at Redis er en database i hukommelsen, og jo kortere nøglerne er, desto mindre plads har du brug for. Naturligvis, når der er millioner eller milliarder af nøgler i en database, vil længden af nøglenavnet have stor betydning. For eksempel, på en 32-bit Redis-server, hvis du gemmer en million nøgler med en længde på 32 tegn, vil det bruge omkring 96 MB plads, når du bruger et 6-tegns nøglenavn, men hvis du bruger et 12-tegns nøglenavn, vil pladsforbruget stige til omkring 111 MB. Med flere nøgler vil de ekstra 15% overhead have en betydelig effekt. 3. Brug den rette datastruktur Uanset om det handler om hukommelsesforbrug eller ydeevne, kan datastrukturer nogle gange have stor indflydelse, her er nogle bedste praksisser, du kan referere til: I stedet for at gemme data som tusindvis (eller millioner) af separate strenge, bør du overveje at bruge hashede datastrukturer til at gruppere relaterede data. Hashtabeller er meget effektive og kan reducere dit hukommelsesforbrug; Samtidig er hashing også mere gavnligt for detaljeabstraktion og kodelæsbarhed. Når det er passende, brug liste i stedet for 'set'. Hvis du ikke behøver at bruge set-funktionen, kan List give hurtigere hastigheder end set, samtidig med at du bruger mindre hukommelse. Sorterede sæt er de dyreste datastrukturer, både hvad angår hukommelsesforbrug og kompleksiteten af grundlæggende operationer. Hvis du bare har brug for en måde at forespørge poster på og ikke bekymrer dig om at sortere sådanne egenskaber, anbefales det stærkt at bruge hashtabeller. En ofte overset funktion i Redis er bitmaps eller bitsets (efter V2.2). Bitsets tillader dig at udføre flere bitniveau-operationer på Redis-værdier, såsom let analyse. 4. Brug ikke nøglen, når du bruger SCAN Fra Redis v2.8 er SCAN-kommandoen allerede tilgængelig, som gør det muligt at hente nøgler fra nøglerummet ved hjælp af markøren. Sammenlignet med KEYS-kommandoen, selvom SCAN ikke kan returnere alle matchende resultater på én gang, undgår den den høje risiko for at blokere systemet, så nogle operationer kan udføres på masternoden. Det er vigtigt at bemærke, at SCAN-kommandoen er en cursor-baseret iterator. Hver gang SCAN-kommandoen kaldes, returneres en ny markør til brugeren, og brugeren skal bruge denne nye markør som markørparameter for SCAN-kommandoen i næste iteration for at fortsætte den forrige iteration. Samtidig kan brugere med SCAN også justere kommandoer ved hjælp af tastnavnetilstand og tælling. SCAN-relaterede kommandoer inkluderer også SSCAN-kommandoer, HSCAN-kommandoer og ZSCAN-kommandoer, som bruges til samlinger, hash-nøgler og efterfølgere, henholdsvis. 5. Brug serverside Lua-scripts I processen med at bruge Redis giver understøttelsen af Lua-scripts uden tvivl udviklerne et meget brugervenligt udviklingsmiljø, hvilket i høj grad frigør brugernes kreativitet. Når de bruges korrekt, kan Lua-scripts give betydelige forbedringer i ydeevne og ressourceforbrug. I stedet for at sende data til CPU'en tillader scripts, at du kan udføre logik tættest på dataene, hvilket reducerer netværkslatens og redundant dataoverførsel. I Redis er et meget klassisk brugsscenarie for Lua datafiltrering eller aggregering af data i en applikation. Ved at indkapsle behandlingsarbejdsgangen i et script kan du blot kalde det for at få et mindre svar med få ressourcer på kortere tid. Pro tip:Lua er fantastisk, men den har også nogle problemer, såsom vanskeligheder med at rapportere og håndtere fejl. En smart tilgang er at bruge Redis' Pub/Sub-funktion og lade scriptet sende logbeskeder over en dedikeret kanal. Opret derefter en abonnentproces og behandl den derefter.
| 
Opslået på 29/12/2015 12.22.28
|
|
|
