ventajas - when use nosql databases

NoSQL Use Case Scenarios o CUÁNDO usar NoSQL (2)

Creo que Nosql es "más adecuado" en estos escenarios por lo menos (más información adicional es bienvenida)

Fácil de escalar simplemente añadiendo más nodos.
Consulta sobre conjunto de datos de gran tamaño.
Imagina toneladas de tweets publicados en twitter todos los días. En RDMS, podría haber tablas con millones (¿o miles de millones?) De filas, y no desea hacer consultas en esas tablas directamente, ni siquiera mencionar, la mayoría de las veces, las combinaciones de tablas también son necesarias para consultas complejas.
Cuello de botella en la E / S del disco
Si un sitio web necesita enviar resultados a diferentes usuarios según la información en tiempo real de los usuarios, probablemente estamos hablando de decenas o cientos de miles de solicitudes de lectura / escritura de SQL por segundo. Entonces el disco I / O será un grave cuello de botella.

Con todo el bombo, parece muy difícil encontrar información confiable sobre cuándo usar esto. Así que planteo las siguientes preguntas, y lamento que estas sean preguntas realmente tontas de antemano:

¿Debo usar NoSQL para datos de usuario? Por ejemplo, perfiles, nombres de usuario + contraseñas, etc.
¿Debo usar NoSQL para contenido importante? Por ejemplo, artículos, publicaciones en blogs, inventario de productos, etc.

Estoy suponiendo que no hay? Y siento que NoSQL es solo para cosas rápidamente accesibles de las que está bien perder datos. Pero también leí que las aplicaciones NoSQL tienen redundancia incorporada para que no pierda datos.

Además, si los 2 ejemplos anteriores son malos, ¿podría darme casos de uso empresarial específicos en los que usaría NoSQL? Veo muchas descripciones generales pero no muchos ejemplos del mundo real. Las únicas cosas en las que puedo pensar son los mensajes y el análisis de usuario a usuario.

¡Gracias!

Realmente es una pregunta "depende". Algunos puntos generales :

Por lo general, NoSQL es bueno para datos no estructurados / "sin esquemas"; por lo general, no es necesario que defina explícitamente su esquema por adelantado y puede incluir nuevos campos sin ninguna ceremonia.
Por lo general, NoSQL favorece un esquema desnormalizado debido a que no admite JOIN en el mundo RDBMS. Por lo tanto, normalmente tendrá una representación plana y desnormalizada de sus datos.
Usar NoSQL no significa que pueda perder datos. DBs diferentes tienen diferentes estrategias. por ejemplo, MongoDB: básicamente puede elegir qué nivel cambiará el rendimiento frente al potencial de pérdida de datos; mejor rendimiento = mayor alcance para la pérdida de datos.
A menudo es muy fácil escalar las soluciones NoSQL. Agregar más nodos para replicar los datos es una forma de a) ofrecer más escalabilidad yb) ofrecer más protección contra la pérdida de datos si un nodo falla. Pero nuevamente, depende de la base de datos NoSQL / configuración. NoSQL no significa necesariamente "pérdida de datos" como infiere.
En mi humilde opinión, las consultas / informes complejos / dinámicos se atienden mejor desde un RDBMS. A menudo, la funcionalidad de consulta para un DB NoSQL es limitada.
No tiene que ser un 1 o la otra opción. Mi experiencia ha estado usando RDBMS junto con NoSQL para ciertos casos de uso.
Los DB de NoSQL a menudo carecen de la capacidad de realizar operaciones atómicas en múltiples "tablas".

Realmente necesita ver y comprender qué son los distintos tipos de almacenes NoSQL, y cómo hacen para proporcionar escalabilidad / seguridad de datos, etc. Es difícil dar una respuesta general, ya que realmente son diferentes y abordan las cosas de manera diferente. .

Para MongoDb como ejemplo, revise sus Casos de uso para ver lo que sugieren como usos "adecuados" y "menos adecuados" de MongoDb.