Escenarios de casos de uso de NoSQL o CUÁNDO usar NoSQL

Question

Con todo el bombo, parece realmente difícil encontrar información confiable sobre cuándo usar esto. Así que planteo las siguientes preguntas, y lo siento si estas son realmente preguntas tontas por adelantado:

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

Supongo que no? Y siento que NoSQL es solo para cosas rápidamente accesibles de 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 específicos de uso empresarial en los que utilizaría NoSQL? Veo muchas descripciones generales pero no muchos ejemplos del mundo real. Lo único que se me ocurre es mensajería y análisis de usuario a usuario.

Gracias!

Answer 1

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

• NoSQL suele ser bueno para datos no estructurados/"sin esquema" - por lo general, no se necesitan para definir explícitamente el esquema en la delantera y solo pueden incluir nuevos campos sin ninguna ceremonia
• NoSQL normalmente favorece un esquema denormalizado debido a que no admite JOINs por el mundo RDBMS. Por lo tanto, normalmente tendrías una representación aplanada y desnormalizada de tus datos.
• El uso de NoSQL no significa que pueda perder datos. Diferentes DB tienen diferentes estrategias. p.ej. MongoDB: básicamente puede elegir qué nivel intercambiar el rendimiento frente a la posibilidad de pérdida de datos; el 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 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 deja de funcionar. Pero, de nuevo, depende de la configuración/DB NoSQL. NoSQL no significa necesariamente "pérdida de datos" como usted deduce.
• En mi humilde opinión, las consultas/informes complejos/dinámicos se realizan mejor desde un RDBMS. A menudo, la funcionalidad de consulta para un DB NoSQL es limitada.
• No tiene que ser una 1 o la otra opción. Mi experiencia ha sido el uso de RDBMS junto con NoSQL para ciertos casos de uso.
• Los DB NoSQL a menudo carecen de la capacidad de realizar operaciones atómicas en múltiples "tablas".

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

Para MongoDb como ejemplo, revisa su Use Cases para ver lo que sugieren como usos "bien adaptados" y "menos adecuados" de MongoDb.

Answer 2

creo NoSQL es "más adecuada" en estos escenarios por lo menos (más adicional es bienvenido)

1. fácil de escalar con sólo añadir más nodos.

2. consulta en grandes conjuntos de datos

   Imagínese 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 directas sobre esas tablas, ni siquiera mencionar, la mayoría de las veces, las uniones de tablas también son necesarias para consultas complejas.

3. /S de disco cuello de botella

   Si un sitio web tiene que enviar los resultados a los diferentes usuarios sobre la base de información en tiempo real de los usuarios, es probable que estemos hablando de decenas o cientos de miles de SQL solicitudes de lectura/escritura por segundo. Entonces disco i/o será un serio cuello de botella.