Discussion :

[Nithril]

En même temps Oracle n'a pas tort.

Quid de MongoDB dans 2 ans ? Bcp l'utilisent car il est "gratuit" mais la santé de 10gen n'est pas celle d'Oracle

[StringBuilder]

Je découvre le NoSQL avec ce topic.

Une question que je me pose : mais pourquoi bon sang les SGBD n'intègrent-ils pas une gestion NoSQL ?

En effet, le NoSQL seul est très limité en terme de contraintes d'intégrité, il y a de la réplication de partout, etc.
Et les SGBD sont eux, très limité lorsque la volumétrie devient importante (quoique).

Pourquoi ne pas proposer des nouveaux types de tables dans les SGBD actuels, qui soient en mode NoSQL, avec possibilité de les référencer depuis les tables du modèle relationnel ?

Ainsi, certains objets en grand nombre, pourraient être gérés dans une table NoSQL, alors que le reste serait, au sein de la même base, dans une structure relationnelle classique.

J'imagine par exemple ce site :
- Toute les gestion des comptes utilisateurs, l'arborescence des forums, des articles, etc. resterait dans des tables relationnelles classiques.
- Et l'ensemble des éléments du forum et des articles seraient dans des tables NoSQL.

Personnellement, cela ne me choquerait pas : on bénéficierait des avantages des deux solutions, qui pourrait tout à fait cohabiter, non ?

[Arnaud B.]

Toujours pas compris l'intérêt de ce NoSQL...

Mais bon je suis prêt changer d'avis si quelqu'un a de vrais arguments.

Qu'est ce qui vous oblige à faire du relationnel dans un SGBDR ? C'est vous qui faites le modèle, c'est pas le SGBD qui vous l'impose !
Si vous avez envie de tout mettre dans une seule table, libre à vous...

Si vous voulez avoir une table avec juste une colonne de type id et une colonne de type XML ou JSON pour stocker une donnée structurée, vous pouvez...

Ca me fait rire les arguments sur le volume de données... vous croyez que les SGBDR "classiques" ne gèrent pas de gros volumes de données ??? Mais les SGBDR gèrent des BDD bien plus volumineuses que les bases des plus gros sites d'e-commerce...

Et on parle de ne pas respecter les principes ACID... mais bon sang quel peut être l'intérêt de ne pas respecter un principe qui permet d'avoir des transactions atomiques, des données cohérentes et intègres, des accès concurrentiels cohérents... etc... ??? alors là j'aimerai bien savoir...

Cdlt, Arnaud.

[StringBuilder]

Je ré-itère : je ne connais pas du tout NoSQL, et j'ai juste rapidement lu une petite définition trouvée dans Google.

Oui, les SGBD actuels permettent de stocker un très grand nombre d'éléments, avec de très gros volumes.

Mais à l'image de MySQL quand il fonctionne avec un système de fichiers n'acceptant pas les transaction "InnoDB" je crois, un moteur de base de données écrit spécifiquement pour ne pas tirer partie des transactions et autres règles d'intégrité des SGBDR est bien plus rapide qu'un Oracle ou un SQL Server par exemple.

C'est là que NoSQL gagne à être utilisé (de ce que je comprends).

Pour le reste, tu as raison, rien n'empêche de stocker du bordel dans une table poubelle dans un SGBDR. Reste que le moteur du SGBDR n'est pas optimisé pour gérer/indexer efficacement cette structure.

D'où mon interrogation/suggestion quant à l'éventuelle intégration de NoSQL dans les moteurs des SGBDR.

[Nithril]

Toujours pas compris l'intérêt de ce NoSQL...

Mais bon je suis prêt changer d'avis si quelqu'un a de vrais arguments.

Qu'est ce qui vous oblige à faire du relationnel dans un SGBDR ? C'est vous qui faites le modèle, c'est pas le SGBD qui vous l'impose !
Si vous avez envie de tout mettre dans une seule table, libre à vous...

