¿Cuáles son algunos casos de uso real para ir con una tienda de documentos NoSQL DB?

Question

He estado leyendo documentación y viendo screencasts específicos de Mongo DB en los últimos días y no tengo pérdida para cuando una solución como esta sería mejor que un entorno típico de PG o MySQL.

Específicamente, mi pregunta es en qué circunstancia (con el caso de uso sería bueno) ¿querría seguir la ruta NoSQL?

¡Gracias!

Answer 1

1. Muchos escritores dispares. Especialmente cuando los escritores pueden segmentarse debido a las desconexiones en la red, y luego necesitará resincar los datos que se han escrito en ambos lados de la bifurcación. Esto rompe el ácido, y aunque puede resolver el problema con la lógica comercial explícita, ahora está en el territorio NoSQL. Esto es muy común en situaciones militares, pero cualquier sistema en el que todos sean un escritor prolífico tendrá un bloqueo de contención de escritura en un sistema ácido.

2. Esquemas de fluido. Cambiar un esquema en un DB 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 tener situaciones en las que desee comenzar a rastrear nueva información en una fecha posterior, los sistemas NoSQL serán mucho más fáciles de tratar. Fusionar dos fuentes de datos para que puedan ser trazadas entre sí es un buen ejemplo en el que puedo pensar.

3. Replicación de bajo ancho de banda. Una vez que haya roto el ácido, puede tener lectores y escritores en 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 empresa, el puesto de mando del Ejército del futuro usa esto.

4. Interoperabilidad de datos. La mayoría de las bases de datos NoSQL le permiten introspectar los datos sin conocer el esquema con anticipación, lo que permite que las conexiones entre los sistemas dispares sean más fáciles.

5. Escala masiva. Este es el que más a menudo es debatido, y con mayor frecuencia abusado por los proponentes de NoSQL. Si esta es la única razón por la que está eligiendo NoSQL, comience con MySQL en su lugar y escala más tarde.

Answer 2

Caso de uso
Utilizamos MongoDB para una estructura de datos extremadamente transitoria a gran escala. En efecto, funciona como un rastreador / gerente de trabajo con muchas unidades de trabajo procesadas cada segundo. La unidad de trabajo no tiene un esquema definido (se inventan diferentes unidades con cierta frecuencia), sin embargo, necesitamos tener la capacidad de consultar campos o propiedades específicos sin iterar en todo el DB. Por lo tanto, para resumir: altamente transitorio, altamente disponible (no puede permitirse el lujo de bloquear una consulta) con una carga de trabajo de aproximadamente 600QP para una sola máquina "mercancía" que se ejecuta en la nube.

El hecho es que es extremadamente difícil hacer lo mismo en una máquina SQL mientras mantiene los mismos costos.

Otros casos de uso populares para MongoDB (también para nosotros) son la recopilación estadística, es extremadamente eficiente para incrementar propiedades específicas dentro de documentos, mucho más que la mayoría de los sistemas RDBMS.

Una vez más, no es que sea imposible hacerlo en MySQL, es más costoso y lleva más tiempo (más habilidad), lo que para una pequeña empresa o un entorno de desarrollo rápido significa que no se puede hacer.

Answer 3

Algunas API REST devuelven los datos JSON (por ejemplo, muchos de los API de datos abiertos del gobierno). Si desea volcar los datos de descanso a un almacén de datos local (en caso de que necesite ejecutar el análisis, etc.), ingerir un objeto JSON con MongoDB es trivial. No es necesario definir un esquema de tabla. Aún mejor, si el objeto JSON cambia con el tiempo (por ejemplo, la API REST devuelve campos adicionales), aún puede ingerir los datos en un solo paso. ¡Prueba eso con una base de datos relacional!