We gebruiken een Ruby-webapp met Redis-server voor caching. Is er een punt om in plaats daarvan Memcachedte testen?

Wat levert ons betere prestaties op? Zijn er voor- of nadelen tussen Redis en Memcached?

Aandachtspunten:

• Lees-/schrijfsnelheid.
• Geheugengebruik.
• Disk I/O-dumping.
• Schaal.

Antwoord 1, autoriteit 100%

Samenvatting (TL;DR)

Bijgewerkt op 3 juni 2017

Redis is krachtiger, populairder en beter ondersteund dan memcached. Memcached kan maar een klein deel van de dingen die Redis kan doen. Redis is beter, zelfs als hun functies elkaar overlappen.

Gebruik Redis voor alles wat nieuw is.

Memcached vs Redis: directe vergelijking

Beide tools zijn krachtige, snelle gegevensopslag in het geheugen die handig is als cache. Beide kunnen u helpen uw toepassing te versnellen door databaseresultaten, HTML-fragmenten of iets anders dat mogelijk duur is om te genereren in de cache op te slaan.

Aandachtspunten

Als ze voor hetzelfde worden gebruikt, is dit hoe ze zich verhouden met behulp van de “Aandachtspunten” van de oorspronkelijke vraag:

• Lees-/schrijfsnelheid: beide zijn extreem snel. Benchmarks variëren per workload, versies en vele andere factoren, maar over het algemeen blijkt redis net zo snel of bijna net zo snel te zijn als memcached. Ik raad redis aan, maar niet omdat memcached traag is. Dat is het niet.
• Geheugengebruik: Redis is beter.
  • memcached: je specificeert de cachegrootte en als je items invoegt, groeit de daemon snel tot iets meer dan deze grootte. Er is nooit echt een manier om die ruimte terug te winnen, behalve het herstarten van memcached. Al je sleutels kunnen verlopen zijn, je zou de database kunnen leegmaken en het zou nog steeds het volledige stuk RAM gebruiken waarmee je het hebt geconfigureerd.
  • redis: het instellen van een maximale grootte is aan jou. Redis gebruikt nooit meer dan nodig is en geeft je geheugen terug dat het niet meer gebruikt.
  • Ik heb 100.000 ~2KB strings (~200MB) willekeurige zinnen in beide opgeslagen. Het gebruik van Memcached RAM groeide tot ~ 225 MB. Redis RAM-gebruik groeide tot ~ 228 MB. Na beide te hebben doorgespoeld, zakte redis naar ~ 29 MB en bleef memcached op ~ 225 MB. Ze zijn even efficiënt in de manier waarop ze gegevens opslaan, maar er is er maar één die deze kan terugvorderen.
• Disk I/O-dumping: een duidelijke overwinning voor redis omdat het dit standaard doet en zeer configureerbare persistentie heeft. Memcached heeft geen mechanismen om naar schijf te dumpen zonder tools van derden.
• Scaling: beide geven je veel hoofdruimte voordat je meer dan één instantie als cache nodig hebt. Redis bevat tools waarmee je verder kunt gaan, terwijl memcached dat niet doet.

memcached

Memcached is een eenvoudige vluchtige cacheserver. Hiermee kunt u sleutel/waarde-paren opslaan waarvan de waarde beperkt is tot een reeks van maximaal 1 MB.

Het is hier goed in, maar dat is alles wat het doet. Je hebt toegang tot die waarden via hun sleutel met extreem hoge snelheid, vaak verzadigend beschikbare netwerk- of zelfs geheugenbandbreedte.

Als je memcached opnieuw opstart, zijn je gegevens verdwenen. Dit is prima voor een cache. Je moet daar niets belangrijks bewaren.

Als u hoge prestaties of hoge beschikbaarheid nodig heeft, zijn er tools, producten en services van derden beschikbaar.

opnieuw

Redis kan hetzelfde werk doen als memcached, en kan ze beter.

Redis kan ook dienen als cache. Het kan ook sleutel/waarde-paren opslaan. In redis kunnen ze zelfs tot 512 MB groot zijn.