Si vous voulez avoir une table avec juste une colonne de type id et une colonne de type XML ou JSON pour stocker une donnée structurée, vous pouvez...

Ca me fait rire les arguments sur le volume de données... vous croyez que les SGBDR "classiques" ne gèrent pas de gros volumes de données ??? Mais les SGBDR gèrent des BDD bien plus volumineuses que les bases des plus gros sites d'e-commerce...

Et on parle de ne pas respecter les principes ACID... mais bon sang quel peut être l'intérêt de ne pas respecter un principe qui permet d'avoir des transactions atomiques, des données cohérentes et intègres, des accès concurrentiels cohérents... etc... ??? alors là j'aimerai bien savoir...

Cdlt, Arnaud.

Certaines bases NoSql gère de TRÈS gros volume de données inaccessible à un SGBDR tel qu'Oracle et à un prix soft et hard bien en dessous.

Un JSOn ou un XML n'est pas recherchable (exception faite pour le XML avec les gros SGBDR).

Les bases NoSQL ont des transactions, des données cohérentes, des accès concurrents...

Le NoSQL ne s’érige pas contre le SQL, il offre en alternative à un modèle tout sql (NotSQL = not only sql). L'idée c'est d'utilisé la techno adaptée à ses besoins.

[shenron666]

Qu'est ce qui vous oblige à faire du relationnel dans un SGBDR ? C'est vous qui faites le modèle, c'est pas le SGBD qui vous l'impose !

reste que le moteur est prévu et optimisé pour gérer du relationnel, que tu en fasse ou pas

[/quote]Si vous avez envie de tout mettre dans une seule table, libre à vous...[/quote]
aucun intérêt ni aucun rapport avec le nosql
c'est juste se tirer une balle dans le pied

Ca me fait rire les arguments sur le volume de données... vous croyez que les SGBDR "classiques" ne gèrent pas de gros volumes de données ??? Mais les SGBDR gèrent des BDD bien plus volumineuses que les bases des plus gros sites d'e-commerce...

et les sites d'e-commerce dont tu parles, est-ce qu'ils ont réellement besoin du côté relationnel ?
si c'est jute pour stocker des informations, une base nosql donnerait peut-être de meilleures performances

Et on parle de ne pas respecter les principes ACID... mais bon sang quel peut être l'intérêt de ne pas respecter un principe qui permet d'avoir des transactions atomiques, des données cohérentes et intègres, des accès concurrentiels cohérents... etc... ??? alors là j'aimerai bien savoir...

parce que trop de limite provoque parfois trop de contraintes
et les contraintes ACID qui font qu'une BDR est efficace pour ce qu'elle fait font aussi que ces mêmes BDR ont des limitations

une simple question : pourquoi stocker un champs vide ?

[StringBuilder]

une simple question : pourquoi stocker un champs vide ?

Si t'as un champ vide, c'est parceque ta base est mal modélisée :o

[shenron666]

Si t'as un champ vide, c'est parceque ta base est mal modélisée :o

donc toutes les bases ayant un champ nullable sont mal modélisées pour toi ?

[Arnaud B.]

Non, mais si dans une table, une colonne est majoritairement à Null, alors oui, il y a peut être une mauvaise modélisation, auquel cas il peut être préférable d'externaliser cette colonne dans une autre table.

Mais bon peu importe, je ne vois pas trop l'inconvénient d'avoir des valeurs null.
Tant qu'on n'a pas de trop de colonnes dans une table, la lecture des pages n'est pas trop ralentie.

Mais encore une fois, je ne maitrise pas la finalité des SGBD NoSQL, c'est justement ce que j'essaie de comprendre.

donc toutes les bases ayant un champ nullable sont mal modélisées pour toi ?

[Arnaud B.]

une simple question : pourquoi stocker un champs vide ?

Ben pour savoir qu'il est vide.
Et parce qu'il est pas toujours vide.

