Cas d'utilisation de NoSQL [fermé]

NoSQL a récemment attiré beaucoup d'attention dans notre industrie. Je suis vraiment intéressé par ce que les gens pensent des meilleurs cas d'utilisation pour son utilisation sur le stockage de base de données relationnelle. Ce qui devrait amener un développeur à penser que des ensembles de données particuliers sont plus adaptés à une solution NoSQL. Je suis particulièrement intéressé par MongoDB et CouchDB car ils semblent avoir le plus de couverture en ce qui concerne le développement PHP et c'est mon objectif.

Promettez-vous simplement que vous n'essaierez jamais de mapper un modèle de données relationnel à une base de données NoSQL comme MongoDB ou CouchDB ... C'est l'erreur la plus courante que font les développeurs lors de l'évaluation des technologies émergentes.

Cette approche est analogue à prendre une voiture et à essayer de l'utiliser pour tirer votre charrette sur la route comme un cheval.

C'est une réaction naturelle due à l'expérience de chacun bien sûr, mais la vraie valeur de l'utilisation d'une base de données de documents est de pouvoir simplifier votre modèle de données et minimiser vos souffrances en tant que développeur. Votre base de code diminuera, vos bogues seront moins nombreux et plus faciles à trouver, les performances seront impressionnantes et l'échelle sera beaucoup plus simple.

En tant que fondateur de Joomla, je suis biaisé :-) mais venant de l'espace CMS, quelque chose comme MongoDB est une solution miracle car le contenu correspond très naturellement aux systèmes de documents.

L'analyse en temps réel est un autre excellent cas pour MongoDB, car MongoDB a des performances et une échelle très élevées, en particulier en ce qui concerne la concurrence. Il existe des études de cas sur le site Web MongoDB.org qui démontrent ces attributs.

Je suis d'accord avec l'idée que chaque base de données a ses propres objectifs et cas d'utilisation; prendre le but de chaque base de données pour l'évaluation en conséquence.

Quelques grands cas d'utilisation - pour MongoDB en tout cas - sont mentionnés sur le site MongoDB. Les exemples donnés sont l'analyse en temps réel, la journalisation et la recherche en texte intégral. Ces articles valent tous la peine d'être lus http://www.mongodb.com/use-cases

Il existe également une excellente description de la base de données NoSQL la mieux adaptée à quel type de projet: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Je suggérerais cet article de Rick Cattell sur divers magasins de données (alias NoSQL), leurs différences et certains de leurs cas d'utilisation: http://www.cattell.net/datastores/index.html

Ce que j'aime chez NoSQL n'a rien à voir avec les performances et tout à voir avec la convivialité. Les magasins de documents sont simplement plus faciles à utiliser lorsque vos unités de données atomiques ressemblent à des documents, car il est facile de sérialiser vers et à partir d'objets. C'est juste plus amusant et c'est un facteur important pour les projets personnels ou parallèles.

J'utilise des bases de données NoSQL depuis un certain temps maintenant, et voici ma contribution au sujet:

Un excellent cas d'utilisation d'une base de données NoSQL est une application de génération de statistiques et / ou de rapports , en particulier lorsque les données sont fournies à partir d'une source tierce.

Dans une situation comme celle-là, une base de données NoSQL peut être un excellent choix

Prenons, par exemple, MongoDB :

Une fois que vous avez vos données en JSON (elles peuvent provenir d'une API tierce ou être exportées à partir d'une application sql) dans MongoDB, il est assez simple d'importer et de mettre à jour les données JSON dans la base de données; par exemple en utilisant l' mongoimportutilitaire de ligne de commande

À ce stade, il est très simple de créer des requêtes dynamiques avec filtrage et regroupement, qui correspondent bien à ce type d'application.

Par exemple, en utilisant le framework d'agrégation :

$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 );

