Usando MongoDB per un'applicazione non scalabile?

Sì, la tua comprensione è corretta.

Se si eseguono più modifiche allo stesso documento in un'unica operazione, si tratterà di un processo atomico. Ma quando un'operazione influisce su più documenti, non vi è alcuna garanzia che eventuali query intermedie non restituiscano parzialmente i documenti prima dell'operazione e parzialmente i documenti dopo l'operazione.

I documenti nidificati di MongoDB incoraggiano a mettere i dati in un singolo documento che verrebbe distribuito su più righe di più tabelle in un database relazionale. Ciò significa che tali operazioni non sono così comuni come lo sono nei database relazionali. Ma se si verificano e la coerenza è importante, puoi gestirli con un bifase . Questa è una brutta soluzione, ma può funzionare se non hai altro modo.

Il tuo unico (main - post edit) plus per mongo sembra essere "Quindi gli sviluppatori di applicazioni possono iniziare subito a scrivere il codice"

Ma questo deve essere causato dalle attuali pratiche di sviluppo piuttosto che dalla tecnologia. Posso creare quelle tabelle in mssql altrettanto velocemente come in mongoDb.

Suppongo che nel tuo lavoro RDBMS devi trasferire il lavoro a un team DBA e aspettare che lo facciano?

Il problema è che non avere uno schema forzato non ti libera dal compito di progettare come archiviare i tuoi dati. In effetti potrebbe persino complicarlo se apporti modifiche in seguito e poi devi preoccuparti degli indirizzi v1 e v2, per esempio.

In RDBMS , its kind of we make the policy , review it upfront and then every one follow it. If we want to change that policy, its bit difficult. In Mongo like DB, you don't have policy in place, but you have to decide some informal contract and rely that every one follow it.

Penso che questa visione della differenza non rappresenti ciò che effettivamente fanno i DBMS. Un DBMS non è semplicemente un fornitore stupido di (purtroppo necessario) servizi di storage per i programmatori front-end, che possono essere valutati in base a quanto ottiene in termini di modo di fare le cose.

Per prima cosa, i sistemi di database possono anche implementare le regole aziendali; e se una regola aziendale si basa sul superamento di molti dati, l'RDBMS è un buon posto per implementarlo.

Un progetto di database realizzato in un RDBMS funge anche da dichiarazione esplicita di impegno per un particolare modello di dati. Un "contratto" informale non può mai avere lo stesso potere universale di applicazione.

Ho la sensazione che gran parte dell'hype sulle alternative agli RDBMS (a parte la questione della scalabilità, in cui i vantaggi sembrano essere genuini) nasce dal disagio con questa idea di seguire le regole applicate su come i dati vengono archiviati. Ma quel disagio, e (a mio parere) tentativi maliziosi di esserne liberati, manca alcuni punti molto importanti:

1. Gli RDBMS sono una tecnica ingegneristica molto matura. Sebbene la struttura di un database possa sembrare statica e non modificabile, un database normalizzato ben progettato ha già la possibilità di modificare il modello (o di migrare i dati), attraverso la sua adesione alle regole di normalizzazione.
2. Correlato a questo: i fautori di altri tipi di database sembrano sovente stimare eccessivamente la difficoltà di impostare o modificare un modello di database RDBMS. Non è così difficile come è presentato. Le difficoltà che sono intrinseche in esso sono inerenti a qualsiasi sistema di archiviazione che deve gestire sia i dati nuovi che quelli precedenti: non esiste un percorso di fuga NoSQL qui.
3. I vincoli imposti da un particolare design RDB non sono necessariamente arbitrari e ingombranti. Un progetto di database può essere così com'è a causa dei reali requisiti aziendali. O perché fornisce il modo più efficiente per archiviare, elaborare e riepilogare grandi quantità di dati.

Nulla di ciò dovrebbe essere preso nel senso che MongoDB non è una soluzione eccellente per determinati scopi. Penso solo che sia spesso la soluzione migliore, senza una chiara comprensione di quali siano questi scopi e con una visione altamente distorta dell'utilità degli RDBMS.