Qu'est-ce que NoSQL, comment fonctionne-t-il et quels avantages apporte-t-il?
J'ai entendu parler de NoSQL et du fait que cela pourrait éventuellement remplacer les méthodes de stockage SQL dans la base de données, du fait que l'interaction entre bases de données est souvent un gouffre pour la vitesse sur le Web.
Donc, j'ai juste quelques questions:
C'est quoi exactement?
Comment ça marche?
Pourquoi serait-il préférable que d'utiliser une base de données SQL? Et combien est-ce mieux?
La technologie est-elle trop nouvelle pour être appliquée ou faut-il s'y intéresser?
De quoi s'agit-il exactement?
D'une part, un système spécifique , mais il est également devenu un mot générique pour un variété de nouveaux systèmes de stockage de données qui ne suit pas le modèle de base de données relationnelle.
Comment ça marche?
Chacun des systèmes étiquetés avec le nom générique fonctionne différemment, mais l’idée de base est d’offrir une meilleure évolutivité et de meilleures performances en utilisant des modèles de base de données qui ne prennent pas en charge toutes les fonctionnalités d’un SGBDR générique, mais qui sont néanmoins suffisantes pour être utiles. D'une certaine manière, c'est comme MySQL, qui à une époque manquait de support pour les transactions mais, exactement parce que, réussissait à surperformer les autres systèmes de base de données. Si vous pouviez écrire votre application d'une manière qui n'exigeait pas de transactions, c'était génial.
Pourquoi serait-il préférable que d'utiliser une base de données SQL? Et à quel point est-il meilleur?
Il serait préférable que votre site évolue si massivement que le meilleur SGBDR fonctionnant sur le meilleur matériel que vous pouvez vous permettre et optimisé autant que possible ne peut tout simplement pas suivre la charge. L’amélioration dépend du cas d’utilisation spécifique (beaucoup d’activités de mise à jour combinées à de nombreuses jointures sont très difficiles avec les SGBDR "traditionnels") - pourrait bien être un facteur de 1000 dans les cas extrêmes.
La technologie est-elle trop nouvelle pour pouvoir être mise en œuvre ou vaut-elle la peine d'être examinée?
Cela dépend principalement de ce que vous essayez d’atteindre. C'est certainement assez mature pour l'utiliser. Mais peu d’applications doivent réellement évoluer à grande échelle. Pour la plupart, un SGBDR traditionnel suffit. Cependant, étant donné que l'utilisation d'Internet devient de plus en plus omniprésente, il est fort probable que les applications qui le deviennent deviendront plus courantes (bien que probablement pas dominantes).
NoSQL n'existe pas!
NoSQL est un mot à la mode.
Pendant des décennies, lorsque les gens parlaient de bases de données, ils désignaient des bases de données relationnelles. Et quand les gens parlaient de bases de données relationnelles, elles désignaient celles que vous contrôlez avec le langage de requête structuré d'Edgar F. Codd. Stocker des données d'une autre manière? La démence! Tout le reste n'est que flatfiles.
Mais ces dernières années, les gens ont commencé à remettre en question ce dogme. Les gens se demandaient si les tableaux avec des lignes et des colonnes étaient vraiment le seul moyen de représenter des données. Les gens ont commencé à réfléchir et à coder, et ont proposé de nombreux nouveaux concepts pour organiser les données. Et ils ont commencé à créer de nouveaux systèmes de base de données conçus pour ces nouvelles façons de travailler avec les données.
Les philosophies de toutes ces bases de données étaient différentes. Cependant, toutes ces bases de données avaient un point commun: le langage de requête structuré ne leur permettait plus de les utiliser. Chaque base de données a donc remplacé SQL par son propre langage de requête. C'est ainsi que le terme NoSQL est né, en tant qu'étiquette pour toutes les technologies de base de données qui défient le modèle de base de données relationnel classique.
Alors, qu'est-ce que les bases de données NoSQL ont en commun?
En fait, pas grand chose.
Vous entendez souvent des phrases telles que:
- NoSQL est évolutif!
- NoSQL est pour BigData!
- NoSQL viole ACID!
- NoSQL est un magasin clé/valeur glorifié!
Est-ce vrai? Certaines de ces déclarations peuvent être vraies pour certaines bases de données communément appelées NoSQL, mais chacune d’elles est également fausse pour au moins une autre. En réalité, les bases de données NoSQL ont un point commun: ce sont des bases de données qui n'utilisent pas SQL. C'est ça. La seule chose qui les définit est ce qui les distingue les uns des autres.
Alors, qu'est-ce qui distingue les bases de données NoSQL?
Nous avons donc précisé que toutes les bases de données communément appelées NoSQL sont trop différentes pour être évaluées ensemble. Chacun d’entre eux doit être évalué séparément pour décider s’il est bien adapté à la résolution d’un problème spécifique. Mais par où commençons-nous? Heureusement, les bases de données NoSQL peuvent être regroupées dans certaines catégories, qui conviennent à différents cas d'utilisation:
orienté document
Exemples: MongoDB, CouchDB
Points forts: Données hétérogènes, orienté objet de travail, développement agile
Leur avantage est qu'ils ne nécessitent pas une structure de données cohérente. Ils sont utiles lorsque vos exigences et, par conséquent, la structure de votre base de données changent constamment, ou lorsque vous traitez avec des jeux de données qui vont ensemble mais qui ont toujours une apparence très différente. Lorsque vous avez beaucoup de tables à deux colonnes appelées "clé" et "valeur", il peut être intéressant de les examiner.
bases de données graphiques
Exemples: Neo4j, GiraffeDB.
Points forts: Data Mining
Tandis que la plupart des bases de données NoSQL abandonnent le concept de gestion des relations de données, ces bases de données l’engloutissent encore plus que ces bases dites relationnelles.
Leur objectif est de définir les données en fonction de leur relation avec d'autres données. Lorsque vous avez beaucoup de tables avec des clés primaires qui sont les clés primaires de deux autres tables (et peut-être des données décrivant la relation entre elles), elles pourraient alors vous intéresser.
Magasins de valeurs clés
Exemples: Redis, Cassandra, MemcacheDB
Points forts: Recherche rapide des valeurs par des clés connues
Ils sont très simplistes, mais cela les rend rapide et facile à utiliser. Lorsque vous n'avez pas besoin de procédures stockées, de contraintes, de déclencheurs et de toutes ces fonctionnalités de base de données avancées et que vous souhaitez simplement un stockage et une récupération rapides de vos données, ils sont faits pour vous.
Malheureusement, ils supposent que vous savez exactement ce que vous recherchez. Vous avez besoin du profil de User157641? Pas de problème, il ne faudra que quelques microsecondes. Mais que faire lorsque vous voulez que les noms de tous les utilisateurs âgés de 16 à 24 ans aient des "gaufres" comme aliment préféré et qu'ils se soient connectés au cours des dernières 24 heures? Mauvais chance. Lorsque vous ne disposez pas d'une clé unique et définitive pour un résultat spécifique, vous ne pouvez pas l'obtenir facilement de votre magasin K-V.
SQL est-il obsolète?
Certains partisans de NoSQL affirment que leur base de données NoSQL préférée constitue la nouvelle façon de faire les choses et que SQL appartient au passé.
Ont-ils raison?
Non, bien sûr, ils ne sont pas. Bien que SQL ne soit pas adapté à certains problèmes, il conserve ses points forts. De nombreux modèles de données sont simplement mieux représentés comme un ensemble de tableaux qui se référent les uns aux autres. Surtout parce que la plupart des programmeurs de bases de données ont été formés pendant des décennies à penser les données de manière relationnelle, et qu’il est très difficile d’essayer de placer cet état d’esprit sur une nouvelle technologie qui n’a pas été conçue.
Les bases de données NoSQL ne remplacent pas SQL, elles constituent une alternative.
La plupart des écosystèmes logiciels autour des différentes bases de données NoSQL ne sont pas encore aussi matures. Bien que des progrès aient été réalisés, vous n’avez toujours pas d’outils supplémentaires, aussi avancés et performants que ceux disponibles pour les bases de données SQL courantes.
En outre, il existe beaucoup plus de savoir-faire en matière de SQL. Des générations d'informaticiens ont consacré des décennies de leur carrière à la recherche sur les bases de données relationnelles, et cela montre que: La littérature consacrée aux bases de données SQL et à la modélisation de données relationnelles, à la fois théoriques et théoriques, pourrait remplir de multiples bibliothèques remplies de livres. Comment construire une base de données relationnelle pour vos données est un sujet si bien documenté qu'il est difficile de trouver un exemple concret où il n'y a pas de meilleure pratique généralement acceptée telle que définie dans le livre.
La plupart des bases de données NoSQL, par contre, en sont encore à leurs balbutiements. Nous sommes toujours en train de trouver le meilleur moyen de les utiliser.
Puisque quelqu'un a dit que mon précédent article était hors sujet, je vais essayer de compenser :-) NoSQL n'est pas et n'a jamais été destiné à remplacer des bases de données SQL plus classiques, mais quelques mots suffisent pour obtenir les choses dans la bonne perspective.
Au cœur même de la philosophie NoSQL , il est pris en compte le fait que, peut-être pour des raisons commerciales et de portabilité, les moteurs SQL ont tendance à ignorer la puissance énorme du système d'exploitation UNIX et de ses dérivés.
Avec une base de données basée sur un système de fichiers, vous pouvez profiter immédiatement des capacités et de la puissance sans cesse croissantes du système d'exploitation sous-jacent, qui ne cessent d'augmenter depuis de nombreuses années maintenant, conformément à la loi de Moore. Avec cette approche, de nombreuses commandes du système d'exploitation deviennent automatiquement aussi des "opérateurs de base de données" (pensez à "ls" "trier", "rechercher" et aux nombreux autres utilitaires UNIX Shell).
En gardant cela à l'esprit, et avec un peu de créativité, vous pouvez effectivement concevoir une base de données basée sur un système de fichiers capable de surmonter les limitations de nombreux moteurs SQL courants, du moins pour des modèles d'utilisation spécifiques, ce qui est le fondement de la philosophie de NoSQL, comme je le vois.
Je gère des centaines de sites Web et tous utilisent NoSQL dans une mesure plus ou moins grande. En fait, ils n'hébergent pas d'énormes quantités de données, mais même si certains d'entre eux le faisaient, je pourrais probablement penser à une utilisation créative de NoSQL et du système de fichiers permettant de surmonter les goulets d'étranglement. Quelque chose qui serait probablement plus difficile avec les "prisons" SQL traditionnelles. Je vous exhorte à google pour "unix", "manis" et "shaffer" pour comprendre ce que je veux dire.
Si je me souviens bien, cela fait référence aux types de bases de données qui ne suivent pas nécessairement la forme relationnelle. On pense aux bases de documents, aux bases de données dépourvues de structure spécifique et n'utilisant pas SQL comme langage de requête spécifique.
Il est généralement mieux adapté aux applications Web qui s'appuient sur les performances de la base de données et ne nécessitent pas de fonctionnalités plus avancées des moteurs de base de données Relation. Par exemple, un magasin de clés-> valeur fournissant une requête simple par interface id peut être 10 à 100 fois plus rapide que l'implémentation du serveur SQL correspondant, avec un coût de maintenance inférieur pour le développeur.
Un exemple est ceci paper pour un OLTP Tuple Store, qui sacrifie les transactions pour le traitement à un seul thread (pas de problème de simultanéité, car aucune simultanéité n'est autorisée ), et a gardé toutes les données en mémoire; obtention de 10 à 100 fois de meilleures performances par rapport à un système similaire RDBMS . Fondamentalement, il s’éloigne de la vue "Taille unique" de SQL et des systèmes de base de données.
En pratique, NoSQL est un système de base de données qui permet un accès rapide à de gros objets binaires (docs, jpgs, etc.) à l’aide d’une stratégie d’accès basée sur des clés. Ceci diffère de l'accès SQL traditionnel, qui ne convient que pour les valeurs alphanumériques. Non seulement la stratégie de stockage interne et d'accès, mais également la syntaxe et les limitations du format d'affichage restreignent le SQL traditionnel. Les implémentations BLOB de bases de données relationnelles traditionnelles souffrent également de ces restrictions.
En coulisse, c'est un aveu indirect de l'échec du modèle SQL à prendre en charge toute forme de OLTP ou à prendre en charge de nouveaux formats de données. "Support" signifie non seulement stocker mais aussi des capacités d'accès complet - par programmation et par requête à l'aide du modèle standard.
Les enthousiastes relationnels ont rapidement modifié la définition de NoSQL de Not-SQL à Not-Only-SQL pour que SQL reste toujours dans l’image! Ce n'est pas bon, surtout quand on voit que la plupart des Java programmes actuels ont recours au mappage ORM du modèle relationnel sous-jacent. Un nouveau concept doit avoir une définition claire. Sinon, ça va finir comme SOA.
La base des systèmes NoSQL réside dans la paire clé/valeur aléatoire. Mais ce n'est pas nouveau. Les systèmes de base de données traditionnels tels que IMS et IDMS prenaient en charge les clés ramdom hachées (sans utiliser d'index) et le font toujours. En fait, IDMS a déjà un mot clé NONSQL qui permet l’accès SQL à la base de données réseau plus ancienne qu’ils ont appelée NONSQL.
NoSQL le programme actuel semble être une base de données relationnelle implémentée dans awk en utilisant des fichiers plats sur le backend. Bien qu'ils prétendent, "NoSQL n'a essentiellement aucune limite arbitraire et peut fonctionner là où d'autres produits ne le peuvent pas. Par exemple, il n'y a pas de limite de taille de champ de données, de nombre de colonnes ou de taille de fichier", je ne pense pas que ce soit le cas. la base de données à grande échelle du futur.
Comme le dit Joel, les bases de données massivement évolutives telles que BigTable ou HBase , sont beaucoup plus intéressantes. GQL est le langage de requête associé à BigTable et à App Engine. Il est en grande partie modifié avec SQL pour éviter les fonctionnalités que Google considère comme des goulots d'étranglement (comme les jointures). Cependant, je n'ai jamais entendu parler de cela "NoSQL" auparavant.
C'est comme Jacuzzi: une marque et un nom générique. Ce n'est pas simplement une technologie spécifique, mais plutôt un type de technologie, faisant ici référence à des "bases de données" à grande échelle (souvent éparses) telles que BigTable ou CouchDB de Google.
NoSQL est un système de base de données qui n'utilise pas de requêtes SQL basées sur des chaînes pour extraire des données.
Au lieu de cela, vous créez des requêtes à l'aide de l'API fournie, par exemple, Amazon DynamoDB est un bon exemple de base de données NoSQL.
Les bases de données NoSQL conviennent mieux aux grandes applications où l'évolutivité est importante.
NoSQL signifie-t-il une base de données non relationnelle?
Oui, NoSQL est différent du SGBDR et de l'OLAP. Il utilise des modèles de cohérence plus souples que les bases de données relationnelles traditionnelles.
Les modèles de cohérence sont utilisés dans des systèmes distribués tels que des systèmes à mémoire partagée distribuée ou un magasin de données distribué.
Comment ça marche en interne?
Les systèmes de base de données NoSQL sont souvent hautement optimisés pour les opérations de récupération et d’ajout et offrent souvent peu de fonctionnalités autres que le stockage d’enregistrements (par exemple, les magasins de valeurs clés). La flexibilité d'exécution réduite par rapport aux systèmes SQL complets est compensée par des gains marqués en termes d'évolutivité et de performances pour certains modèles de données.
Il peut fonctionner sur des données structurées et non structurées. Il utilise des collections au lieu de tables
Comment interrogez-vous une telle "base de données"?
Regarder SQL vs NoSQL: La bataille du backends ; ça explique tout.