Y at-il quelque chose de révolutionnaire à propos de NoSQL? [fermé]


46

Je suis un type très solide dans la base de données relationnelle et je comprends parfaitement la 3ème forme normale, j'apprécie les racines de la théorie des ensembles algébriques de SQL et je peux probablement relationaliser un cœur brisé (ou pas).

Je n'ai pas encore trouvé de structure de base de données relationnelle POUR les soirées de rendez-vous avec ma femme, mais j'ai réfléchi aux projets de bases de données relationnelles les soirs de rendez-vous avec ma femme.

Maintenant, j'entends parler de NoSQL et je fais des recherches. Pour aller droit au but, y a-t-il quelque chose à propos de NoSQL qui soit révolutionnaire, mathématiquement nouveau, ou un "hé vous n'avez même pas vraiment besoin d'organiser vos données de manière relationnelle, c'est tellement plus simple"?

NoSQL ressemble-t-il à un super shell pour la structure de données? Dans mon esprit, les données doivent en fin de compte avoir une structure pour pouvoir être récupérées et la récupération doit être définie dans un langage quelconque.


2
Quels types de bases de données NoSQL n'ont pas de structure? Les bases de documents peuvent être hiérarchisées, mais elles stockent de manière minimale leurs données dans des documents contenant les données dans un format donné. Les bases de données graphiques et les magasins de valeurs-clés sont assez explicites. Quelles bases de données NoSQL n'ont pas de langage à interroger? Certaines bases de documents sont simplement une recherche textuelle ou XQuery for XML, par exemple. SPARQL est utilisé pour les magasins RDF.
Thomas Owens

2
Mise à jour pour "J'ai pensé à des projets de bases de données relationnelles le soir de ma femme .." :) LOL. Bonne question aussi.
Rocklan

2
Les bases de données NoSQL ont une structure, mais la structure n'est pas toujours facile à mapper à l'algèbre relationnelle. Différentes NoSQL utilisent différentes structures. Certaines sont des types communs de NoSQL: hashmap, hiérarchique, base de données d'objets, base de données de graphes ou magasin de documents. Tout ce que NoSQL est réellement, c’est la prise de conscience que SQL n’est pas une panacée, que certains domaines problématiques sont mal mappés à l’algèbre SQL / relationnelle.
Lie Ryan

7
NoSQL est un nom trompeur. Cela implique un groupe avec des caractéristiques alors que la seule caractéristique commune est de ne pas être une base de données relationnelle SQL classique. C'est un ensemble ouvert. C'est comme décrire chaque aliment qui n'est pas du pain comme "la famille des non-pains".
Pieter B

2
Ok, quel est le problème avec NoSQL? C'est facile: nous avons une génération de personnes qui ont grandi avec des bases de données relationnelles et c'était le seul outil dont elles disposaient. Parce que si vous n'avez qu'un marteau, tout devient un clou. Ensuite, vous obtenez des trucs laids comme essayer de placer des objets dans une base de données relationnelle ou de construire un moteur de recherche par dessus. La grande réalisation est que: une base de données SQL est bonne pour beaucoup de choses, mais pas pour tout. le "pas tout" est la grande chose.
Pieter B

Réponses:


24

NoSQL est plus évolutif que révolutionnaire. Il combine essentiellement les idées existantes de "stockage de base de données externe" avec "l'utilisation de structures de données familières, pas de tables relationnelles".

Il existe plus de types de bases de données que de bases de données relationnelles, par exemple les bases de données hiérarchiques . Bien qu'archaïque par rapport aux normes actuelles, il s'intègre parfaitement dans les structures de données de ses données (par exemple, les enregistrements COBOL ). Le fait est que les données de la base de données ont été modélisées en fonction de la manière dont les enregistrements ont été disposés dans les langages de programmation qui les utilisaient.

Avance rapide vers l’invention des bases de données relationnelles , où la base de données a été séparée de ses préoccupations et, bien normalisée, est un excellent moyen de visualiser la plupart des types de données et les relations entre données. C'est vraiment facile à comprendre par rapport à d'autres types de bases de données. Cependant, ce qui échoue complètement, c’est stocker les données d’une manière qui reflète les objets et les classes d’un programme. D'où l'invention du mappage objet-relationnel . En d'autres termes, la conception de la base de données est en réalité un obstacle à la conception du programme qui l'utilise. C'est pourquoi nous avons besoin de bibliothèques ORM telles que Hibernate.. Bien que propre et cohérent, il y a toujours ce doute lancinant qui me tient à l’esprit que quelque chose ne va pas tout à fait.

Cela a donné lieu à deux autres types de bases de données, les bases de données objet et NoSQL .

Les deux cherchent à résoudre les problèmes introduits par les bases de données relationnelles sans nous exposer aux horreurs hallucinantes des bases de données hiérarchiques. Les données sont toujours présentées dans des référentiels qui ressemblent vaguement à des tableaux, mais ressemblent en réalité davantage à la programmation de structures de données qu'à des tableaux relationnels. Bien que les bases de données objet suivent principalement des règles bien définies, ma compréhension est que NoSQL est plutôt arbitraire. Par exemple, une table peut être visualisée sous forme de table de hachage ou de tableau. Il n’existe pas de moyen facile et bien défini de les interroger à l’aide d’un outil arbitraire analogue à Oracle SQL Developer ou SQL Server Management Studio .

