Discussion :

[Coriolan]

Une nouvelle étude montre la montée en puissance du NoSQL
Avec de plus en plus d'entreprises qui se tournent vers le cloud public

La NoSQL désigne une famille de systèmes de gestion de bases de données (SGBD) qui s’écarte du paradigme classique des bases relationnelles. À partir des années 2000, les grandes entreprises du web ont été amenées à traiter des volumes de données très importants, une tâche non adaptée au modèle relationnel qui souffre de plusieurs limitations liées au fait qu’il a été conçu pour fonctionner sur des ordinateurs uniques. Afin de répondre à ces limites, ces entreprises ont commencé à développer de nouvelles solutions de gestion de bases de données pouvant fonctionner sur des architectures matérielles distribuées et permettant de traiter des volumes de données importants. Ces nouveaux systèmes NoSQL sont dotés de performances qui restent bonnes avec la montée en charge (scalabilité) en multipliant simplement le nombre de serveurs, solution raisonnable avec la baisse de coûts.

Aujourd’hui, les bases de données NoSQL sont devenues incontournables, avec de plus en plus d’entreprises qui se tournent vers ces solutions. Selon le rapport Forrester Wave for Big Data NoSQL, Q3 2016, « le NoSQL n’est plus une option, c’est une nécessité pour les applications de nouvelle génération ». Les décideurs (de plusieurs pays, dont la France) ont réalisé le potentiel que présente le NoSQL. L’enquête de Forrester a révélé que 29 % des interrogés ont déclaré avoir déjà implémenté ou sont en train d’implémenter la technologie NoSQL; 12 % sont en train d’élargir ou mettre à niveau leurs implémentations. Les entreprises sont attirées par le modèle NoSQL qui permet le traitement d’énormes quantités de données, la structuration relationnelle faible et la capacité d’accès très rapide, quitte à multiplier les serveurs.

61 % des entreprises interrogées par Forrester ont déjà implémenté une base de données NoSQL ou prévoient de le faire à court terme

Il n’est plus question aujourd’hui de savoir si les entreprises vont adopter le NoSQL, 61 % des entreprises interrogées par Forrester ont déjà implémenté une base de données NoSQL ou prévoient de le faire à court terme. Aujourd’hui, on se demande plutôt si les entreprises vont se contenter de leurs propres serveurs ou se tourner vers le cloud public.

Classement des différentes SGBD NoSQL sur le marché

Pour le classement des bases de données NoSQL, MongoDB reste le leader et la solution open source la plus populaire. Cette base de données NoSQL orientée-document tire sa popularité de sa facilité et sa capacité de supporter la montée en charge des applications les plus exigeantes. La solution NoSQL Cloud propriétaire DynamoDb est aussi bien classée. Utilisable essentiellement via AWS, cette solution est exploitée par les entreprises pour un large éventail de tâches, comme les campagnes de publicité, les applications de médias sociaux et la collecte et l’analyse de données… Bien que Microsoft a eu un certain retard sur ce marché, sa solution Azure DocumentDB a connu une forte croissance depuis son lancement.

Selon les chiffres avancés par le cabinet d’études Gartner, le nombre de machines virtuelles (VMs) du cloud public a été multiplié par 20 en trois ans (entre 2011 et 2014 ) alors que les VM du cloud privé ont été multipliées par 3, une performance liée au fait que le cloud public permet une scalabilité horizontale adaptée aux nouveaux besoins du marché. Le cloud public favorise une agilité accrue qui permet aux entreprises de se concentrer sur l’amélioration de leurs services et laisser aux opérateurs du cloud la tâche de gérer leur infrastructure. Selon Gartner, d’ici 2020, 10 % de part du marché de systèmes de bases de données va être conquise par des solutions de cloud public, ce qui ne peut que renforcer le statut du NoSQL comme la solution de choix pour les applications de nouvelle génération.

Source : Forrester - Gartner

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Forum NoSQL

[micka132]

Qu'en pensez-vous ?

Je pense que 90% des projets sont totalement a coté de la plaque et il n'y avait aucun besoin de NoSql pour les traiter.
Seulement beaucoup de monde veut se donner l'impression de faire des choses impressionnantes comme les gros...Sauf qu' il y a peu d'entreprise qui gère le peta-(voire exa-)octet.
Par exemple sur ce fil http://www.developpez.net/forums/d15...nnees-l-insee/ , on a un besoin impressionnant sur de la big data. Rendez vous compte un fichier zip de 33mo! Bon là le gars va surement s'en sortir sans devoir trop investir en infra, mais si le fichier monte a 50Mo là je pense qu'il faudra serieusement envisager le cloud pour les monter en charges...

