Le mouvement anti-SQL s'amplifie ?

Le , par Annaelle32, Correspondant Actualités
Les adversaires de SQL multiplient les actions de protestation contre ce qu’ils appellent « la tyrannie » exercée par SQL dans l’univers de la gestion des bases des données. Mais la relève est-elle bien prête et constitue une alternative fiable et tout aussi bien performante ?
Rencontre NoSQL

Ceux qui disent non à SQL ont organisé, le mois dernier, une rencontre à San Francisco, pour discuter de leurs soucis quant à l’hégémonie de SQL. Cette rencontre, hébergée dans une salle de réunion de CBS Interactive, a vu la participation de 150 personnes, issues de divers horizons informatiques. En décrétant la fin du règne de SQL, ils préconisent des solutions moins onéreuses mais tout aussi efficaces pour gérer les bases de données.
L’un des orateurs, Jon Travis, directeur en système de base de données relationnelles chez SrpingSource, a déclaré que SQL étouffe ses utilisateurs par de nombreux modules ou outils qui leur obligent à tous les coups à maltraiter leurs bases de données. Pourquoi ne pas leur offrir juste ce dont ils auraient besoins ?

Éveil de l’open source

Les grands initiateurs de ce mouvement sont les développeurs Web et Java. En effet, ils ont essayé par leurs propres moyens de créer leurs propres outils de gestion de base de données, faisant fi des prestiges d’Oracle, et en s’inspirant des divers programmes open source livrés sur le net. L’un des organisateurs de la rencontre NoSQl, Johan Oskarsson, lui aussi développeur mais basé à Londres, martelaient que les participants doivent prendre des risques et être convaincus des solutions NoSQL. Il continue en affirmant que beaucoup de développeurs assez fidèles à MySQL, l’ont abandonné au profit de Web 2.0, une alternative NoSQL dont les avantages certains ne peuvent pas être volontairement mis sous silence. L’exemple de Facebook a été évoqué pour étayer cette thèse. En effet, selon l’ingénieur de Facebook, Avinash Lakshman, son stockage de données fait confiance à Cassandra pour les interrogations, plutôt que de se servir de MySQL. Comme pour mieux justifier son choix il affirme qu’il ne faut que 0,12s pour écrire dans sa base jusqu’à 50Gb de données. Soit 2500 fois plus rapide que MySQL.

NoSQL

Ce terme désigne, en fait, un ensemble de projets dont la finalité reste le rejet définitif de tout ce qui se réfère au gestionnaire SQL. Selon ses concepteurs, chaque projet revêt son propre nom, au gré de leurs fantaisies : Hadoop, Voldemort, Dynomite, entre autres. Google appelle Bigtable, sa base de données.

Une des caractéristiques communes de NoSQL, c’est que ces logiciels peuvent manipuler d’énormes volumes de données et se sont inspirés sur le modèle de Bigtable. Ainsi, selon un ingénieur de Zvents, Doug Judd, le moteur de la base peut écrire sur 1 milliard de cellules de données par jour. En attendant, Bigtable conjointement avec la technologie MapReduce arrive jusqu’à 1 pétaoctets de données par jour. Et TRavis de SpringSource d’appuyer que les gens traitent tellement de grandes quantités de données qu’ils recherchent d’autres solutions plus avantageuses, bref d’autres alternatives que celles proposées par SQL.

La solution NoSQL permet également de bénéficier d’une grande souplesse de l’étendue des clusters, si bien qu’il ne sera plus nécessaire de morceler les grands paquets de données vers plusieurs autres tables. Cette technologie est doublement rentable tant en terme de fiabilité qu’en terme de coût d’exploitation. Google confirme en annonçant que l’un de ses plus grands clusters gèrent plus 6 pétaoctets de données sur des milliers de serveurs. Bien sûr, disait Javier Soltero de SpringSource, le Rac (Real Apllication Clusters) d’Oracle pourrait offrir une performance identique, mais quel sera le prix à payer ?

