Base de données relationnelle ou NoSQL, laquelle constitue le meilleur choix ?
Un développeur défend les SGBDR après avoir abandonné NoSQL

Le , par Cedric Chevalier, Expert éminent sénior
Matt Butcher est un développeur logiciel qui travaille pour la compagnie Revolv basée aux États-Unis. Revolv propose du matériel (ampoules électriques, thermostats, serrures, etc.) pour implémenter le concept de « Smart Home » qui donne la possibilité aux utilisateurs de contrôler avec leurs smartphones ou tablettes les périphériques de leur maison.

Ces équipements interconnectés génèrent un flot d’informations que Revolv gérait avec les systèmes de gestion de base de données non relationnelle. Mais ça, c’était avant. En effet, la firme a décidé d’abandonner le NoSQL, pour retourner à la gestion classique avec les bases de données relationnelles (via PostgreSQL).

Pourquoi ce subit changement ? Le développeur de la maison (Matt) présente trois points essentiels qui les ont poussés à faire ce choix. Le premier relève même de la nature des bases de données non relationnelles. Pour Matt, elles ne prennent pas correctement en charge les relations. Or, les données sur lesquelles ils sont amenés à travailler sont fortement relationnelles.

La seconde observation de Matt, c’est que l’écriture de la syntaxe pour le retrait d’information dans la base de données non relationnelle peut s’avérer complexe. Spécialement dans le cas de Revolv, où la solution employée n’avait pas de langage de requête intermédiaire. Par conséquent, il fallait écrire du code complexe pour chaque requête.

La troisième raison est relative à la documentation. Matt trouve que celles des bases de données NoSQL sont fragmentées et manquent de maturité par rapport à leurs équivalents chez les SGBDR. Ce qui constitue d’après lui un énorme handicap. Il dira même qu’il a passé énormément de temps à rechercher dans les documentations des configurations qui s’avéraient au final triviales.

Des points de vue certes personnels, mais qui alimentent l’éternelle bataille entre fervents défenseurs des technologies de base de données relationnelles à leurs homologues NoSQL. Plusieurs arguments sont souvent évoqués par les défenseurs du NOSQL.

On peut lire très souvent, « L’opération join employée pour les bases de données relationnelles est un réel handicap lorsqu’elle se fait pour un grand nombre d’éléments. Google l’a compris et développé sa propre solution. De plus, elles ne sont pas parfaitement adaptées pour les données telles que le XML ou encore les objets complexes. »

Ce à quoi répondent les fervents défenseurs des bases de données relationnelles en argumentant qu’à « chaque type de donnée, correspond au moins un modèle relationnel. Il en est de même pour le XML et les objets complexes. De plus, de nos jours l’opération Join ne constitue plus un problème. Avec des acteurs comme Oracle, elle peut être exécutée sans crainte pour des gros systèmes ».

Source: Technosophos

Et vous ?

Êtes-vous un fervent défenseur des bases de données relationnelles ou NoSQL ?


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


 Poster une réponse

Avatar de Bono_BX Bono_BX - Membre confirmé https://www.developpez.com
le 16/04/2014 à 17:13
Pour Matt, elles ne prennent pas correctement en charge les relations. Or, les données sur lesquelles ils sont amenés à travailler sont fortement relationnelles.

Je ne suis que partiellement d'accord avec ce premier argument, car, bien qu'à part dans le monde NoSQL, les bases de données orientées graphes gèrent très bien les relations, elles sont même faites pour. Après, leur complexité est vraiment énorme.

Pour le reste, je rappelle que NoSQL signifie Not Only SQL, et n'a donc pas vocation à remplacer les SGBD-R. On en revient encore une fois au traditionnel "le bon outil pour le bon emploi".
Avatar de Tripow Tripow - Membre à l'essai https://www.developpez.com
le 16/04/2014 à 17:44
Pour le reste, je rappelle que NoSQL signifie Not Only SQL, et n'a donc pas vocation à remplacer les SGBD-R. On en revient encore une fois au traditionnel "le bon outil pour le bon emploi".

