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

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.

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.

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 #.

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 .

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.