Je kunt persistentie uitschakelen en het zal ook graag je gegevens verliezen bij het opnieuw opstarten. Als u wilt dat uw cache het herstarten overleeft, kunt u dat ook doen. In feite is dat de standaardinstelling.

Het is ook supersnel, vaak beperkt door netwerk- of geheugenbandbreedte.

Als één exemplaar van redis/memcached niet voldoende is voor uw werklast, is redis de duidelijke keuze. Redis bevat clusterondersteuningen wordt geleverd met tools voor hoge beschikbaarheid (redis-sentinel) rechts “in de doos”. Redis heeft zich de afgelopen jaren ook ontpopt als de duidelijke leider in tooling van derden. Bedrijven zoals Redis Labs, Amazon en anderen bieden veel handige redis-tools en -services. Het ecosysteem rond redis is veel groter. Het aantal grootschalige implementaties is nu waarschijnlijk groter dan voor memcached.

De Redis-superset

Redis is meer dan een cache. Het is een in-memory datastructuurserver. Hieronder vindt u een snel overzicht van dingen die Redis kan doen naast een eenvoudige sleutel/waarde-cache zoals memcached. De meestefuncties van redis zijn dingen die memcached niet kunnen doen.

Documentatie

Redis is beter gedocumenteerd dan memcached. Hoewel dit subjectief kan zijn, lijkt het steeds meer waar te zijn.

redis.iois een fantastische, gemakkelijk te navigeren bron. Het laat je redis proberen in de browseren geeft je zelfs live interactieve voorbeelden bij elke opdracht in de documenten.

Er zijn nu 2x zoveel stackoverflow-resultaten voor redis als memcached. 2x zoveel Google-resultaten. Gemakkelijker toegankelijke voorbeelden in meer talen. Meer actieve ontwikkeling. Actievere klantontwikkeling. Deze metingen kunnen afzonderlijk misschien niet veel betekenen, maar in combinatie geven ze een duidelijk beeld dat de ondersteuning en documentatie voor redis groter en veel actueler is.

Persistentie

Standaard bewaart redis uw gegevens op schijf met behulp van een mechanisme dat snapshotting wordt genoemd. Als je genoeg RAM beschikbaar hebt, kan het al je gegevens naar schijf schrijven met bijna geen prestatievermindering. Het is bijna gratis!

In de snapshot-modus bestaat de kans dat een plotselinge crash kan resulteren in een kleine hoeveelheid gegevensverlies. Als u er absoluut zeker van wilt zijn dat er nooit gegevens verloren gaan, hoeft u zich geen zorgen te maken, redis staat ook voor u klaar met de AOF-modus (Append Only File). In deze persistentiemodus kunnen gegevens naar de schijf worden gesynchroniseerd terwijl ze worden geschreven. Dit kan de maximale schrijfdoorvoer verminderen tot hoe snel uw schijf ook kan schrijven, maar het zou nog steeds vrij snel moeten zijn.

Er zijn veel configuratie-opties om de persistentie te verfijnen als dat nodig is, maar de standaardinstellingen zijn zeer verstandig. Deze opties maken het gemakkelijk om Redis in te stellen als een veilige, redundante plek om gegevens op te slaan. Het is een echtedatabase.

Veel gegevenstypen

Memcached is beperkt tot strings, maar Redis is een datastructuurserver die veel verschillende datatypes kan leveren. Het biedt ook de commando’s die u nodig hebt om het meeste uit deze gegevenstypen te halen.

Strings (opdrachten)

Eenvoudige tekst of binaire waarden die maximaal 512 MB groot kunnen zijn. Dit is het enige datatype voor redis en memcached share, hoewel memcached strings beperkt zijn tot 1 MB.

Redis geeft je meer tools om dit datatype te benutten door commando’s aan te bieden voor bitsgewijze bewerkingen, manipulatie op bitniveau, drijvende-komma verhogen/verlagen ondersteuning, bereikquery’s en bewerkingen met meerdere toetsen. Memcached ondersteunt dat allemaal niet.

Strings zijn handig voor allerlei gebruikssituaties, daarom is memcached redelijk handig met alleen dit gegevenstype.

Hashes (commando’s)