L'idée est que l'on peut définir des structures de données qui sont facilement recherchées dans le code, plutôt que de reconstituer des requêtes SQL mieux adaptées à un moteur de base de données SQL plutôt que d'exprimer la requête souhaitée. Par exemple, les correspondances floues ou partielles sont plus difficiles et moins performantes dans une base de données relationnelle, alors qu'une base de données NoSQL peut avoir une structure optimisée pour une telle recherche et se terminer en une fraction du temps.

Il existe des langues pour interroger NoSQL. Cependant, il n'existe pas de langage universel tel que SQL pour les bases de données relationnelles.


Édition tardive:

Bien que je connaisse assez bien les bases de données NoSQL, cette question m'a incité à acheter un livre de qualité sur le sujet et à commencer à le lire avec l'objectif final d'être un véritable expert du sujet. Les autres commentaires sont basés sur NoSQL Distilled: un bref guide sur le monde émergent de la persistance polyglotte par Pramod Sadalage et Martin Fowler .

Les auteurs déclarent que les bases de données relationnelles ne s'adaptent pas parfaitement aux clusters capables de fournir les données nécessaires à des sites tels qu'Amazon et Google: NoSQL a été développé pour s'adapter à ce créneau, réduisant ainsi la concurrence et la durabilité d'ACID afin de traiter utilisent largement des données statiques (les transactions ACID ne sont donc pas aussi importantes).

En outre, ils soutiennent que les bases de données NoSQL fonctionnent sans schéma (page 10), ce qui permet aux bases de données NoSQL de modifier plus facilement la structure des données. Je ne suis pas sûr que la présence ou l'absence d'un schéma formel soit important à cet égard, car les bases de données SQL permettent également de modifier les schémas. Quoi qu'il en soit, les deux auteurs renommés font cette affirmation et mérite donc d'être examinée.

Je crois que ces deux points principaux ne font que renforcer mon argument principal, à savoir que NoSQL est évolutif et non révolutionnaire. Ils stockent toujours des données et apportent des améliorations incrémentielles à l’échelle et à la possibilité de modification. Ils soulignent également que NoSQL ne cherche pas à usurper les bases de données relationnelles en tant que roi du stockage de données, mais uniquement à fournir un moyen alternatif de stockage des données pour les types de données devant être redimensionnés et transformés de manière (vraisemblablement) relationnelle. les bases de données ne supportent pas assez bien.


2
Certaines bases de données NoSQL ont un langage de requête. J'ai déjà utilisé XQuery et SPARQL auparavant, si les données sont stockées au format XML ou RDF. Ces langues ont tendance à être structurées et à interroger. Mais là encore, cela ne couvre que les bases de données NoSQL qui contiennent des formats de données bien définis et ne font pas grand chose pour le texte ou les paires clé-valeur.
Thomas Owens

@ThomasOwens J'ai modifié ma réponse pour qu'elle soit plus précise.

1
Ceci est un aperçu intéressant de NoSQL mais ne répond pas vraiment à la question. Autant que je sache, la seule chose qui soit "révolutionnaire" à propos de NoSQL est que vos données n'ont pas besoin de se conformer à une structure spécifique avant d'être stockées.
Rocklan

2
In other words, the design of the database is actually a hindrance to the design of the program that uses it, ...J'ai l'impression que cela met souvent la charrue avant les boeufs. Pour les grandes entreprises disposant de grands ensembles de données, les données sont extrêmement précieuses et resteront très longtemps - plus longtemps que les langages de programmation, outils et paradigmes actuels. Il serait peut-être plus exact de dire que la programmation orientée objet est un obstacle à la conception de la base de données. Essayer de modifier la conception de la base de données pour l'adapter au paradigme de la programmation n'est peut-être pas la meilleure idée.
Doval

2
Je soulignerai simplement que nous utilisons tous encore une implémentation héritée d'une base de données hiérarchique - cela s'appelle un système de fichiers.
Wyatt Barnett

13

Je pense que vous aimeriez vraiment regarder cet article d'Erik Meijer & Gavin Bierman intitulé "Contrairement à la croyance populaire, SQL et NoSQL ne sont en réalité que deux faces d'une même pièce" . En bref, elle affirme que, mathématiquement, les deux approches reposent sur la même théorie, mais avec quelques différences.

Quelques différences intéressantes sont, de mon point de vue, les suivantes: le sens des dépendances croisées (FK en SQL) est le contraire dans SQL et NoSQL et le type de collections n'est pas limité à être défini dans NoSQL (et donc certaines opérations théoriques pourrait ne plus être utilisé dans le monde NoSQL, mais d’autres sont toujours valables). Un autre point intéressant de l'article est le langage de requête unique proposé pour interroger les bases de données SQL et NoSQL. Cela s'appelle LINQ, et si vous pensez avoir déjà entendu ce nom, vous avez raison: c'est le langage d'interrogation de Microsoft à partir de C #.


