Wann zu Redis? Wann zu MongoDB?

Question

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 verbraucht mehr Ressourcen, aber die API ist sehr einfach zu benutzen, und ich bin sehr zufrieden damit.

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

Was halten Sie also von der Verwendung dieser beiden Mittel? Wann sollte man Redis wählen? Wann sollte man MongoDB wählen?

Answer 1

Ich würde sagen, es hängt davon ab, welche Art von Entwicklerteam Sie sind und welche Anforderungen Ihre Anwendung hat.

Benötigen Sie zum Beispiel eine Vielzahl von abfragen. Das bedeutet vor allem, dass es für Ihre Entwickler mehr Arbeit bedeutet, Redis zu verwenden, wo Ihre Daten in einer Vielzahl von spezialisierten Datenstrukturen gespeichert werden können, die aus Effizienzgründen für jeden Objekttyp angepasst sind. In MongoDB könnten die gleichen Abfragen einfacher sein, da die Struktur über Ihre Daten hinweg konsistenter ist. Auf der anderen Seite, in Redis, schiere Geschwindigkeit der Antwort auf diese Abfragen ist der Lohn für die zusätzliche Arbeit, die mit der Vielfalt der Strukturen, in denen Ihre Daten gespeichert sein könnten, verbunden ist.

MongoDB bietet Einfachheit und eine viel kürzere Lernkurve für Entwickler mit traditioneller DB- und SQL-Erfahrung. Der nicht-traditionelle Ansatz von Redis erfordert jedoch einen höheren Lernaufwand, bietet aber mehr Flexibilität.

Z. B. A Cache Schicht kann wahrscheinlich besser in Redis implementiert werden. Für mehr schema-fähige Daten ist MongoDB besser geeignet. [Hinweis: Sowohl MongoDB als auch Redis sind technisch gesehen schemalos.]

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

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

Answer 2

Ich habe gerade festgestellt, dass diese Frage schon ziemlich alt ist. Dennoch halte ich die folgenden Aspekte für ergänzenswert:

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

  MongoDB eignet sich für Hackathons, Startups oder immer dann, wenn Sie nicht wissen, wie Sie die eingegebenen Daten abfragen werden. MongoDB macht keine Annahmen über Ihr zugrunde liegendes Schema. Obwohl MongoDB schemalos und nicht-relational ist, bedeutet das nicht, dass es überhaupt kein Schema gibt. Es bedeutet lediglich, dass Ihr Schema in Ihrer Anwendung definiert werden muss (z. B. mit Mongoose). Abgesehen davon eignet sich MongoDB hervorragend für das Prototyping oder das Ausprobieren von Dingen. Die Leistung ist nicht so toll und kann nicht mit Redis verglichen werden.

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

  Redis lässt sich leicht als LRU-Cache . Es ist sehr unüblich, Redis als eigenständiges Datenbanksystem zu verwenden (manche Leute ziehen es vor, es als "Key-Value"-Speicher zu bezeichnen). Websites wie Craigslist verwenden Redis neben ihrer primären Datenbank . Antirez (Entwickler von Redis) demonstrierte anhand von Lamernews, dass es tatsächlich möglich ist, Redis als eigenständiges Datenbanksystem zu verwenden.

• Redis trifft keine Annahmen auf der Grundlage Ihrer Daten.

  Redis bietet eine Reihe von nützlichen Datenstrukturen (z.B. Sets, Hashes, Lists), aber man muss explizit definieren, wie man seine Daten speichern möchte. Um es kurz zu machen: Redis und MongoDB können verwendet werden, um ähnliche Dinge zu erreichen. Redis ist einfach schneller, aber nicht für das Prototyping geeignet. Das ist ein Anwendungsfall, bei dem Sie typischerweise MongoDB bevorzugen würden. Abgesehen davon ist Redis wirklich flexibel. Die zugrundeliegenden Datenstrukturen sind die Bausteine von Hochleistungs-DB-Systemen.

Wann sollte Redis verwendet werden?

• Caching

  Die Zwischenspeicherung mit MongoDB ist einfach nicht sehr sinnvoll. Es würde zu langsam sein.

• Wenn Sie genügend Zeit haben, über Ihr DB-Design nachzudenken.

  Sie können Ihre Dokumente nicht einfach in Redis einspeisen. Sie müssen sich überlegen, wie Sie Ihre Daten speichern und organisieren wollen. Ein Beispiel sind Hashes in Redis. Sie unterscheiden sich deutlich 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, innerhalb des Hashes einen Verweis auf einen anderen Hash zu speichern (etwas wie Schlüssel: [id des zweiten Hashes] ). Eine andere Idee wäre, sie als JSON zu speichern, was für die meisten Menschen mit *SQL-Hintergrund nicht intuitiv erscheint.

• Wenn Sie wirklich hohe Leistung.

  Es ist fast unmöglich, die Leistung von Redis zu übertreffen. Stellen Sie sich vor, Ihre Datenbank wäre so schnell wie Ihr Cache. Genau so fühlt es sich an, wenn Sie Redis als real Datenbank.

• Wenn es Sie nicht interessiert dass viel über Skalierung.

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

Wann wird MongoDB verwendet?