Hashes zijn een soort sleutelwaardearchief binnen een sleutelwaardearchief. Ze verwijzen tussen tekenreeksvelden en tekenreekswaarden. Veld->waarde-kaarten die een hash gebruiken, zijn iets meer ruimtebesparend dan sleutel->waarde-kaarten die gewone tekenreeksen gebruiken.

Hashes zijn handig als naamruimte of wanneer u veel sleutels logisch wilt groeperen. Met een hash kun je alle leden efficiënt pakken, alle leden samen laten verlopen, alle leden samen verwijderen, enz. Geweldig voor elk gebruik waarbij je verschillende sleutel/waarde-paren hebt die moeten worden gegroepeerd.

Een voorbeeld van het gebruik van een hash is voor het opslaan van gebruikersprofielen tussen applicaties. Een redis-hash die is opgeslagen met de gebruikers-ID als sleutel, stelt u in staat zoveel gegevens over een gebruiker op te slaan als nodig is, terwijl ze onder één enkele sleutel worden bewaard. Het voordeel van het gebruik van een hash in plaats van het profiel in een string te serialiseren, is dat u verschillende toepassingen verschillende velden in het gebruikersprofiel kunt laten lezen/schrijven zonder dat u zich zorgen hoeft te maken dat de ene app wijzigingen door anderen overschrijft (wat kan gebeuren als u verouderde gegevens).

Lijsten (opdrachten)

Redis-lijsten zijn geordende verzamelingen tekenreeksen. Ze zijn geoptimaliseerd voor het invoegen, lezen of verwijderen van waarden aan de boven- of onderkant (ook wel: links of rechts) van de lijst.

Redis biedt veel commando’svoor het gebruik van lijsten, inclusief commando’s om items te pushen/poppen, push/pop tussen lijsten, lijsten inkorten, bereikquery’s uitvoeren, enz.

Lijsten vormen geweldige, duurzame, atomaire wachtrijen. Deze werken uitstekend voor taakwachtrijen, logboeken, buffers en vele andere gebruiksscenario’s.

Sets (opdrachten)

Sets zijn ongeordende verzamelingen van unieke waarden. Ze zijn geoptimaliseerd zodat u snel kunt controleren of een waarde in de set zit, snel waarden kunt toevoegen/verwijderen en overlap met andere sets kunt meten.

Deze zijn geweldig voor zaken als toegangscontrolelijsten, unieke bezoekerstrackers en vele andere dingen. De meeste programmeertalen hebben iets soortgelijks (meestal een set genoemd). Dit is zo, alleen gedistribueerd.

Redis biedt verschillende opdrachtenom sets te beheren. Voor de hand liggende zoals het toevoegen, verwijderen en controleren van de set zijn aanwezig. Dat geldt ook voor minder voor de hand liggende commando’s, zoals een willekeurig item laten knallen/lezen en commando’s voor het uitvoeren van vakbonden en kruisingen met andere sets.

Gesorteerde sets (opdrachten)

Gesorteerde sets zijn ook verzamelingen van unieke waarden. Deze zijn, zoals de naam al aangeeft, geordend. Ze zijn gerangschikt op partituur en vervolgens lexicografisch.

Dit gegevenstype is geoptimaliseerd voor snelle zoekopdrachten op score. Het verkrijgen van de hoogste, laagste of een reeks waarden daartussen is extreem snel.

Als je gebruikers aan een gesorteerde set toevoegt, samen met hun hoogste score, heb je een perfect scorebord. Als er nieuwe highscores binnenkomen, voeg je ze gewoon opnieuw toe aan de set met hun highscore en het zal je leaderboard opnieuw ordenen. Ook geweldig om bij te houden wanneer gebruikers voor het laatst bezocht hebben en wie er actief is in uw applicatie.

Als u waarden met dezelfde score opslaat, worden ze lexicografisch geordend (denk alfabetisch). Dit kan handig zijn voor zaken als functies voor automatisch aanvullen.

Veel van de gesorteerde set commando’slijken op commando’s voor sets, soms met een extra scoreparameter. Ook inbegrepen zijn commando’s voor het beheren van scores en het zoeken op score.

Geo

