it-swarm.com.de

Wann ist Redis? Wann zu MongoDB?

Was ich will, ist kein Vergleich zwischen Redis und MongoDB. Ich weiß, dass sie unterschiedlich sind; Die Leistung und die API ist völlig anders.

Redis ist sehr schnell, aber die API ist sehr "atomar". MongoDB wird mehr Ressourcen verbrauchen, aber die API ist sehr einfach zu bedienen und ich bin sehr zufrieden damit.

Sie sind beide fantastisch, und ich möchte Redis so oft wie möglich für die Bereitstellung verwenden, aber es ist schwer zu programmieren. Ich möchte MongoDB so oft wie möglich in der Entwicklung einsetzen, aber dafür ist eine teure Maschine erforderlich.

Also, was denkst du über die Verwendung von beiden? Wann sollte man Redis wählen? Wann wähle ich MongoDB?

466
guilin 桂林

Ich würde sagen, es hängt von der Art Ihres Entwicklerteams und Ihren Anwendungsanforderungen ab.

Wenn Sie beispielsweise viele Abfragen benötigen, bedeutet dies meistens, dass Ihre Entwickler mehr Arbeit mit Redis haben, wo Ihre Daten möglicherweise gespeichert werden in verschiedenen spezialisierten Datenstrukturen, die für jede Art von Objekt auf Effizienz zugeschnitten sind. In MongoDB sind dieselben Abfragen möglicherweise einfacher, da die Struktur Ihrer Daten konsistenter ist. Auf der anderen Seite ist in Redis die bloße Geschwindigkeit der Beantwortung dieser Fragen die Auszahlung für die zusätzliche Arbeit beim Umgang mit der Vielfalt der Strukturen Ihrer Daten könnte mit gespeichert werden.

MongoDB bietet Entwicklern mit herkömmlicher DB- und SQL-Erfahrung eine einfache und viel kürzere Lernkurve. Der nicht-traditionelle Ansatz von Redis erfordert jedoch mehr Lernaufwand, aber mehr Flexibilität.

Z.B. Eine Cache Schicht kann wahrscheinlich besser in Redis implementiert werden. Für mehr schematisierbare Daten ist MongoDB besser. [Hinweis: Sowohl MongoDB als auch Redis sind technisch nicht schematisiert]

Wenn Sie mich fragen, ist Redis meine persönliche Wahl für die meisten Anforderungen.

Zum Schluss hoffe ich, dass Sie http://antirez.com/post/MongoDB-and-Redis.html gesehen haben

308
Shekhar

Mir ist gerade aufgefallen, dass diese Frage ziemlich alt ist. Dennoch halte ich die folgenden Aspekte für erwähnenswert:

  • Verwenden Sie MongoDB, wenn Sie noch nicht wissen, wie Sie Ihre Daten abfragen werden.

    MongoDB eignet sich für Hackathons, Startups oder jedes Mal, wenn Sie nicht wissen, wie Sie die von Ihnen eingegebenen Daten abfragen. MongoDB nimmt keine Annahmen zu Ihrem zugrunde liegenden Schema vor. MongoDB ist zwar schemenlos und nicht relational, dies bedeutet jedoch nicht, dass es überhaupt kein Schema gibt. Dies bedeutet lediglich, dass Ihr Schema in Ihrer App definiert werden muss (z. B. mithilfe von Mongoose). Außerdem eignet sich MongoDB hervorragend zum Prototypen oder Ausprobieren. Seine Leistung ist nicht so gut und kann nicht mit Redis verglichen werden.

  • Verwenden Sie Redis, um Ihre vorhandene Anwendung zu beschleunigen.

    Redis kann einfach als LRU-Cache eingebunden werden. Es ist sehr ungewöhnlich, Redis als eigenständiges Datenbanksystem zu verwenden (manche Leute ziehen es vor, es als "Schlüsselwert" -Speicher zu bezeichnen). Websites wie Craigslist verwenden Redis neben ihrer Primärdatenbank . Antirez (Entwickler von Redis) demonstrierte mit Lamernews, dass es tatsächlich möglich ist, Redis als eigenständiges Datenbanksystem zu verwenden.

  • Redis trifft keine Annahmen, die auf Ihren Daten beruhen.

    Redis bietet eine Reihe nützlicher Datenstrukturen (z. B. Mengen, Hashes, Listen), aber Sie müssen explizit definieren, wie Sie Ihre Daten speichern möchten. Kurz gesagt, Redis und MongoDB können verwendet werden, um ähnliche Ziele zu erreichen. Redis ist einfach schneller, aber nicht für das Prototyping geeignet. Dies ist ein Anwendungsfall, bei dem Sie normalerweise MongoDB bevorzugen. Außerdem ist Redis wirklich flexibel. Die zugrunde liegenden Datenstrukturen sind die Bausteine ​​für leistungsfähige DB-Systeme.