Tu es sur? Ici on dirait qu'à la base c'était pas de SQL (No SQL), mais qu'avec l'utilisation ça c'est transformé en Not Only SQL, comme tu le dis. Je ne suis pas sur que cela signifie exactement Not Only SQL.
Avatar de Grimly Grimly - Membre averti https://www.developpez.com
le 16/04/2014 à 18:20
Je rejoins Bono_BX pour dire que NoSQL n'est pas du tout la même réponse que SQL, ils se complémentent dans un sens.

Je travaille sur une application où j'ai des dossiers.
Un dossier appartient à un client qui a une adresse qui appartient à une zone qui lui est géré par plusieurs entités.
Mais ce dossier a un type qui n'est géré que pas certaines entités.
La jointure de ces deux listes entités à partir du dossier doit donner un résultat unique quoi qu'il arrive.
Qu'on n'aille pas me dire que NoSQL réponds efficacement à cette problématique. J'ai ici besoin d'une structure relationnelle solide.

Sur cette même application, j'ai des clients avec une tonne d'informations qui sont utiles/renseignées ou pas suivant leur catégorie. Je dois en plus pouvoir chercher sur chacune de ces informations.
Ici encore, qu'on n'aille pas me dire qu'un SGBDR réponds efficacement à cette problématique. L'aspect déstructuré de mes informations client et les capacités d'indexation qu'offrent des outils comme Solr répondent bien plus efficacement au besoin.

En bref :
Êtes-vous un fervent défenseur des bases de données relationnelles ou NoSQL ?

Les deux.
Avatar de coolspot coolspot - Membre confirmé https://www.developpez.com
le 16/04/2014 à 18:51
Question totalement stupide, il n'y a pas de solution meilleurs que d'autre mais des besoins différent ou chacune des deux solutions peut être la meilleur au grès du besoin.

Bref cette question du meilleurs est aussi stupide que si l'on affirmait que C++ c'est meilleur que Java.
Avatar de atha2 atha2 - Membre éprouvé https://www.developpez.com
le 16/04/2014 à 20:12
Citation Envoyé par Bono_BX  Voir le message
Je ne suis que partiellement d'accord avec ce premier argument, car, bien qu'à part dans le monde NoSQL, les bases de données orientées graphes gèrent très bien les relations, elles sont même faites pour.

Ma question peut aussi paraitre stupide mais qu'elle différence fait tu entre une BDD NoSQL orientées graphes et une BDD relationnelle ? Pour moi (0 expérience sur NoSql ) c'est la même chose... Au API et SGBD utilisé prés. Si on a besoin de relations, autant utiliser une BDD relationnelle, non ?

