Quindi, per rispondere direttamente alle domande...
L'archiviazione senza schema è sicuramente un motivo convincente per utilizzare MongoDB, ma come hai sottolineato, è anche abbastanza facile archiviare JSON in un RDBMS. Il potere dietro MongoDB è nelle query avanzate contro l'archiviazione senza schema.
Se posso evidenziare un piccolo difetto nell'illustrazione sull'aggiornamento di un campo JSON, non si tratta semplicemente di ottenere il valore corrente, aggiornare il documento e quindi reinserirlo nel database. Il processo deve essere tutto racchiuso in una transazione. Le transazioni tendono ad essere abbastanza semplici, fino a quando non inizi a denormalizzare il tuo database. Quindi qualcosa di semplice come la registrazione di un voto positivo può bloccare le tabelle in tutto il tuo schema.
Con MongoDB non ci sono transazioni. Ma le operazioni possono quasi sempre essere strutturate in modo da consentire aggiornamenti atomici. Questo di solito comporta alcuni cambiamenti drammatici dai paradigmi SQL, ma secondo me sono abbastanza ovvi una volta che si smette di forzare gli oggetti nelle tabelle. Per lo meno, molte altre persone hanno incontrato gli stessi problemi che dovrai affrontare e la comunità di Mongo tende a essere abbastanza aperta e esplicita riguardo alle sfide che ha superato.
Per "scritture sicure" presumo tu intenda l'opzione per attivare un "getLastError()" automatico dopo ogni scrittura. Abbiamo un wrapper molto sottile su una DBCollection che ci consente un controllo granulare quando viene chiamato getLastError(). Tuttavia, la nostra politica non si basa su quanto siano "importanti" i dati, ma piuttosto se il codice che segue la query prevede che eventuali modifiche siano immediatamente visibili nelle letture seguenti.
In generale, questo è ancora un indicatore scadente e abbiamo invece migrato a findAndModify() per lo stesso comportamento. Nell'occasione in cui chiamiamo ancora esplicitamente getLastError() è quando è probabile che il database rifiuti una scrittura, come quando insert() con un _id che potrebbe essere un duplicato.
Temo di non poter parlare se la nostra politica di backup/ripristino sia efficace poiché non abbiamo ancora dovuto eseguire il ripristino. Stiamo seguendo i consigli di MongoDB per il backup; @mark-hillick ha fatto un ottimo lavoro nel riassumerli. Utilizziamo i set di repliche e abbiamo migrato le versioni di MongoDB e abbiamo introdotto nuovi membri di replica. Finora non abbiamo avuto tempi di inattività, quindi non sono sicuro di poter parlare bene fino a questo punto.
Quindi, secondo la mia esperienza, MongoDB offre l'archiviazione di dati senza schema con un insieme di primitive di query abbastanza ricco che le transazioni possono spesso essere sostituite da operazioni atomiche. È stato difficile disimparare oltre 10 anni di esperienza SQL, ma ogni problema che ho riscontrato è stato affrontato dalla community o direttamente da 10gen. Non abbiamo perso dati o avuto tempi di inattività che posso ricordare.
Per dirla semplicemente, MongoDB è senza dubbio il miglior ecosistema di archiviazione dati che abbia mai utilizzato in termini di query, manutenzione, scalabilità e affidabilità. A meno che non avessi un'applicazione così chiaramente relazionale da non poter in buona coscienza usare nient'altro che SQL, farei ogni sforzo per usare MongoDB.
Non lavoro per 10gen, ma sono molto grato per le persone che lo fanno.
