Quand devrais-je utiliser une base de données NoSQL au lieu d'une base de données relationnelle? Puis-je utiliser les deux sur le même site?
Quels sont les avantages d'utiliser des bases de données NoSQL? J'ai beaucoup lu à leur sujet ces derniers temps, mais je ne comprends toujours pas pourquoi je souhaiterais en mettre un en œuvre et dans quelles circonstances je souhaiterais en utiliser un.
Les bases de données relationnelles appliquent ACIDE . 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 des bases de données relationnelles.
Cependant, il existe des limitations en termes de vitesse et d'évolutivité lorsqu'il s'agit de magasins de données à haute disponibilité massifs. Par exemple, Google et Amazon ont des téraoctets de données stockées dans de grands centres de données. Les requêtes et les insertions 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 réalité, des magasins de clés-valeurs) pour un gain de performance et une évolutivité énormes.
Les bases de données NoSQL existent depuis longtemps - le terme est nouveau. Quelques exemples sont les bases de données de graphes, objets, colonnes, XML et documents.
Pour votre deuxième question: Est-il possible d'utiliser les deux sur le même site?
Pourquoi pas? Les deux servent des fins différentes non?
Les solutions NoSQL sont généralement conçues pour résoudre un problème pour lequel les bases de données relationnelles ne sont pas bien adaptées, trop coûteuses (comme Oracle) ou vous obligent à implémenter quelque chose qui casse 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 n'ayez un problème pour modéliser vos données dans un SGBDR, je ne vois pas pourquoi vous choisiriez NoSQL.
J'utilise moi-même MongoDB et Riak pour des problèmes spécifiques pour lesquels un SGBDR n'est pas une solution viable, pour tout le reste, j'utilise MySQL (ou SQLite pour les tests).
Si vous besoin une base de données NoSQL que vous connaissez habituellement, les raisons possibles sont:
- le client souhaite une disponibilité de 99,999% sur un site à fort trafic.
- vos données n'ont aucun sens en SQL, vous vous retrouvez en train de faire plusieurs requêtes JOIN pour accéder à certaines informations.
- vous cassez le modèle relationnel, vous avez des objets CLOB qui stockent des données dénormalisées et vous générez des index externes pour rechercher ces données.
Si vous n’avez pas besoin d’une solution NoSQL, gardez à l’esprit que ces solutions ne sont pas conçues pour remplacer un SGBDR, mais plutôt comme des solutions de remplacement lorsque les solutions précédentes échouent et, ce qui est plus important, elles sont relativement nouvelles en tant que telles. caractéristiques manquantes.
Oh, et en ce qui concerne la deuxième question, il est tout à fait possible d’utiliser une technologie en association avec une autre. En résumé, pour que mon expérience soit complète, MongoDB et MySQL fonctionnent bien tant qu’ils ne sont pas sur la même machine.
Martin Fowler a un excellent 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 disposez de grandes quantités de données, en particulier si vous ne pouvez pas toutes les stocker sur un serveur physique, car NoSQL a été conçu pour évoluer correctement.
incompatibilité impédance 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) pouvant correspondre beaucoup plus étroitement à votre modèle de données.
NoSQL est un système de base de données où les données sont organisées dans le document (MongoDB), paire clé-valeur (MemCache, Redis), forme de structure graphique (Neo4J).
Voici peut-être des questions et réponses pour "Quand faut-il utiliser NoSQL":
Exige-t-il un schéma flexible ou utilise-t-il des données de type arbre?
En général, dans le développement agile, nous commençons à concevoir un système sans connaître toutes les exigences. Dès lors, le système de base de données de développement devra peut-être s'adapter à de fréquents changements de conception, mettant en valeur le produit MVP (produit minimal viable). Ou vous avez affaire à un schéma de données de nature dynamique. par exemple. Journaux système, un exemple très précis est celui des journaux AWS cloudwatch.L'ensemble de données est vaste/grand?
Oui La base de données NoSQL est 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 sur cohérence
Contrairement à RDMS, 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 à adapter en termes de performances. Exemple: cela peut être utile pour stocker les personnes en ligne dans l'application de messagerie instantanée, les jetons dans la base de données, l'enregistrement des statistiques de trafic sur le site Web.Exécution d'opérations de géolocalisation: MongoDB prend en charge de nombreuses opérations de géolocalisation et de géolocalisation. J'ai vraiment aimé 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.
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 pouvoir traiter de nombreuses transactions ( OLTP )? Quelle est la structure de données? C'est loin de la fin de l'heure des questions.
À mon avis, il est faux de prendre des décisions technologiques en se basant sur des mots à la mode audacieux sans savoir exactement ce qui les cache. NoSQL est souvent félicité 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 traiter des problèmes tels que 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 base de données distribués.
La joie des développeurs avec le mot "schéma moins" chez NoSQL est aussi très grande au début. Ce mot à la mode est rapidement désabusé après une analyse technique, car il n’exige correctement pas de schéma lors de l’écriture, mais entre en jeu lors de la lecture. C'est pourquoi il devrait être correctement "schéma en lecture". Il peut être tentant de pouvoir écrire des données à sa propre discrétion. Mais comment puis-je gérer la situation s'il existe des données mais que la nouvelle version de l'application attend un schéma différent?
Le modèle de document (comme dans MongoDB, par exemple) est non approprié pour les 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 représente un effort supplémentaire et pourquoi devrais-je programmer les tâches que la base de données devrait faire.
Si vous expliquez que Google et Amazon ont développé leurs propres bases de données parce que les SGBDR classiques ne peuvent plus gérer le flot de données, vous pouvez simplement dire: Vous n'êtes pas Google et Amazon. Ces sociétés sont le fer de lance, environ 0,01% des scénarios dans lesquels les bases de données traditionnelles ne conviennent plus, mais le reste du monde.
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 que Oracle ou Microsoft SQL. Cela doit être réalisé par certaines 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.
Je suis tombé sur cette question en cherchant des raisons convaincantes de dévier de la conception du SGBDR.
Il y a un grand post de Julian Brown qui met en lumière les contraintes des systèmes distribués. Le concept s'appelle le théorème de Brewer CAP, qui résume:
Les trois exigences des systèmes distribués sont les suivantes: cohérence, disponibilité et tolérance de partition (CAP en abrégé). Mais vous ne pouvez en avoir que deux à la fois.
Et voici comment je l'ai résumé pour moi-même:
Vous feriez mieux de choisir NoSQL si la consistance est ce que vous sacrifiez.