Dus, om de vragen direct te beantwoorden...
Schemaloze opslag is zeker een dwingende reden om met MongoDB te werken, maar zoals je hebt opgemerkt, is het vrij eenvoudig om JSON ook in een RDBMS op te slaan. De kracht achter MongoDB zit in de uitgebreide query's tegen schemaloze opslag.
Als ik een kleine fout in de illustratie over het updaten van een JSON-veld mag aanwijzen, is het niet alleen een kwestie van de huidige waarde ophalen, het document bijwerken en het dan terugzetten naar de database. Het proces moet allemaal verpakt zijn in een transactie. Transacties zijn meestal vrij eenvoudig, totdat u begint met het denormaliseren van uw database. Dan kan zoiets eenvoudigs als het opnemen van een upvote tabellen in uw hele schema vergrendelen.
Met MongoDB zijn er geen transacties. Maar operaties kunnen bijna altijd zo worden gestructureerd dat atomaire updates mogelijk zijn. Dit brengt meestal enkele dramatische verschuivingen met zich mee van de SQL-paradigma's, maar naar mijn mening zijn ze vrij duidelijk als je stopt met proberen objecten in tabellen te forceren. Op zijn minst zijn veel andere mensen tegen dezelfde problemen aangelopen als jij, en de Mongo-gemeenschap is meestal vrij open en vocaal over de uitdagingen die ze hebben overwonnen.
Met "veilig schrijven" neem ik aan dat je de optie bedoelt om na elke schrijfactie een automatische "getLastError()" in te schakelen. We hebben een zeer dunne wrapper over een DBCollection waarmee we fijnmazige controle hebben over wanneer getLastError() wordt aangeroepen. Ons beleid is echter niet gebaseerd op hoe "belangrijk" gegevens zijn, maar eerder op de vraag of de code die op de zoekopdracht volgt, verwacht dat eventuele wijzigingen onmiddellijk zichtbaar zijn in de volgende tekst.
Over het algemeen is dit nog steeds een slechte indicator en zijn we in plaats daarvan gemigreerd naar findAndModify() voor hetzelfde gedrag. Als we getLastError() nog steeds expliciet aanroepen, is het waarschijnlijk dat de database een schrijfactie weigert, zoals wanneer we invoegen() met een _id die een duplicaat kan zijn.
Ik ben bang dat ik niet kan zeggen of ons back-up/herstelbeleid effectief is, omdat we nog niet hebben hoeven herstellen. We volgen de MongoDB-aanbevelingen voor het maken van back-ups; @mark-hillick heeft deze uitstekend samengevat. We gebruiken replicasets en we hebben MongoDB-versies gemigreerd en nieuwe replicaleden geïntroduceerd. Tot nu toe hebben we geen downtime gehad, dus ik weet niet zeker of ik op dit punt goed kan praten.
Dus, in mijn ervaring, biedt MongoDB opslag van schemaloze gegevens met een set query-primitieven die zo rijk zijn dat transacties vaak kunnen worden vervangen door atomaire bewerkingen. Het was moeilijk om meer dan 10 jaar SQL-ervaring af te leren, maar elk probleem dat ik ben tegengekomen, is door de gemeenschap of 10gen rechtstreeks aangepakt. We zijn geen gegevens kwijtgeraakt of hebben geen downtime gehad voor zover ik me kan herinneren.
Simpel gezegd, MongoDB is zonder twijfel het beste ecosysteem voor gegevensopslag dat ik ooit heb gebruikt op het gebied van query's, onderhoud, schaalbaarheid en betrouwbaarheid. Tenzij ik een applicatie had die zo duidelijk relationeel was dat ik naar eer en geweten niets anders dan SQL kon gebruiken, zou ik er alles aan doen om MongoDB te gebruiken.
Ik werk niet voor 10gen, maar ik ben erg dankbaar voor de mensen die dat wel doen.