Escenarios de casos de uso de NoSQL o CUANDO usar NoSQL [cerrado]

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

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

Estoy asumiendo que no? Y siento que NoSQL es solo para cosas de acceso rápido desde las cuales 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 comercial específicos en los que usaría NoSQL? Veo muchas descripciones generales pero no muchos ejemplos del mundo real. Lo único que se me ocurre son los mensajes y análisis de usuario a usuario.

¡Gracias!

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

• NoSQL suele ser bueno para datos no estructurados / "sin esquema"; por lo general, no necesita definir explícitamente su esquema por adelantado y puede incluir nuevos campos sin ninguna ceremonia.
• NoSQL generalmente favorece un esquema desnormalizado debido a que no es compatible con JOINs en el mundo RDBMS. Por lo tanto, normalmente tendría una representación aplanada y desnormalizada de sus datos.
• Usar NoSQL no significa que pueda perder datos. Diferentes bases de datos tienen diferentes estrategias. Por ejemplo, MongoDB: puede elegir esencialmente qué nivel intercambiar el rendimiento frente al potencial de pérdida de datos: el mejor rendimiento = mayor alcance para la pérdida de datos.
• A menudo es muy fácil escalar soluciones NoSQL. Agregar más nodos para replicar 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 se cae. Pero, de nuevo, depende de la configuración / DB NoSQL. NoSQL no significa necesariamente "pérdida de datos" como usted 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 sido usar RDBMS junto con NoSQL para ciertos casos de uso.
• Las bases de datos NoSQL a menudo carecen de la capacidad de realizar operaciones atómicas en varias "tablas".

Realmente necesita ver y comprender cuáles son los diversos tipos de almacenes NoSQL y cómo proporcionan escalabilidad / seguridad de datos, etc. Es difícil dar una respuesta general, ya que realmente son todos diferentes y abordan las cosas de manera diferente .

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

Creo que Nosql es "más adecuado" en estos escenarios al menos (más complementario es bienvenido)

1. Fácil de escalar horizontalmente simplemente agregando más nodos.

2. Consulta en conjunto de datos grande

   Imagine 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 consultar directamente en esas tablas, sin mencionar, la mayoría de las veces, las uniones de tabla también son necesarias para consultas complejas.

3. Cuello de botella de E / S de disco

   Si un sitio web necesita enviar resultados a diferentes usuarios en función de 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 la E / S del disco será un serio cuello de botella.