De plus, la technologie adoptée dans NoSQL élimine les goulots d’étranglement générés par les outils traditionnels, notamment en offrant des formats plus fluides dans les opérations de traduction. Du côté d’Adobe System Inc, les concepteurs se sont aussi tournés vers la solution NoSQL lors de sa relance d’Adobe ConnectNow pour la simple raison que MySQL ne semble pas s’adapter à des bases de données très simples. Cette nouvelle version de ConnectNow s’appuie sur le clustering Java de Terracotta Inc pour gérer ses formats java, ce qui lui a donné deux fois plus de rapidité, comparée à la précédente version, un système de base de données relationnelles étant complètement inadapté.

Open source
Du fait ces options NoSQL sont conçues open source, ces logiciels ne bénéficient pas (encore) d’un cadre officiel de soutien. Ce qui n’est le cas pour certains qui peuvent s’acquérir d’une protection matérielle et financière.
Bref, autant d’arguments plus ou moins objectifs et rationnels qui cultivent l’esprit NoSQL. Quoiqu’il en soit, une frange de développeurs ne peut s’empêcher de se demander s’il est vraiment raisonnable de prendre les Hadoop, Voldemort au sérieux !

Voir aussi
Le portail SGBD
Le portail SQL
Les forums SGBD

Qu'en pensez vous?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Erwy Erwy - Rédacteur http://www.developpez.com
le 08/07/2010 à 10:53
Citation Envoyé par fsmrel  Voir le message
Mais tout SGBD relationnel (le mien en tout cas) gère son propre catalogue actif (organisé sous forme de vues, donc accessible à coup de requêtes SQL), que l’on peut interroger pour connaître à tout moment l’impact du moindre changement sur les tables, les vues, les assertions, les triggers, les contraintes référentielles, les procédures, les programmes contenant des requêtes SQL, etc.

Pour ma culture, ou est-ce qu'on peut trouver de la doc sur ce sujet.
C'est l'un de mes gros points faibles en base de donnée

Par rapport à l'évolution d'un modèle de donnée je pense que j'ai mal exprimer ma pensée, ce n'est pas mon domaine d'origine donc je manque un peu de vocabulaire théorique...
Le mieux est peut être que reprenne l'analogie de la construction de la maison
Si on considère une maison,percer une fenêtre, une porte , constuire une annexe comme un garage ne change pas réellement la nature de ma maison ( à condition de respecter certaines contraintes comme faire attention au mur porteur prévoir les lintaux dalles etc...) de même que rajouter des tables et , à la limite des colonnes (à conditions qu'il n'y ait pas un couillon qui ait laissé trainer un select * ).De mon point de vue ce n'est pas une vrai évolution du modéle (toutes proportions gardées).
Par contre rajouter un étage, là c'est un problème et si ce n'était pas prévu dès l'origine , tu risque fort en plus un jour , de pouvoir visiter ton grenier sans avoir besoin d'y monter, de même qu'éclater des tables ou concaténer des colonnes.Si on en arrive là , il y a de fortes chances que quelqu'un ce soit planté dans son analyse des données (si analyse il y a eu )

