Casos de uso para NoSQL [cerrado]

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.

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.

En el sitio MongoDB se mencionan algunos casos de uso excelentes, para MongoDB de todos modos. Los ejemplos dados son análisis en tiempo real, registro y búsqueda de texto completo. Todos estos artículos merecen una lectura http://www.mongodb.com/use-cases

También hay una excelente reseña sobre qué base de datos NoSQL se adapta mejor a cada tipo de proyecto: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Sugeriría este artículo de Rick Cattell sobre almacenes de datos diversos (también conocido como NoSQL), sus diferencias y algunos de sus casos de uso: http://www.cattell.net/datastores/index.html

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.

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

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.

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)

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

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