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

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

Sie sind beide großartig und ich möchte Redis so oft wie möglich in der Bereitstellung verwenden, aber es ist schwer zu codieren. Ich möchte MongoDB so oft wie möglich in der Entwicklung verwenden, aber es braucht eine teure Maschine.

Was denkst du über die Verwendung von beiden? Wann sollte man Redis auswählen? Wann sollte man MongoDB auswählen?

Ich würde sagen, es hängt von der Art des Entwicklerteams ab, das Sie sind, und von Ihren Anwendungsanforderungen.

Wenn Sie beispielsweise viel abfragen müssen, bedeutet dies meistens, dass Ihre Entwickler mehr Arbeit benötigen , um Redis zu verwenden, bei dem Ihre Daten möglicherweise in verschiedenen spezialisierten Datenstrukturen gespeichert werden, die aus Effizienzgründen für jeden Objekttyp angepasst sind. In MongoDB sind dieselben Abfragen möglicherweise einfacher, da die Struktur für Ihre Daten konsistenter ist. Andererseits ist in Redis die Geschwindigkeit der Beantwortung dieser Fragen die Auszahlung für die zusätzliche Arbeit im Umgang mit der Vielfalt der Strukturen, in denen Ihre Daten möglicherweise gespeichert sind.

MongoDB bietet Entwicklern mit traditioneller 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 schemafähige Daten ist MongoDB besser. [Hinweis: Sowohl MongoDB als auch Redis sind technisch schemenlos]

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

Schließlich hoffe ich, dass Sie inzwischen http://antirez.com/post/MongoDB-and-Redis.html gesehen haben

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

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

  MongoDB eignet sich für Hackathons, Startups oder jedes Mal, wenn Sie nicht wissen, wie Sie die eingegebenen Daten abfragen. MongoDB macht keine Annahmen über Ihr zugrunde liegendes Schema. Während MongoDB schemenlos und nicht relational ist, bedeutet dies nicht, dass es überhaupt kein Schema gibt. Es bedeutet einfach, dass Ihr Schema in Ihrer App definiert werden muss (z. B. mit Mongoose). Außerdem eignet sich MongoDB hervorragend zum Prototyping oder Ausprobieren. Die 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 integriert werden . Es ist sehr ungewöhnlich, Redis als eigenständiges Datenbanksystem zu verwenden (einige Leute bevorzugen es, es als "Schlüsselwertspeicher" zu bezeichnen). Websites wie Craigslist verwenden Redis neben ihrer Primärdatenbank . Antirez (Entwickler von Redis) hat mit Lamernews gezeigt, dass es tatsächlich möglich ist, Redis als eigenständiges Datenbanksystem zu verwenden.

• Redis macht keine Annahmen basierend auf Ihren Daten.

  Redis bietet eine Reihe nützlicher Datenstrukturen (z. B. Sets, Hashes, Listen), aber Sie müssen explizit definieren, wie Sie Ihre Daten speichern möchten. Um es auf den Punkt zu bringen: 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, in dem Sie normalerweise MongoDB bevorzugen. Außerdem ist Redis sehr flexibel. Die zugrunde liegenden Datenstrukturen sind die Bausteine ​​von Hochleistungs-DB-Systemen.

Wann sollte Redis verwendet werden?

• Caching

  Das Zwischenspeichern mit MongoDB macht einfach nicht viel 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 sich überlegen, wie Sie Ihre Daten speichern und organisieren möchten. Ein Beispiel sind Hashes in Redis. Sie unterscheiden sich erheblich von "traditionellen" verschachtelten Objekten. Dies bedeutet, dass Sie die Art und Weise, in der Sie verschachtelte Dokumente speichern, überdenken müssen. Eine Lösung wäre, eine Referenz innerhalb des Hashs auf einen anderen Hash zu speichern (so etwas wie Schlüssel: [ID des zweiten Hashs] ). Eine andere Idee wäre, es als JSON zu speichern, was für die meisten Leute mit * SQL-Hintergrund kontraintuitiv erscheint.