Pour ce qui est de l'analyse métier pour le modèle de donnée, de mon point de vue (et par rapport à mon milieu professionnel), il faut s'en méfier.
Il vaut mieux chercher à obtenir et analyser les données qu'ils utilisent en priorité (formulaire facture...).
Les métiers changent, évoluent et surtout , même quand ils sont théoriquement une "chaîne", cela ne marche pas forcement comme ça.
Je m'explique: soit 3 personnes A,B,C qui se transmettent l'information et F l'info origianl.
On doit faire une application pour B, et, dans un futur proche C.
A à l'information originale F il la traite et transmet le résultat à B qui effetue la même tâche et le transmet à C pour l'utilisation finale.
Dans ce magnifique fonctionnement théorique, il suffit de connaitre le format des données fournit par A pour avoir un schema de données utilisable pour B et C mais , dans ma réalité , si on creuse un peu , on s'aperçoit que :
- pour affiner et simplifier leur tavail on s'aperçoit que B et C utilisent F partiellement
- les rôles entre A et B ne sont pas toujours aussi clair que sur le papier pour
des raisons d'échelles d'effectifs et sont peut être amené à évoluer.
etc...
Donc à court terme, en basant son étude sur la production de A, on va dans le mur et il faudrait plutôt basé son modèle sur celui de F, même si on n'en utilise pas tout à l'instant T , il sera plus facile à faire évoluer à l'instant T+1.
J'ai un avantage c'est vrai.Dans ma branche, la nature de F bouge peu, et quand il y a changement, les concertations , et les implications, sont telles qu'on est prévenu au minimum 1 ou 2 ans avant, mais les "métiers" eux sont plutot "volatiles" , je ne pense pas néanmoins être une exception en informatique de gestion.
Avatar de SQLpro SQLpro - Rédacteur http://www.developpez.com
le 08/07/2010 à 13:54
Citation Envoyé par B.AF  Voir le message
...
Comment faites vous pour rendre cela testable, sans exploiter la base existante, avec un jeu de données permettant de répondre à l'ensemble des cas de production ?

Le faire sur un serveur de test avec un sauvegarde...
Quand à la couverture complète des cas, ne rêvez pas c'en est toujours au stade théorique quelque soit la technique, l'outil et les langages utilisés !
Mais il existe des robots de test pour SQL (non régression).

Citation Envoyé par B.AF  Voir le message
Comment faites vous les versionings ? (Modification de structure, plus modification de la donnée)

Un outil de modélisation comme Power AMC est fait pour cela !

A +
Avatar de B.AF B.AF - Membre chevronné http://www.developpez.com
le 08/07/2010 à 14:14
Citation Envoyé par SQLpro  Voir le message
Le faire sur un serveur de test avec un sauvegarde...
Quand à la couverture complète des cas, ne rêvez pas c'en est toujours au stade théorique quelque soit la technique, l'outil et les langages utilisés !
Mais il existe des robots de test pour SQL (non regeression).

Un outil de modélisation comme Power AMC est fait pour cela !

A +

PowerAmc fait des choses mais il ne peut pas créer de l'intelligence métier.
La couverture complète des cas, c'est une des applis que j'ai créé qui tient plusieurs milliers de transactions par jour avec un sla sur la latence et la qualité. 100% des domaines fonctionnels de l'application sont testés et testables. Et mine de rien, le temps perdu à le faire et un vrai temps gagné à la maintenance. Ce n'est pas un rêve c'est parfaitement possible.
Avatar de SQLpro SQLpro - Rédacteur http://www.developpez.com
le 08/07/2010 à 14:44
Citation Envoyé par Erwy  Voir le message
Pour ma culture, ou est-ce qu'on peut trouver de la doc sur ce sujet.
C'est l'un de mes gros points faibles en base de donnée

Par défaut ce sont les vues d'information de schéma : http://sqlpro.developpez.com/cours/s...age=partie2#L9

Citation Envoyé par Erwy  Voir le message
Par rapport à l'évolution d'un modèle de donnée je pense que j'ai mal exprimer ma pensée, ce n'est pas mon domaine d'origine donc je manque un peu de vocabulaire théorique...
Le mieux est peut être que reprenne l'analogie de la construction de la maison
Si on considère une maison,percer une fenêtre, une porte , constuire une annexe comme un garage ne change pas réellement la nature de ma maison ( à condition de respecter certaines contraintes comme faire attention au mur porteur prévoir les lintaux dalles etc...) de même que rajouter des tables et , à la limite des colonnes (à conditions qu'il n'y ait pas un couillon qui ait laissé trainer un select * ).De mon point de vue ce n'est pas une vrai évolution du modéle (toutes proportions gardées).
Par contre rajouter un étage, là c'est un problème et si ce n'était pas prévu dès l'origine , tu risque fort en plus un jour , de pouvoir visiter ton grenier sans avoir besoin d'y monter, de même qu'éclater des tables ou concaténer des colonnes.Si on en arrive là , il y a de fortes chances que quelqu'un ce soit planté dans son analyse des données (si analyse il y a eu )

