Redis vs. Memcached – 2021 Sammenligning

Redis står for RE mote DI ordbog S erver, skabt i 2009 af Salvatore Sanfilippo. Memcached blev på den anden side skabt i 2003 af Brad Fitzpatrick. Både Redis og Memcached er:

• NoSQL-datastrukturer i hukommelsen
• Skrevet i C
• Open source
• Bruges til at fremskynde applikationer
• Understøttet forsinkelse på under millisekunder

I 2014 skrev Salvatore et fremragende StackOverflow-indlæg om, hvornår det giver mere mening at bruge Memcached end Redis. I dette indlæg giver vi en aktuel og detaljeret sammenligning mellem Redis og Memcached, så du kan træffe et informeret valg om deres brug i din applikation.

Infografik

Dette indlæg er blevet komprimeret til nedenstående infografik. Med denne infografik kan du nemt visualisere resultaterne af denne sammenligning for at se, hvilken der kommer øverst i forskellige scenarier. Hvis du vil læse sammenligningen i tekstformat, så klik her.

Dokumentation

For at starte med er Redis meget mere omfattende dokumenteret end Memcached. Dette gør det nemmere at lære, administrere og bruge.

Databasemodel

Redis er primært en nøgleværdibutik. Mens nøgler er binære strenge, er fordelen med Redis, at værdien ikke er begrænset til kun binære strenge. De kan være en række datastrukturer, som muliggør lagring af komplekse objekter og giver et rigt sæt af operationer over dem. Redis sørger også for udvidelsesmuligheder via Redis-moduler. Redis-moduler er udvidelser, der giver mulighed for yderligere datastrukturer og funktioner, der ikke er tilgængelige i kernefunktionssættet. Her er et eksempel på nogle få funktioner, der nu er tilgængelige som moduler:

• Dokumentlager
• Graf DBMS
• Søgemaskine
• Tidsserie-DBMS

Memcached er et almindeligt nøgleværdilager, som kun understøtter binære strenge som værdi.

Datastrukturer

Som nævnt ovenfor tilbyder Redis flere datastrukturtyper, der gør det muligt at bruge det ekstremt fleksibelt, herunder strenge, hashes, lister, sæt, sorterede sæt, bitmaps, bitfelter, HyperLogLog, Geospatiale indekser og streams. Du kan lære mere om disse i denne artikel om Top Redis Use Cases efter Core Data Structure Types.

Billedkilde:https://redislabs.com/redis-enterprise/data-structures/

Memcached understøtter kun almindelige binære strenge, som er gode til skrivebeskyttede data, så hvis du ikke har brug for alle Redis' klokker og fløjter, er Memcached en enklere database for dig at bruge.

Databaserangering og popularitet

Den større popularitet af en database resulterer i et større fællesskab af brugere, flere diskussioner og brugergenererede tutorials og mere hjælp og support gennem tredjepartsværktøjer såsom DBaaS-platforme og analyseværktøjer til at hjælpe med at optimere dine implementeringer.

Redis er den 8. mest populære database i verden i februar 2021 ifølge DB-Engines på grund af dens enkelhed, rige datastrukturer og fremragende dokumentation. Memcached er i øjeblikket rangeret som den 28. mest populære database. Når Redis og Memcached er rangeret med hensyn til nøgleværdidatabasemodeller, står Redis på 1. og Memcached kommer på 4. pladsen. Men hvis du kun leder efter en open source-nøgleværdi-database eller en, der kan implementeres på stedet, kommer Memcached på andenpladsen, da både Amazon DynamoDB og Microsoft Azure Cosmos DB begge er kommercielle databaser, der kun kan implementeres i skyen.

Arkitektur

Redis og Memcached følger begge client-server arkitektur. Klienter udfylder dataene på serveren i form af nøgleværdi.

Redis er enkelttrådet, hvor Memcached på den anden side har en flertrådsarkitektur. Memcached skalerer bedre på et system med flere kerner, der kan håndtere flere operationer, hvis beregningskapaciteten skaleres. Imidlertid kan mere end én Redis-instans initieres på det samme system for at bruge yderligere kerner.

Brugervenlighed