Redis heeft verschillende commando’svoor het opslaan, ophalen en meten van geografische gegevens. Dit omvat radiusvragen en het meten van afstanden tussen punten.

Technisch geografische gegevens in redis worden opgeslagen in gesorteerde sets, dus dit is geen echt afzonderlijk gegevenstype. Het is meer een uitbreiding bovenop gesorteerde sets.

Bitmap en HyperLogLog

Net als geografisch zijn dit geen volledig gescheiden gegevenstypen. Dit zijn opdrachten waarmee u tekenreeksgegevens kunt behandelen alsof het een bitmap of een hyperloglog is.

Bitmaps zijn waar de operators op bitniveau voor zijn waarnaar ik verwees onder Strings. Dit gegevenstype was de basisbouwsteen voor het recente gezamenlijke kunstproject van reddit: r /Plaats.

HyperLogLog stelt u in staat om een constant extreem kleine hoeveelheid ruimte te gebruiken om bijna onbeperkte unieke waarden te tellen met schokkende nauwkeurigheid. Met slechts ~16 KB kunt u het aantal unieke bezoekers van uw site efficiënt tellen, zelfs als dat aantal in de miljoenen loopt.

Transacties en atoomkracht

Commando’s in redis zijn atomair, wat betekent dat u er zeker van kunt zijn dat zodra u een waarde naar redis schrijft, die waarde zichtbaar is voor alle clients die op redis zijn aangesloten. Er is geen wachttijd tot die waarde zich verspreidt. Technisch gezien is memcached ook atomair, maar met redis die al deze functionaliteit naast memcached toevoegt, is het vermeldenswaard en enigszins indrukwekkend dat al deze aanvullende gegevenstypen en functies ook atomair zijn.

Hoewel niet helemaal hetzelfde als transacties in relationele databases, heeft redis ook transactiesdie gebruikmaken van “optimistische vergrendeling ” (KIJK/MULTI/EXEC).

Pijpvoering

Redis biedt een functie genaamd ‘pipelining‘. Als je veel redis-commando’s hebt die je wilt uitvoeren, kun je pipelining gebruiken om ze allemaal tegelijk naar redis te sturen in plaats van één voor één.

Normaal gesproken is elke opdracht een afzonderlijke verzoek-/antwoordcyclus wanneer u een opdracht uitvoert naar redis of memcached. Met pipelining kan redis verschillende commando’s bufferen en ze allemaal tegelijk uitvoeren, waarbij alle reacties op al je commando’s in één antwoord worden beantwoord.

Hierdoor kunt u een nog grotere doorvoer bereiken bij bulkimport of andere acties waarbij veel opdrachten nodig zijn.

Pub/Sub

Redis heeft opdrachtengewijd aan pub/sub-functionaliteit, waardoor redis kan fungeren als een snelle berichtenzender. Hierdoor kan een enkele klant berichten publiceren naar vele andere klanten die op een kanaal zijn aangesloten.

Redis doet pub/sub en bijna elke tool. Toegewijde berichtenmakelaars zoals RabbitMQkunnen op bepaalde gebieden voordelen hebben, maar het feit dat dezelfde server u ook aanhoudende duurzame wachtrijen en andere gegevensstructuren die uw pub/sub-workloads waarschijnlijk nodig hebben, zal Redis vaak de beste en meest eenvoudige tool voor de klus blijken te zijn.

Lua-scripts

Je kunt denken aan lua-scriptszoals redis’ eigen SQL of opgeslagen procedures. Het is zowel meer als minder dan dat, maar de analogie werkt meestal.

Misschien heeft u complexe berekeningen die u opnieuw wilt laten uitvoeren. Misschien kunt u het zich niet veroorloven om uw transacties terug te draaien en heeft u garanties nodig dat elke stap van een complex proces atomair zal plaatsvinden. Deze problemen en nog veel meer kunnen worden opgelost met lua-scripting.

Het hele script wordt atomair uitgevoerd, dus als je je logica in een lua-script kunt passen, kun je vaak voorkomen dat je knoeit met optimistische vergrendelingstransacties.

Schaal

Zoals hierboven vermeld, bevat redis ingebouwde ondersteuning voor clustering en wordt het gebundeld met zijn eigen tool voor hoge beschikbaarheid genaamd redis-sentinel.