Relisez les règles de CODD... en créant la théorie des SGBDR CODD avait tout prévue depuis le départ. Lisez en particulier les règles 8 à 11 et surtout la 9... Vous comprendrez que l'utilisation du modèle externe combiné au respect de cette règle permet une très grande souplesse !

Citation Envoyé par Erwy  Voir le message
Pour ce qui est de l'analyse métier pour le modèle de donnée, de mon point de vue (et par rapport à mon milieu professionnel), il faut s'en méfier.
Il vaut mieux chercher à obtenir et analyser les données qu'ils utilisent en priorité (formulaire facture...).
Les métiers changent, évoluent et surtout , même quand ils sont théoriquement une "chaîne", cela ne marche pas forcement comme ça.
Je m'explique: soit 3 personnes A,B,C qui se transmettent l'information et F l'info origianl.
On doit faire une application pour B, et, dans un futur proche C.
A à l'information originale F il la traite et transmet le résultat à B qui effetue la même tâche et le transmet à C pour l'utilisation finale.
Dans ce magnifique fonctionnement théorique, il suffit de connaitre le format des données fournit par A pour avoir un schema de données utilisable pour B et C mais , dans ma réalité , si on creuse un peu , on s'aperçoit que :
- pour affiner et simplifier leur tavail on s'aperçoit que B et C utilisent F partiellement
- les rôles entre A et B ne sont pas toujours aussi clair que sur le papier pour
des raisons d'échelles d'effectifs et sont peut être amené à évoluer.
etc...
Donc à court terme, en basant son étude sur la production de A, on va dans le mur et il faudrait plutôt basé son modèle sur celui de F, même si on n'en utilise pas tout à l'instant T , il sera plus facile à faire évoluer à l'instant T+1.
J'ai un avantage c'est vrai.Dans ma branche, la nature de F bouge peu, et quand il y a changement, les concertations , et les implications, sont telles qu'on est prévenu au minimum 1 ou 2 ans avant, mais les "métiers" eux sont plutot "volatiles" , je ne pense pas néanmoins être une exception en informatique de gestion.

J'ai mis en gras le point ou vous vous trompez.... On ne "formate" pas les données pour un usage. On format les données parc ce qu'elles ont intrinsèquement une signification au regard de la sémantique qu'elle contiennent....
A partir de là, votre modèle sera plus souple car il contiendra des données "purifiées" et non spécifique à un usage.
Chaque fois que l'on modélise pour un usage on se trouve bloqué.
C'est pourquoi il faut modéliser les données intrinsèquement et non spécifiquement, exercice en général difficile à faire pour des personnes orientées fonctionnel !
Ce qui ne veut pas dire que certaines entités et associations clairement identifiées et bien distinctes des autres ne soit spécifique au fonctionnel.

Par exemple dans mes modèles de données, je tague différemment les entités data, les entités pilotant les traitement ou les IHM et les entités contenant des données "externes".

A +
Avatar de B.AF B.AF - Membre chevronné http://www.developpez.com
le 08/07/2010 à 14:46
Citation Envoyé par SQLpro  Voir le message
On ne "formate" pas les données pour un usage. On format les données parc ce qu'elles ont intrinsèquement une signification au regard de la sémantique qu'elle contiennent....
A partir de là, votre modèle sera plus souple car il contiendra des données "purifiées" et non spécifique à un usage.
Chaque fois que l'on modélise pour un usage on se trouve bloqué.
C'est pourquoi il faut modéliser les données intrinsèquement et non spécifiquement, exercice en général difficile à faire pour des personnes orientées fonctionnel !

A +