Som forklaret ovenfor i afsnittet Databasemodel, kan Redis, som er en multimodeldatabase, bruges med enhver type datamodel. I Redis er det nemt at skrive kode, da det forenkler komplekse opgaver. Redis har avancerede datastrukturer og er ikke begrænset til simple strengværdier. For eksempel, hvis din applikation gemmer data i sæt, og du vil holde styr på sæt på en liste, kan du nemt gøre dette i Redis. En lignende opgave på Memcached er ikke mulig. Men der er andre måder at udføre de samme opgaver på, som vil kræve flere linjer kode.

Memcached gemmer på den anden side kun almindelige strengværdier. Så applikationen er overladt til at håndtere datastrukturens kompleksitet.

Datapartitionering

Redis understøtter partitionering af data på tværs af flere node-forekomster. Nuværende brugere af Redis udnytter forskellige teknikker som rækkepartitionering, hash-partitionering og konsekvent hashing til datapartitionering. I Redis kan datapartitionering implementeres på tre forskellige måder:

• Partitionering på klientsiden
• Proxy-assisteret partitionering (eksempel:twemproxy)
• Serversidepartitionering med forespørgselsrouting inden for klyngeknuderne

Memcached understøtter også datapartitionering på tværs af flere noder, og konsekvent hashing er en anbefalet tilgang til at sikre, at trafikbelastningen er jævnt fordelt.

Understøttede sprog

Redis understøtter næsten alle de mest brugte programmeringssprog, fra højniveau til lavniveausprog. Memcached understøtter dog færre sprog sammenlignet med Redis, men understøtter alle de populære sprog.

Memcached

• .Net
• C
• C++
• ColdFusion
• Erlang
• Java
• Lisp
• Lua
• OCaml
• Perl
• PHP
• Python
• Ruby

Redis

• C
• C#
• C++
• Clojure
• Krystal
• D
• Dart
• Eliksir
• Erlang
• Fancy
• Gå
• Haskell
• Haxe
• Java
• JavaScript (Node.js)
• Lisp
• Lua
• MatLab
• Mål-C
• OCaml
• Pascal
• Perl
• PHP
• Prolog
• Rene data
• Python
• R
• Rebol
• Ruby
• Rust
• Scala
• Skema
• Smalltalk
• Hurtig
• Tcl
• Visual Basic

Transaktioner

Redis "transaktioner" udføres med de tre nedenstående garantier:

• Transaktioner serialiseres og udføres sekventielt
• Enten behandles alle kommandoerne, eller ingen, (atomtransaktioner)
• Optimistisk låsning giver en ekstra garanti ved brug af check-and-set

Redis sørger for, at kun én kommando fra én klientmaskine udføres på én gang. Alle kommandoerne i transaktionerne udføres, når kommandoen "EXEC" kaldes for at sikre atomiciteten.

Memcached giver på den anden side ikke transaktionsstyring.

Replikering

Redis tilbyder en simpel leder-følger (master-slave) replikering, der skaber nøjagtige kopier af master-forekomsterne med disse funktioner:

• Masteren bliver ved med at sende datakommandoer til slaven, så længe de er forbundet.
• Hvis forbindelsen afbrydes, vil slaven følge delvis resynkronisering og kopiere kun de data, der blev savnet under afbrydelsen.
• Hvis delvis gensynkronisering ikke er mulig, vil den prøve en fuld gensynkronisering.

Du kan også udnytte funktionerne med høj tilgængelighed, Redis Sentinels eller Redis Cluster, til avanceret failover-beskyttelse.

Native Memcached understøtter ikke replikering, men du kan bruge Repcached, en gratis open source-patch for at opnå høj tilgængelighed til din implementering. Det tilbyder multimasterreplikering, asynkron datareplikering og understøtter alle Memcached-kommandoer.

Snapshots/vedholdenhed

Snapshots er simpelthen en skrivebeskyttet visning af din database, som den var på et bestemt tidspunkt. Redis understøtter snapshots, og som standard gemmer Redis snapshots af datasættet på disken i en binær fil kaldet dump.rdb. Du kan manuelt kalde et øjebliksbillede eller tilpasse frekvensen eller ændre tærskelværdien for at køre operationen.

Her er de to persistensmuligheder, som Redis understøtter:

• RDB-vedholdenhed
• AOF-vedholdenhed

RDB står for "Redis Database Backup". Det er et kompakt øjebliksbillede af databasen på et bestemt tidspunkt. Den fylder mindre, maksimerer Redis-ydelsen og er god til katastrofeoprettelse.

