Casos de uso para NoSQL [cerrado]


144

NoSQL ha recibido mucha atención en nuestra industria recientemente. Estoy realmente interesado en lo que piensa la gente sobre los mejores casos de uso para su uso sobre el almacenamiento de bases de datos relacionales. Lo que debería hacer que un desarrollador piense que determinados conjuntos de datos son más adecuados para una solución NoSQL. Estoy particularmente interesado en MongoDB y CouchDB, ya que parecen estar obteniendo la mayor cobertura con respecto al desarrollo de PHP y ese es mi enfoque.


66
Cassandra y MongoDB son productos completamente diferentes, categorías completamente diferentes . Esta pregunta sería más fácil de responder si se tratara de casos de uso para un tipo específico de base de datos (OODB, DODB, DKVS, etc.) "NoSQL" es solo un término general para "cualquier cosa que no sea SQL" - podría podría ser algo así como BerkleyDB o un montón de archivos planos en un recurso compartido de red.
Aaronaught

@Aaronaught aprecio las diferencias, creo que soy culpable de usar un término general con nosql
robjmills

Respuestas:


86

Solo prométete que nunca intentarás asignar un modelo de datos relacionales a una base de datos NoSQL como MongoDB o CouchDB ... Este es el error más común que cometen los desarrolladores al evaluar la tecnología emergente.

Ese enfoque es análogo a tomar un automóvil e intentar usarlo para tirar de su carro como un caballo.

Es una reacción natural debido a la experiencia de todos, por supuesto, pero el valor real de usar una base de datos de documentos es poder simplificar su modelo de datos y minimizar su sufrimiento como desarrollador. Su base de código se reducirá, sus errores serán menos y más fáciles de encontrar, el rendimiento será increíble y la escala será mucho más simple.

Como fundador de Joomla, soy parcial :-) pero viniendo del espacio CMS, algo así como MongoDB es una viñeta plateada, ya que el contenido se asigna muy naturalmente a los sistemas de documentos.

Otro gran caso para MongoDB es el análisis en tiempo real, ya que MongoDB tiene un rendimiento y una escala muy sólidos, especialmente en lo que respecta a la concurrencia. Hay estudios de casos en el sitio web MongoDB.org que demuestran esos atributos.

Estoy de acuerdo con la idea de que cada base de datos tiene sus propios objetivos y casos de uso; tome el propósito de cada base de datos para su evaluación en consecuencia.


1
realmente bien dicho spacemonkey, estoy en la misma posición que seengee, claramente debemos pensar de una manera nueva y deberíamos preguntarnos cómo estructurar los datos de mis aplicaciones en una estructura de documentos, eliminándonos de la forma de pensar RDBMS cuando lo hacemos este análisis
on_



8

Lo que me gusta de NoSQL no tiene nada que ver con el rendimiento y todo con la usabilidad. Es más fácil trabajar con los almacenes de documentos cuando sus unidades de datos atómicos son como documentos, porque es trivial serializar hacia y desde los objetos. Es simplemente más divertido, y ese es un factor importante para proyectos personales o secundarios.


1
No diría exactamente que es trivial , pero este es un buen punto sobre las bases de datos orientadas a documentos. Lo contrario es realmente cierto para algunos otros productos NoSQL: los DKVS tienden a ser más difíciles de mapear que SQL / DB relacionales.
Aaronaught

8

He estado usando NoSQL DB por un tiempo, y esta es mi contribución al tema:

Un gran caso de uso para una base de datos NoSQL es una aplicación para la generación de estadísticas y / o informes , especialmente cuando los datos provienen de una fuente de terceros.

En una situación como esa, una base de datos NoSQL puede ser un gran opción

Consideremos, por ejemplo, MongoDB :

Una vez que tenga sus datos en JSON, (podría provenir de una API de terceros o exportarse desde una aplicación SQL) en MongoDB es bastante sencillo importar y actualizar los datos JSON en la base de datos; por ejemplo usando la mongoimportutilidad de línea de comandos

En este punto es muy simple construir consultas dinámicas con filtrado y agrupación, que encajan bien con este tipo de aplicación.

Por ejemplo, usando el Marco de agregación :

$pipeline = [];

//filter by date
$pipeline[] = [ '$match' => [ 'created_at' => [ '$gte' => $starDate, '$lte' => $endDate ]  ]  ];

//if we want to filter by a specific field, we add the filter to the pipeline array
if( $filters->isFilterByField() )
    $pipeline[] = [ '$match' => [ 'field' => $fieldValue ] ];    

//group the results by date and get the count
$pipeline[] = [ '$group' => [ '_id' => '$created_at', 'num_elements' => [ '$sum' => 1 ] ] ];

return $collection->aggretate( $pipeline );

