Så for at svare direkte på spørgsmålene...
Skemaløs lagring er bestemt en overbevisende grund til at gå med MongoDB, men som du har påpeget, er det også ret nemt at gemme JSON i en RDBMS. Styrken bag MongoDB ligger i de rige forespørgsler mod skemaløs lagring.
Hvis jeg må påpege en lille fejl i illustrationen om opdatering af et JSON-felt, er det ikke blot et spørgsmål om at få den aktuelle værdi, opdatere dokumentet og derefter skubbe det tilbage til databasen. Processen skal alle være pakket ind i en transaktion. Transaktioner plejer at være ret ligetil, indtil du begynder at denormalisere din database. Så kan noget så simpelt som at registrere en upvote låse tabeller over hele dit skema.
Med MongoDB er der ingen transaktioner. Men operationer kan næsten altid struktureres på en måde, der giver mulighed for atomare opdateringer. Dette involverer normalt nogle dramatiske skift fra SQL-paradigmerne, men efter min mening er de ret indlysende, når du stopper med at prøve at tvinge objekter ind i tabeller. I det mindste er masser af andre mennesker løbet ind i de samme problemer, som du vil stå over for, og Mongo-samfundet har en tendens til at være ret åbent og højtråbende omkring de udfordringer, de har overvundet.
Med "sikker skrivning" antager jeg, at du mener muligheden for at aktivere en automatisk "getLastError()" efter hver skrivning. Vi har en meget tynd indpakning over en DBCollection, der giver os mulighed for finkornet kontrol over, hvornår getLastError() kaldes. Vores politik er dog ikke baseret på, hvor "vigtige" data er, men snarere om koden efter forespørgslen forventer, at eventuelle ændringer er umiddelbart synlige i de følgende læsninger.
Generelt er dette stadig en dårlig indikator, og vi har i stedet migreret til findAndModify() for den samme adfærd. I den anledning, hvor vi stadig eksplicit kalder getLastError(), er det, når databasen sandsynligvis vil afvise en skrivning, såsom når vi indsætter() med et _id, der kan være en duplikat.
Jeg er bange for, at jeg ikke kan udtale mig om, hvorvidt vores sikkerhedskopierings-/gendannelsespolitik er effektiv, da vi ikke har skullet gendanne endnu. Vi følger MongoDB anbefalingerne for sikkerhedskopiering; @mark-hillick har gjort et godt stykke arbejde med at opsummere dem. Vi bruger replikasæt, og vi har migreret MongoDB-versioner samt introduceret nye replikamedlemmer. Indtil videre har vi ikke haft nogen nedetid, så jeg er ikke sikker på, at jeg kan tale godt til dette punkt.
Så efter min erfaring tilbyder MongoDB lagring af skemaløse data med et sæt forespørgselsprimitiver, der er rige nok til, at transaktioner ofte kan erstattes af atomoperationer. Det har været svært at aflære mere end 10 års SQL-erfaring, men alle problemer, jeg er stødt på, er blevet løst af fællesskabet eller 10gen direkte. Vi har ikke mistet data eller haft nogen nedetid, som jeg kan huske.
For at sige det enkelt er MongoDB uden tvivl det bedste datalagringsøkosystem, jeg nogensinde har brugt med hensyn til forespørgsler, vedligeholdelse, skalerbarhed og pålidelighed. Medmindre jeg havde en applikation, der var så tydeligt relationel, at jeg ikke med god samvittighed kunne bruge andet end SQL, ville jeg gøre alt for at bruge MongoDB.
Jeg arbejder ikke for 10gen, men jeg er meget taknemmelig for de folk, der gør.