[Arnaud B.]

Certaines bases NoSql gère de TRÈS gros volume de données inaccessible à un SGBDR tel qu'Oracle et à un prix soft et hard bien en dessous.

Je ne sais pas ce que tu entends par très gros volumes mais des bases de plusieurs Peta sont gérées avec Oracle, Postgresql, MS SQL ou Teradata.

Dell, Wall Mart, ebay, bank of America utilisent des SGBDR Teradata et ont plus de 1 Peta de données.

Un JSOn ou un XML n'est pas recherchable (exception faite pour le XML avec les gros SGBDR).

Mais tous les vrais SGBDR gèrent le XML (stockage, indexation, XQL...) ! Et à mon avis s'ils gèrent le XML, ils peuvent gérer le JSON...

D'autre part, on est pas obligé de modéliser toute l'arborescence d'un type structuré (XML, JSON...) dans un modèle relationnel ! On créé un méta-modèle que le SGBDR saura indexer.

Enfin, bon, je demande qu'à comprendre...

[Nithril]

Je ne sais pas ce que tu entends par très gros volumes mais des bases de plusieurs Peta sont gérées avec Oracle, Postgresql, MS SQL ou Teradata.

Dell, Wall Mart, ebay, bank of America utilisent des SGBDR Teradata et ont plus de 1 Peta de données.

Mais tous les vrais SGBDR gèrent le XML (stockage, indexation, XQL...) ! Et à mon avis s'ils gèrent le XML, ils peuvent gérer le JSON...

D'autre part, on est pas obligé de modéliser toute l'arborescence d'un type structuré (XML, JSON...) dans un modèle relationnel ! On créé un méta-modèle que le SGBDR saura indexer.

Enfin, bon, je demande qu'à comprendre...

Les SGBDR gèrent effectivement un volume important de données. Le problème est l'aspect distribué. Le SQL se prête mal a une distribution des données sur plusieurs nœuds avec une réplication partielle des données. La limite se situe notamment au niveau des mécanismes de jointure, de tri... Une requête se joue donc généralement que sur un nœud.

Pour avoir de bonnes performance sur un volume important de données, le cout de l'infrastructure/installation/consultant est donc énorme. Si en plus le choix se porte sur Oracle ou Teradata, la facture est plus que salée. Effectivement il n'y a que des sociétés du type de celles que tu cites qui peuvent se le permettre.

Il y a l'exception SQLFire de VMWare, mais il ne peut faire des jointures que si les tables sont sur le même nœud.

A coté de cela tu as des bases NoSQL nativement distribuées avec un facteur de réplication des données réglables. Une requête est distribuée sur l'ensemble des nœuds. Cela est rendu possible par le fait que les requêtes sont simples et n'impliquent pas de jointure. Les jointures sont à faire "manuellement". Le tout fonctionnant souvent suivant le principe mapreduce. Le cout de l'infrastructure/installation/consultant est bien moindre et les performances sont bien supérieures.

Les SGBDR, en tous cas Oracle, ne gèrent pas le JSON. Coté XML avec Oracle il faut taper dans le XQL. XML + XQL, on est loin de la simplicité d'accès JSON ou d'un stockage clé/valeur.

[StringBuilder]

Dans ce que tu expliques sur l'incapacité de faire des requêtes distribuées sur plusieurs serveurs avec les SGBDR, je ne vois qu'un problème de conception/modélisation.

Rien ne m'empêche de faire un proxy de données, qui va permettre de séparer les partitions des tables sur plusieurs serveurs (genre un serveur gère les factures de 2011, un autre celles de 2010, etc.) et pouvoir les interroger simultanément. Les données à répliquer dans ce cas sont moindre (tables de références), voir nulles (si on prends la logique de NoSQL, on n'a qu'une seule entité avec tout dedans, et tant pis pour les doublons).

Donc non, cet argument ne tiens pas la route.

