Mit MongoDB vs MySQL mit viel JSON-Felder?

Es ist ein microblogging-Art der Anwendung. Zwei Haupt-grundlegende Datenbank-Speicher auf null gesetzt sind:
MySQL oder MongoDB.

Ich bin Planung zu denormalize Menge von Daten I. e. Eine Abstimmung erfolgt auf ein post gespeichert wird in einem voting-Tabelle, auch eine Zählung erhöht wird, in den main-posts-Tabelle. Es gibt andere Aktionen, die mit der post zu (z.B. Wie, Stimme runter).

Wenn ich MySQL verwenden, einige der Daten besser passt als JSON als festes schema, für schnellere Suchvorgänge.

E. g.

POST_ID   |  activity_data

213423424 | { 'likes': {'count':213,'recent_likers' :
             ['john','jack',..fixed list of recent N users]} , 'smiles' : 
             {'count':345,'recent_smilers' :
             ['mary','jack',..fixed list of recent N users]}  }

Gibt es andere Komponenten der Anwendung, wo die Verwendung von JSON wird vorgeschlagen.
So, ein update JSON-Feld, die Reihenfolge ist:

  1. Lesen Sie die JSON python-Skript.

  2. Update der JSON -

  3. Speichern von JSON wieder in MySQL.

Wäre es gewesen, eine einzige Betrieb in MongoDB mit atomaren Operationen wie $push,$inc,$pull etc. Auch
Dokument Struktur von MongoDB passt meiner Daten gut.

Meine überlegungen bei der Auswahl der Daten zu speichern.

Bezüglich MySQL:

  1. Stabil und vertraut.
  2. Sicherung und-Wiederherstellung ist einfach.
  3. Zukunft einige änderungen am schema können vermieden werden, indem einige Felder als schemaless JSON.
  4. Möglicherweise Schicht von memcached früh.
  5. JSON-blobs werden statisch in einigen Tabellen wie die main, die Einträge werden aktualisiert, eine Menge, die in einigen anderen Tabellen wie die Post Stimmen, und mag.

Bezüglich MongoDB:

  1. Besser geeignet zum speichern von schema-weniger Daten als Dokumente.
  2. Zwischenspeichern könnten, werden vermieden, bis später.
  3. Manchmal die app kann sich schreiben intensive, MongoDB können besser auf jene Punkte, wo unsichere schreibt nicht ein Problem.
  4. Nicht sicher über die Stabilität und Zuverlässigkeit.
  5. Nicht sicher, wie einfach ist es, um die backup und restore.

Fragen:

  1. Sind wir wählten MongoDB, wenn die Hälfte der Daten ist schemaless, und wird als JSON gespeichert, wenn Sie MySQL?

  2. Einige Daten wie Haupt-posts ist kritisch, es wird also gespeichert werden, mit safe schreibt, die Schalter etc
    gespeichert werden unsichere schreibt. Ist diese Politik, die auf die Bedeutung der Daten und schreiben, die Intensität richtig?

  3. Wie einfach ist es, zu überwachen, sichern und wiederherstellen von MongoDB im Vergleich zu MySQL? Wir müssen planen, regelmäßige backups ( sprich täglich ), und diese wiederherstellen, mit Leichtigkeit im Falle einer Katastrophe. Was sind die besten Möglichkeiten, ich habe mit MongoDB zu machen es eine sichere Wette für die Anwendung.

Stabilität, Datensicherung, snapshots, Wiederherstellung, breitere Annahme I. e.Datenbank Haltbarkeit sind die Gründe, verweist mich
für die Verwendung von MySQL als RDBMS+NoSql, obwohl eine NoSQL Dokument-Speicher dienen könnte meine Zwecke besser.

Bitte konzentrieren Sie Ihre Ansichten über die Wahl zwischen MySQL und MongoDB unter Berücksichtigung der Datenbank-design habe ich im Hinterkopf. Ich weiß, es könnte besser sein, Wege zu planen, Datenbank-design mit entweder RDBMS oder MongoDB Dokumente. Aber das ist nicht der aktuelle Schwerpunkt meiner Frage.