Ca il faudrait le mettre en note que tout le monde puisse le lire et le relire. C'est excellent.
Avatar de fsmrel fsmrel - Expert éminent sénior http://www.developpez.com
le 08/07/2010 à 16:16
Citation Envoyé par B.AF  Voir le message
Imaginons que vous ayez une entité lambda.
Jusqu'à j, tout va bien, l'entité se suffit, et pour la traiter, il existe un jeu d'UDF ou de SP qui déterminent un résultat qui peut être exploité dans d'autres traitements métiers et éventuellement des triggers assurant un complément d'intégrité ou une validation métier le cas échéant.


Vous parlez de l’exploitation des données. On est donc hors de la modélisation des données proprement dite.

Citation Envoyé par B.AF  Voir le message
Un jour, la règle métier change avec un motif légal qui fait que n attributs de l'entité existent sur une plage de date valide.


Vous faites allusion aux données datées : une entité-type E comporte des attributs A1, .., Am dont les valeurs changent au fil du temps. E doit donc faire l’objet de m+1 entités-types. Tout d’abord E elle-même où chaque attribut A1, ..., Am, est accompagné d’un attribut T1, ..., Tm, tels que Ti est associé à Ai et est du type Date, cet attribut permettant de savoir à partir de quelle date la valeur prise par Ai prend effet. Par ailleurs, pour chaque Ai on met en œuvre une entité-type Hi associée à E par une relation de composition. Au niveau logique, Hi fait l’objet d’une table de structure {Ek, Ai, Di), où Ek représente la clé de la table E, Ai l’attribut de facto historisé et Di l’intervalle de temps, la période de validité de Ai.

A supposer que l’attribut Ek soit du type te, Ai du type tai, Ti du type Date et Di du type Intervalle_date, la structure correspondante est la suivante, dans le style de Tutorial D (qui n’est pas SQL !) :
Code D : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
  
E {Ek te, A1 ta1, ..., Am tam, T1 date, ..., Tm date, ...}  
    KEY {Ek} ; 
 
H1 {Ek te, A1 ta1, D1 intervalle_date} 
    KEY {Ek, D1} 
    FOREIGN KEY {Ek} REFERENCES E {Ek} ; 
... 
Hm {Ek te, Am tam, Dm intervalle_date} 
    KEY {Ek, Dm} 
    FOREIGN KEY {Ek} REFERENCES E {Ek} ;