Conclusie

Zonder aarzeling zou ik aanraden om opnieuw te gebruiken via memcached voor nieuwe projecten, of bestaande projecten die nog geen gebruik maken van memcached.

Het bovenstaande klinkt misschien alsof ik niet van memcached houd. Integendeel: het is een krachtig, eenvoudig, stabiel, volwassen en gehard stuk gereedschap. Er zijn zelfs gevallen waarin het iets sneller is dan redis. Ik hou van memcaches. Ik denk gewoon niet dat het veel zin heeft voor toekomstige ontwikkeling.

Redis doet alles wat memcached doet, vaak beter. Elk prestatievoordeel voor memcached is klein en specifiek voor de werkbelasting. Er zijn ook workloads waarvoor redis sneller zal zijn, en veel meer workloads die redis kan doen en die memcached gewoon niet kunnen. De kleine prestatieverschillen lijken klein in het licht van de gigantische kloof in functionaliteit en het feit dat beide tools zo snel en efficiënt zijn dat ze wel eens het laatste onderdeel van je infrastructuur kunnen zijn waar je je ooit zorgen over hoeft te maken.

Er is maar één scenario waarin memcached logischer is: waar memcached al in gebruik is als cache. Als je al aan het cachen bent met memcached, blijf het dan gebruiken als het aan je behoeften voldoet. Het is waarschijnlijk niet de moeite waard om over te stappen naar redis en als je redis alleen voor caching gaat gebruiken, biedt het misschien niet genoeg voordeel om je tijd waard te zijn. Als memcached niet aan uw behoeften voldoet, moet u waarschijnlijk naar redis gaan. Dit is waar, of je nu verder wilt schalen dan memcached of dat je extra functionaliteit nodig hebt.

Antwoord 2, autoriteit 7%

Gebruik Redis als

1. Je moet selectief items in de cache verwijderen/verlopen. (Dit heb je nodig)

2. Je hebt de mogelijkheid nodig om sleutels van een bepaald type op te vragen. vgl. ‘blog1:posts:*’, ‘blog2:categories:xyz:posts:*’. O ja! dit is erg belangrijk. Gebruik dit om bepaalde typen items in de cache selectief ongeldig te maken. U kunt dit ook gebruiken om fragmentcache, paginacache, alleen AR-objecten van een bepaald type, enz. ongeldig te maken.

3. Persistentie (dit heb je ook nodig, tenzij je het goed vindt dat je cache na elke herstart moet opwarmen. Zeer essentieel voor objecten die zelden veranderen)

Gebruik geheugencache als

1. Memcached bezorgt je hoofdpijn!
2. umm… clusteren? eh. als je zo ver wilt gaan, gebruik dan Varnish en Redis voor het cachen van fragmenten en AR-objecten.

Uit mijn ervaring heb ik veel betere stabiliteit gehad met Redis dan Memcached

Antwoord 3, autoriteit 5%

Memcached is multithreaded en snel.

Redis heeft veel functies en is erg snel, maar volledig beperkt tot één kern omdat het is gebaseerd op een gebeurtenislus.

We gebruiken beide. Memcached wordt gebruikt voor het cachen van objecten, voornamelijk om de leesbelasting van de databases te verminderen. Redis wordt gebruikt voor zaken als gesorteerde sets die handig zijn voor het oprollen van tijdreeksgegevens.

Antwoord 4, autoriteit 4%

Dit is te lang om als commentaar op een reeds geaccepteerd antwoord te worden geplaatst, dus ik heb het als een apart antwoord geplaatst

Een ding dat u ook moet overwegen, is of u een harde bovengeheugenlimiet voor uw cache-instantie verwacht.

Aangezien redis een nosql-database is met tal van functies en caching slechts één optie is waarvoor het kan worden gebruikt, wijst het geheugen toe zoals het dat nodig heeft —  hoe meer objecten je erin plaatst, hoe meer geheugen het gebruikt. De optie maxmemoryhandhaaft het gebruik van de bovenste geheugenlimiet niet strikt. Terwijl u met cache werkt, worden sleutels verwijderd en verlopen; de kans is groot dat uw sleutels niet allemaal even groot zijn, waardoor er interne geheugenfragmentatie optreedt.

