Les bases de données se font découper maintenant, tu as le stockage qui se fait en nosql clé valeur (voir sur du stockage objet) et/ou en colonne, tu as un moteur sql qui peu être exécuté sur du faas et par dessus tu as des implémentation de protocoles sql ou non.
Pour moi le SQL (et donc le NoSQL) ça ne dit absolument rien du stockage sous-jacent. Du coup la différence entre SQL et NoSQL aujourd’hui ce serait, comme tu le dis je crois, d’un côté de solutions qui t’imposent l’utilisation de SQL pour enregistrer er accéder à la donnée, d’un langage particulier donc, et de l’autre des solutions où l’emploi de SQL n’est qu’une option parmi d’autre. Je vois qu’effectivement on dit plus ou moins la même chose.
La différence fait peu de sens je suis d’accord avec toi, étant donné que dans NoSQL il y a différents types, orientés documents ou autre. Je crois que ce qui est nouveaux aujourd’hui (par rapport à l’époque où SQL est apparu) c’est la quantité tellement énorme de données à traiter, que l’idée même de la structurer fortement n’est pas un sujet, étant donné qu’on doit d’abord trouver des solutions pour savoir comment la stocker (et y accéder) de manière efficace, donc de manière distribuée et traitée en parallèle par plusieurs nœuds.
C’est pas forcément la meilleure solution pour tous les besoins mais l’aspect big-data et scalabilité a l’air d’être pris en compte de manière plutôt satisfaisante. C’est assez loin de n’être plus qu’un « SGBD à papa » qui se contente de remplir ses fonctionnalités historiques de moteur de base de données relationnelle. Et c’est bien heureux !
[^] # Re: Tout se paye un jour ou l'autre
Posté par Marotte ⛧ . En réponse au journal Tour d'horizon de l'état des bases NoSQL. Évalué à 6. Dernière modification le 24 décembre 2023 à 01:35.
Pour moi le SQL (et donc le NoSQL) ça ne dit absolument rien du stockage sous-jacent. Du coup la différence entre SQL et NoSQL aujourd’hui ce serait, comme tu le dis je crois, d’un côté de solutions qui t’imposent l’utilisation de SQL pour enregistrer er accéder à la donnée, d’un langage particulier donc, et de l’autre des solutions où l’emploi de SQL n’est qu’une option parmi d’autre. Je vois qu’effectivement on dit plus ou moins la même chose.
La différence fait peu de sens je suis d’accord avec toi, étant donné que dans NoSQL il y a différents types, orientés documents ou autre. Je crois que ce qui est nouveaux aujourd’hui (par rapport à l’époque où SQL est apparu) c’est la quantité tellement énorme de données à traiter, que l’idée même de la structurer fortement n’est pas un sujet, étant donné qu’on doit d’abord trouver des solutions pour savoir comment la stocker (et y accéder) de manière efficace, donc de manière distribuée et traitée en parallèle par plusieurs nœuds.
Je m’étais jamais penché sur la question mais Postgres semble bien effectivement ne plus faire de différence et assumer clairement la compétition avec d’autres produit étiquetés NoSQL : https://www.nobledesktop.com/classes-near-me/blog/why-learn-postgresql-for-data-science
C’est pas forcément la meilleure solution pour tous les besoins mais l’aspect big-data et scalabilité a l’air d’être pris en compte de manière plutôt satisfaisante. C’est assez loin de n’être plus qu’un « SGBD à papa » qui se contente de remplir ses fonctionnalités historiques de moteur de base de données relationnelle. Et c’est bien heureux !