• 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, Redis als echte Datenbank zu verwenden.

• Wenn Sie sich nicht so sehr für die Skalierung interessieren .

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

Wann wird MongoDB verwendet?

• 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 ein 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 herkömmlichen relationalen DBMS ist äußerst teuer und langsam. MongoDB löst dieses Problem, indem Sie nicht viele Annahmen zu Ihren zugrunde liegenden Daten treffen. 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, Zeit mit der Optimierung und Organisation Ihrer Daten zu verbringen. - Verwenden Sie MongoDB, wenn Sie einen Prototyp erstellen müssen, ohne sich über Ihre Datenbank Gedanken zu machen.

Weiterführende Literatur:

• Interessante Aspekte bei der Verwendung von Redis als primären Datenspeicher

Redis. Angenommen, Sie haben eine Website in PHP geschrieben. Aus irgendeinem Grund wird es populär und ist seiner Zeit voraus oder hat Pornos drauf. Sie erkennen, dass dieses PHP so verdammt 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 die PHP noch langsamer ist. :( Dann erstellen Sie einen Speichermechanismus unter Verwendung des Speichers und dieser URL, die Sie als "Schlüssel" bezeichnen, während Sie den Webseiteninhalt als "Wert" bezeichnen. Das ist alles, was Sie haben - Schlüssel und Inhalt. Sie nennen ihn "Meme-Cache". Sie mögen Richard Dawkins, weil er großartig ist. Sie zwischenspeichern Ihr HTML wie Eichhörnchen, die ihre Nüsse zwischenspeichern. Sie müssen Ihren Mist-PHP-Code nicht umschreiben. Du bist glücklich. Dann sehen Sie, dass andere es getan haben - aber Sie wählen Redis, weil der andere verwirrende Bilder von Katzen hat, einige mit Reißzähnen.

Mongo. Sie haben eine Site geschrieben. Du hast viele geschrieben und das in jeder Sprache. Sie erkennen, dass ein Großteil Ihrer Zeit damit verbracht wird, diese stinkenden SQL-Klauseln zu schreiben. Du bist kein dba, aber da bist du und schreibst dumme SQL-Statements ... nicht nur eine, sondern überall verrückt. "Wählen Sie dies, wählen Sie das". Vor allem aber erinnern Sie sich an die irritierende WHERE-Klausel. Wobei Nachname gleich "Thornton" und Film gleich "Bad Santa" ist. Urgh. Sie denken: "Warum machen diese dbas nicht einfach ihre Arbeit und geben mir einige gespeicherte Prozeduren?" Dann vergessen Sie ein kleines Feld wie den Mittelnamen und müssen dann die Tabelle löschen, alle 10 G Big Data exportieren und mit diesem neuen Feld ein weiteres erstellen und die Daten importieren - und das geht in den nächsten 14 Tagen zehnmal so weiter wie Sie Erinnere dich immer wieder an Mist wie Anrede, Titel, plus Hinzufügen eines Fremdschlüssels mit Adressen. Dann stellen Sie sich vor, dass Nachname Nachname sein sollte. Fast eine Änderung pro Tag. Dann sagst du verdammt. Ich muss einsteigen und eine Website / ein System schreiben, egal dieses Datenmodell bs. Also googeln Sie, "Ich hasse es, SQL zu schreiben, bitte kein SQL, lassen Sie es aufhören", aber es erscheint 'nosql' und dann lesen Sie einige Dinge und es heißt, es werden nur Daten ohne Schema ausgegeben. Sie erinnern sich an das Fiasko der letzten Woche, als Sie mehr Tische fallen ließen und lächelten. Dann wählst du Mongo, weil einige große Leute wie 'Airbud', den die passende Vermietungsseite benutzt, es benutzen. Süss. Keine Änderungen mehr am Datenmodell, da Sie ein Modell haben, das Sie ständig ändern.

Vielleicht ist diese Ressource hilfreich, um sich zwischen beiden zu entscheiden. Es werden auch mehrere andere NoSQL-Datenbanken behandelt und eine kurze Liste von Merkmalen sowie eine Erklärung "Wofür ich sie verwenden würde" für jede von ihnen angeboten.

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

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

Sie müssen beide testen, um festzustellen, welche von ihnen Ihren Anforderungen entsprechen.

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

Redis ist ein In-Memory- Datenspeicher, der seinen Status auf der Festplatte beibehalten kann (um die Wiederherstellung nach dem Neustart zu ermöglichen). Ein speicherinterner Datenspeicher zu sein bedeutet jedoch, dass die Größe des Datenspeichers (auf einem einzelnen Knoten) den gesamten Speicherplatz auf dem System (physischer RAM + Swap-Speicher) nicht überschreiten kann. In Wirklichkeit wird dies viel weniger sein, da Redis diesen Speicherplatz mit vielen anderen Prozessen auf dem System teilt und wenn es den Systemspeicherplatz erschöpft, wird es wahrscheinlich vom Betriebssystem abgeschaltet.

Mongo ist ein festplattenbasierter Datenspeicher, der am effizientesten ist, wenn sein Arbeitssatz in den physischen Arbeitsspeicher passt (wie alle Software). Als festplattenbasierte Daten gibt es keine intrinsischen Beschränkungen für die Größe einer Mongo-Datenbank. Konfigurationsoptionen, verfügbarer Speicherplatz und andere Bedenken können jedoch dazu führen, dass Datenbankgrößen über einem bestimmten Grenzwert unpraktisch oder ineffizient werden.

Sowohl Redis als auch Mongo können für Hochverfügbarkeit, Sicherung und zur Erhöhung der Gesamtgröße des Datenspeichers geclustert werden.

Alle Antworten (zum Zeitpunkt dieses 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. So vergleichen Sie 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 zusammengefasst sind.

JSON-Dateien haben eine ähnliche Struktur wie XML- und YAML-Dateien sowie Wörterbücher wie 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 Skalarwerte 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 Wert hat 555 634-5789. Sie können eine Sammlung von Dokumenten durchsuchen, in denen der Schlüssel PhoneNumber.Mobileeinen Wert hat. Sie sind indiziert.

Es hat auch ein Array, Accountsdas mehrere Indizes enthält. Es ist möglich , dass ein Dokument abfragen , wo Accountsenthält genau Werte eine Teilmenge, alle von einem gewissen Teilmenge von Werten, oder jede einiger Teilmenge von Werten. Das heißt, Sie können Accounts = ["379-1111", "379-2574"]das oben Gesagte suchen und nicht finden. Sie können Accounts includes ["379-1111"]das obige Dokument suchen und finden. und Sie können Accounts includes any of ["974-3785","414-6731"]das oben genannte und jedes Dokument suchen und finden, das das Konto "974-3785" enthält, falls vorhanden.

Dokumente gehen so tief wie Sie wollen. PhoneNumber.Mobilekönnte ein Array oder sogar ein Unterdokument ( PhoneNumber.Mobile.Workund PhoneNumber.Mobile.Personal) enthalten. Wenn Ihre Daten stark strukturiert sind, sind Dokumente ein großer Fortschritt gegenüber relationalen Datenbanken.

Wenn Ihre Daten größtenteils flach, relational und starr strukturiert sind, ist eine relationale Datenbank besser geeignet. Auch hier ist das große Zeichen, ob Ihre Datenmodelle am besten für eine Sammlung miteinander verbundener CSV-Dateien oder eine Sammlung von XML / JSON / YAML-Dateien geeignet sind.

Bei den meisten Projekten müssen Sie Kompromisse eingehen und in einigen kleinen Bereichen, in denen entweder SQL- oder Dokumentenspeicher nicht passen, eine geringfügige Umgehung akzeptieren. Bei einigen großen, komplexen Projekten, in denen eine breite Datenverteilung 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 Diagrammdatenbank (in der Daten in Knoten gespeichert und Knoten mit anderen Knoten verbunden werden). Craigslist verwendete früher MySQL und MongoDB, hatte jedoch versucht, sich vollständig auf MongoDB zu konzentrieren. Dies sind Orte, an denen die Spanne und die Beziehung der Daten erhebliche Nachteile aufweisen, wenn sie unter einem Modell zusammengefasst werden.

Redis: Schlüsselwert

Redis ist im Grunde ein Schlüsselwertspeicher. 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 beim Namen nachgeschlagen.

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

Der offensichtlichste Fall einer Ungültigmachung ist die Aktualisierung beim Schreiben: Wenn Sie lesen user:Simon:lingots = NOTFOUND, können Sie SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simondas Ergebnis 100als speichern SET user:Simon:lingots = 100. Dann , wenn Sie Simon 5 lingots vergeben, lesen Sie user:Simon:lingots = 100, SET user:Simon:lingots = 105und 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:lingotsohne Abfrage der Datenbank erhalten.

Der zweite Fall ist die Aktualisierung abhängiger Informationen. Angenommen, Sie generieren Teile einer Seite und speichern deren Ausgabe zwischen. Der Header zeigt die Erfahrung, das Level und den Geldbetrag des Spielers. Die Profilseite des Spielers enthält einen Block, in dem die Statistiken angezeigt werden. und so weiter. Der Spieler sammelt etwas Erfahrung. Nun, jetzt haben Sie mehrere templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simonund so weiter Bereiche , in denen Sie die Ausgabe von einer halben Dutzend Datenbankabfragen durch einen Template - Engine ausgeführt wird zwischengespeichert haben. Wenn Sie diese Seiten anzeigen, sagen Sie normalerweise:

$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 aktualisiert GetStatsFromDatabase("Simon")haben, müssen Sie templates:*:SimonIhren Schlüsselwert-Cache verlassen. Wenn Sie versuchen, eine dieser Vorlagen zu rendern, wird Ihre Anwendung Daten aus Ihrer Datenbank (PostgreSQL, MongoDB) abrufen und in Ihre Vorlage einfügen. Dann speichert es das Ergebnis in Redis und macht hoffentlich keine Datenbankabfragen und Rendering-Vorlagen, wenn es das nächste Mal diesen Ausgabeblock anzeigt.

Mit Redis können Sie auch Nachrichtenwarteschlangen für Publisher und Abonnenten erstellen. Das ist ein ganz anderes Thema. Hier geht es darum, 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 dies bestimmt, wie komplex und fehleranfällig Ihr Code ist. Spezialisierte Anwendungen stützen sich auf die Leistung, Orte, 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.

Und Sie sollten keine verwenden, wenn Sie viel RAM haben. Redis und MongoDB kosten ein Allzweckwerkzeug. Dies führt zu einem hohen Overhead.

Es gab das Sprichwort, dass Redis zehnmal schneller ist als Mongo. Das könnte nicht mehr so ​​wahr sein. MongoDB (wenn ich mich richtig erinnere) behauptete, Memcache zum Speichern und Zwischenspeichern von Dokumenten zu schlagen, solange die Speicherkonfigurationen identisch 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).

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

Redis ist eine Schlüssel- / Wertedatenbank und verwendet In-Memory-Speicher, wodurch sie sehr schnell ist. Es ist ein guter Kandidat für das Zwischenspeichern von Inhalten und die temporäre Datenspeicherung (im Speicher). Da die meisten Cloud-Plattformen (wie Azure, AWS) dies unterstützen, ist die Speichernutzung skalierbar. Wenn Sie sie jedoch auf Ihren Computern mit verwenden möchten begrenzte Ressourcen, bedenken Sie die Speichernutzung.

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. Es verwendet die Festplatte als Speichermedium, sodass die Daten erhalten bleiben.

Wenn Ihr Projekt es Ihnen ermöglicht, genügend RAM-Speicher in Ihrer Umgebung zu haben, lautet die Antwort Redis. Insbesondere unter Berücksichtigung des neuen Redis 3.2 mit Cluster-Funktionalität.