Ce n'est pas une question de type NOSQL vs. SQL. Je suis intéressé par des types de scénarios où l'on peut utiliser une combinaison d'une base de données RDBMS et NOSQL et que l'utilisation Chacun des types de solutions ci-dessus existe des forces et des faiblesses propres - ce que je suis après est des situations / des scénarios où les points forts des deux peuvent être pleinement exploités et utilisés.
Dans mon esprit, on pourrait être le commerce électronique. Paiements, transactions, etc. sur un SGBDM (pensez à l'acide 2 ) et à des informations sur les produits et catalogues dans une base de données NOSQL. Mais est-ce approprié?
Préoccupations transversales d'une application, par exemple. La journalisation est probablement bien adaptée à une solution de type NOSQL comme un autre exemple.
Alternativement, pourquoi n'utiliseriez-vous pas à la fois ces deux types de technologies en combinaison?
Edit: Juste pour réitérer, je comprends que SQL et NOSQL ont leurs avantages et inconvénients inhérents et que certains types de situations sont plus adaptées à l'unique des magasins de données ci-dessus.
1 Je sais que les géants comme Facebook, Google, etc. utilisent probablement une combinaison de ceux-ci, mais en 2 Ravendb est une solution NOSQL prenant en charge les transactions acides presque tous la plupart des cas, je ne pense pas que la plupart des membres travaillent jamais sur de telles solutions énormes. Plus de choses de type quotidien typiques.
5 Réponses :
Ce n'est pas vraiment une question de programmation mais voici ce que je pense.
Si vous considérez le théorème de casquette http://fr.wikipedia.org/wiki/cap_theorem, vous pouvez supposer que des bases de données relatinales se concentrent sur la cohérence et la disponibilité, tandis que NOSQL se concentre sur la disponibilité et la tolérance de la partition (avec une cohérence «forte» éventuelle ).
Si vous essayez que la requête SQL soit vraiment cohérente, vous devez envisager d'utiliser un SGBDM. Si ce n'est pas une condition préalable, vous pouvez utiliser une base de données NOSQL.
C'est pourquoi la plupart du temps, la meilleure réponse à utiliser les deux, prenant des avantages des deux.
@sebastian - Re le dernier point - que la question concerne exactement des exemples de situations où les avantages des deux solutions sont utilisés.
Un bon exemple peut être mis à jour de plusieurs nœuds de données distribués à plusieurs nœuds simultanément et de prendre en charge des requêtes ad hoc potentiellement complexes. Les nœuds seraient "éventuellement cohérents", ce qui signifie que tout nœud particulier peut avoir des lacunes dans sa photo des données à tout moment.
Ceci convient bien à un SGBDM car les lacunes peuvent être manipulées très simplement par des jointures "extérieures" entre les relations. Le modèle relationnel devrait être meilleur à cela que, par exemple, un modèle de graphique, car le modèle de graphique repose sur des chemins de navigation entre différents éléments de données. Si un élément est manquant, le graphique est cassé en deux graphiques et une requête basée sur le chemin peut donc être invalidée. Ce problème n'existe pas dans le modèle relationnel, car les bases de données relationnelles ne sont pas de navigation - il n'y a pas de "liens" structurel entre éléments de données, de sorte que la "forme" des requêtes contre les données n'a pas besoin de changer simplement parce que les données sont manquantes. < / p>
Notez que j'ai pris une approche légèrement différente des autres réponses ici. J'essayais de donner un exemple qui était adapté à une solution de base de données NOSQL NOSQL - c'est-à-dire une base de données relative et nosql. À mon avis, Nosql et relationnel ne sont pas exclusivement exclusifs, même si certaines personnes semblent supposer qu'ils sont.
Je pense que le point NOSQL et qui tente de forcer (bien que cela puisse être fait), un modèle relationnel dans une solution de NOSQL vaincre le but de NOSQL?
@Ahmad: Pas de quelque manière que ce soit ne vainger le but. NOSQL n'est pas un modèle de données différent et NOSQL ne signifie pas "non relationnel". NOSQL signifie simplement une solution de base de données qui prend en charge une évolutivité massive, une consistance éventuelle et tout cela implique. Le modèle relationnel est idéal pour celui-ci - mieux que d'autres modèles de données NOSQL en fait. RechercheSkowledge.wordpress.com/2010 / 10/04 / ...
Très intéressant après certains des articles liés. Connaissez-vous de tout exemples montrant le «modèle relationnel» en action avec NOSQL?
@Ahmad: La plupart des solutions qui sont généralement appelées NOSQL ne sont pas relationnelles. Mais les données de données distribuées à l'échelle Web à l'aide de bases de données SQL étaient autour depuis des années avant que le terme NOSQL ait été utilisé pour les décrire. NOSQL est juste un nom gadîteux pour quels développeurs de base de données ont fait depuis des années. Un exemple bien documenté d'un système basé sur SQL est le télescope mondial, qui a une décennie âgée d'environ une décennie. recherche.microsoft.com/en-us/projects/wwt
Une réponse évidente pourrait signaler à titre d'exemple sur l'endroit où l'une est plus appropriée que l'autre dans une application simple.
Par exemple, vous voudrez peut-être utiliser une base de données de documents comme Ravendb ou canapé pour votre travail OLTP, car il vous donne les moyens de sauvegarder vos entités et interrogeez ces entités dans des projections aplaties sur des documents (vues à une seule requête) . (Ravendb plus que Couchdb, mais ce n'est ni ici ni là; -))
Vous pouvez également l'utiliser pour des rapports simples, en utilisant la carte / réduction pour vous donner des statistiques à afficher sur certaines pages (produits populaires, clouds de tags, etc.).
Cependant, de nombreux systèmes de rapport sont conçus pour interroger des magasins relationnels, vous pouvez donc répliquer les données dans une base de données de reporting.
Par exemple, dans Ravendb, vous avez la possibilité de prendre tout index et de répliquer automatiquement les données dans cet index dans un magasin relationnel.
C'est logique car avoir les données dans un format relationnel signifie que vous pouvez faire des requêtes inter-documentaires complexes et s'intégrer aux produits de rapport existants - sans vous mettre en place du travail OLTP standard ou de la conception de la base de données de documents.
Ceci n'est qu'une réponse en dehors de nombreuses réponses, car il existe d'autres exemples où une sorte de magasin de données particulier est plus adapté à un but spécifique, à la fin de la journée, il n'y a pas de sortie de cela. (Sauf si vous croyez que les gars Voltdb)
J'aime que vous ayez une mentalité «inversée» lorsque vous répondez à cette question. Nosql comme primaire et utilisez SQL pour les rapports hardcore. Les statistiques simples sont quelque chose que je pense que la plupart des gens veulent afficher sur leurs sites - vous utilisez donc un magasin de données SQL et utilisez une solution NOSQL pour les statistiques simples.
Si vous pouvez être dérangé de manière à reproduire les données, assurez-vous - ça va travailler - mais si vous travaillez sur un projet à partir de zéro, il n'y a pas de raison réelle d'utiliser une base de données SQL comme magasin principal =)
Sauf si vous opérez à une échelle où des bases de données relationnelles ne fonctionneront tout simplement pas, le grand avantage de NOSQL est la facilité de développement - des choses comme ne pas avoir besoin de scripts de mise à niveau de l'orje ou de la base de données. Dès que vous commencez à utiliser SQL pour une partie du système, il faut très peu d'efforts supplémentaires pour l'utiliser pour d'autres parties.
Dans à peu près tout projet, des composants seront plus adaptés à un type de magasin de données particulier. La question importante est de savoir si la différence est suffisante pour justifier les frais généraux d'utiliser plusieurs magasins de données. Généralement, cela signifie une combinaison d'échelle, de notification ad hoc et de structures de données qui ne correspondent pas bien à une base de données relationnelle.
Juste pour clarifier, vous répondez à la partie «alternative» de la question. Si possible, un exemple aiderait vraiment à solidifier votre réponse.
Oui, c'est la réponse alternative - en supposant qu'un système à petite échelle construit pour effectuer une tâche unique que je ne peux penser à aucun cas où plusieurs magasins en vaudaient la peine. Les rapports sont une possibilité, bien que cela a tendance à atteindre davantage de contextes où NOSQL n'est pas une option de toute façon. Pour quelque chose comme votre exemple de commerce électronique, les transactions ne sont pas aussi importantes que vous pouvez penser - transactions assurez-vous que la commande et les ordonnances sont mises à jour ensemble, mais avec NOSQL, ils peuvent faire partie du même objet et être mis à jour de toute façon.
NOSQL pourrait éventuellement être utilisé pour répliquer les données d'un magasin de données SQL. Dans ce scénario, je souhaite créer des documents à partir d'enregistrements SQLITE mobiles et comptez sur Couch ou Mongo pour reproduire ceci à un NOSQL sur le serveur. Le serveur SQL peut alors traiter les documents entrants.
Je ne sais pas si la balise subjective doit également être ajoutée ici. S'il vous plaît donnez votre avis.
Serait-il aider cette question, si je limite l'aspect «NOSQL» à un type orienté sur des documents, par exemple Mongodb, Couchdb, Ravendb?