Les bases de données relationnelles appliquent ACID . Ainsi, vous aurez des magasins de données orientés transaction basés sur un schéma. Il a fait ses preuves et convient à 99% des applications du monde réel. Vous pouvez pratiquement tout faire avec les bases de données relationnelles.
Cependant, il existe des limitations de vitesse et d'évolutivité lorsqu'il s'agit de magasins de données massifs à haute disponibilité. Par exemple, Google et Amazon ont des téraoctets de données stockés dans de grands centres de données. L'interrogation et l'insertion ne sont pas performantes dans ces scénarios en raison de la nature de blocage / schéma / transaction des RDBM. C'est la raison pour laquelle ils ont implémenté leurs propres bases de données (en fait, des magasins de valeurs clés) pour un gain de performances et une évolutivité massifs.
Les bases de données NoSQL existent depuis longtemps - seul le terme est nouveau. Quelques exemples sont des bases de données de graphiques, d'objets, de colonnes, XML et de documents.
Pour votre deuxième question: est-il possible d'utiliser les deux sur le même site?
Pourquoi pas? Les deux servent des objectifs différents, non?
Les solutions NoSQL sont généralement destinées à résoudre un problème pour lequel les bases de données relationnelles ne sont pas bien adaptées, trop coûteuses à utiliser (comme Oracle) ou vous obligent à implémenter quelque chose qui brise de toute façon la nature relationnelle de votre base de données.
Les avantages sont généralement spécifiques à votre utilisation, mais à moins que vous ne rencontriez un problème pour modéliser vos données dans un SGBDR, je ne vois aucune raison pour laquelle vous choisiriez NoSQL.
J'utilise moi-même MongoDB et Riak pour des problèmes spécifiques où un SGBDR n'est pas une solution viable, pour toutes les autres choses, j'utilise MySQL (ou SQLite pour les tests).
Si vous avez besoin d' une base de données NoSQL que vous connaissez généralement, les raisons possibles sont:
Si vous n'avez pas besoin d'une solution NoSQL, gardez à l'esprit que ces solutions n'étaient pas destinées à remplacer un SGBDR mais plutôt à être des alternatives là où l'ancien échoue et, plus important encore, qu'elles sont relativement nouvelles en tant que telles, elles ont encore beaucoup de bogues et caractéristiques manquantes.
Oh, et en ce qui concerne la deuxième question, il est parfaitement bien d'utiliser n'importe quelle technologie en conjonction avec une autre, donc juste pour être complet de mon expérience MongoDB et MySQL fonctionnent bien ensemble tant qu'ils ne sont pas sur la même machine
la source
Martin Fowler a une excellente vidéo qui donne une bonne explication des bases de données NoSQL. Le lien va directement à ses raisons de les utiliser, mais toute la vidéo contient de bonnes informations.
Vous avez de grandes quantités de données, surtout si vous ne pouvez pas tout mettre en place sur un seul serveur physique car NoSQL a été conçu pour bien évoluer.
Incompatibilité d'impédance objet-relationnelle - Vos objets de domaine ne s'intègrent pas bien dans un schéma de base de données relationnelle. NoSQL vous permet de conserver vos données sous forme de documents (ou de graphiques) qui peuvent correspondre beaucoup plus étroitement à votre modèle de données.
la source
NoSQL est un système de base de données où les données sont organisées en document (MongoDB), paire clé-valeur (MemCache, Redis), forme de structure graphique (Neo4J).
Voici peut-être des questions et réponses possibles pour "Quand opter pour NoSQL":
Besoin d'un schéma flexible ou traiter des données comme des arbres?
En général, dans le développement agile, nous commençons à concevoir un système sans connaître toutes les exigences à l'avance, où plus tard tout au long du développement, le système de base de données peut nécessiter des changements de conception fréquents, mettant en vedette MVP (produit minimal viable). Ou vous avez affaire à un schéma de données de nature dynamique. Par exemple, les journaux système, un exemple très précis est les journaux AWS cloudwatch.
L'ensemble de données est vaste / volumineux?
Oui Non, les bases de données SQL sont le meilleur candidat pour les applications où la base de données doit gérer des millions voire des milliards d'enregistrements sans compromettre les performances.
Compromis entre mise à l'échelle et cohérence Contrairement au SGBDR, la base de données NoSQL peut perdre de petites données ici et là (Remarque: la probabilité est de .x%), mais elle est facile à mettre à l'échelle en termes de performances. Exemple: Cela peut être utile pour stocker les personnes en ligne dans une application de messagerie instantanée, des jetons dans la base de données, pour enregistrer les statistiques de trafic sur le site Web.
Effectuer des opérations de géolocalisation: Prise en charge riche du hachage MongoDB pour effectuer des opérations de géolocalisation et de géolocalisation. J'ai vraiment adoré cette fonctionnalité de MongoDB.
En résumé, MongoDB convient parfaitement aux applications dans lesquelles vous pouvez stocker des données structurées dynamiques à grande échelle.
la source
Certaines informations essentielles manquent pour répondre à la question: Quels cas d'utilisation la base de données doit-elle pouvoir couvrir? Des analyses complexes doivent-elles être effectuées à partir de données existantes ( OLAP ) ou l'application doit-elle être capable de traiter de nombreuses transactions ( OLTP )? Quelle est la structure des données? C'est loin d'être la fin de l'heure des questions.
À mon avis, il est faux de prendre des décisions technologiques sur la base de mots à la mode audacieux sans savoir exactement ce qui se cache derrière eux. NoSQL est souvent loué pour son évolutivité. Mais il faut aussi savoir que la mise à l'échelle horizontale (sur plusieurs nœuds) a aussi son prix et n'est pas gratuite. Ensuite, vous devez gérer des problèmes tels que la cohérence éventuelle et définir comment résoudre les conflits de données s'ils ne peuvent pas être résolus au niveau de la base de données. Cependant, cela s'applique à tous les systèmes de bases de données distribuées.
La joie des développeurs avec le mot «schema less» chez NoSQL est également très grande au début. Ce mot à la mode est rapidement désenchanté après analyse technique, car il ne nécessite correctement pas de schéma lors de l'écriture, mais entre en jeu lors de la lecture. C'est pourquoi il doit être correctement "schéma en lecture". Il peut être tentant de pouvoir écrire des données à sa discrétion. Mais comment gérer la situation s'il existe des données existantes mais que la nouvelle version de l'application attend un schéma différent?
Le modèle de document (comme dans MongoDB, par exemple) ne convient pas aux modèles de données où il existe de nombreuses relations entre les données. Les jointures doivent être effectuées au niveau de l'application, ce qui est un effort supplémentaire et pourquoi devrais-je programmer des choses que la base de données devrait faire.
Si vous faites valoir que Google et Amazon ont développé leurs propres bases de données parce que les SGBDR conventionnels ne peuvent plus gérer le flot de données, vous pouvez seulement dire: vous n'êtes pas Google et Amazon. Ces entreprises sont le fer de lance, environ 0,01% des scénarios où les bases de données traditionnelles ne conviennent plus, mais pour le reste du monde, elles le sont.
Ce qui n'est pas anodin: SQL existe depuis plus de 40 ans et des millions d'heures de développement ont été consacrées à de grands systèmes tels qu'Oracle ou Microsoft SQL. Ceci doit être réalisé par de nouvelles bases de données. Parfois, il est également plus facile de trouver un administrateur SQL que quelqu'un pour MongoDB. Ce qui nous amène à la question de la maintenance et de la gestion. Un sujet qui n'est pas vraiment sexy, mais qui fait partie de la décision technologique.
la source
Je suis tombé sur cette question en cherchant des raisons convaincantes de s'écarter de la conception du SGBDR.
Il y a un excellent article de Julian Brown qui met en lumière les contraintes des systèmes distribués. Le concept s'appelle le Théorème CAP de Brewer qui, en résumé, dit:
Et voici comment je l'ai résumé pour moi-même:
la source
J'ai conçu et implémenté des solutions avec des bases de données NoSQL et voici ma liste de points de contrôle pour prendre la décision d'aller avec SQL ou NoSQL orienté document .
À NE PAS FAIRE
SQL n'est pas obsolète et reste un meilleur outil dans certains cas. Il est difficile de justifier l'utilisation d'un NoSQL orienté document lorsque
À faire
Si vous ne disposez pas de ces conditions ou pouvez les atténuer, voici 2 raisons pour lesquelles vous pouvez bénéficier de NoSQL:
Plus d'informations
Dans mes articles de blog, j'explique les raisons plus en détail:
Remarque: ce qui précède s'applique uniquement à NoSQL orienté document. Il existe d' autres types de NoSQL, qui nécessitent d'autres considérations.
la source
Gestion d'un grand nombre d'opérations de lecture / écriture
Recherchez les bases de données NoSQL lorsque vous avez besoin d'évoluer rapidement. Et quand devez-vous généralement évoluer rapidement?
Lorsqu'il y a un grand nombre d'opérations de lecture-écriture sur votre site Web et lorsqu'il s'agit d'une grande quantité de données, les bases de données NoSQL conviennent le mieux à ces scénarios. Puisqu'ils ont la possibilité d'ajouter des nœuds à la volée, ils peuvent gérer plus de trafic simultané et une grande quantité de données avec une latence minimale.
Flexibilité avec la modélisation des données
Le deuxième signal est lors des phases initiales de développement lorsque vous n'êtes pas sûr du modèle de données, de la conception de la base de données, les choses devraient changer à un rythme rapide. Les bases de données NoSQL nous offrent plus de flexibilité.
Cohérence éventuelle par rapport à une forte cohérence
Il est préférable de choisir les bases de données NoSQL lorsque nous pouvons abandonner la cohérence forte et lorsque nous n'avons pas besoin de transactions.
Un bon exemple de ceci est un site Web de réseautage social comme Twitter. Lorsqu'un tweet d'une célébrité explose et que tout le monde l'aime et le re-tweet du monde entier. Est-ce important que le nombre de likes augmente ou diminue un peu pendant un court moment?
La célébrité ne se soucierait certainement pas si, au lieu des 5 millions 500 `` j'aime '', le système montre que le même compte comme 5 millions 250 pendant un court moment.
Lorsqu'une application volumineuse est déployée sur des centaines de serveurs répartis dans le monde entier, les nœuds répartis géographiquement mettent un certain temps à atteindre un consensus mondial.
Jusqu'à ce qu'ils parviennent à un consensus, la valeur de l'entité est incohérente. La valeur de l'entité devient finalement cohérente après un court moment. C'est ce qu'est la cohérence éventuelle.
Bien que l'incohérence ne signifie pas qu'il y a une sorte de perte de données. Cela signifie simplement que les données mettent un peu de temps à voyager à travers le monde via les câbles Internet sous l'océan pour atteindre un consensus mondial et devenir cohérentes.
Nous éprouvons ce comportement tout le temps. Surtout sur YouTube. Souvent, vous voyez une vidéo avec 10 vues et 15 likes. Comment est-ce possible?
Ce n'est pas. Les vues réelles sont déjà plus que les goûts. C'est juste que le nombre de vues est incohérent et prend un peu de temps pour être mis à jour.
Exécution de l'analyse des données
Les bases de données NoSQL conviennent également mieux aux cas d'utilisation de l'analyse de données, dans lesquels nous devons faire face à un afflux massif de données.
la source