Standaard gebruikt redis jemallocgeheugentoewijzer, die zijn best doet om zowel geheugencompact als snel, maar het is een geheugentoewijzer voor algemene doeleinden en het kan de vele toewijzingen en het opschonen van objecten met een hoge snelheid niet bijhouden. Hierdoor kan bij sommige laadpatronen het redis-proces blijkbaar geheugen lekken vanwege interne fragmentatie. Als u bijvoorbeeld een server heeft met 7 Gb RAM en u redis wilt gebruiken als niet-permanente LRU-cache, zult u merken dat het redis-proces met maxmemoryingesteld op 5Gb in de loop van de tijd steeds meer zou gaan gebruiken geheugen, waarbij uiteindelijk de totale RAM-limiet wordt bereikt totdat de moordenaar zonder geheugen ingrijpt.

Memcached past beter bij het hierboven beschreven scenario, omdat het zijn geheugen op een heel andere manier beheert. memcached wijst één groot deel van het geheugen toe – alles wat het ooit nodig zal hebben – en beheert dit geheugen vervolgens zelf, met behulp van zijn eigen geïmplementeerde plaattoewijzer. Bovendien doet memcached er alles aan om de interne fragmentatie laag te houden, aangezien het feitelijk per-slab gebruikt LRU-algoritme, wanneer LRU-uitzettingen worden uitgevoerd met inachtneming van de objectgrootte.

Dat gezegd hebbende, heeft memcached nog steeds een sterke positie in omgevingen, waar geheugengebruik moet worden afgedwongen en/of voorspelbaar moet zijn. We hebben geprobeerd de nieuwste stabiele redis (2.8.19) te gebruiken als een drop-in, niet-permanente, op LRU gebaseerde memcached-vervanging met een werklast van 10-15k op/s, en het lekte VEEL geheugen; dezelfde werklast crashte om dezelfde redenen de ElastiCache-redisinstanties van Amazon in een dag of zo.

Antwoord 5, autoriteit 2%

Memcached is goed in het zijn van een eenvoudige sleutel/waarde-opslag en is goed in het uitvoeren van key => SNAAR. Dit maakt het echt goed voor sessieopslag.

Redis is goed in key => SOME_OBJECT.

Het hangt er echt van af wat je erin gaat doen. Ik heb begrepen dat ze qua prestaties redelijk gelijk zijn.

Veel succes met het vinden van objectieve benchmarks, als je er een vindt, stuur ze dan zo vriendelijk naar mij.

Antwoord 6, autoriteit 2%

Als je een grove schrijfstijl niet erg vindt, Redis vs Memcachedop de Systoilet-blog is het lezen waard vanuit het oogpunt van bruikbaarheid, maar lees zeker de achterkant & vermeld in de opmerkingen voordat conclusies worden getrokken over de prestaties; er zijn enkele methodologische problemen (single-threaded busy-loop-tests), en Redis heeft ook enkele verbeteringen aangebracht sinds het artikel werd geschreven.

En geen enkele benchmarklink is compleet zonder de zaken een beetje te verwarren, dus bekijk ook enkele tegenstrijdige benchmarks op Dormondo’s LiveJournal en de Antirez Weblog.

Bewerken— zoals Antirez aangeeft, is de Systoilet-analyse nogal ondoordacht. Zelfs buiten het single-threading-tekort, kan een groot deel van de prestatieverschillen in die benchmarks worden toegeschreven aan de clientbibliotheken in plaats van aan de serverdoorvoer. De benchmarks op de Antirez Webloglaten inderdaad een veel meer appels-tot-appels (met dezelfde mond) vergelijking.

Antwoord 7

Ik kreeg de kans om zowel memcached als redis samen te gebruiken in de caching-proxy waaraan ik heb gewerkt, laat me je vertellen waar ik precies wat en de reden achter hetzelfde heb gebruikt….

Redis >

1) Gebruikt voor het indexeren van de cache-inhoud , over het cluster . Ik heb meer dan een miljard sleutels verspreid over redis-clusters, de responstijden van redis zijn veel minder en stabiel.

