Cas d'utilisation pour NoSQL
NoSQL a récemment attiré beaucoup d'attention dans notre industrie. Je suis vraiment intéressé par les opinions des gens sur les meilleurs cas d'utilisation pour son utilisation sur le stockage de bases de données relationnelles. Ce qui devrait inciter un développeur à penser que des ensembles de données particuliers conviennent mieux à une solution NoSQL. Je suis particulièrement intéressé par MongoDB et CouchDB car ils semblent obtenir le plus de couverture en ce qui concerne PHP développement et c'est mon concentrer.
Quelques grands cas d'utilisation - pour MongoDB de toute façon - 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 un excellent rapport sur la base de données NoSQL qui convient le mieux à quel type de projet: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
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 les développeurs font lors de l'évaluation des technologies émergentes.
Cette approche est analogue à prendre une voiture et à essayer de l'utiliser pour tirer votre chariot sur la route comme un cheval.
C'est une réaction naturelle en raison de 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 partisan :-) mais venant de l'espace CMS, quelque chose comme MongoDB est une solution miracle car le contenu est très naturellement mappé aux systèmes de documentation.
Un autre excellent cas pour MongoDB est l'analyse en temps réel, car MongoDB a des performances et une échelle très solides, 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 en compte l'objectif de chaque base de données pour l'évaluation.
Je suggère cet article de Rick Cattell sur les différents 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 trivial de sérialiser vers et depuis des 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 c'est ma contribution au sujet:
Un grand cas d'utilisation pour une base de données NoSQL est une application pour les statistiques et/ou génération de rapports , en particulier lorsque les données sont fournies par une source tierce.
Dans une situation comme celle-ci, une base de données NoSQL peut être un excellent choix
Considérons, par exemple, MongoDB:
Une fois que vous avez vos données dans JSON, (elles peuvent provenir d'une API tierce ou être exportées à partir d'une application sql) dans MongoDB est assez strightforward importer et mettre à jour les données JSON dans la base de données; par exemple en utilisant l'utilitaire de ligne de commande mongoimport
À 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 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 );
Je voudrais souligner la facilité avec laquelle nous pouvons ajouter/supprimer des filtres en utilisant des structures de données php et en évitant la concaténation fastidieuse de chaînes pour construire nos requêtes. Avec cette approche, ajouter/supprimer des filtres de manière dinamycale 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 d'utiliser 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 limites principales d'une base de données NoSQL:
Manque de transactions: L'application n'effectue pas d'écritures mais lit seulement, donc nous n'avons pas besoin de transactions du tout
Manque de jointures entre les tables: Nous n'avons pas besoin de jointures, car nous pouvons utiliser la redondance pour stocker notre données dénormalisées dans les collections. Comme nous ne lisons que les données, nous n'avons pas à nous inquiéter 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 concentrera sur des collections uniques.
J'écris juste 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 fortement cet exposé 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 proviennent, la nature des modèles de données qu'elles utilisent et les différents vous devez penser à la cohérence. À partir de cela, il décrit quels types de circonstances vous devriez envisager de les utiliser, pourquoi ils ne rendront pas les bases de données relationnelles obsolètes, et les conséquences importantes de la persistance polyglotte.
Il dessine une belle image de ce qu'est NoSQL, des différentes catégories et des choses que tout le monde doit comprendre en venant du monde des bases de données relationnelles. Cordialement.
Vous devez d'abord comprendre la théorie du CAP (cohérence, disponibilité et partitionnement, où vous devez en prendre deux sur trois) et notre cas d'utilisation commerciale. MongoDB satisfait la cohérence et le partitionnement et le DB de canapé satisfait 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/EdurekaIN/no-sql-databases-35591065?qid=f1b9c095-6d70-4d0a-91da-1df664c4f389&v=qf1&b=&from_search= (Cette présentation prend en charge le didacticiel vidéo) sur youtube)
Parce qu'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 Gartner Magic Quadrant si vous recherchez une base de données qui sera également idéale pour les 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 présentée dans le rapport (2.5.1) car il y a près de 2 révisions de plus que CB Server aujourd'hui, s'approchant de la sortie de 4.0 en 2H15 .
http://www.couchbase.com/coming-in-couchbase-server-4-
L'autre aspect de Couchbase en tant que fournisseur/produit est qu'il s'agit d'un type de base de données à usages multiples. Il peut agir comme un magasin K/V pur, une base de données orientée document avec une mise à l'échelle multidimensionnelle, Memcached, mis en cache avec persistance, et prend en charge SQL conforme à ANSI 92 avec des jointures automatiques, la réplication vers des clusters DR en appuyant simplement 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 repères:
http://info.couchbase.com/Benchmark_MongoDB_VS_CouchbaseServer_HPW_BM.htmlhttp://info.couchbase.com/NoSQL-Technical-Comparison-Report.html
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.