[Aeson]

Je pense que 90% des projets sont totalement a coté de la plaque et il n'y avait aucun besoin de NoSql pour les traiter

Le seul avantage du NoSql n'est pas les performances. Dans beaucoup (la plupart) des projets il n'est pas nécessaire du point de vue performance.

Mais dans la facilité et l'architecture des applications ça apporte un plus. Il n'y a plus besoin de mapper le Domain Model vers le Data Model. Donc simplification. On sauve le Domain Model directement. Ce qui force les developpeurs a adopter le DDD et a créer des 'Boundaries' fortes. Ce qui permet de faire du Microservice et donc d'en avoir les avantages.

Mais ça engendre d'autre problématiques quand on change le DomainModel (Migration du schéma...)

Et il ne faut pas se mentir.. quand on peut se passer des DBA pour le tuning et toute les contraintes c'est tentant..

[micka132]

Il n'y a plus besoin de mapper le Domain Model vers le Data Model. Donc simplification. On sauve le Domain Model directement.
...
Mais ça engendre d'autre problématiques quand on change le DomainModel (Migration du schéma...)

A voir sur la durée, effectivement on gagne lors de la phase initial mais sur le long terme j'en suis pas certains. Si l'on est aller mettre une donnée au fin fond d'une hiérarchie parceque ca semblait accessoire lors de la conception ça va être délicat a faire remonter.
Sinon pour ce qui est de se passer de DBA, j'en ai tellement rarement vu que je serais bien content d'en avoir un de temps à autres (je déteste le SQL...)! En vrai je préfère l'approche NoSql mais plus par feneantise que par réel besoin. Un peu comme les ORM, normalement ca nécessite pas mal de boulot pour etre sûr de pas faire de la merde, mais en vrai on s'en sert surtout pour s'eviter la tache bien chiante de l'ecriture de la DAL.

[Aeson]

je déteste le SQL...

Comme beaucoup... C'est un point fort du NoSql

Pour les ORM c'est toujours du SQL derriere. D'ou le mapping vers le DataModel. Pouvoir se passer de ce mapping offre donc des avantages. Et comme le NoSql offre de très bonne performance vu sont architecture c'est tous bon..

L'avantage des ORM c'est de masquer le SQL (avec du mapping). Le SQL generé faisait souvent bondir les DBA... Utiliser un ORM fait dans la plupart des cas perdre en performance. Mais comme c'est plus facile et que ca fait gagner du temps, ces pertes sont acceptées malgré les cris des DBA.

Avec des store comme MongoDB on peut encore aller plus loin en gardant les performances, augmentant la productivité et en forcant une architecture DDD (avec tous ces avantages)

[Gugelhupf]

je déteste le SQL...

Quel que soit le domaine, on a souvent tendance à "détester" les choses que l'on ne maîtrise pas. Pour moi le SQL est le meilleur langage standardisé existant pour manipuler des données tabulaires, on aura beau utiliser des map/reduce, streams, LINQ ou autre, on n'arrive pas à la cheville de ce concept créé par des ingénieurs d'IBM en 1974.

Les bases NoSQL c'est bien, surtout ceux qui ont une utilité bien précise telle que Redis pour le cache par exemple, mais pour une utilisation plus étendue, les bases NoSQL telle que MongoDB par exemple, je me pose des questions. Je suis conscient du fait que ces technos permettent de gagner en agilité (surtout pour les développeurs JavaScript/ Node.js), il est possible durant le développement de changer son modèle de donnée à la volée lorsque le client décide d'ajouter une feature sur un coup de tête, conclusion ça pète pas alors qu'avec une base relationnelle cela demande plus de délicatesse (on doit gérer le typage des colonnes etc je ne vous apprends rien)...

Mais il y a beaucoup de concept que l'on châtre en utilisant ce type de techno, on veut créer un site e-commerce ? Ok, comment allons-nous gérer les transactions entre les traitements effectuées sur plusieurs documents à la fois ? On veut récupérer des données sans forcément dupliquer une infinité d'objets dans des objets, comment faire sans une simple jointure ? Comment réaliser des requêtes complexes avec une syntaxe JS alors qu'en SQL j'enchaine avec une simplicité hallucinante mon groupement, mes filtres, et mes fonctions d'agrégats ?
Aujourd'hui ces technos sont cools, mais trop jeunes... Je vous prends un tout petit exemple d'un projet, avec MongoDB vous ne pouvez pas faire un "sort" correctement du fait que ce dernier ne sait pas gérer l'insensitive, alors que fait-t-on ? On bidouille, on crée un champ supplémentaire dont le contenu est en uppercase ou lowercase par exemple.