2) In principe is het een sleutel/waarde-archief, dus waar je ook in je applicatie iets soortgelijks hebt, je kunt redis gebruiken met veel moeite.

3) Redis-persistentie, failover en back-up (AOF) maken uw werk gemakkelijker.

Geheugencache >

1) ja , een geoptimaliseerd geheugen dat als cache kan worden gebruikt. Ik heb het gebruikt voor het opslaan van cache-inhoud die zeer vaak wordt geopend (met 50 treffers/seconde) met een grootte van minder dan 1 MB.

2) Ik heb slechts 2 GB van de 16 GB toegewezen aan memcached dat ook toen mijn enkele inhoudsgrootte >1 MB was.

3) Naarmate de inhoud tegen de limieten aangroeit, heb ik af en toe hogere responstijden waargenomen in de statistieken (niet het geval bij redis).

Als u om algemene ervaring vraagt, is Redis veel groen omdat het eenvoudig te configureren is, veel flexibeler met stabiele robuuste functies.

Verder is er een benchmarkresultaat beschikbaar op deze link, hieronder zijn enkele hoogtepunten van hetzelfde,

Hopelijk helpt dit!!

Antwoord 8

Test. Voer enkele eenvoudige benchmarks uit. Lange tijd beschouwde ik mezelf als een ouderwetse neushoorn, aangezien ik voornamelijk memcached gebruikte en Redis als het nieuwe kind beschouwde.

Bij mijn huidige bedrijf werd Redis gebruikt als de hoofdcache. Toen ik me verdiepte in prestatiestatistieken en gewoon begon te testen, was Redis qua prestaties vergelijkbaar of minimaal langzamerdan MySQL.

Memcached, hoewel simplistisch, blies Redis totaaluit het water. Het schaalde veel beter:

• voor grotere waarden (vereist verandering in plaatgrootte, maar werkte)
• voor meerdere gelijktijdige verzoeken

Bovendien is het memcached-uitzettingsbeleid naar mijn mening veel beter geïmplementeerd, wat resulteert in een over het algemeen stabielere gemiddelde responstijd terwijl er meer gegevens worden verwerkt dan de cache aankan.

Enkele benchmarking wees uit dat Redis in ons geval erg slecht presteert. Dit heeft volgens mij met veel variabelen te maken:

• type hardware waarop u Redis uitvoert
• soorten gegevens die u opslaat
• aantal ophaalacties en sets
• hoe gelijktijdig uw app is
• heb je datastructuuropslag nodig

Persoonlijk deel ik niet de mening van Redis-auteurs over gelijktijdigheid en multithreading.

Antwoord 9

Een andere bonus is dat het heel duidelijk kan zijn hoe memcache zich zal gedragen in een caching-scenario, terwijl redis over het algemeen wordt gebruikt als een permanente datastore, hoewel het kan worden geconfigureerd om zich net als memcached te gedragen, oftewel het verwijderen van minst recent gebruikte items wanneer het bereikt de maximale capaciteit.

Sommige apps waaraan ik heb gewerkt, gebruiken beide om duidelijk te maken hoe we van plan zijn de gegevens zich te gedragen – dingen in memcache, we schrijven code om de gevallen af te handelen waar het er niet is – dingen in redis, we vertrouwen op het is er.

Anders dan dat wordt Redis over het algemeen als superieur beschouwd, omdat het in de meeste gevallen rijker en dus flexibeler is.

Antwoord 10

Het zou niet verkeerd zijn als we zeggen dat redis een combinatie is van (cache + datastructuur) terwijl memcached slechts een cache is.

Antwoord 11

Een zeer eenvoudige test om 100k unieke sleutels en waarden in te stellen en te verkrijgen tegen redis-2.2.2 en memcached. Beide draaien op linux VM (CentOS) en mijn clientcode (hieronder geplakt) draait op Windows Desktop.

Opnieuw

• De tijd die nodig is om 100.000 waarden op te slaan is = 18954 ms

• De tijd die nodig is om 100000 waarden te laden is = 18328 ms

Memcached

• De tijd die nodig is om 100.000 waarden op te slaan is = 797 ms