AOF står for "Append Only File". AOF holder styr på alle de kommandoer, der udføres, og i en katastrofal situation udfører den kommandoerne igen for at få dataene tilbage. Denne metode tager mere plads, da alle kommandoerne udføres igen, og er ikke en særlig holdbar metode til snapshots.

Memcached understøtter på den anden side ikke vedholdenhed på disken.

Scripts på serversiden

Lua er det indlejrede scriptsprog til din Redis-server, tilgængelig fra version 2.6, som lader dig udføre operationer inde i Redis for at forenkle din kode og øge ydeevnen. De to hovedfunktioner, der bruges til at evaluere scripts ved hjælp af Lua-fortolkeren, er:

• EVAL
• EVALSHA

Når Lua-scriptet udføres, blokeres alle andre anmodninger som vist i figuren nedenfor.

Redis inkluderer også Lua scripts debugger i version 3.2, som gør det nemmere at skrive komplekse scripts og hjælper med at øge ydeevnen.

Memcached understøtter ikke nogen scripting på serversiden.

Skalerbarhed

Der er to teknikker til at skalere din Redis-database vandret:

• Tilføjelse af shards i Redis Clusters
• Tilføjelse af noder til en Redis HA (master/replika) opsætning

Du kan også skalere din Redis-opsætning lodret, når du har brug for mere hukommelse eller computer. Det kan gøres uden nedetid, hvis du har en HA-opsætning, eller du bruger Redis Cluster-teknologi.

Memcached-serveren giver ikke en mekanisme til at distribuere data på tværs af noder (sharding). Så i Memcached er horisontal skalerbarhed så simpelt som at tilføje flere noder - problemet med at opdele dine data i forskellige shards skal gøres på applikations-/klientniveau. Der er nogle open source-værktøjer, der kan hjælpe dig med dette.

Kommunikationsprotokol

Redis bruger TCP som en netværksprotokol og understøtter ikke UDP.

Memcached understøtter både TCP- og UDP-kommunikationsprotokollerne. Data sendes til Memcached-serveren i to former:

• Tekstlinjer:Send kommandoer og modtag svar fra serveren.
• Ustrukturerede data:Modtag eller send værdioplysninger for en given nøgle, og data returneres i det angivne format.

Understøttede cache-udsmidningspolitikker

Redis understøtter forskellige typer af fraflytningspolitikker. Lad os tage et kig på nogle.

• udelukkelse:  I "noeviction" returneres en fejl, når hukommelsen når den bundet.

• allkeys-lru:  Lru står for "mindst nyligt brugt". Denne politik fjerner de senest anvendte data.

• allkeys-lfu:  Lfu står for "mindst brugt". Denne politik fjerner de mindst hyppigt anvendte data.

• allkeys-random:  Denne politik fjerner dataene tilfældigt.

• volatile-lru:  Flygtige data er med udløbsdatasæt. Denne politik fjerner de mindst nyligt anvendte flygtige data.

• volatile-lfu:  Flygtige data er med udløbsdatasæt. Denne politik fjerner de mindst hyppigt anvendte flygtige data.

• flygtig-tilfældig:  Denne politik fjerner de flygtige data tilfældigt.

• volatile-ttl:  "TTL" står for tid til at leve. Denne politik fjerner de data, der har den korteste tid tilbage.

Memcached bruger LRU-algoritme til at fjerne data, når der kræves plads. Den søger først efter de allerede udløbne data for at slette, hvis udløbne data ikke er tilgængelige, bruges LRU-algoritmen.

Udgiv og abonner på beskeder

Redis understøtter Pub/Sub-meddelelser (publicer og abonner). Der er tre kommandoer, der bruges til dette formål.

Klienten bruger:

• Abonner
• Afmeld

Abonner og afmeld bruges til at få beskeder fra en bestemt kanal.

Serveren bruger:

• Udgiv

"Publicer" bruges til at sende data til klienterne.

Memcached understøtter ikke udgivelse og abonnement på beskeder.

Streams Support

Redis understøtter Kafka-lignende streams med 5.0 eller nyere version ved hjælp af en ny datastruktur "Redis Streams". Redis Streams har konceptet med forbrugergrupper, som Apache Kafka, der lader klientapplikationer forbruge beskeder på en distribueret måde, hvilket gør det nemt at skalere og skabe meget tilgængelige systemer.

