-
Muchos escritores dispares. Especialmente cuando los escritores pueden segmentarse debido a desconexiones en la red y más tarde necesitarán resincronizar los datos que se han escrito en ambos lados de la bifurcación. Esto rompe ACID y, si bien puede resolver el problema con una lógica comercial explícita, ahora se encuentra en territorio NoSQL. Esto es muy común en situaciones militares, pero cualquier sistema en el que todos sean escritores prolíficos tendrá algún bloqueo de contención de escritura en un sistema ACID.
-
Esquemas fluidos. Cambiar un esquema en una base de datos tradicional es una operación costosa que a menudo requiere algún tipo de tiempo de inactividad del servidor u otros procesos complicados. Con la mayoría de los sistemas NoSQL es trivial. Entonces, si tiene datos de muchas fuentes dispares para fusionar y/o tiene situaciones en las que puede querer comenzar a rastrear nueva información en una fecha posterior, los sistemas NoSQL serán mucho más fáciles de manejar. La combinación de dos fuentes de datos para que se puedan graficar entre sí es un buen ejemplo que se me ocurre.
-
Replicación de bajo ancho de banda. Una vez que haya roto ACID, puede tener lectores y escritores en los nodos de hoja de un gráfico de red con datos parciales que no necesitan réplicas completas de la base de datos. El producto de mi propia compañía, el Puesto de Mando del Futuro del Ejército usa esto.
-
Interoperabilidad de datos. La mayoría de las bases de datos NoSQL le permiten realizar una introspección de los datos sin conocer el esquema de antemano, lo que facilita las conexiones entre sistemas dispares.
-
Escalado masivo. Este es el que se debate con mayor frecuencia y los defensores de NoSQL abusan con mayor frecuencia. Si esta es la única razón por la que elige NoSQL, comience con MySQL y escale más tarde.