Sinon, c'est dommage que cette news ne reprenne pas la conclusion de l'article original qui en gros précise :
  • que s'ils n'ont pas gardé NoSql, c'est parce qu'il ne correspondait pas leurs besoins
  • que NoSql ne doit pas être utiliser parce que c'est à la mode mais s'il répond à nos besoin (mieux qu'un SGBDR)
  • que NoSql est jeune, fragmenté et manque d'outil (analyse de perf, import/export...) et d'une documentation complète
Avatar de pcaboche pcaboche - Rédacteur https://www.developpez.com
le 16/04/2014 à 20:48
À plusieurs reprises je me suis demandé quels étaient les avantages des BDD NoSQL, et j'ai fait quelques recherches.
Certaines de ces recherches sont assez révélatrices.

En effet, allez dans Google et tapez "mongodb vs postgresql", c'est particulièrement éloquent.

Les résultats sont principalement de 2 types :
1. les gens qui se sont essayés au NoSQL, qui ont dit "plus jamais ça" et qui sont revenus sur du relationnel
2. les gens qui ont fait des tests de performances entre les 2

Là aussi, les tests sont très intéressants. La plupart du temps, ils arrivent aux conclusions suivantes :
- postgres permet de faire du relationnel, mais il permet aussi de faire du non relationnel (stockage de documents en XML ou en JSON, stockage de key/value avec hstore)
- pour du non relationnel, et avec la bonne configuration, postgres se révèle au moins aussi performant que MongoDB
- par conséquent, avec postsgres on a le meilleur des 2 mondes : on peut faire du non relationnel avec d'excellentes performantes, et faire du relationnel quand on en a besoin, le tout avec un seul et même outil !
Avatar de Grimly Grimly - Membre averti https://www.developpez.com
le 16/04/2014 à 21:15
Citation Envoyé par pcaboche  Voir le message
À plusieurs reprises je me suis demandé quels étaient les avantages des BDD NoSQL, et j'ai fait quelques recherches.
Certaines de ces recherches sont assez révélatrices.

En effet, allez dans Google et tapez "mongodb vs postgresql", c'est particulièrement éloquent.

Les résultats sont principalement de 2 types :
1. les gens qui se sont essayés au NoSQL, qui ont dit "plus jamais ça" et qui sont revenus sur du relationnel
2. les gens qui ont fait des tests de performances entre les 2

Là aussi, les tests sont très intéressants. La plupart du temps, ils arrivent aux conclusions suivantes :
- postgres permet de faire du relationnel, mais il permet aussi de faire du non relationnel (stockage de documents en XML ou en JSON, stockage de key/value avec hstore)
- pour du non relationnel, et avec la bonne configuration, postgres se révèle au moins aussi performant que MongoDB
- par conséquent, avec postsgres on a le meilleur des 2 mondes : on peut faire du non relationnel avec d'excellentes performantes, et faire du relationnel quand on en a besoin, le tout avec un seul et même outil !

Désolé de mettre en doute les résultats que tu a pu trouver, mais si les comparaisons se font sur la base d'une recherche sur un champ (ou partie précise d'un document) particulier, alors le SGBDR est au moins aussi performant que le moteur non structuré. C'est d'ailleurs une bonne nouvelle car sinon on aurait des questions à se poser.
L'avantage de la plupart des moteurs NoSQL est leur capacité d'indexation sur le document entier grâce aux différentes implémentations de MapReduce. Là où Postgre va rendre l'âme c'est dans une recherche de type google. Rechercher un ou plusieurs mots parmi des téra-octets de simples textes comme nos réponses sur ce forum avec classification par pertinence.
Il existe certains modèles relationnels qui permettent d'effectuer ces recherches efficacement par la recherche de mots clés, je n'en doute pas, mais ce n'est pas le but premier d'un SGBDR alors qu'un moteur déstructuré sacrifiera les propriétés ACID d'un SGBD pour te permettre de bonnes performances de recherche.
Avatar de anykeyh anykeyh - Membre confirmé https://www.developpez.com
le 16/04/2014 à 21:29
La grande force (mais aussi ça faiblesse) du NoSQL, c'est l'aspect elastique des types de données, qui permet de stocker des informations spécifiques au cas par cas.

Enfin, moi c'est ce que je ressent. Je trouve le modele HStore de PGSQL pas mal pour ça: une base relationnel avec un champs fourre-tout qui permet d'ajouter des elements à un objet relationnel.

Après je ne sais pas ce que ça vaut en terme de performance, et la complexité des requetes va en grandissant lors de l'usage d'HStore...
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 16/04/2014 à 23:11
Quand je vois la syntaxe NoSQL de MongoDB (c'est du JS ), comparé au SQL ça fait peur :


Là encore ça va, mais les requêtes SQL que je met en place ne sont pas aussi simples que dans cet exemple.
Sans entrer dans les détails des SGBDR vs bases NoSQL, le langage SQL à lui seul est très puissant.

PS: Je ne sais pas si vous avez remarqué mais l'exemple JavaScript me fait penser à l'API Stream de Java 8
Avatar de phili_b phili_b - Expert éminent https://www.developpez.com
le 16/04/2014 à 23:49
Citation Envoyé par Gugelhupf  Voir le message
Quand je vois la syntaxe NoSQL de MongoDB (c'est du JS ), comparé au SQL ça fait peur

Argl ?! C'est à ce point là ? Ben je préfére le bon vieux SQL.
Offres d'emploi IT
Architecte sécurité des systèmes d'information embarqués H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Architecte systèmes études & scientifiques H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Chef projet big data - pse flotte H/F
Safran - Ile de France - Évry (91090)

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