Wann ist Redis anzuwenden?

  • Caching

    Zwischenspeichern mit MongoDB macht einfach keinen Sinn. Es wäre zu langsam.

  • Wenn Sie genug Zeit haben, um über Ihr DB-Design nachzudenken.

    Sie können Ihre Dokumente nicht einfach in Redis einwerfen. Sie müssen überlegen, wie Sie Ihre Daten speichern und organisieren möchten. Ein Beispiel sind Hashes in Redis. Sie unterscheiden sich stark von "traditionellen", verschachtelten Objekten, was bedeutet, dass Sie die Art und Weise, wie Sie verschachtelte Dokumente speichern, überdenken müssen. Eine Lösung wäre, eine Referenz im Hash zu einem anderen Hash zu speichern (so etwas wie key: [id of second hash] ). Eine andere Idee wäre, es als JSON zu speichern, was für die meisten Leute mit einem * SQL-Hintergrund nicht intuitiv zu sein scheint.

  • Wenn Sie wirklich hohe Leistung benötigen.

    Die Leistung von Redis zu übertreffen ist nahezu unmöglich. Stellen Sie sich vor, Ihre Datenbank ist so schnell wie Ihr Cache. So fühlt es sich an, wenn Redis als echte Datenbank verwendet wird.

  • Wenn es Ihnen nicht so wichtig ist , wie Sie skalieren.

    Die Skalierung von Redis ist nicht mehr so ​​schwierig wie früher. Beispielsweise könnten Sie eine Art Proxy-Server verwenden, um die Daten auf mehrere Redis-Instanzen zu verteilen. Die Master-Slave-Replikation ist nicht kompliziert , aber die Verteilung der Schlüssel auf mehrere Redis-Instanzen muss auf der Anwendungsseite erfolgen (z. B. mit einer Hash-Funktion, Modulo usw.). . Das Skalieren von MongoDB im Vergleich ist viel einfacher.

Wann ist MongoDB anzuwenden?

  • Prototyping, Startups, Hackathons

    MongoDB eignet sich perfekt für Rapid Prototyping. Trotzdem ist die Leistung nicht so gut. Denken Sie auch daran, dass Sie höchstwahrscheinlich eine Art Schema in Ihrer Anwendung definieren müssen.

  • Wenn Sie Ihr Schema schnell ändern müssen.

    Weil es kein Schema gibt! Das Ändern von Tabellen in traditionellem relationalem DBMS ist schmerzhaft teuer und langsam. MongoDB löst dieses Problem, indem es nicht viele Annahmen zu Ihren zugrunde liegenden Daten macht. Es wird jedoch versucht, so weit wie möglich zu optimieren, ohne dass Sie ein Schema definieren müssen.

TL; DR - Verwenden Sie Redis, wenn die Leistung wichtig ist und Sie bereit sind, Ihre Daten zu optimieren und zu organisieren. - Verwenden Sie MongoDB, wenn Sie einen Prototyp erstellen müssen, ohne sich über Ihre Datenbank Gedanken machen zu müssen.

Weitere Lektüre:

236
Alexander Gugel

