Dans NoSQL :si seulement c'était aussi simple , l'auteur écrit à propos de MongoDB :
MongoDB n'est pas un magasin clé/valeur, c'est un peu plus. Ce n'est certainement pas non plus un SGBDR. Je n'ai pas utilisé MongoDB en production, mais je l'ai utilisé un peu pour créer une application de test et c'est un kit très cool. Il semble être très performant et a, ou aura bientôt, la tolérance aux pannes et l'auto-sharding (c'est-à-dire qu'il évoluera). Je pense que Mongo pourrait être la chose la plus proche d'un remplacement de RDBMS que j'ai vu jusqu'à présent. Cela ne fonctionnera pas pour tous les ensembles de données et modèles d'accès, mais il est conçu pour vos éléments CRUD typiques. Stocker ce qui est essentiellement un énorme hachage et pouvoir sélectionner l'une de ces clés est ce pour quoi la plupart des gens utilisent une base de données relationnelle. Si votre base de données est 3NF et que vous ne faites aucune jointure (vous sélectionnez simplement un tas de tables et rassemblez tous les objets, c'est-à-dire ce que la plupart des gens font dans une application Web), MongoDB botterait probablement le cul pour vous.
Puis, en conclusion :
La vraie chose à souligner est que si vous êtes empêché de faire quelque chose de super génial parce que vous ne pouvez pas choisir une base de données, vous le faites mal. Si vous connaissez mysql, utilisez-le. Optimisez quand vous en avez vraiment besoin. Utilisez-le comme un magasin k/v, utilisez-le comme un rdbms, mais pour l'amour de Dieu, créez votre application qui tue ! Rien de tout cela n'aura d'importance pour la plupart des applications. Facebook utilise encore beaucoup MySQL. Wikipédia utilise beaucoup MySQL. FriendFeed utilise beaucoup MySQL. NoSQL est un excellent outil, mais ce ne sera certainement pas votre avantage concurrentiel, cela ne rendra pas votre application populaire et, surtout, vos utilisateurs ne se soucieront pas de tout cela.
Sur quoi vais-je construire ma prochaine application ? Probablement Postgres. Vais-je utiliser NoSQL ? Peut-être. Je pourrais aussi utiliser Hadoop et Hive. Je pourrais tout conserver dans des fichiers plats. Je vais peut-être commencer à pirater Maglev. J'utiliserai ce qui est le mieux pour le travail. Si j'ai besoin de rapports, je n'utiliserai aucun NoSQL. Si j'ai besoin de cache, j'utiliserai probablement Tokyo Tyrant. Si j'ai besoin d'ACIDity, je n'utiliserai pas NoSQL. Si j'ai besoin d'une tonne de compteurs, j'utiliserai Redis. Si j'ai besoin de transactions, j'utiliserai Postgres. Si j'ai une tonne d'un seul type de documents, j'utiliserai probablement Mongo. Si j'ai besoin d'écrire 1 milliard d'objets par jour, j'utiliserai probablement Voldemort. Si j'ai besoin d'une recherche en texte intégral, j'utiliserais probablement Solr. Si j'ai besoin d'une recherche plein texte de données volatiles, j'utiliserais probablement Sphinx.
J'aime cet article, je le trouve très instructif, il donne un bon aperçu du paysage NoSQL et de la hype. Mais, et c'est la partie la plus importante, cela aide vraiment à se poser les bonnes questions lorsqu'il s'agit de choisir entre RDBMS et NoSQL. Ça vaut le coup de lire à mon humble avis.
Lien alternatif vers l'article
