Um die Fragen direkt zu beantworten...
Schemalose Speicherung ist sicherlich ein überzeugender Grund, sich für MongoDB zu entscheiden, aber wie Sie bereits betont haben, ist es ziemlich einfach, JSON auch in einem RDBMS zu speichern. Die Stärke von MongoDB liegt in den umfangreichen Abfragen für schemalosen Speicher.
Wenn ich auf einen kleinen Fehler in der Abbildung zum Aktualisieren eines JSON-Felds hinweisen darf, geht es nicht einfach darum, den aktuellen Wert zu erhalten, das Dokument zu aktualisieren und es dann zurück in die Datenbank zu verschieben. Der gesamte Prozess muss in eine Transaktion eingeschlossen werden. Transaktionen sind in der Regel recht unkompliziert, bis Sie mit der Denormalisierung Ihrer Datenbank beginnen. Dann kann etwas so Einfaches wie das Aufzeichnen einer positiven Bewertung Tabellen in Ihrem gesamten Schema sperren.
Bei MongoDB gibt es keine Transaktionen. Operationen können jedoch fast immer so strukturiert werden, dass atomare Aktualisierungen möglich sind. Dies beinhaltet normalerweise einige dramatische Verschiebungen von den SQL-Paradigmen, aber meiner Meinung nach sind sie ziemlich offensichtlich, sobald Sie aufhören zu versuchen, Objekte in Tabellen zu zwingen. Zumindest sind viele andere Leute auf die gleichen Probleme gestoßen wie Sie, und die Mongo-Community neigt dazu, ziemlich offen und lautstark über die Herausforderungen zu sprechen, die sie gemeistert haben.
Mit "sicheren Schreibvorgängen" meinen Sie vermutlich die Option, nach jedem Schreibvorgang ein automatisches "getLastError()" einzuschalten. Wir haben einen sehr dünnen Wrapper über einer DBCollection, der uns eine feinkörnige Kontrolle darüber ermöglicht, wann getLastError() aufgerufen wird. Unsere Richtlinie basiert jedoch nicht darauf, wie "wichtig" Daten sind, sondern ob der Code nach der Abfrage erwartet, dass Änderungen sofort in den folgenden Lesevorgängen sichtbar sind.
Im Allgemeinen ist dies immer noch ein schlechter Indikator, und wir sind stattdessen für das gleiche Verhalten zu findAndModify() migriert. Wenn wir immer noch explizit getLastError() aufrufen, dann ist es wahrscheinlich, dass die Datenbank einen Schreibvorgang ablehnt, z. B. wenn wir insert() mit einer _id einfügen, die möglicherweise ein Duplikat ist.
Ich fürchte, ich kann nicht sagen, ob unsere Sicherungs-/Wiederherstellungsrichtlinie wirksam ist, da wir noch keine Wiederherstellung durchführen mussten. Wir befolgen die MongoDB-Empfehlungen für Backups; @mark-hillick hat diese großartig zusammengefasst. Wir verwenden Replikatsätze, und wir haben MongoDB-Versionen migriert sowie neue Replikatmitglieder eingeführt. Bisher hatten wir keine Ausfallzeit, daher bin ich mir nicht sicher, ob ich zu diesem Punkt gut sprechen kann.
Meiner Erfahrung nach bietet MongoDB also die Speicherung von schemalosen Daten mit einer Reihe von Abfrageprimitiven, die so reichhaltig sind, dass Transaktionen oft durch atomare Operationen ersetzt werden können. Es war schwierig, mehr als 10 Jahre SQL-Erfahrung zu verlernen, aber jedes Problem, auf das ich gestoßen bin, wurde von der Community oder 10gen direkt angegangen. Wir haben keine Daten verloren oder hatten Ausfallzeiten, soweit ich mich erinnern kann.
Um es einfach auszudrücken, MongoDB ist zweifellos das beste Datenspeicher-Ökosystem, das ich je in Bezug auf Abfragen, Wartung, Skalierbarkeit und Zuverlässigkeit verwendet habe. Sofern ich keine Anwendung habe, die so eindeutig relational ist, dass ich guten Gewissens nichts anderes als SQL verwenden könnte, würde ich mich bemühen, MongoDB zu verwenden.
Ich arbeite nicht für 10gen, aber ich bin den Leuten, die es tun, sehr dankbar.
