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


252

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!

Respuestas:


183

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.


16
La afirmación de que NoSQL no admite combinaciones es engañosa. Algunas bases de datos NoSQL son en realidad mucho mejores en combinaciones que las bases de datos relacionales. Algunos no los apoyan en absoluto. Esta respuesta parece ser más sobre MongoDB en particular que sobre NoSQL en general.
Alan Plum

1
Gran resumen @AlanPlum, ¿a qué bases de datos NoSQL específicas se refiere?
Brian

2
@brian Soy colaborador de ArangoDB ( arangodb.com ), que es una combinación de una base de datos de documentos (piense en MongoDB) y una base de datos de gráficos (piense en Neo4J) con no solo combinaciones baratas sino también transacciones reales. Dicho esto, las bases de datos NoSQL no son un grupo homogéneo y es imposible generalizar desde una base de datos NoSQL a toda la "categoría".
Alan Plum

Si considera que está usando RDB porque "las uniones no son compatibles" en NoSQL, le recomiendo que vea este video de AWS re: Invent. ¡Desglosa todo el enfoque NoSQL! Me ayudo mucho. youtu.be/HaEPXoXVf2k
dillon.harless

9

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.


20
No entiendo qué podría ser un problema con RDBMS para el n. ° 2. ¿Y NoSQL tiene menos E / S de disco según # 3?
avi

55
Como dice @avi, creo que no hay problema para el n. ° 2, siempre y cuando consultes las tablas sobre el índice. Millones de hileras? Ok, recupera solo los índices que quiero usar
Xtreme Biker

11
# 2 y 3 son falsos. Para 2, he realizado pruebas de rendimiento en la importación / exportación de datos y he visto que SQL Server 2014 aplastó a Mongo por las grandes importaciones y exportaciones de datos. Para 3, los datos fuertemente tipados en SQL suelen ocupar (he visto más del 50% antes de la compresión) mucho menos espacio que las bases de datos de documentos.
Brian

77
Sí, e incluso para el # 1, simplemente no lo entiendo. Ampliar es parte del contrato de agrupamiento que proponen todos los principales rdbms
Sebas

2
Los tres están mal si tienes dinero ilimitado
Chazt3n
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.