Pour moi, il ne reste que le moteur de manipulation des fichiers (modifications des données, indexation, recherche) qui diffère.

[kain_tn]

Dans ce que tu expliques sur l'incapacité de faire des requêtes distribuées sur plusieurs serveurs avec les SGBDR, je ne vois qu'un problème de conception/modélisation.

Rien ne m'empêche de faire un proxy de données, qui va permettre de séparer les partitions des tables sur plusieurs serveurs (genre un serveur gère les factures de 2011, un autre celles de 2010, etc.) et pouvoir les interroger simultanément. Les données à répliquer dans ce cas sont moindre (tables de références), voir nulles (si on prends la logique de NoSQL, on n'a qu'une seule entité avec tout dedans, et tant pis pour les doublons).

Donc non, cet argument ne tiens pas la route.

Pour moi, il ne reste que le moteur de manipulation des fichiers (modifications des données, indexation, recherche) qui diffère.

Il n'a pas parlé d'incapacité mais de coût de mise en œuvre (machines + compétences) plus élevé que pour du NoSQL. De plus, de par la nature de ces bases de données, les performances en écriture sont souvent largement supérieures (mais le prix à payer est la perte de l'ACIDité...) à celles des SGBD classiques.

[Nithril]

Problème de conception / modélisation ?

Tu adaptes tes données aux contraintes des SGBDR. Tu es obligé de mettre en place une infrastructure spécifique puis de découper tes données. De mettre en place un proxy qui va faire du mapreduce (un comble ). Ça complexifie ton infra et sa maintenance. Les couts et la complexité s’empilent.

Le problème de "conception / modélisation" se situent plutôt ici dans le choix de cette technologie (SGBDR)

Il y a un moment où il faut se poser des questions quand la conception et la modélisation sont obligés d'emprunter des chemins tortueux pour adapter le besoin aux contraintes d'une technologie.


Si je suis thread safe, j'utilise StringBuilder, autrement StringBuffer.... Idem pour SGBDR / NoSQL.

[shenron666]

Rien ne m'empêche de faire un proxy de données, qui va permettre de séparer les partitions des tables sur plusieurs serveurs (genre un serveur gère les factures de 2011, un autre celles de 2010, etc.) et pouvoir les interroger simultanément. Les données à répliquer dans ce cas sont moindre (tables de références), voir nulles (si on prends la logique de NoSQL, on n'a qu'une seule entité avec tout dedans, et tant pis pour les doublons).

explosion des coûts d'infrastructure et de la complexité de mise en oeuvre / maintenance, augmentation du risque de panne et de la difficulté d'évolution des bases, complexe gestion des "lock", ...
tout ce que nosql "combat"

[Arnaud B.]

Merci pour ces explications très claires.
Je commence à mieux comprendre les arguments du NoSQL.

Ceci-dit, les SGBDR savent aussi répartir les requêtes :
- soit sur plusieurs noeuds par une mise en cluster
- soit en parallélisant les accès par la gestion des espaces de stockages, ce qui permet à au SGBDR de solliciter plusieurs volumes simultanément afin de distribuer la requete.

Et c'est pas forcément cher : on peut faire du clustering avec MySQL ou postgresql.

Il me semble qu'ebay utilise aussi un cluster de 96 bases pg.

Mais bon, peut être les SGBD NoSQL sont ils spécialement performants pour ça... En tout cas avec un meilleur rapport performance/coût d'après ce que tu dis.

J'attends de voir des benchmark quand même pour me faire définitivement un avis...

Les SGBDR gèrent effectivement un volume important de données. Le problème est l'aspect distribué. Le SQL se prête mal a une distribution des données sur plusieurs nœuds avec une réplication partielle des données. La limite se situe notamment au niveau des mécanismes de jointure, de tri... Une requête se joue donc généralement que sur un nœud.

Pour avoir de bonnes performance sur un volume important de données, le cout de l'infrastructure/installation/consultant est donc énorme. Si en plus le choix se porte sur Oracle ou Teradata, la facture est plus que salée. Effectivement il n'y a que des sociétés du type de celles que tu cites qui peuvent se le permettre.

Il y a l'exception SQLFire de VMWare, mais il ne peut faire des jointures que si les tables sont sur le même nœud.

A coté de cela tu as des bases NoSQL nativement distribuées avec un facteur de réplication des données réglables. Une requête est distribuée sur l'ensemble des nœuds. Cela est rendu possible par le fait que les requêtes sont simples et n'impliquent pas de jointure. Les jointures sont à faire "manuellement". Le tout fonctionnant souvent suivant le principe mapreduce. Le cout de l'infrastructure/installation/consultant est bien moindre et les performances sont bien supérieures.

Les SGBDR, en tous cas Oracle, ne gèrent pas le JSON. Coté XML avec Oracle il faut taper dans le XQL. XML + XQL, on est loin de la simplicité d'accès JSON ou d'un stockage clé/valeur.

[Nithril]

Pour info Cassandra 1.0 est sortie :
http://www.globenewswire.com/newsroo....html?d=235203

Il y a des cas d'utilisations intéressants avec les volumétries associées

[FMIMF]

Les BDR sont actuellement le modèle dominant.
Les BDR se fixent plein de contraintes strictes (ACID etc...) qui peuvent être indispensables dans certaines applications mais sont overkill dans de nombreux cas alors qu'elles consomment de la ressource et/ou sont source de complexité.
Les NoSQL se libèrent de certaines de ces contraintes en contrepartie de quoi elles présentent des avantages en terme de perf, de scalabilités etc... La conséquence est que même si il y a des applis ou le NoSQL peut difficilement remplacer les BDR il y a beaucoup d'appli où des NoSQL seraient meilleures que des BDR *en théorié*.

Ce qui nous amène à la pratique dont se pâme Oracle. A savoir que le modèle BDR est une variable bien connu: ça fait des années qu'il existe, le marché est mature, les standards existent est sont très diffusés et globalement accepté.
Inversement l'offre NoSQL est encore en construction, fragmenté, pas normalisée, il n'y a pas encore de système qui fasse l'unanimité...

Il faut aussi reconnaître qu'il y a aussi un effet "hype" lié au NoSQL: c'est nouveau, c'est utilisé par Google et Facebook...

Donc:
* le NoSQL offre des avantages sur le SQL (mais n'est pas meilleur dans toutes les applications - pas de sur-hype)
* le NoSQL est moins mâture que le SQL il y a plus de risques sur la longévité des systèmes actuels et/ou sur leur support
* ce n'est pas un risque pour les grosses boîtes dont c'est le cœur de cible et qui développent au fil de leurs besoins (genre Google), mais pour les boîtes qui se contentent de suivre le mouvement il y a un risque de se retrouver en slip si elles investissent trop dans la techno et que son orientation diverge de leurs intérêts

Honnêtement la plupart des arguments sont raisonnables pour une boîte moyenne, voire grosse, en l'état actuel j'aurai tendance à conseiller à des utilisateurs moyens d'attendre que les choses se tassent.

Évidemment là où c'est malhonnête c'est qu'Oracle est leader en terme de base de données grâce à sa position dans les BDR et qu'ils n'ont aucun intérêt à ce que les cartes soient rebattues par une nouvelle techno, ou qu'a minima ils doivent gagner du temps pour:
* continuer à se remplir les poches
* préparer leur propre offre en NoSQL
Leur argumentaire est donc de toute vraisemblance biaisé en faveur des BDR et ils chargent la barque contre le NoSQL.

Après ils se content d'appliquer les principes de base de la com' de mauvaise foi:
Tout système a des avantages et des inconvénients. Quand on veut discréditer un système au détriment d'un autre la base c'est de minorer les avantages et de gonfler les inconvénients.