IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Coriolan

143PARTAGES

9  1 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 25/08/2016 à 21:17
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.
10  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 25/08/2016 à 19:34
Citation Envoyé par Coriolan Voir le message
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...
7  3 
Avatar de Aeson
Nouveau Candidat au Club https://www.developpez.com
Le 25/08/2016 à 19:49
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..
4  2 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 25/08/2016 à 20:26
Citation Envoyé par Aeson Voir le message
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.
2  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 29/08/2016 à 11:20
Citation Envoyé par Aeson Voir le message

Effectivement. Mais les développeurs veulent de l'orienté objet. D'ou le succes des ORM et de frameork comme Linq.
Les mauvais développeurs veulent de l'orienté objet, les autres apprennent le SQL. Je trouve pour ma part tous les ORM que j'ai pu tester / pratiquer imbouffables dès qu'il s'agit de faire autre chose qu'un select sur une table by id.

Le SQL est un outil, comme les langages orientés objets. Le SQL est designé pour traiter avec des données tabulaires, pas l'orienté objet.

Je me désolé de voir les horreurs écrites en java ou c# dans les couches DAO simplement parce que le développeur qui a écrit ce code n'a pas pris 1 journée pour se former au SQL (c'est hyper simple comme langage).
2  0 
Avatar de gros_bidule
Membre régulier https://www.developpez.com
Le 25/08/2016 à 21:26
Citation Envoyé par Gugelhupf Voir le message
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.
Totalement vrai pour MongoDB. Si l'on veut faire de la recherche, on nous pousse très vite à passer par du elasticsearch :p
Par contre je te recommande vivement Couchbase (le langage est très proche du SQL : jointures, etc, ainsi que de vraies transactions) et Marklogic, ce dernier étant très très fort pour la recherche (case sensitive, support ds langues, et plein de trucs très poussés) ; il est connu pour ça.

MongoDB est peut être une des bases NoSQL les moins évoluées, mais hélas la plus en vogue.
1  0 
Avatar de rawsrc
Expert éminent sénior https://www.developpez.com
Le 27/08/2016 à 15:34
Citation Envoyé par micka132 Voir le message
J'ai jamais aimé les SI avec une partie seulement qui était sous forme de procédure stockée. Soit on mets aucune logique soit on mets tout
Non, pas forcément. L'extrémisme n'est jamais bon. J'ai bien plus souvent vu des système où ce qui aiguillait le choix entre procédure stockée et routine externe était uniquement le temps de traitement. J'ai travaillé pour des clients qui avaient des règles strictes du genre : si le temps de réponse à une requête dépassait par exemple 600 millisecondes -> tu passais en mode spéléo. Et bien souvent le traitement finissait déporté en procédure stockée.
1  0 
Avatar de marteloudini
Candidat au Club https://www.developpez.com
Le 28/08/2016 à 9:27
Bonjour,

Pour ma part, je regarde fortement vers le NoSQL, dans cette myriade de base de données, un qui sort du lot étant OrientDB (certes il est jeune), au vu de ce qu'il offre déjà maintenant c'est un grand pas en avant.

1) Gestion des Groupes-Users et permissions jusqu'à un niveau bas.
2) Multi-Model (Key-Values; Documents; Graph)
3) Master-Master (réplication)
Et je ne cite que les 3 premiers que j'ai en tête.

ne me parlez pas de MongoDB ou l'on perd la notion de "relation" ce qui est normal puisque ce n'est qu'une base de données Documents et donc si relation il y a au niveau business il faut la coder dans l'application.
ne me parlez pas de Neo4J ou aucune gestion de permission n'est possible, et ou les requêtes sont très différentes de part le fait que c'est du graph uniquement..

Pourquoi chercher une db qui ne fait qu'un type de structuration data, alors qu'on peut avoir le meilleur de toute la famille NoSQL ??? je confirme avoir un oeil sur l'évolution d'OrientDB.

bàv
1  0 
Avatar de Aeson
Nouveau Candidat au Club https://www.developpez.com
Le 25/08/2016 à 20:37
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)
0  0 
Avatar de gros_bidule
Membre régulier https://www.developpez.com
Le 25/08/2016 à 21:16
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.
1  1