[SurferIX]

Le seul avantage du NoSql n'est pas les performances. Dans beaucoup (la plupart) des projets il n'est pas nécessaire du point de vue performance.

Mais dans la facilité et l'architecture des applications ça apporte un plus. Il n'y a plus besoin de mapper le Domain Model vers le Data Model. Donc simplification. On sauve le Domain Model directement. Ce qui force les developpeurs a adopter le DDD et a créer des 'Boundaries' fortes. Ce qui permet de faire du Microservice et donc d'en avoir les avantages.

Mais ça engendre d'autre problématiques quand on change le DomainModel (Migration du schéma...)

Et il ne faut pas se mentir.. quand on peut se passer des DBA pour le tuning et toute les contraintes c'est tentant..

Cherche juste "is mongodb safe". Tu verras.
De plus comme le dit Mika132 juste après ton post, c'est bien pour démarrer à l'arrache, mais c'est totalement ingérable très rapidement.

Et tu en arrive à l'image qui parle le mieux au monde :

"Sets of sets of sets of sets. Tasty fractals."

[gros_bidule]

La mise à jour du schéma d'une base NoSQL est souvent plus simple qu'en SQL. Retour d'expérience :

SQL : modifier un schéma en SQL (que l'on utilise un ORM ou pas) demande du travail, ne serait-ce que pour toucher à des FK, casser des contraintes, etc. Ce n'est pas pas évident à la base (et peut être, avouons-le, pas tellement pensé pour)

NoSQL (MongoDB, Neo4j et Marklogic pour mon expérience personnelle) : modifier un schéma NoSQL est plus facile à mettre en œuvre car il y a beaucoup moins de contraintes. Pas de FK, pas de liens forts entre les données. On peut donc faire ce que l'on veut (aka "tout casser").
La mise à jour du schéma se fait généralement en remodelant les données : on ajoute/retire/renomme/déplace facilement des champs. En fait il n'y a aucune contrainte (si ce n'est le temps d'exécuter l'upgrade des données) pour tout modifier.
Dans la boite où je travaille on a l'habitude de maintenir des scripts de migration. Ces scripts sont lancés à chaque démarrage de l'appli. L'évo du modèle se fait donc en même temps que la livraison (et biensûr testée en intégration continue). Les partie obsolètes des scripts d'évo sont retirés quand on remarque qu'ils ne servent plus.
Faire ça en SQL est plus prise de tête.

La seule chose qui me manque quand je fais du NoSQL, c'est la puissance et la simplicité (toute relative, j'ai surtout commencé ma vie de dev par ça, ça aide) du langage ainsi que sa normalisation. Quasiment le même SQL sur MariaDB, Oracle, SQLServer... alors qu'en NoSQL non seulement les dialectes sont nouveaux, pas toujours très pratiques pour les requêtes complexes (en particulier MongoDB, les projections deviennent vite tordues), mais on presque a un dialecte par base NoSQL. Il n'y en a que 2~3 qui proposent soit un langage proche du SQL (le cas de Couchbase) ou un driver JDBC (ex avec Neo4j).

Les pro-SQL diront sans doute que le SQL permet de bien verrouiller le modèle avec des contraintes, sécurité que l'on n'a pas en NoSQL (même si cette fonctionnalité commence à pointer le bout de son nez) ; mais finalement on s'en passe très bien. Du moment que le code métier est bien testé, tout roule.

Bref, pour moi l'avenir de la donnée c'est du NoSQL (type document, graphe, keyvalue, etc selon les besoins) + du test-driven.

[SQLpro]

La NoSQL désigne une famille de systèmes de gestion de bases de données (SGBD) qui s’écarte du paradigme classique des bases relationnelles. [.... Le] modèle relationnel qui souffre de plusieurs limitations liées au fait qu’il a été conçu pour fonctionner sur des ordinateurs uniques.

Ceci est faux... Les bases de données relationnelles sont aujourd'hui et depuis longtemps capable de dispatcher les données sur différentes nœuds. Si je prend l'exemple de SQL Server il existe des mécanismes de partitionnement et de fédération (DPV, service broker ... par exemple) tout à fait capable de "spliter" une même base sur plusieurs serveurs. Un exemple est PANN STARS. Autre exemple en France FNAC.COM.

A +