UPDATE : Von MySQL 5.7 ab, MySQL unterstützt eine reiche native JSON-Datentyp, die Daten die Flexibilität sowie reichhaltige JSON-Abfragen.

https://dev.mysql.com/doc/refman/5.7/en/json.html

  • Ernst nehmen tun Sie das nicht. Sollten Sie nicht verwenden json in sql als Sie nicht lange die Möglichkeit haben, Abfragen. Wenn Sie nicht brauchen, um Abfrage, die Daten, die Sie verwenden können, jede Binär-format (beinhaltet json). Mongodb verwendet json, weil es es versteht und kann Abfragen. postgresql kann es unterstützen, ich habe nicht versucht. Aber trotzdem sollten Sie die Verwendung von mysql in der normalen mysql Weg. Sie brauchen nichts anderes, bis Sie nach einer dedizierten Maschine zu bedienen und haben-Betrag schreibt, wächst. Wenn Sie möchten, um zu versuchen, mongodb machen eine Spielzeug-app oder bereiten Sie sich, verbringen viel Zeit mit der Pflege - /Lern - /bug-oder andere Update.
  • Ich werde nicht Abfragen oder die Suche der Daten im json-Format. Sie werden nur verarbeitet, für das schreiben, wenn eine Aktion passiert, aber Lesen Sie immer durch den Primärschlüssel als ganzes json.
  • hmm ok, aber meinen letzten Satz. Auch bewusst sein, sicher schreibt (die Sperrung) und dass die 32-bit bedeutet, dass deine db ist beschränkt auf 2GBs