• De tijd die nodig is om 100000 waarden op te halen is = 38984 ms

Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");
startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");

Antwoord 12

Een groot verschil dat hier niet is aangegeven, is dat Memcache te allen tijde een bovenlimiet heeft voor het geheugen, terwijl Redis dit niet standaard heeft (maar wel zo kan worden geconfigureerd). Als u een sleutel/waarde altijd voor een bepaalde tijd wilt opslaan (en deze nooit wilt verwijderen vanwege weinig geheugen), wilt u Redis gebruiken. Natuurlijk riskeer je ook het probleem van onvoldoende geheugen…

Antwoord 13

Memcached zal sneller zijn als u geïnteresseerd bent in prestaties, zelfs omdat Redis netwerken (TCP-oproepen) omvat. Ook intern is Memcache sneller.

Redis heeft meer functies zoals vermeld in andere antwoorden.

Antwoord 14

De grootste resterende reden is specialisatie.

Redis kan veel verschillende dingen doen en een neveneffect daarvan is dat ontwikkelaars veel van die verschillende functiesets op dezelfde instantie kunnen gaan gebruiken. Als je de LRU-functie van Redis gebruikt voor een cache naast harde gegevensopslag die GEEN LRU is, is het heel goed mogelijk dat het geheugen vol raakt.

Als je een speciale Redis-instantie gaat instellen die ALLEEN als een LRU-instantie wordt gebruikt om dat specifieke scenario te vermijden, dan is er niet echt een dwingende reden om Redis via Memcached te gebruiken.

Als je een betrouwbare “never goes down” LRU-cache nodig hebt… Memcached zal hiervoor geschikt zijn, aangezien het onmogelijk is om door het ontwerp te weinig geheugen te hebben en de gespecialiseerde functionaliteit voorkomt dat ontwikkelaars proberen om het zo te maken dat het zou kunnen dat in gevaar brengen. Eenvoudige scheiding van zorgen.

Antwoord 15

We zagen Redis als een startpunt voor ons project op het werk. We dachten dat door het gebruik van een module in nginxgenaamd HttpRedis2Moduleof iets dergelijks we een geweldige snelheid zouden hebben, maar bij het testen met AB-test hebben we het tegendeel bewezen.

Misschien was de module slecht of onze lay-out, maar het was een heel eenvoudige taak en het was zelfs nog sneller om gegevens met php te nemen en deze vervolgens in MongoDB te proppen. We gebruiken APC als caching-systeem en daarbij php en MongoDB. Het was veel sneller dan de nginxRedis-module.

Mijn tip is om het zelf te testen, als je het doet, krijg je de resultaten voor je omgeving te zien. We besloten dat het gebruik van Redis niet nodig was in ons project, omdat het geen zin zou hebben.

Antwoord 16

Redis is beter.

De voordelen van Rediszijn ,

1. Het heeft veel opties voor gegevensopslag, zoals string, sets, gesorteerde sets, hashes, bitmaps
2. Schijfpersistentie van records
3. Opgeslagen procedure (LUAscripting) ondersteuning
4. Kan optreden als berichtenmakelaar met PUB/SUB

Terwijl Memcacheeen in-memory systeem is van het sleutelwaardecachetype.

1. Geen ondersteuning voor opslag van verschillende gegevenstypen zoals lijsten, sets als in
   opnieuw.
2. Het belangrijkste nadeel is dat Memcache geen schijfpersistentie heeft.

Antwoord 17

Hieris het echt geweldige artikel/de verschillen van Amazon

Redis is een duidelijke winnaar in vergelijking met memcached.

Slechts één pluspunt voor Memcached
Het is multithreaded en snel. Redis heeft veel geweldige functies en is erg snel, maar beperkt tot één kern.

Geweldige punten over Redis, die niet worden ondersteund in Memcached

• Momentopnamen – Gebruiker kan een momentopname maken van de Redis-cache en blijven bestaan
  secundaire opslag op elk moment.
• Ingebouwde ondersteuning voor veel datastructuren zoals Set, Map, SortedSet,
  Lijst, BitMaps enz.
• Ondersteuning voor Lua-scripting in redis