• Prototyping, Startups, Hackathons

  MongoDB eignet sich hervorragend für Rapid Prototyping. Allerdings 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 traditionellen, relationalen DBMS ist schmerzhaft teuer und langsam. MongoDB löst dieses Problem, indem es nicht viele Annahmen über Ihre zugrunde liegenden Daten trifft. Dennoch versucht es, 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 für die Optimierung und Organisation Ihrer Daten aufzuwenden. - Verwenden Sie MongoDB, wenn Sie einen Prototyp erstellen möchten, ohne sich zu viele Gedanken über Ihre DB zu machen.

Lesen Sie weiter:

• Interessante Aspekte, die bei der Verwendung zu beachten sind Redis als primärer Datenspeicher

Answer 3

Redis. Nehmen wir an, Sie haben eine Website in php geschrieben; aus welchem Grund auch immer, sie wird populär und ist ihrer Zeit voraus oder enthält Pornos. Du stellst fest, dass dieses php so verdammt langsam ist, dass du denkst: "Ich verliere meine Fans, weil sie einfach keine 10 Sekunden auf eine Seite warten wollen." Plötzlich wird dir klar, dass eine Webseite eine konstante URL hat (sie ändert sich nie, wow), einen Primärschlüssel, wenn man so will, und dann erinnerst du dich daran, dass der Speicher schnell ist, während die Festplatte langsam ist und php noch langsamer ist :( Dann bastelst du einen Speichermechanismus, der den Speicher und diese URL benutzt, die du "Schlüssel" nennst, während du den Inhalt der Webseite "Wert" nennst. Das ist alles, was Sie haben - Schlüssel und Inhalt. Sie nennen es "Meme-Cache". Sie mögen Richard Dawkins, weil er großartig ist. Sie speichern Ihre HTML-Seiten im Cache, wie Eichhörnchen ihre Nüsse im Cache speichern. Du brauchst deinen beschissenen php-Code nicht umzuschreiben. Du bist glücklich. Dann siehst du, dass andere das auch gemacht haben - aber du wählst Redis, weil das andere verwirrende Bilder von Katzen hat, einige mit Reißzähnen.

Mongo. Sie haben eine Website geschrieben. Oder besser gesagt, Sie haben schon viele geschrieben, und zwar in jeder Sprache. Ihnen ist klar, dass Sie einen Großteil Ihrer Zeit damit verbringen, diese stinkenden SQL-Klauseln zu schreiben. Sie sind kein Datenbankadministrator, und doch schreiben Sie dumme SQL-Anweisungen... nicht nur eine, sondern überall. "select this, select that". Aber vor allem erinnern Sie sich an die irritierende WHERE-Klausel. Where lastname equals "thornton" and movie equals "bad santa". Urgh. Sie denken: "Warum machen diese Datenbanken nicht einfach ihren Job und geben mir ein paar gespeicherte Prozeduren?" Dann vergisst man irgendein unbedeutendes Feld wie Nachname und muss die Tabelle löschen, alle 10 GB großer Daten exportieren und eine neue Tabelle mit diesem neuen Feld erstellen und die Daten importieren - und das geht in den nächsten 14 Tagen 10 Mal so weiter, während man sich immer wieder an Mist wie Anrede und Titel erinnert und einen Fremdschlüssel mit Adressen hinzufügt. Dann stellen Sie fest, dass Nachname zu Nachname werden sollte. Fast eine Änderung pro Tag. Dann sagen Sie: Verdammt. Ich muss eine Website/ein System schreiben und mich nicht um dieses Datenmodell kümmern. Also googeln Sie: "Ich hasse es, SQL zu schreiben, bitte kein SQL, machen Sie, dass es aufhört", aber es erscheint 'nosql', und dann lesen Sie etwas und es heißt, dass es nur Daten ohne Schema ausgibt. Du erinnerst dich an das Fiasko von letzter Woche, als du weitere Tabellen löschen musstest und lächelst. Dann entscheidest du dich für Mongo, weil einige große Unternehmen, wie z.B. airbud", die Website für Wohnungsvermietung, es benutzen. Super. Keine Datenmodelländerungen mehr, weil man ein Modell hat, das man einfach immer wieder ändert.

Answer 4

Vielleicht ist diese Ressource nützlich, um zwischen beiden zu entscheiden. Es werden auch verschiedene andere NoSQL-Datenbanken besprochen, und es wird eine kurze Liste von Merkmalen angeboten, zusammen mit einer "Wofür ich es verwenden würde" eine Erklärung für jedes dieser Elemente.

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

Answer 5

Diese Frage ist schwer zu beantworten - wie bei den meisten technologischen Lösungen hängt es wirklich von Ihrer Situation ab, und da Sie das Problem, das Sie zu lösen versuchen, nicht beschrieben haben, wie kann jemand eine Lösung vorschlagen?

Sie müssen beide testen, um festzustellen, welche von ihnen zufriedenstellend sind Ihr Bedürfnisse.

Das heißt, MongoDB benötigt keine teure Hardware. Wie jede andere Datenbanklösung wird sie mit mehr CPU und Speicher besser funktionieren, aber das ist sicherlich keine Voraussetzung - vor allem nicht für frühe Entwicklungszwecke.