Je voudrais souligner la facilité avec laquelle nous pouvons ajouter / supprimer des filtres de manière dynamique utilisant des structures de données php et en évitant la concaténation de chaînes fastidieuse pour construire nos requêtes. Avec cette approche, ajouter / supprimer des filtres de manière dynamique est aussi simple que d'ajouter / supprimer des éléments d'un tableau

Un autre grand avantage vient du fait qu'une solution comme celle-ci est susceptible d'être plus rapide que l'utilisation d'une base de données relationnelle , où nous devons faire des jointures avec différentes tables pour obtenir toutes les données dont nous avons besoin.

De plus, ce cas d'utilisation est optimal car évite toutes les principales limites d'une base de données NoSQL:

• Manque de transactions: l'application n'effectue pas d'écritures mais uniquement des lectures, nous n'avons donc pas du tout besoin de transactions

• Manque de jointures entre les tables: nous n'avons pas besoin de jointures, car nous pouvons utiliser la redondance pour stocker nos données dénormalisées dans les collections. Comme nous lisons uniquement des données, nous n'avons pas à nous soucier de la synchronisation des données dénormalisées entre les mises à jour.

De cette façon, nous pouvons nous concentrer sur le stockage des données avec redondance d'une manière qui correspond bien à nos requêtes , qui se concentreront sur des collections uniques.

J'écris juste ceci parce que si j'avais lu quelque chose comme ça il y a quelques temps, cela m'aurait fait gagner du temps pour faire des recherches

J'espère que cela sera utile à quelqu'un

Je recommande vivement cette conférence de Martin Fowler:

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

RÉSUMÉ: Martin donne une introduction rapide aux bases de données NoSQL: d'où elles viennent, la nature des modèles de données qu'elles utilisent et la manière différente dont vous devez penser la cohérence. À partir de là, il décrit les types de circonstances que vous devriez envisager de les utiliser, pourquoi elles ne rendront pas les bases de données relationnelles obsolètes et la conséquence importante de la persistance polyglotte.

Il dresse une belle image de ce qu'est NoSQL, des différentes catégories et des choses que chacun doit comprendre lorsqu'il vient du monde des bases de données relationnelles. Cordialement.

Vous devez d'abord comprendre la théorie CAP (cohérence, disponibilité et partitionnement, où vous devez en prendre deux sur trois) et notre cas d'utilisation métier. MongoDB satisfait la cohérence et le partitionnement et la base de données de canapé satisifie la disponibilité et le partitionnement.

Les vidéos Edureka sur YouTube concernant NoSQL sont parmi les meilleurs didacticiels vidéo.

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

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

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

De bonnes présentations sont disponibles sur 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 (Cette présentation prend en charge le didacticiel vidéo sur youtube)

Pour certains cas d'utilisation dont vous avez besoin, en particulier pour les requêtes analytiques, vous pouvez exécuter des requêtes SQL sur MongoDB avec ce wrapper de Postgres.

Comme il y a maintenant beaucoup plus de bases de données NoSQL sur le marché que jamais auparavant, je suggère de jeter un coup d'œil au Magic Quadrant de Gartner si vous recherchez une base de données qui conviendra également aux applications d'entreprise basées sur le support, l'extensibilité, la gestion et Coût.

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

Je voudrais suggérer Couchbase à tous ceux qui ne l'ont pas encore essayé, mais pas sur la base de la version indiquée dans le rapport (2.5.1) car il y a près de 2 révisions derrière CB Server aujourd'hui, proche de la sortie de 4.0 en 2H15 .

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

L'autre aspect de Couchbase en tant que fournisseur / produit est qu'il s'agit d'un type de base de données multi-usage. Il peut agir comme un pur magasin K / V, une base de données orientée document avec mise à l'échelle multidimensionnelle, Memcached, mise en cache avec persistance, et prend en charge SQL conforme ANSI 92 avec jointures automatiques, réplication vers des clusters DR en appuyant sur un bouton, et a même un composant mobile intégré à l'écosystème.

Si rien d'autre, cela vaut la peine de consulter les derniers benchmarks:

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