Redis. Nehmen wir an, Sie haben eine Website in PHP geschrieben. aus welchem ​​Grund auch immer, es wird populär und es ist seiner Zeit voraus oder hat Pornos drauf. Du erkennst, dass diese PHP-Version so langsam ist. "Ich werde meine Fans verlieren, weil sie einfach nicht 10 Sekunden auf eine Seite warten." Sie haben plötzlich die Erkenntnis, dass eine Webseite eine konstante URL hat (sie ändert sich nie, whoa), einen Primärschlüssel, wenn Sie so wollen, und dann erinnern Sie sich, dass der Speicher schnell ist, während die Festplatte langsam und PHP noch langsamer. :( Dann erstellen Sie einen Speichermechanismus unter Verwendung des Speichers und dieser URL, die Sie als "Schlüssel" bezeichnen, während der Inhalt der Webseite den "Wert" bezeichnet. Das ist alles, was Sie haben - Schlüssel und Inhalt. Sie nennen es "Meme-Cache". Du magst Richard Dawkins, weil er großartig ist. Du zwischenspeicherst dein HTML wie Eichhörnchen ihre Nüsse. Du musst deinen Mist-PHP-Code nicht umschreiben. Du bist glücklich. Dann siehst du, dass andere es getan haben - aber du wählst Redis, weil das andere haben verwirrende Bilder von Katzen, einige mit Reißzähnen.

Mongo. Sie haben eine Website geschrieben. Verdammt, Sie haben viele und in jeder Sprache geschrieben. Sie erkennen, dass ein Großteil Ihrer Zeit damit verbracht wird, diese stinkenden SQL-Klauseln zu schreiben. Du bist kein dba, und doch schreibst du dumme SQL-Anweisungen ... nicht nur eine, sondern flippig überall. msgstr "wähle dies aus, wähle das aus". Vor allem aber erinnern Sie sich an die irritierende WHERE-Klausel. Wo Nachname gleich "Thornton" und Film gleich "Bad Santa". Urgh. Sie denken: "Warum erledigen diese dbas nicht einfach ihre Arbeit und geben mir gespeicherte Prozeduren?" Dann vergisst du ein kleines Feld wie den Zwischennamen und dann musst du die Tabelle löschen, alle 10 GB großen Datenmengen exportieren und ein neues mit diesem neuen Feld erstellen und die Daten importieren - und das zehnmal in den nächsten 14 Tagen Denken Sie immer daran, wie Anrede, Titel und Hinzufügen eines Fremdschlüssels mit Adressen. Dann stellen Sie sich vor, dass Nachname Nachname sein sollte. Fast ein Wechsel pro Tag. Dann sagst du verdammt. Ich muss einsteigen und eine Website/ein System schreiben, egal welches Datenmodell. Sie googeln also: "Ich hasse es, SQL zu schreiben, bitte kein SQL, lass es aufhören", aber dann erscheint 'nosql' und Sie lesen ein paar Sachen und es heißt, es gibt nur Daten ohne Schema aus. Sie erinnern sich an das Fiasko der letzten Woche, als Sie mehr Tische fallen ließen und lächelten. Dann entscheiden Sie sich für Mongo, weil es einige große Leute wie "Airbud" gibt, die es von der entsprechenden Vermietungsseite verwenden. Süss. Keine Datenmodelländerungen mehr, da Sie ein Modell haben, das Sie ständig ändern.

223
Gabe Rainbow

Vielleicht hilft diese Ressource bei der Entscheidung zwischen beiden. Es werden auch einige andere NoSQL-Datenbanken besprochen und eine kurze Liste von Merkmalen zusammen mit einer "Wofür ich sie verwenden würde" Erklärung für jedes von ihnen angeboten .

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

16
stackex

Schwierig zu beantwortende Frage - wie bei den meisten Technologielösungen hängt es wirklich von Ihrer Situation ab, und da Sie das zu lösende Problem nicht beschrieben haben, wie kann jemand eine Lösung vorschlagen?

Sie müssen beide testen, um zu sehen, welche von ihnen zufrieden sind Ihre Bedürfnisse.

Trotzdem benötigt MongoDB keine teure Hardware. Wie jede andere Datenbanklösung funktioniert es besser mit mehr CPU und Arbeitsspeicher, ist jedoch sicherlich keine Voraussetzung - insbesondere für frühe Entwicklungszwecke.

11

Alle Antworten (zum Zeitpunkt des Schreibens) setzen voraus, dass Redis, MongoDB und möglicherweise eine SQL-basierte relationale Datenbank im Wesentlichen dasselbe Tool sind: "Daten speichern". Sie berücksichtigen überhaupt keine Datenmodelle.

MongoDB: Komplexe Daten

MongoDB ist ein Dokumentenspeicher. Vergleich mit einer SQL-gesteuerten relationalen Datenbank: Relationale Datenbanken vereinfachen die Indizierung von CSV-Dateien, wobei jede Datei eine Tabelle ist. Dokumentenspeicher vereinfachen die Indizierung von JSON-Dateien, wobei jede Datei ein Dokument ist und mehrere Dateien in Gruppen zusammengefasst sind.

JSON-Dateien haben eine ähnliche Struktur wie XML- und YAML-Dateien und Wörterbücher wie in Python. Denken Sie also an Ihre Daten in dieser Art von Hierarchie. Bei der Indizierung ist die Struktur der Schlüssel: Ein Dokument enthält benannte Schlüssel, die entweder weitere Dokumente, Arrays oder skalare Werte enthalten. Betrachten Sie das folgende Dokument.

{
  _id:  0x194f38dc491a,
  Name:  "John Smith",
  PhoneNumber:
    Home: "555 999-1234",
    Work: "555 999-9876",
    Mobile: "555 634-5789"
  Accounts:
    - "379-1111"
    - "379-2574"
    - "414-6731"
}

Das obige Dokument hat einen Schlüssel, PhoneNumber.Mobile, der den Wert 555 634-5789 hat. Sie können eine Sammlung von Dokumenten durchsuchen, bei denen der Schlüssel PhoneNumber.Mobile einen bestimmten Wert hat. Sie sind indiziert.

Es hat auch ein Array von Accounts, das mehrere Indizes enthält. Es ist möglich, ein Dokument abzufragen, bei dem Accountsgena eine Teilmenge von Werten, alle eine Teilmenge von Werten oder beliebige enthält = einer Teilmenge von Werten. Das heißt, Sie können nach Accounts = ["379-1111", "379-2574"] suchen und das oben Gesagte nicht finden. Sie können nach Accounts includes ["379-1111"] suchen und das obige Dokument finden. und Sie können nach Accounts includes any of ["974-3785","414-6731"] suchen und das obige und das Dokument mit dem Konto "974-3785" (falls vorhanden) finden.

Dokumente gehen so tief, wie Sie wollen. PhoneNumber.Mobile könnte ein Array oder sogar ein Unterdokument enthalten (PhoneNumber.Mobile.Work und PhoneNumber.Mobile.Personal). Wenn Ihre Daten stark strukturiert sind, sind Dokumente ein großer Schritt von relationalen Datenbanken entfernt.

Wenn Ihre Daten größtenteils flach, relational und starr strukturiert sind, ist eine relationale Datenbank die bessere Wahl. Auch hier ist das große Zeichen, ob sich Ihre Datenmodelle am besten für eine Sammlung zusammenhängender CSV-Dateien oder eine Sammlung von XML/JSON/YAML-Dateien eignen.

Bei den meisten Projekten müssen Sie Kompromisse eingehen und in einigen kleinen Bereichen, in denen SQL- oder Dokumentenspeicher nicht passen, eine geringfügige Umgehung akzeptieren. Bei einigen großen, komplexen Projekten, in denen eine große Datenbreite gespeichert ist (viele Spalten, Zeilen sind irrelevant), ist es sinnvoll, einige Daten in einem Modell und andere Daten in einem anderen Modell zu speichern. Facebook verwendet sowohl SQL als auch eine Grafikdatenbank (wobei Daten in Knoten abgelegt werden und Knoten mit anderen Knoten verbunden sind). Craigslist benutzte früher MySQL und MongoDB, hatte jedoch die vollständige Umstellung auf MongoDB in Erwägung gezogen. Dies sind Orte, an denen die Spanne und Beziehung der Daten erhebliche Nachteile aufweist, wenn sie unter einem Modell zusammengefasst werden.

Redis: Schlüsselwert

Redis ist im Grunde genommen ein Geschäft mit Schlüsselwerten. Mit Redis können Sie ihm einen Schlüssel geben und einen einzelnen Wert nachschlagen. Redis selbst kann Zeichenfolgen, Listen, Hashes und einige andere Dinge speichern. Es wird jedoch nur mit dem Namen nachgeschlagen.

Die Ungültigmachung des Cache ist eines der größten Probleme der Informatik. der andere nennt Dinge. Das bedeutet, dass Sie Redis verwenden, wenn Sie Hunderte von übermäßigen Suchvorgängen für ein Back-End vermeiden möchten. Sie müssen jedoch herausfinden, wann Sie einen neuen Suchvorgang benötigen.

Der offensichtlichste Fall einer Ungültigerklärung ist die Aktualisierung beim Schreiben: Wenn Sie user:Simon:lingots = NOTFOUND lesen, können Sie SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon und das Ergebnis 100 als SET user:Simon:lingots = 100 speichern. Wenn Sie dann Simon 5 Lingots verleihen, lesen Sie user:Simon:lingots = 100, SET user:Simon:lingots = 105 und UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon. Jetzt haben Sie 105 in Ihrer Datenbank und in Redis und können user:Simon:lingots abrufen, ohne die Datenbank abzufragen.

Der zweite Fall aktualisiert abhängige Informationen. Angenommen, Sie generieren Seitenabschnitte und speichern deren Ausgabe im Cache. Der Header zeigt die Erfahrung, das Level und den Geldbetrag des Spielers an. Die Profilseite des Spielers enthält einen Block, in dem die Statistiken angezeigt werden. und so weiter. Der Spieler gewinnt etwas Erfahrung. Nun haben Sie mehrere templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simon und so weiter Felder, in denen Sie die Ausgabe von einem halben Dutzend Datenbankabfragen zwischengespeichert haben, die über eine Vorlagen-Engine ausgeführt werden. Normalerweise sagen Sie beim Anzeigen dieser Seiten:

$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
  $t = BuildTemplate("StatsBox.tmpl",
                     GetStatsFromDatabase($playerName));
  SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;

Da Sie gerade die Ergebnisse von GetStatsFromDatabase("Simon") aktualisiert haben, müssen Sie templates:*:Simon aus Ihrem Schlüsselwert-Cache löschen. Wenn Sie versuchen, eine dieser Vorlagen zu rendern, werden in Ihrer Anwendung keine Daten aus Ihrer Datenbank (PostgreSQL, MongoDB) abgerufen und in Ihre Vorlage eingefügt. Dann wird das Ergebnis in Redis gespeichert und es wird hoffentlich nicht die Mühe gemacht, Datenbankabfragen und Rendervorlagen beim nächsten Anzeigen dieses Ausgabeblocks durchzuführen.

Mit Redis können Sie auch Nachrichtenwarteschlangen für Herausgeber und Abonnenten erstellen. Das ist ein ganz anderes Thema. Hier ist zu erwähnen, dass Redis ein Schlüsselwert-Cache ist, der sich von einer relationalen Datenbank oder einem Dokumentenspeicher unterscheidet.

Fazit

Wählen Sie Ihre Werkzeuge nach Ihren Bedürfnissen aus. Der größte Bedarf besteht normalerweise im Datenmodell, da dieses bestimmt, wie komplex und fehleranfällig Ihr Code ist. Spezialisierte Anwendungen basieren auf der Leistung, also auf Stellen, an denen Sie alles in einer Mischung aus C und Assembly schreiben. Die meisten Anwendungen behandeln nur den allgemeinen Fall und verwenden ein Caching-System wie Redis oder Memcached, das viel schneller ist als eine Hochleistungs-SQL-Datenbank oder ein Dokumentenspeicher.

10
John Moser

Redis ist ein im Speicher Datenspeicher, der seinen Status auf der Festplatte beibehalten kann (um die Wiederherstellung nach dem Neustart zu ermöglichen). Da es sich jedoch um einen speicherinternen Datenspeicher handelt, darf die Größe des Datenspeichers (auf einem einzelnen Knoten) den gesamten Speicherplatz auf dem System (physischer RAM + Auslagerungsspeicher) nicht überschreiten. In Wirklichkeit wird dies viel weniger der Fall sein, da Redis diesen Speicherplatz mit vielen anderen Prozessen auf dem System gemeinsam nutzt. Wenn der Systemspeicherplatz erschöpft ist, wird er wahrscheinlich vom Betriebssystem gelöscht.

Mongo ist ein festplattenbasierter Datenspeicher, der am effizientesten ist, wenn sein Arbeitssatz in den physischen RAMpasst. _ (wie alle Software). Da es sich um festplattenbasierte Daten handelt, gibt es keine Grenzen für die Größe einer Mongo-Datenbank. Konfigurationsoptionen, verfügbarer Speicherplatz und andere Probleme können jedoch dazu führen, dass Datenbanken, die eine bestimmte Grenze überschreiten, unpraktisch oder ineffizient werden.

Sowohl Redis als auch Mongo können zu Clustern zusammengefasst werden, um eine hohe Verfügbarkeit und Sicherung zu gewährleisten und die Gesamtgröße des Datenspeichers zu erhöhen.

10
aaa90210

Und Sie sollten auch nicht verwenden, wenn Sie über ausreichend RAM verfügen. Redis und MongoDB kommen zum Preis eines Allzweckwerkzeugs. Dies führt zu viel Aufwand.

Es hieß, Redis sei zehnmal schneller als Mongo. Das mag nicht mehr so ​​sein. MongoDB behauptete (wenn ich mich recht erinnere), Memcache für das Speichern und Zwischenspeichern von Dokumenten zu übertreffen, solange die Speicherkonfigurationen gleich sind.

Jedenfalls. Redis gut, MongoDB ist gut. Wenn Sie sich für Unterstrukturen interessieren und eine Aggregation benötigen, entscheiden Sie sich für MongoDB. Wenn das Speichern von Schlüsseln und Werten Ihr Hauptanliegen ist, dreht sich alles um Redis. (oder ein anderer Schlüsselwertspeicher).

2
Martin Kersten

Redis und MongoDB sind beide nicht relationale Datenbanken, aber sie gehören verschiedenen Kategorien an.

Redis ist eine Schlüssel-/Wert-Datenbank und verwendet In-Memory-Speicher, was sie superschnell macht. Es ist ein guter Kandidat für das Zwischenspeichern von Daten und den temporären Datenspeicher (im Speicher). Da die meisten Cloud-Plattformen (wie Azure, AWS) dies unterstützen, ist die Speichernutzung skalierbar Bedenken Sie, dass nur begrenzte Ressourcen zur Verfügung stehen.

MongoDB hingegen ist eine Dokumentendatenbank. Es ist eine gute Option, um große Texte, Bilder, Videos usw. und fast alles, was Sie mit Datenbanken tun, außer Transaktionen, aufzubewahren. Wenn Sie beispielsweise ein Blog oder ein soziales Netzwerk entwickeln möchten, ist MongoDB die richtige Wahl. Es ist mit einer Scale-Out-Strategie skalierbar. Die Festplatte wird als Speichermedium verwendet, sodass die Daten erhalten bleiben.

2
akazemis

Wenn Ihr Projekt über genügend RAM Arbeitsspeicher in Ihrer Umgebung verfügt, lautet die Antwort "Redis". Insbesondere unter Berücksichtigung des neuen Redis 3.2 mit Clusterfunktionalität.

1
Denys