He estado usando NoSQL DBs desde hace un tiempo, y este es mi contribuyen al tema:
Un gran caso de uso para una base de datos NoSQL es una aplicación para estadísticas y/o informes generación, especialmente cuando los datos provienen de una fuente externa.
En una situación como la que una base de datos NoSQL puede ser un gran elección
Consideremos, por ejemplo, MongoDB:
Una vez que tenga sus datos en JSON, (que podría provenir de una tercera parte de la API, o exportarse desde un sql-aplicación) en MongoDB es bastante strightforward para importar y actualizar el JSON datos en la base de datos; por ejemplo, utilizando la línea de comandos mongoimport utilidad
En este punto es muy sencillo de construir consultas dinámicas con el filtrado y la agrupación, así que encaja con este tipo de aplicación.
Por ejemplo, utilizando el Aggregation Framework:
$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 añadir dinámicamente /quitar filtros usando estructuras de datos php y evitar la tediosa concatenación de cadena para construir nuestras consultas. Con este enfoque añadir/quitar filtros dinamycally es tan fácil como añadir/quitar elementos de una matriz
Otra gran ventaja proviene del hecho de que una solución de este tipo es probable que sea más rápido de utilizar un base de datos relacional , donde tenemos que hacer que se une con diferentes tablas para obtener todos los datos que necesitamos
Además, este caso de uso es óptimo debido a evita todos los principales límites de una base de datos NoSQL:
La falta de transacciones: La aplicación no realiza la escritura pero sólo lee, por lo que no es necesario en absoluto transacciones
La falta de unión entre tablas: No necesitamos une, como podemos usar redundancy para almacenar nuestros datos desnormalizados en las colecciones. Como solo leemos datos, no necesitamos preocuparnos por sincronizar los datos desnormalizados entre las actualizaciones.
De esta manera podemos centrarnos en almacenar los datos con redundancia de manera que así se adapta a nuestras preguntas, que será el foco en colecciones individuales.
Sólo estoy escribiendo esto porque si lo hubiera leído algo así hace unos momentos, me habría sido ahorrado algo de tiempo para hacer investigaciones
Esperamos que sea útil a alguien
Cassandra y MongoDB son productos completamente diferentes - categorías * completamente diferentes. Esta pregunta sería más fácil de responder si preguntara por casos de uso para un tipo de base de datos * específico * (OODB, DODB, DKVS, etc.) "NoSQL" es simplemente un término general para "cualquier cosa que no sea SQL" - podría ser algo como BerkleyDB o un montón de archivos planos en una red compartida. – Aaronaught
@Aaronaught aprecio las diferencias, supongo que soy culpable de utilizar un término paraguas con nosql – robjmills