usar - nosql vs sql
Casos de uso para NoSQL (9)
En primer lugar, debe comprender la teoría de CAP (coherencia, disponibilidad y partición, donde debe recoger dos de tres) y nuestro caso de uso comercial. MongoDB cumple con la consistencia y el particionamiento y Couch DB satisface la disponibilidad y el particionamiento.
Los videos de Edureka en youtube con respecto a 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/EdurekaIN/no-sql-databases-35591065?qid=f1b9c095-6d70-4d0a-91da-1df664c4f389&v=qf1&b=&from_search=3 (Esta presentación es compatible con el video tutorial en youtube)
NoSQL ha estado recibiendo mucha atención en nuestra industria recientemente. Estoy realmente interesado en los pensamientos de las personas sobre los mejores casos de uso para su uso sobre el almacenamiento de bases de datos relacionales. Lo que debería inducir a un desarrollador a pensar 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.
Debido a que ahora hay muchas más bases de datos NoSQL en el mercado que nunca, sugiero echarle un vistazo al Magic Quadrant 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 no lo haya probado aún, pero no basado en la versión que se muestra en el informe (2.5.1) porque hay casi 2 revisiones detrás de donde CB Server está hoy, cerca del lanzamiento de 4.0 en 2H15 .
http://www.couchbase.com/coming-in-couchbase-server-4-0
La otra parte sobre Couchbase como proveedor / producto es que es un tipo de DB de usos múltiples. Puede actuar como una tienda de K / V pura, una base de datos orientada a documentos con escalado multidimensional, Memcached, caché a un lado con persistencia y admite SQL compatible con ANSI 92 con uniones automáticas, replicación en clústeres de DR con solo presionar un botón y incluso tiene un componente móvil incorporado en el ecosistema.
Si nada más, vale la pena revisar 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
En el sitio de MongoDB se mencionan algunos casos de uso excelentes, de todos modos para MongoDB. Los ejemplos que se dan son análisis en tiempo real, registro y búsqueda de texto completo. Todos estos artículos merecen la pena leer http://www.mongodb.com/use-cases
También hay un gran resumen sobre qué base de datos NoSQL se adapta mejor a qué tipo de proyecto: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
He estado usando NoSQL DBs desde hace un tiempo, y este es mi aporte 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 externa.
En una situación como esa, una base de datos NoSQL puede ser una gran elección
Consideremos, por ejemplo, MongoDB :
Una vez que tenga sus datos en JSON, (podría provenir de una API de un tercero, o exportarse desde una aplicación sql) en MongoDB es bastante difícil importar y actualizar los datos JSON en la base de datos; por ejemplo, utilizando la utilidad mongoimport línea de comandos
En este punto, es muy simple crear consultas dinámicas con filtrado y agrupamiento, que se ajusten bien a este tipo de aplicaciones.
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 destacar la facilidad con la que podemos agregar / eliminar dinámicamente filtros utilizando estructuras de datos php y evitando la tediosa concatenación de cadenas para construir nuestras consultas. Con este enfoque, agregar / eliminar filtros dinamicamente es tan fácil como agregar / eliminar elementos de una matriz
Otro gran beneficio proviene del hecho de que una solución como esta probablemente sea más rápida que usar una base de datos relacional , donde tenemos que hacer combinaciones 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 que solo lee, por lo que no necesitamos transacciones en absoluto
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 necesitamos preocuparnos por sincronizar datos desnormalizados entre actualizaciones.
De esta forma podemos enfocarnos en almacenar los datos con redundancia de una manera que se adapte bien a nuestras consultas , que se enfocarán en colecciones individuales.
Solo escribo esto porque si hubiera leído algo así hace algún tiempo, me habría ahorrado tiempo para hacer investigaciones
Espero que sea útil para alguien
Lo que me gusta de NoSQL no tiene nada que ver con el rendimiento y todo lo relacionado con la usabilidad. Las tiendas de documentos son simplemente más fáciles de usar cuando sus unidades de datos atómicos son similares a 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.
Para algunos casos de uso que necesite, especialmente para consultas analíticas, puede ejecutar consultas SQL en MongoDB con este contenedor de Postgres.
Recomiendo encarecidamente esta charla de Martin Fowler:
https://www.youtube.com/watch?v=qI_g07C_Q5I
RESUMEN: Martin ofrece una introducción rápida a las bases de datos NoSQL: de dónde provienen, la naturaleza de los modelos de datos que usan y la diferente forma en que deben pensar sobre la coherencia. A partir de esto, describe qué tipo de circunstancias debería considerar usarlas, por qué no harán obsoletas las bases de datos relacionales y la consecuencia importante de la persistencia políglota.
Dibuja una buena imagen de lo que es NoSQL, las diferentes categorías y las cosas que todos deben entender cuando provienen de las bases de datos relacionales del mundo. Saludos.
Solo prométete que nunca intentarás mapear un modelo de datos relacional a una base de datos NoSQL como MongoDB o CouchDB ... Este es el error más común que cometen los desarrolladores cuando evalúan la tecnología emergente.
Ese enfoque es análogo a tomar un automóvil e intentar usarlo para tirar de su carro por el camino como un caballo.
Es una reacción natural debido a la experiencia de todos, por supuesto, pero el valor real en el uso de una base de datos documental es que puede 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á asombroso y la escala será mucho más simple.
Como fundador de Joomla, soy parcial :-), pero viniendo del espacio de CMS, algo así como MongoDB es una bala de plata, 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 fuertes, especialmente en cuanto a la concurrencia. Hay casos de estudio 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 la evaluación en consecuencia.
Sugeriría este artículo de Rick Cattell sobre diversos almacenes de datos (también conocidos como NoSQL), sus diferencias y algunos de sus casos de uso: http://www.cattell.net/datastores/index.html