Oversigt (TL;DR)
Opdateret 3. juni 2017
Redis er mere kraftfuld, mere populær og bedre understøttet end memcached. Memcached kan kun gøre en lille brøkdel af de ting, Redis kan. Redis er bedre, selv hvor deres funktioner overlapper hinanden.
Til noget nyt, brug Redis.
Memcached vs Redis:Direkte sammenligning
Begge værktøjer er kraftfulde, hurtige datalagre i hukommelsen, der er nyttige som cache. Begge kan hjælpe med at fremskynde din applikation ved at cache databaseresultater, HTML-fragmenter eller andet, der kan være dyrt at generere.
Punkter at overveje
Når de bruges til det samme, er det her, hvordan de sammenligner med det originale spørgsmåls "Punkter at overveje":
- Læse-/skrivehastighed :Begge er ekstremt hurtige. Benchmarks varierer efter arbejdsbyrde, versioner og mange andre faktorer, men viser generelt, at redis er lige så hurtig eller næsten lige så hurtig som memcached. Jeg anbefaler redis, men ikke fordi memcached er langsom. Det er det ikke.
- Hukommelsesbrug :Redis er bedre.
- memcached:Du angiver cachestørrelsen, og efterhånden som du indsætter elementer, vokser dæmonen hurtigt til lidt mere end denne størrelse. Der er aldrig rigtig en måde at genvinde noget af den plads på, undtagen at genstarte memcached. Alle dine nøgler kunne være udløbet, du kunne tømme databasen, og den ville stadig bruge hele den del af RAM, du konfigurerede den med.
- redis:Indstilling af en maksimal størrelse er op til dig. Redis vil aldrig bruge mere, end det skal, og vil give dig hukommelse, det ikke længere bruger.
- Jeg gemte 100.000 ~2KB strenge (~200MB) af tilfældige sætninger i begge. Memcached RAM-brug voksede til ~225MB. Redis RAM-forbrug voksede til ~228MB. Efter at have tømt begge, faldt redis til ~29MB og memcached forblev på ~225MB. De er på samme måde effektive med hensyn til, hvordan de gemmer data, men kun én er i stand til at genvinde dem.
- Disk I/O-dumping :En klar gevinst for redis, da den gør dette som standard og har meget konfigurerbar vedholdenhed. Memcached har ingen mekanismer til dumping til disk uden 3. parts værktøjer.
- Skalering :Begge giver dig tonsvis af frihøjde, før du har brug for mere end en enkelt instans som cache. Redis inkluderer værktøjer, der hjælper dig med at gå ud over det, mens memcached ikke gør det.
memcached
Memcached er en simpel flygtig cacheserver. Det giver dig mulighed for at gemme nøgle/værdi-par, hvor værdien er begrænset til at være en streng på op til 1 MB.
Den er god til det her, men det er alt, hvad den gør. Du kan få adgang til disse værdier ved hjælp af deres nøgle ved ekstrem høj hastighed, hvilket ofte mætter tilgængeligt netværk eller endda hukommelsesbåndbredde.
Når du genstarter memcached, er dine data væk. Dette er fint for en cache. Du bør ikke gemme noget vigtigt der.
Hvis du har brug for høj ydeevne eller høj tilgængelighed, er der 3. parts værktøjer, produkter og tjenester tilgængelige.
redis
Redis kan udføre de samme opgaver, som memcached kan, og kan gøre dem bedre.
Redis kan også fungere som en cache. Det kan også gemme nøgle/værdi-par. I redis kan de endda være op til 512 MB.
Du kan slå vedholdenhed fra, og det vil også med glæde miste dine data ved genstart. Hvis du vil have din cache til at overleve, genstarter den dig også. Faktisk er det standarden.
Det er også superhurtigt, ofte begrænset af netværks- eller hukommelsesbåndbredde.
Hvis én forekomst af redis/memcached ikke er nok ydeevne til din arbejdsbyrde, er redis det klare valg. Redis inkluderer klyngeunderstøttelse og leveres med værktøjer med høj tilgængelighed (redis-sentinel) lige "i kassen". I løbet af de sidste par år har redis også vist sig som den klare leder inden for 3. parts værktøj. Virksomheder som Redis Labs, Amazon og andre tilbyder mange nyttige redis-værktøjer og -tjenester. Økosystemet omkring redis er meget større. Antallet af implementeringer i stor skala er nu sandsynligvis større end for memcached.
Redis Superset
Redis er mere end en cache. Det er en datastrukturserver i hukommelsen. Nedenfor finder du et hurtigt overblik over ting Redis kan ud over at være en simpel nøgle/værdi-cache som memcached. De fleste af redis' funktioner er ting, som memcached ikke kan.
Dokumentation
Redis er bedre dokumenteret end memcached. Selvom dette kan være subjektivt, ser det ud til at være mere og mere sandt hele tiden.
redis.io er en fantastisk let-navigeret ressource. Det lader dig prøve Redis i browseren og giver dig endda interaktive eksempler med hver kommando i dokumenterne.
Der er nu 2 gange så mange stackoverflow-resultater for redis som memcached. 2 gange så mange Google-resultater. Mere let tilgængelige eksempler på flere sprog. Mere aktiv udvikling. Mere aktiv kundeudvikling. Disse målinger betyder måske ikke meget individuelt, men i kombination tegner de et klart billede af, at support og dokumentation for redis er større og meget mere up-to-date.
Vedholdenhed
Som standard bevarer redis dine data til disk ved hjælp af en mekanisme kaldet snapshotting. Hvis du har nok RAM til rådighed, er den i stand til at skrive alle dine data til disken uden næsten ingen forringelse af ydeevnen. Det er næsten gratis!
I snapshot-tilstand er der en chance for, at et pludseligt nedbrud kan resultere i en lille mængde tabte data. Hvis du absolut har brug for at sikre dig, at ingen data nogensinde går tabt, skal du ikke bekymre dig, redis har også din ryg der med AOF (Append Only File)-tilstand. I denne persistenstilstand kan data synkroniseres til disk, mens de skrives. Dette kan reducere den maksimale skrivegennemstrømning til hvor hurtigt din disk kan skrive, men bør stadig være ret hurtig.
Der er mange konfigurationsmuligheder for at finjustere persistens, hvis du har brug for det, men standardindstillingerne er meget fornuftige. Disse muligheder gør det nemt at konfigurere redis som et sikkert, redundant sted at gemme data. Det er en rigtig database.
Mange datatyper
Memcached er begrænset til strenge, men Redis er en datastrukturserver, der kan betjene mange forskellige datatyper. Det giver også de kommandoer, du skal bruge for at få mest muligt ud af disse datatyper.
Strenge (kommandoer)
Simpel tekst eller binære værdier, der kan være op til 512 MB i størrelse. Dette er den eneste datatype redis og memcached share, selvom memcached strenge er begrænset til 1 MB.
Redis giver dig flere værktøjer til at udnytte denne datatype ved at tilbyde kommandoer til bitvise operationer, bit-niveau manipulation, flydende komma inkrementer/decrement support, interval forespørgsler og multi-key operationer. Memcached understøtter ikke noget af det.
Strings er nyttige til alle mulige anvendelsestilfælde, hvorfor memcached er ret nyttigt alene med denne datatype.
Hashes (kommandoer)
Hashes er ligesom et nøgleværdilager i et nøgleværdilager. De kortlægger mellem strengfelter og strengværdier. Felt->værdikort, der bruger en hash, er lidt mere pladseffektive end nøgle->værdikort, der bruger almindelige strenge.
Hashes er nyttige som et navneområde, eller når du logisk vil gruppere mange nøgler. Med en hash kan du gribe alle medlemmerne effektivt, udløbe alle medlemmerne sammen, slette alle medlemmerne sammen osv. Fantastisk til enhver brug, hvor du har flere nøgle/værdi-par, der skal grupperes.
Et eksempel på brug af en hash er til lagring af brugerprofiler mellem applikationer. En redis-hash, der er gemt med bruger-id'et som nøglen, giver dig mulighed for at gemme så mange bits af data om en bruger, som det er nødvendigt, mens du holder dem gemt under en enkelt nøgle. Fordelen ved at bruge en hash i stedet for at serialisere profilen til en streng er, at du kan få forskellige applikationer til at læse/skrive forskellige felter i brugerprofilen uden at skulle bekymre dig om, at én app tilsidesætter ændringer foretaget af andre (hvilket kan ske, hvis du serialiserer forældet data).
Lister (kommandoer)
Redis-lister er ordnede samlinger af strenge. De er optimeret til at indsætte, læse eller fjerne værdier fra toppen eller bunden (aka:venstre eller højre) af listen.
Redis giver mange kommandoer til at udnytte lister, herunder kommandoer til push/pop-elementer, push/pop mellem lister, afkorte lister, udføre områdeforespørgsler osv.
Lister gør store holdbare, atomare, køer. Disse fungerer fremragende til jobkøer, logfiler, buffere og mange andre brugssager.
Sæt (kommandoer)
Sæt er uordnede samlinger af unikke værdier. De er optimeret, så du hurtigt kan tjekke, om en værdi er i sættet, hurtigt tilføje/fjerne værdier og måle overlapning med andre sæt.
Disse er gode til ting som adgangskontrollister, unikke besøgendesporere og mange andre ting. De fleste programmeringssprog har noget lignende (normalt kaldet et sæt). Det er sådan, kun distribueret.
Redis giver flere kommandoer til at administrere sæt. Indlysende som at tilføje, fjerne og kontrollere sættet er til stede. Det samme er mindre indlysende kommandoer som at poppe/læse et tilfældigt element og kommandoer til at udføre foreninger og krydsninger med andre sæt.
Sorterede sæt (kommandoer)
Sorterede sæt er også samlinger af unikke værdier. Disse er, som navnet antyder, bestilt. De er ordnet efter et partitur, derefter leksikografisk.
Denne datatype er optimeret til hurtige opslag efter score. Det er ekstremt hurtigt at få den højeste, laveste eller et hvilket som helst interval af værdier imellem.
Hvis du tilføjer brugere til et sorteret sæt sammen med deres høje score, har du dig selv en perfekt rangliste. Efterhånden som nye highscores kommer ind, skal du bare tilføje dem til sættet igen med deres high score, og det vil omorganisere din rangliste. Også fantastisk til at holde styr på sidste gang, brugere besøgte, og hvem der er aktive i din applikation.
Lagring af værdier med samme score får dem til at blive ordnet leksikografisk (tænk alfabetisk). Dette kan være nyttigt til ting som autofuldførelsesfunktioner.
Mange af de sorterede sæt-kommandoer ligner kommandoer for sæt, nogle gange med en ekstra score-parameter. Der er også inkluderet kommandoer til styring af score og forespørgsel efter score.
Geo
Redis har flere kommandoer til lagring, hentning og måling af geografiske data. Dette inkluderer radiusforespørgsler og måling af afstande mellem punkter.
Teknisk set er geografiske data i redis gemt i sorterede sæt, så dette er ikke en virkelig separat datatype. Det er mere en udvidelse oven på sorterede sæt.
Bitmap og HyperLogLog
Ligesom geo er disse ikke helt separate datatyper. Disse er kommandoer, der giver dig mulighed for at behandle strengdata, som om det enten er en bitmap eller en hyperlog.
Bitmaps er, hvad de bit-niveau-operatorer, jeg refererede til under Strings er til. Denne datatype var den grundlæggende byggesten til reddits nylige samarbejdskunstprojekt:r/Place.
HyperLogLog giver dig mulighed for at bruge en konstant ekstrem lille mængde plads til at tælle næsten ubegrænsede unikke værdier med chokerende nøjagtighed. Ved kun at bruge ~16KB kunne du effektivt tælle antallet af unikke besøgende på dit websted, selvom det tal er i millioner.
Transaktioner og atomicitet
Kommandoer i redis er atomiske, hvilket betyder, at du kan være sikker på, at så snart du skriver en værdi til redis, er denne værdi synlig for alle klienter, der er forbundet til redis. Der er ingen ventetid på, at værdien forplanter sig. Teknisk er memcached også atomisk, men med redis tilføjelse af al denne funktionalitet ud over memcached er det værd at bemærke og noget imponerende, at alle disse yderligere datatyper og funktioner også er atomare.
Selvom det ikke er helt det samme som transaktioner i relationelle databaser, har redis også transaktioner, der bruger "optimistisk låsning" (WATCH/MULTI/EXEC).
Rørføring
Redis har en funktion kaldet 'pipelining'. Hvis du har mange redis-kommandoer, du vil udføre, kan du bruge pipelining til at sende dem til Redis-alt-på-en gang i stedet for én ad gangen.
Normalt når du udfører en kommando til enten redis eller memcached, er hver kommando en separat anmodning/svar-cyklus. Med pipelining kan redis buffere adskillige kommandoer og udføre dem alle på én gang og svare med alle svarene på alle dine kommandoer i et enkelt svar.
Dette kan give dig mulighed for at opnå endnu større gennemløb ved masseimport eller andre handlinger, der involverer mange kommandoer.
Pub/Sub
Redis har kommandoer dedikeret til pub/sub-funktionalitet, hvilket gør det muligt for redis at fungere som en højhastighedsmeddelelsesudsender. Dette giver en enkelt klient mulighed for at udgive beskeder til mange andre klienter, der er forbundet til en kanal.
Redis laver pub/sub såvel som næsten ethvert værktøj. Dedikerede meddelelsesmæglere som RabbitMQ kan have fordele på visse områder, men det faktum, at den samme server også kan give dig vedvarende holdbare køer og andre datastrukturer, som dine pub-/sub-arbejdsbelastninger sandsynligvis har brug for, vil Redis ofte vise sig at være det bedste og mest enkle værktøj til jobbet.
Lua Scripting
Du kan lidt tænke på lua-scripts som Redis' egen SQL eller lagrede procedurer. Det er både mere og mindre end det, men analogien virker for det meste.
Måske har du komplekse beregninger, du vil have redis til at udføre. Måske har du ikke råd til at få dine transaktioner til at rulle tilbage og har brug for garantier, at hvert trin i en kompleks proces vil ske atomært. Disse problemer og mange flere kan løses med lua scripting.
Hele scriptet udføres atomisk, så hvis du kan passe din logik ind i et lua-script, kan du ofte undgå at rode med optimistiske låsetransaktioner.
Skalering
Som nævnt ovenfor inkluderer redis indbygget understøttelse af clustering og er bundtet med sit eget værktøj med høj tilgængelighed kaldet redis-sentinel .
Konklusion
Uden tøven vil jeg anbefale redis over memcached for alle nye projekter eller eksisterende projekter, der ikke allerede bruger memcached.
Ovenstående kan lyde som om jeg ikke kan lide memcached. Tværtimod:det er et kraftfuldt, enkelt, stabilt, modent og hærdet værktøj. Der er endda nogle use cases, hvor det er lidt hurtigere end redis. Jeg elsker memcached. Jeg synes bare ikke, det giver meget mening for den fremtidige udvikling.
Redis gør alt, hvad memcached gør, ofte bedre. Enhver ydeevnefordel for memcached er mindre og arbejdsbelastningsspecifik. Der er også arbejdsbelastninger, for hvilke redis vil være hurtigere, og mange flere arbejdsbelastninger, som redis kan gøre, som memcached simpelthen ikke kan. De små præstationsforskelle synes små i lyset af den gigantiske kløft i funktionalitet og det faktum, at begge værktøjer er så hurtige og effektive, at de meget vel kan være den sidste del af din infrastruktur, du nogensinde skal bekymre dig om at skalere.
Der er kun ét scenarie, hvor memcached giver mere mening:hvor memcached allerede er i brug som en cache. Hvis du allerede cacher med memcached, så fortsæt med at bruge det, hvis det opfylder dine behov. Det er sandsynligvis ikke besværet værd at flytte til Redis, og hvis du vil bruge Redis kun til caching, giver det muligvis ikke nok fordel til at være din tid værd. Hvis memcached ikke opfylder dine behov, skal du nok flytte til redis. Dette gælder uanset om du skal skalere ud over memcached, eller du har brug for yderligere funktionalitet.