1
"Un autre point intéressant de l'article est le langage de requête unique proposé pour interroger les bases de données SQL et NoSQL. Il s'appelle LINQ", ce n'est pas tout à fait vrai. doit se produire pour le faire fonctionner sur des bases de données SQL. Ce qui signifie que tout peut être introduit pour interroger les deux, à condition qu'il y ait une couche de traduction assurant son exécution sur la base de données cible
Frans Bouma

6
Eh bien, on peut affirmer que SQL n'est pas également exécuté directement sur une base de données. Ce qui est exécuté est un plan d'exécution, et on peut également affirmer que Linq pourrait être traduit directement dans le plan d'exécution. Donc, pas de grande différence après tout.
Haspemulator

10

La réponse de Snowman décrit correctement la différence entre les structures de données SQL et NoSQL et les méthodes d'accès à celles-ci. Cependant, une différence probablement encore plus importante est leur domaine de problèmes respectif.

NoSQL n'est pas un successeur de SQL. Au contraire, les différentes branches de NoSQL sacrifient certaines qualités de SQL pour être meilleures à d’autres . Le théorème CAP indique qu'il est impossible pour un système de base de données réparti de satisfaire toutes les propriétés suivantes:

  • Cohérence
  • Disponibilité
  • Tolérance de partition

Ainsi, certaines variantes de NoSQL suivent plutôt le principe BASE , qui assouplit la contrainte de cohérence permanente de ACID , qui constitue la base des bases de données SQL classiques. En perdant certaines garanties de cohérence, ils ont la possibilité de combiner haute disponibilité et tolérance de partition dans des systèmes largement distribués, tels que les sites Web contenant de grandes quantités de données et de requêtes des utilisateurs, sans trop exiger une cohérence parfaite. Ainsi, ces bases de données NoSQL sont au cœur de Google , Facebook et Amazon . Donc, pour répondre à votre question: Oui, NoSQL est novateur en ce sens qu’il permet à peu près autant de services Web gigantesques.

Ce n’est qu’un exemple, car NoSQL est un domaine très diversifié et ses variantes couvrent à peu près toutes les combinaisons de paramètres possibles dans le triangle CAP .


Je ne connais pas ElasticSearch. Une recherche rapide sur Google semble montrer qu’elle sacrifie la consistance (C), et est donc AP, pas CAP, ce qui est théoriquement impossible. Edit: C’est en réponse à un commentaire qui a maintenant disparu que ElasticSearch remplit toutes les propriétés du CAP.
Florian von Stosch

3
Oh comme c'est mignon, ils sont allés avec BASE pour contrer ACID. Existe-t-il une approche intermédiaire appelée REDOX ou SALT?
Patrick M

3

Les cas d'utilisation courants de NoSQL sont révolutionnaires en termes de gains de productivité par rapport aux bases de données courantes basées sur SQL. Il y a plusieurs facteurs dans ceci.

L'un est le ménage. La plupart des NoSQL sont open source et peuvent être installés sur un poste de travail ou une machine virtuelle à l’aide de quelques commandes, et fonctionnent avec des valeurs par défaut raisonnables. D'après mon expérience, même Postgres et MySQL ne le sont pas. la configuration est généralement nécessaire pour démarrer même sur un poste de travail à des fins de développement.

Un autre est le développement commode, comme d'autres réponses l'ont décrit en détail. Les fonctionnalités d’indexation JSON de Mongo, ou la sémantique clé / valeur de redis et de Riak, peuvent être l’ensemble des applications Web nécessaires pour que le travail soit effectué, et les API sont simples à utiliser. Certains NoSQL fournissent leurs propres API RESTful, alors qu'avec SQL, vous devez généralement les écrire vous-même.

Ces facteurs rendent les bases de données NoSQL attrayantes pour les projets de petite taille. Le temps de prise en charge a tendance à être faible. Bien sûr, en production, vous devez configurer la sécurité et l’échelle, mais la capacité de commencer à coder et à collaborer rapidement est puissante et, à mon sens, révolutionnaire.

De plus, en relation avec ce qui précède, pour les applications à petite échelle (telles que les services internes à l'entreprise ou les applications d'application à application), une équipe peut être en mesure de gérer une base de données NoSQL de production sans impliquer ses équipes d'administrateurs de base de données et sans compromettre les performances ou l'intégrité. problèmes en conséquence. Les administrateurs de base de données professionnels peuvent ne pas aimer cela, mais les développeurs qui y voient une source d'obstruction (juste ou non) voient parfois NoSQL comme un moyen d'éviter de devoir les gérer. J'avoue avoir déjà changé une application à petite échelle de Postgres à SQLite pour supprimer le DBA contradictoire et j'ai choisi de l'implémenter sur Mongo plutôt que sur Oracle pour éviter les processus d'approbation DBA et les restrictions d'accès. Sans conséquences néfastes dans les deux cas.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.