Entonces, para responder directamente a las preguntas...
El almacenamiento sin esquema es sin duda una razón convincente para elegir MongoDB, pero como ha señalado, también es bastante fácil almacenar JSON en un RDBMS. El poder detrás de MongoDB está en las consultas enriquecidas contra el almacenamiento sin esquema.
Si pudiera señalar una pequeña falla en la ilustración sobre la actualización de un campo JSON, no se trata simplemente de obtener el valor actual, actualizar el documento y luego enviarlo de vuelta a la base de datos. Todo el proceso debe estar envuelto en una transacción. Las transacciones tienden a ser bastante sencillas, hasta que comienza a desnormalizar su base de datos. Luego, algo tan simple como registrar un voto a favor puede bloquear tablas en todo su esquema.
Con MongoDB, no hay transacciones. Pero las operaciones casi siempre se pueden estructurar de manera que permitan actualizaciones atómicas. Esto generalmente implica algunos cambios drásticos de los paradigmas de SQL, pero en mi opinión, son bastante obvios una vez que dejas de intentar forzar objetos en las tablas. Como mínimo, muchas otras personas se han encontrado con los mismos problemas que usted enfrentará, y la comunidad de Mongo tiende a ser bastante abierta y expresa los desafíos que han superado.
Por "escrituras seguras" asumo que te refieres a la opción de activar un "getLastError()" automático después de cada escritura. Tenemos un envoltorio muy delgado sobre DBCollection que nos permite un control detallado sobre cuándo se llama a getLastError(). Sin embargo, nuestra política no se basa en qué tan "importantes" son los datos, sino en si el código que sigue a la consulta espera modificaciones para ser visibles inmediatamente en las siguientes lecturas.
En términos generales, este sigue siendo un indicador deficiente y, en cambio, migramos a findAndModify() para obtener el mismo comportamiento. En la ocasión en la que seguimos llamando explícitamente a getLastError() es cuando es probable que la base de datos rechace una escritura, como cuando insertamos() con un _id que puede ser un duplicado.
Me temo que no puedo hablar sobre si nuestra política de respaldo/restauración es efectiva ya que aún no hemos tenido que restaurar. Estamos siguiendo las recomendaciones de MongoDB para realizar copias de seguridad; @mark-hillick ha hecho un gran trabajo al resumirlos. Estamos utilizando conjuntos de réplicas, hemos migrado versiones de MongoDB y hemos introducido nuevos miembros de réplica. Hasta ahora no hemos tenido tiempo de inactividad, por lo que no estoy seguro de poder hablar bien hasta este punto.
Entonces, en mi experiencia, MongoDB ofrece almacenamiento de datos sin esquema con un conjunto de primitivas de consulta lo suficientemente ricas como para que las transacciones a menudo puedan reemplazarse por operaciones atómicas. Ha sido difícil desaprender más de 10 años de experiencia en SQL, pero todos los problemas que he encontrado han sido abordados por la comunidad o 10gen directamente. No hemos perdido datos ni hemos tenido ningún tiempo de inactividad que yo pueda recordar.
En pocas palabras, MongoDB es sin duda el mejor ecosistema de almacenamiento de datos que he usado en términos de consultas, mantenimiento, escalabilidad y confiabilidad. A menos que tuviera una aplicación que fuera tan claramente relacional que no pudiera en conciencia usar otra cosa que no sea SQL, haría todo lo posible por usar MongoDB.
No trabajo para 10gen, pero estoy muy agradecido con las personas que lo hacen.