Évidemment, les traitements ne doivent pas se contenter de manipuler l’attribut Ai, mais la paire {Ai, Ti} en ce qui concerne la table E et la paire {Ai, Di} en ce qui concerne la table Hi. C’est le prix à payer (conséquence d'une modélisation Naf-Naf) pour traiter des données temporelles (ou plus généralement intervallaires). Du point de vue de la théorie relationnelle, la table E doit respecter la cinquième forme normale et la table Hi la sixième forme normale. Pour plus d’informations sur cette approche, je vous renvoie à l’ouvrage suivant : « C.J. Date, Hugh Darwen, Nikos Lorentzos. Temporal Data and the Relational Model » où sont consacrées près de 400 pages à l'étude des bases de données temporelles.

Citation Envoyé par B.AF  Voir le message
Comment faites vous pour rendre cela testable, sans exploiter la base existante, avec un jeu de données permettant de répondre à l'ensemble des cas de production ?


Je demande à la Production informatique de me dupliquer dans un environnement dédié les seuls objets qui me sont nécessaires (tables, programmes, etc.), sur la base du contenu du catalogue relationnel. Ainsi pourrai-je effectuer mes tests en toute sérénité.

Citation Envoyé par B.AF  Voir le message
Comment faites vous les versionings ? (Modification de structure, plus modification de la donnée)


Ceci n’est pas de mon ressort mais celui de la Production informatique (les DBA de cette direction étant particulièrement impliqués). Une Production informatique digne de ce nom est rodée à ce genre d’exercice.
Avatar de Erwy Erwy - Rédacteur http://www.developpez.com
le 09/07/2010 à 6:17
Citation Envoyé par SQLpro  Voir le message


J'ai mis en gras le point ou vous vous trompez.... On ne "formate" pas les données pour un usage. On format les données parc ce qu'elles ont intrinsèquement une signification au regard de la sémantique qu'elle contiennent....

Ben non, je suis tout à fait d'accord avec et c'est ce que je préconise même si ce n'est pas le point que j'abordais ici.Quand je disais que mon manque de connaissance théorique du sujet m'amène à mal exprimer ma pensée...
Avatar de gene69 gene69 - Membre chevronné http://www.developpez.com
le 13/10/2010 à 4:01
comment il faut traduire et comprendre les "eventualy consistant" ?

passer d'un moteur "cher" mais qui offre toutes les garanties vers un modèle moins cher mais qui offre moins de prestation. C'est ça le deal de NoSql?
Avatar de CinePhil CinePhil - Modérateur http://www.developpez.com
le 13/10/2010 à 8:49
Citation Envoyé par gene69  Voir le message
comment il faut traduire et comprendre les "eventualy consistant" ?

La discussion fait à ce jour 10 pages. Ce serait bien de citer le passage d'oû tu sors cette expression.

passer d'un moteur "cher" mais qui offre toutes les garanties vers un modèle moins cher mais qui offre moins de prestation. C'est ça le deal de NoSql?

Qu'entends-tu par "cher" ?
Postgresql est gratuit, plutôt dans la moyenne haute quant au respect de la norme SQL et performant.
Avatar de SQLpro SQLpro - Rédacteur http://www.developpez.com
le 13/10/2010 à 9:52
Citation Envoyé par B.AF  Voir le message
Ok je veux bien reconnaitre que le sysobjet et ses amis permettent de vérifier pas mal de choses.

[...]
Un jour, la règle métier change avec un motif légal qui fait que n attributs de l'entité existent sur une plage de date valide. Cette règle spécifie un moyen de déterminer à J+3 les nouvelles données, sachant qu'il faut que chaque règle métier soit modifiée de façon à tenir compte des nouveaux attributs, correctement inscrits dans le temps.
Naturellement, il existe aussi une relation fonctionnelle avec d'autres éléments.

Comment faites vous pour rendre cela testable, sans exploiter la base existante, avec un jeu de données permettant de répondre à l'ensemble des cas de production ?

1) il suffit de regarder les impacts d'un changement d'objet sur l'existant à l'aide des méta données de la table.
Exemple (Microsoft SQL Server) : vue sys.sql_expression_dependencies qui tient à jour les informations croisées des objets de la base en permanence (cette vue propre à SQL Server existe dans d'autres SGBDR sous d'autres noms)
Voire aussi :
sys.dm_sql_referenced_entities
sys.dm_sql_referencing_entities

Comment faites vous les versionings ? (Modification de structure, plus modification de la donnée)

2) Il existe des outils pour ce faire.

Personnellement j'utilise Power AMC Designer qui permet de faire des scripts de mise à jour et d'archiver des modèles de base entre toutes les combinaisons de versions.

Autres produits : Win Design, Rational Rose....

A +
Avatar de Serguei_TARASSOV Serguei_TARASSOV - Membre averti http://www.developpez.com
le 06/07/2011 à 13:48
Je suis plutôt d'accord avec Frédéric.
Techniquement, il n'y a que 2 raisons pour "NoSQL" :
1. SGBD spécifique est nécessaire (bien évidemment que SGBDR existantes ont été mis en examens avant)
2. Incompétence sur SGBD et notamment sur SQL sans vouloir/possibilité en monter
Offres d'emploi IT
Administrateur(trice) systèmes et réseaux, devOps, linux, éditeur logiciels
AGYSOFT - Languedoc Roussillon - Montpellier (34000)
Développeur lamp h/f
ALTRAN - Provence Alpes Côte d'Azur - Nice (06000)
Développeur java j2ee (H/F)
Opensourcing - Ile de France - Paris (75000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique MySQL