Me gustaría señalar la facilidad con la que podemos agregar / quitar filtros dinámicamente usando estructuras de datos php y evitando la tediosa concatenación de cadenas para construir nuestras consultas. Con este enfoque, agregar / eliminar filtros dinamycally es tan fácil como agregar / eliminar elementos de una matriz

Otro gran beneficio proviene del hecho de que una solución como esta es probable que sea más rápida que usar una base de datos relacional , donde tenemos que hacer uniones con diferentes tablas para obtener todos los datos que necesitamos

Además, este caso de uso es óptimo porque evita todos los límites principales de una base de datos NoSQL:

  • Falta de transacciones: la aplicación no realiza escrituras sino solo lecturas, por lo que no necesitamos transacciones

  • Falta de uniones entre tablas: no necesitamos uniones, ya que podemos usar la redundancia para almacenar nuestros datos desnormalizados en las colecciones. Como solo leemos datos, no debemos preocuparnos por sincronizar datos desnormalizados entre actualizaciones.

De esta manera, podemos centrarnos en almacenar los datos con redundancia de una manera que se ajuste bien a nuestras consultas , que se centrará en colecciones individuales.

Solo estoy escribiendo esto porque si hubiera leído algo así hace algunas veces, me habría ahorrado algo de tiempo hacer investigaciones

Espero que sea útil para alguien


3

Recomiendo esta charla de Martin Fowler:

https://www.youtube.com/watch?v=qI_g07C_Q5I

RESUMEN: Martin ofrece una rápida introducción a las bases de datos NoSQL: de dónde provienen, la naturaleza de los modelos de datos que utilizan y la forma diferente en que debe pensar en la coherencia. A partir de esto, describe qué tipo de circunstancias debería considerar usar, por qué no harán obsoletas las bases de datos relacionales y la importante consecuencia de la persistencia políglota.

Dibuja una buena imagen de lo que es NoSQL, las diferentes categorías y las cosas que todo el mundo tiene que entender cuando proviene del mundo de las bases de datos relacionales. Saludos.


Entendido, lo tendré en cuenta para el futuro.
usuario3631881

3

Primero debe comprender la teoría CAP (consistencia, disponibilidad y particionamiento, donde debe elegir dos de tres) y nuestro caso de uso comercial. MongoDB satisface Consistencia y Particionamiento y Couch DB satisface Disponibilidad y Particionamiento.

Los videos de Edureka en youtube sobre NoSQL son algunos de los mejores videos tutoriales.

https://www.youtube.com/watch?v=gJFG04Sy6NY

https://www.youtube.com/watch?v=KSq6tMMXZ8s

https://www.youtube.com/watch?v=3z1KFA2qcSo

Buenas presentaciones están disponibles en slideshare.net

http://www.slideshare.net/quipo/nosql-databases-why-what-and-when?qid=3bb9f7f6-a53d-41b1-8403-cd6f181d0ca7&v=qf1&b=&from_search=1

http://www.slideshare.net/EdurekaIN/no-sql-databases-35591065?qid=f1b9c095-6d70-4d0a-91da-1df664c4f389&v=qf1&b=&from_search=3 (Esta presentación admite video tutorial en youtube)


1

Para algunos casos de uso que necesita, especialmente para consultas analíticas, puede ejecutar consultas SQL en MongoDB con este contenedor de Postgres.


1

Debido a que ahora hay muchas más bases de datos NoSQL en el mercado que nunca antes, sugiero echar un vistazo al Cuadrante Mágico de Gartner si está buscando una base de datos que también sea ideal para aplicaciones empresariales basadas en soporte, capacidad de expansión, administración y costo.

http://www.gartner.com/technology/reprints.do?id=1-23A415Q&ct=141020&st=sb

Me gustaría sugerir Couchbase a cualquiera que aún no lo haya probado, pero que no se base en la versión que se muestra en el informe (2.5.1) porque hay casi 2 revisiones detrás de donde está CB Server hoy, cerca del lanzamiento de 4.0 en 2H15 .

http://www.couchbase.com/coming-in-couchbase-server-4-0

La otra parte acerca de Couchbase como proveedor / producto es que es un tipo de DB de usos múltiples. Puede actuar como una tienda K / V pura, base de datos orientada a documentos con escalamiento multidimensional, Memcached, almacenamiento en caché con persistencia, y admite SQL compatible con ANSI 92 con uniones automáticas, replicación a clústeres DR con solo presionar un botón, y incluso tiene un componente móvil integrado en el ecosistema.

Por lo menos, vale la pena consultar los últimos puntos de referencia:

http://info.couchbase.com/Benchmark_MongoDB_VS_CouchbaseServer_HPW_BM.html http://info.couchbase.com/NoSQL-Technical-Comparison-Report.html

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.