Memcached tilbyder ikke indbygget support til streams, men der er open source biblioteksværktøjer som Kafcache til streambehandling med lav latenstid.

Geospatial support

Redis har en datastruktur kaldet Geospatiale indekser, der gemmer længde- og breddegradsdata for en placering. Du kan udføre forskellige operationer på de geospatiale data, som at beregne afstanden mellem to punkter eller finde steder i nærheden.

Memcached har ingen særlige datastrukturer til at håndtere geospatiale data.

Ydeevne

En præstationssammenligning mellem nøgleværdidatalagre i hukommelsen er mere en intellektuel øvelse end af nogen praktisk betydning – medmindre du implementerer systemer i en sådan skala, at dette bliver interessant som en omkostningsbesparende foranstaltning. Dette skyldes, at sådanne lagre er IO-bundne, og normalt kan netværksforsinkelsen spille en større rolle i applikationens opfattede latens end databaselatensen.

Et mere praktisk ydeevneaspekt er lagereffektivitet – hvor meget data kan pakkes i den samme mængde hukommelse. Selv her varierer de interne datastrukturer, der bruges af Redis, baseret på datastørrelsen. Så enhver diskussion om ydeevne mellem disse databaser bør tages med et gran salt.

Lad os tage et kig på nogle sammenligninger vist i et forskningspapir fra 2016. I dette papir eksperimenterer forfatterne de meget anvendte in-memory-databaser for at måle deres ydeevne i form af:

1. Den tid, det tager at fuldføre handlinger.
2. Hvor effektivt bruger de hukommelsen under operationer.

Databaseversioner brugt i papiret:

Skrivehandling

Mens du skriver data, som du kan se, viser Memcached i tabellen nedenfor exceptionel hastighed, selv efter at antallet af poster er rykket op til millioner.

Den beregnede tid til at skrive nøgleværdi-par (ms)

Læs Operation

Læsedata forbliver næsten konsistent i Redis selv for en million poster, men i Memcached stiger tiden også en smule, efterhånden som antallet af poster stiger.

Den forløbne tid til at læse værdien svarende til en given nøgle pr. database (ms)

Hukommelsesbrug

Mens man diskuterer hukommelsesbrug, er Redis altid det bedste, som du kan se i resultaterne.

Hukommelsesbrug af databaser i hukommelsen til skriveoperation (MB)

Som du kan se er Redis bedre end Memcached.

Hukommelsesbrug af databaser i hukommelsen til sletningsoperation (MB)

Administrerede tjenester/support

Den større popularitet og fællesskabet for Redis har også drevet behovet for administrerede tjenester, hosting og support. Populære administrerede databaseudbydere til Redis™* inkluderer ScaleGrid, Redis Labs, AWS Elasticache, Azure Cache og DigitalOcean. Denne side giver en fantastisk sammenligning af de bedste udbydere af Redis™. Redis har også omfattende interne rapporteringsværktøjer som cache-hits, hukommelsesbrug, ops og endda en langsom forespørgsel, der logges.

Administrerede tjenester til Memcached er langt mindre tilgængelige, men understøttes stadig via Amazon Elasticache.

Transport Layer Security (TLS) Support

Redis har indbygget TLS-understøttelse fra Redis 6.0. Tidligere versioner af Redis anbefalede brugen af ​​stunnel til at levere TLS-understøttelse.

Memcached 1.5.13 og nyere versioner understøtter godkendelse og kryptering via TLS. Denne funktion er stadig i eksperimentelle stadier.

Godkendelse

Op til Redis 5.x understøttede Redis kun en simpel adgangskodebaseret godkendelse. Denne adgangskode blev gemt i almindelig tekst på serveren. Redis i version 6.0 og fremefter understøtter en fuldt udstyret ACL.

Memcached version 1.4.3 og nyere har SASL-understøttelse. Tidligere havde Memcached ikke noget godkendelseslag.

Oversigt

Redis og Memcached er begge fantastiske og har applikationer inden for forskellige områder. Redis, der udvikles senere, har mange avancerede funktionaliteter og har fantastisk dokumentation og fællesskab.

*Redis er et varemærke tilhørende Redis Labs Ltd. Alle rettigheder hertil er forbeholdt Redis Labs Ltd. Enhver brug af ScaleGrid er kun til referenceformål og angiver ikke nogen form for sponsorering, godkendelse eller tilknytning mellem Redis og ScaleGrid.