Så, för att direkt svara på frågorna...
Schemalös lagring är verkligen en övertygande anledning att gå med MongoDB, men som du har påpekat är det ganska enkelt att lagra JSON i en RDBMS också. Kraften bakom MongoDB ligger i de rika frågorna mot schemalös lagring.
Om jag får påpeka ett litet fel i illustrationen om att uppdatera ett JSON-fält, så handlar det inte bara om att hämta det aktuella värdet, uppdatera dokumentet och sedan skjuta tillbaka det till databasen. Processen måste alla vara insvept i en transaktion. Transaktioner tenderar att vara ganska enkla, tills du börjar avnormalisera din databas. Då kan något så enkelt som att spela in en uppröst låsa tabeller över hela ditt schema.
Med MongoDB finns det inga transaktioner. Men verksamheten kan nästan alltid struktureras på ett sätt som tillåter atomära uppdateringar. Detta innebär vanligtvis några dramatiska förändringar från SQL-paradigmen, men enligt min mening är de ganska uppenbara när du slutar försöka tvinga in objekt i tabeller. Åtminstone har många andra människor stött på samma problem som du kommer att ställas inför, och Mongo-gemenskapen tenderar att vara ganska öppen och högljudd om de utmaningar de har övervunnit.
Med "säkra skrivningar" antar jag att du menar alternativet att aktivera en automatisk "getLastError()" efter varje skrivning. Vi har ett mycket tunt omslag över en DBCollection som tillåter oss finkornig kontroll över när getLastError() anropas. Vår policy är dock inte baserad på hur "viktig" data är, utan snarare huruvida koden efter frågan förväntar sig att några ändringar ska synas omedelbart i följande läsningar.
Generellt sett är detta fortfarande en dålig indikator, och vi har istället migrerat till findAndModify() för samma beteende. Vid det tillfälle då vi fortfarande uttryckligen anropar getLastError() är det när databasen sannolikt kommer att avvisa en skrivning, till exempel när vi infogar() med ett _id som kan vara en dubblett.
Jag är rädd att jag inte kan tala om huruvida vår policy för säkerhetskopiering/återställning är effektiv eftersom vi inte har behövt återställa ännu. Vi följer MongoDB-rekommendationerna för säkerhetskopiering; @mark-hillick har gjort ett bra jobb med att sammanfatta dessa. Vi använder replikuppsättningar och vi har migrerat MongoDB-versioner samt introducerat nya replikmedlemmar. Hittills har vi inte haft några driftstopp, så jag är inte säker på att jag kan tala bra till den här punkten.
Så enligt min erfarenhet erbjuder MongoDB lagring av schemalösa data med en uppsättning frågeprimitiver som är tillräckligt rika för att transaktioner ofta kan ersättas av atomära operationer. Det har varit svårt att lära sig mer än 10 års SQL-erfarenhet, men alla problem jag har stött på har åtgärdats av communityn eller 10gen direkt. Vi har inte förlorat data eller haft någon driftstopp som jag kan komma ihåg.
För att uttrycka det enkelt, MongoDB är utan tvekan det bästa datalagringsekosystemet jag någonsin har använt när det gäller frågor, underhåll, skalbarhet och tillförlitlighet. Om jag inte hade en applikation som var så tydligt relationell att jag inte med gott samvete kunde använda något annat än SQL, skulle jag anstränga mig för att använda MongoDB.
Jag jobbar inte för 10gen, men jag är väldigt tacksam för de som gör det.