GRATUIT

Vos offres d'emploi informatique

Développeurs, chefs de projets, ingénieurs, informaticiens
Postez gratuitement vos offres d'emploi ici visibles par 4 000 000 de visiteurs uniques par mois

emploi.developpez.com

Oracle veut « démystifier la mode NoSQL »
Et pose la question des ressources nécessaires pour tirer partie de ces bases de données

Le , par Gordon Fowler, Expert éminent sénior
Dans un document daté de mai, Oracle a mis en place un argumentaire pour contrer la progression (supposée ou réelle) des bases de données NoSQL.

Ce petit livre blanc de 15 pages, baptisé « Debunking the NoSQL Hype » (« Démystifier la mode NoSQL ») aurait pu rester relativement confidentiel. Mais sa publication sur le Web lui a donné une publicité inattendue.

Dans ces 15 pages on retrouve, comme d'habitude dans ce type d'exercice, les arguments de plus ou moins mauvaises fois et les dénigrements inhérents à tout argumentaire commercial. En débattre n'a donc pas grand intérêt.

En revanche, il a le mérite de poser clairement la question des ressources nécessaires pour déployer et utiliser une base NoSQL. En comparaison bien sûr avec un SGBD Oracle supposé plus économe en temps et en compétences pour l'entreprise.

Un des passages intéressants (indépendamment de son côté provocateur et polémique) est certainement celui-ci (p 12) : « Les bases de données NoSQL ont été soutenues par les grandes sociétés internet. Un tel parrainage a donné de la crédibilité et une image «cool» à ces bases. Les grandes sociétés Internet ont été motivées par le fait d'avoir une base de données libre, qui soit entièrement sous leur contrôle. Ces entreprises ont embauché les meilleurs développeurs pour implémenter ces bases de données évolutives (NDT : scalable) et les maintenir ».

Et Oracle de demander à ses clients et prospects : « Votre entreprise est-elle prête à faire un tel investissement dans un domaine qui n'est pas son cœur de métier ? Voulez-vous vraiment contribuer à un effort open-source? Voulez-vous vraiment miser votre projet sur une technologie avant-gardiste (NDT : bleeding edge) ? Voulez-vous vraiment bâtir une équipe de superstars, nécessaire pour faire de la vision de NoSQL une réalité ? ».

Et de conclure : « Vous n'êtes pas Google ».

Un tel argumentaire, dont chacun pensera ce qu'il veut sur la forme, laisse en tout cas imaginer que Oracle voit dans les bases NoSQL une menace de plus en plus pressante.

Est-ce le cas ? NoSQL devient-il « mainstream » et plus « avant-gardiste » ? Et si ce n'est pas le cas, pourquoi sortir un tel Livre Blanc ?

La deuxième question que pose Oracle, et qui mérite de l'être (une fois de plus indépendamment du style polémique de ces quelques pages), est celle des ressources que demande NoSQL.

Une question qui est d'autant plus intéressante qu'elle est posée calmement et sans parti pris.

Et que nous vous posons donc pour aider développeurs et décideurs à y voir plus clair sur ces technologies centrales, aussi bien pour le Web que pour les développements applicatifs ou les entreprises en général : les bases NoSQL demandent-elles plus, moins ou les mêmes ressources que les SGBD de Oracle, de Microsoft ou de SAP/Sybase ?

Source : « Démystifier la mode NoSQL » (PDF)


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


 Poster une réponse

Avatar de Arnaud B. Arnaud B. - Membre confirmé http://www.developpez.com
le 14/10/2011 à 19:17
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.

Citation Envoyé par shenron666  Voir le message
donc toutes les bases ayant un champ nullable sont mal modélisées pour toi ?

Avatar de Arnaud B. Arnaud B. - Membre confirmé http://www.developpez.com
le 14/10/2011 à 19:19
Citation Envoyé par shenron666  Voir le message
une simple question : pourquoi stocker un champs vide ?

Ben pour savoir qu'il est vide.
Et parce qu'il est pas toujours vide.
Avatar de Arnaud B. Arnaud B. - Membre confirmé http://www.developpez.com
le 14/10/2011 à 19:40
Citation Envoyé par Nithril  Voir le message
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.

Citation Envoyé par Nithril  Voir le message
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...
Avatar de Nithril Nithril - Membre régulier http://www.developpez.com
le 14/10/2011 à 23:25
Citation Envoyé par Arnaud B.  Voir le message
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.
Avatar de StringBuilder StringBuilder - Expert confirmé http://www.developpez.com
le 15/10/2011 à 11:17
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.
Avatar de kain_tn kain_tn - Membre chevronné http://www.developpez.com
le 15/10/2011 à 12:15
Citation Envoyé par StringBuilder  Voir le message
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.
Avatar de Nithril Nithril - Membre régulier http://www.developpez.com
le 15/10/2011 à 13:45
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.
Avatar de shenron666 shenron666 - Expert confirmé http://www.developpez.com
le 15/10/2011 à 13:53
Citation Envoyé par StringBuilder  Voir le message
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"
Avatar de Arnaud B. Arnaud B. - Membre confirmé http://www.developpez.com
le 17/10/2011 à 0:17
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...

Citation Envoyé par Nithril  Voir le message
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.

Avatar de Nithril Nithril - Membre régulier http://www.developpez.com
le 18/10/2011 à 22:41
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
Avatar de FMIMF FMIMF - Membre à l'essai http://www.developpez.com
le 19/10/2011 à 14:23
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.
Offres d'emploi IT
Ingénieur java jee h/f
Atos - Provence Alpes Côte d'Azur - Sophia-Antipolis
Développeur front-end
BeMore - Provence Alpes Côte d'Azur - Sophia-Antipolis
Data scientist
Mobiskill - Ile de France - Paris (75000)

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