InformationsquelleAutor DhruvPathak | 2012-10-17
  1. 18

    So, direkt die Fragen beantworten...

    Sind wir wählten mongodb, wenn die Hälfte der Daten ist schemaless, und wird als JSON gespeichert, wenn Sie MySQL?

    Schemaless Speicher ist sicherlich ein zwingender Grund zu gehen, mit MongoDB, aber wie haben Sie darauf hingewiesen, es ist ziemlich leicht zu speichern, JSON, in einem RDBMS als gut. Die Kraft, die hinter MongoDB ist in der reichen Abfragen schemaless Speicher.

    Wenn ich vielleicht ein kleines Manko in der Abbildung über die Aktualisierung eines JSON-Feld, es geht nicht einfach darum, immer den aktuellen Wert, aktualisieren Sie das Dokument, und dann schieben Sie es zurück in die Datenbank. Der Prozess muss alle eingewickelt in eine Transaktion. Transaktionen sind in der Regel Recht unkompliziert, bis Sie beginnen, denormalizing Ihrer Datenbank. Dann etwas so einfaches wie die Aufnahme ein upvote sperren können Tabellen, die alle über Ihr schema.

    Mit MongoDB, es sind keine Transaktionen. Aber Operationen sind fast immer strukturiert in einer Weise, die es ermöglichen, für Atomare updates. Dies erfordert in der Regel einige dramatische Veränderungen aus der SQL-Paradigmen, aber meiner Meinung nach sind Sie ziemlich offensichtlich, wenn Sie aufhören zu versuchen zu zwingen, Objekte in Tabellen. Zumindest, viele andere Leute haben die gleichen Probleme, die Sie konfrontiert werden, und die Mongo-community eher ziemlich offen und lautstark über die Herausforderungen, die Sie haben, zu überwinden.

    Einige Daten wie Haupt-posts ist kritisch , es wird also gespeichert werden, mit safe schreibt , die Schalter etc gespeichert werden unsichere schreibt. Ist diese Politik, die auf die Bedeutung der Daten und schreiben, die Intensität richtig?

    Durch "sicher schreibt" ich nehme an, du meinst die option zum aktivieren eine automatische "getLastError()" nach jedem schreiben. Wir haben ein sehr dünner wrapper über eine DBCollection, die es uns ermöglicht feinkörnige Kontrolle über getLastError() aufgerufen wird. Aber, unsere Politik ist nicht darauf basiert, wie die "wichtigen" Daten ist, sondern vielmehr, ob der folgende code die Abfrage ist zu erwarten, dass jede änderungen werden sofort sichtbar in der folgenden liest.

    Generell ist dies immer noch ein schlechter Indikator, und wir haben stattdessen wanderten zu findAndModify() für das gleiche Verhalten. Auf die Gelegenheit, wo wir immer noch der explizite Aufruf von getLastError() ist es, wenn die Datenbank wahrscheinlich ablehnen, eine zu schreiben, wie wenn wir insert() mit einem _id, die möglicherweise ein Duplikat.

    Wie einfach ist es, zu überwachen,sichern und wiederherstellen von Mongodb im Vergleich zu mysql? Wir müssen planen, regelmäßige backups (sprich täglich), und diese wiederherstellen, mit Leichtigkeit im Falle einer Katastrophe. Was sind die besten Möglichkeiten, ich habe mit mongoDb zu machen es eine sichere Wette für die Anwendung?

    Ich fürchte, ich kann nicht sprechen, ob unser backup - /restore-Politik wirksam ist, da wir noch nicht wieder herstellen musste noch. Wir sind nach der MongoDB-Empfehlungen für die Sicherung; @mark-hillick hat einen großartigen job gemacht, zusammenzufassen die. Wir verwenden Replikat-sets, und wir haben migriert MongoDB-Versionen sowie die Einführung neuer replica-Mitglieder. Bisher hatten wir keine Ausfallzeiten, so dass ich nicht sicher bin, ob ich sprechen kann, gut zu diesem Punkt.

    Stabilität,Datensicherung,snapshots,Wiederherstellung,breitere Annahme ich.e.Datenbank Haltbarkeit sind die Gründe, verweist mich auf die Verwendung von MySQL als RDBMS+NoSql, obwohl eine NoSQL Dokument-Speicher dienen könnte meine Zwecke besser.

    So, in meiner Erfahrung, MongoDB bietet die Lagerung von schemaless Daten mit einer Reihe von Abfrage-primitive Reich genug, dass die Transaktionen oft ersetzt werden durch Atomare Operationen. Es war hart, zu verlernen, 10+ Jahre im Wert von SQL-Erfahrung, aber jedes problem, das ich gestoßen bin ist angesprochen worden von der Gemeinschaft oder von 10gen direkt. Wir haben keine Daten verloren oder hatte keine Ausfallzeiten, die ich mich erinnern kann.

    Um es einfach auszudrücken, MongoDB ist die Hände nach unten die besten Daten-storage-ökosystem, die ich je benutzt habe im Sinne von Abfragen, Wartung, Skalierbarkeit und Zuverlässigkeit. Es sei denn, ich hatte eine Anwendung, die war so deutlich, relationale, ich könnte nicht guten Gewissens etwas anderes als SQL, ich würde jede Anstrengung zu verwenden MongoDB.

    Ich arbeite nicht für 10gen, aber ich bin sehr dankbar für die Leute, die das tun.

    • danke. Seine informative und aus der realen Welt zu erleben.
    InformationsquelleAutor Fuwjax
  2. 13

    Ich werde nicht Kommentar auf die Vergleiche (ich arbeite für 10gen und nicht das Gefühl, es ist angemessen für mich, dies zu tun), aber ich beantworte die spezifischen MongoDB Fragen, so dass Sie besser Ihre Entscheidung treffen.

    Back-Up -

    Dokumentation hier ist eine sehr Gründliche, über viele verschiedene Aspekte:

    • Block-Level-Methoden (LVM macht es sehr einfach und ziemlich viele Leute tun dies)
    • Mit/Ohne Journaling
    • EBS-Snapshots
    • Allgemeinen Snapshots
    • Replikation (technisch gesehen kein back-up, aber viel folk verwenden Replikat-sets für Ihre Redundanz-und back-up - nicht zu empfehlen dies, aber es ist fertig)

    Bis vor kurzem, es gibt keine MongoDB äquivalent mylvmbackup aber ein netter Kerl, schrieb einer 🙂 In seinen Worten

    Frühen Tagen so weit: es ist nur ein besserer shell-Skript und muss so mehr Fehler überprüfen. Aber bereits, es funktioniert für mich und ich dachte, ich würde teilen die Freude. Bug-reports, patches & Vorschläge willkommen.

    Holen Sie sich eine Kopie von hier.

    Stellt

    mongodump ist vollständig dokumentiert hier und mongorestore ist hier.

    mongodump nicht enthalten, werden die Indizes jedoch enthält das system.Indizes Sammlung so mongorestore kann die Neuerstellung der Indizes, wenn Sie die Wiederherstellung des bson-Datei. Die bson-Datei sind die eigentlichen Daten in der Erwägung, dass mongoexport/mongoimport sind nicht Typ-sicher, so könnte es alles sein (techically sprechen) 🙂

    Überwachung

    Dokumentiert hier.

    Mag ich Kakteen, aber afaik, die Kakteen Vorlagen haben nicht Schritt gehalten mit den Veränderungen in MongoDB und so verlassen sich auf alte syntax so schreiben 2.0.4, glaube ich, gibt es Probleme.

    Nagios funktioniert gut, aber es ist Nagios, so dass Sie entweder lieben oder hassen es. Viel folk Nagios nutzen, und es scheint so, dass Sie mit großer Sichtbarkeit.

    Ich habe gehört, einige Leute betrachten Zappix aber ich habe es nie benutzt, so kann nicht kommentieren.

    Zusätzlich, Sie können MMS nutzen, die frei ist und extern gehostet. Ihre MongoDB Instanzen einer Agenten-und einer dieser Agenten kommunizieren (mit python-code) über https mms.10gen.com. Wir verwenden Sie MMS, um alle performance-Statistiken über die MongoDB-Instanzen und es ist sehr vorteilhaft, aus einem high-level weiten Blick und bietet auch die Möglichkeit zum drill-down. Es ist einfach zu installieren und Sie nicht haben, um eine hardware für dieses. Viele Kunden laufen zu lassen und ein Kompliment es mit Kakteen/Nagios.

    Helfen, Informationen über MMS finden hier (es ist eine sehr detaillierte inclusive-Dokument).

    • Vielen Dank für Ihre Zeit und die tolle Antwort, das ist sehr hilfreich.
    • Ich möchte hinzufügen, dass Sie sollten betrachten Zuverlässigkeit im Kontext von Funktionen wie replica sets und automatisches failover. Nicht nur, dass es eine redundante up-to-date Kopie Ihrer Daten, im Falle der vollständigen Verlust der primären server, den Sie möchten, haben die sofortige failover statt, dass zu akzeptieren, Ausfallzeiten und Datenverlust während der Wiederherstellung der letzten Sicherung.
    InformationsquelleAutor Mark Hillick
  3. 4

    Einer der Nachteile, eine mysql-Lösung mit gespeicherten json ist, dass Sie nicht in der Lage, effizient zu suchen, auf die json-Daten. Wenn Sie es speichern alles in mongodb, können Sie Indizes anlegen und/oder Abfragen, die auf alle Ihre Daten, einschließlich der json.

    Mongo ' s schreibt sehr gut, und wirklich das einzige, was Sie verlieren, vs mysql Transaktion zu unterstützen, und damit die Fähigkeit zum rollback multipart spart. Allerdings, wenn Sie sind in der Lage, um Ihre änderungen in der atomaren Operationen, dann es gibt keine Daten, die Frage der Sicherheit. Wenn Sie repliziert werden, mongo bietet einen "eventually consistent" Versprechen, dass die Sklaven schließlich spiegeln Sie den master.

    Mongodb keine einheitlichen Vollzug oder die Kaskadierung von bestimmten db-Konstruktionen wie Fremdschlüssel, so haben Sie zu verwalten, die sich (wie entweder durch die Zusammensetzung, das ist ein mongo ' s stärken), oder durch Verwendung von dbrefs.

    Wenn Sie wirklich brauchen, transaction support und robust "sicher" schreibt, aber immer noch Lust die Flexibilität von nosql, sollten Sie überlegen, eine hybrid-Lösung. Dies ermöglicht die Verwendung von mysql als main-post-Shop, und verwenden Sie dann mongodb als "schemaless" lagern. Hier ist ein link zu einem doc besprechen hybrid-mongo/rdbms Lösungen: http://www.10gen.com/events/hybrid-applications Der Artikel ist von 10gen-Website, aber Sie finden andere Beispiele, indem Sie einfach eine schnelle google-Suche.

    Update 5/28/2019

    Hier wurden eine Reihe von änderungen in MySQL-und Mongodb, da diese Antwort gepostet wurde, also die vor - /Nachteile zwischen Ihnen haben sich sogar unschärfer. Dieses update hilft da nicht viel mit der ursprünglichen Frage, aber ich bin es zu tun, um sicherzustellen, dass alle neuen Leser, die ein wenig mehr aktuelle Informationen.

    MongoDB unterstützt nun Transaktionen: https://docs.mongodb.com/manual/core/transactions/

    MySql unterstützt nun die Indizierung und Suche von json-Felder:
    https://dev.mysql.com/doc/refman/5.7/en/json.html

    • Danke @DavidA , brauche ich nicht Abfragen und indizieren, es ist ein PK-lookup, um zu Lesen oder zu aktualisieren JSON. Keine Abfragen auf Elemente in der JSON.
    • nur eine Korrektur hier - es gibt keine solche Sache wie das schreiben zu Sklaven. Und der mongo ist nicht eventually consistent " - standardmäßig ist stark konsistent (oder Lesen-konsistent) - nur, wenn Sie ausdrücklich, richten Sie Ihre Anwendung zum Lesen von einer sekundären tun, das letztendliche Konsistenz der Semantik kommen. In der Tat, es ist ein level von safe schreibt, nur bestätigen Erfolg, wenn die Daten geschrieben wurden, auf die Grundschule und erfolgreich repliziert werden, um eine bestimmte Anzahl von secondaries.
    • Asya ist richtig, mein Fehler und tut mir Leid zu verwirren, wenn ich es Tat. Sie können Lesen, die von Sklaven, wenn Sie nichts dagegen haben die chance, die Daten ein klein wenig abgestanden und wollen eine bessere Skalierbarkeit, eine Kraft oder ein Lesen aus dem master-für eine "sichere" Lesen.
    • Basierend auf Ihre aktuellen Anforderungen erfüllen, sehe ich nicht ein deutlich zwingenden Grund für die Verwendung von MongoDB oder eine hybrid-Lösung über MySQL erwägen, sind Sie bereits vertraut und komfortabel mit MySQL.
    • Der wichtigste Faktor für mich zu wechseln, so viel wie möglich zu MongoDB von MySQL ist, dass es so mühelos, beim verschieben von Daten in und aus Wörterbüchern/Objekte, die ich Neige dazu, verwenden Sie die ganze Zeit. Wenn ich große Mengen von tabellarischen Daten aus einer CSV zum Beispiel, dann verwende ich MySQL. Es ist der Mühe Wert, laufen beide Dienste. Die Zeitersparnis durch nicht das müssen zu reduzieren oder erweitern Sie die Datensätze macht es lohnt sich die Investition in die Installation der anderen service als gut.
    • MySQL unterstützt JSON-sekundäre/virtuelle indizieren und Abfragen von JSON-Schlüssel. dev.mysql.com/doc/refman/5.7/en/json.html

    InformationsquelleAutor DavidA
Schreibe einen Kommentar