Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Expert éminent sénior
    Base de données relationnelle ou NoSQL, laquelle constitue le meilleur choix ?
    Ce message n'a pas pu être affiché car il comporte des erreurs.

  2. #2
    Membre confirmé
    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".

  3. #3
    Membre à l'essai
    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.

  4. #4
    Membre averti
    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.

  5. #5
    Membre confirmé
    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.

  6. #6
    Membre éprouvé
    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

  7. #7
    Rédacteur

    À 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 !
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  8. #8
    Membre averti
    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.

  9. #9
    Membre confirmé
    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...

  10. #10
    Modérateur

    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
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  11. #11
    Expert éminent
    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.

  12. #12
    Rédacteur

    Citation Envoyé par Grimly Voir le message
    Désolé de mettre en doute les résultats que tu a pu trouver,
    Voici l'une de ces présentations, que j'ai trouvée tres intéressante (j'étais trop fatigué pour la rechercher hier soir) :
    http://www.slideshare.net/stjernstro...gdayfosdem2013

    Parmi les conclusions :
    Vous pouvrrez toujours touver des tâches qui "prouvent" qu'une technologie est la meilleure
    ... y compris pour DBase II
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  13. #13
    Membre éclairé
    Comme d'autre avant moi dans ce fil, je suis d'avis qu'il n'est pas pertinent de poser la question en ces termes. "Laquelle constitue le meilleur choix ?" ne peut avoir de réponse en dehors de tout contexte, puisque c'est justement ce contexte en lien avec les forces et les faiblesses des différents modèles qui permettra de déterminer laquelle est la plus appropriée. De plus, la réponse ne doit pas forcément être unique, certaines données d'une application peuvent se trouver dans une base de données NoSql alors que d'autres se trouvent dans une base de données relationnelle.

    Si dans une application on remplace un système de gestion de bases de données relationnelles par un système de gestion de bases de données NoSql et qu'on se rend compte que cela n'apporte aucun avantage, que cela nuit aux performances, ou que cela complique le développement, cela ne dit rien ni à propos du NoSql en général ni à propos des SGBDR en général, cela indique seulement que le modèle relationnelle était le plus adapté pour cette application.

    Les bases de données NoSql ont leur domaine d'application. Jamais les modèles NoSql (key-value, column, object, etc.) n'ont eu pour vocation de remplacer le modèle relationnel, il n'ont été développé que pour répondre à des problème auxquelles les SGBDR n'apportaient pas de réponse satisfaisante.

  14. #14
    Membre averti
    Bonjour,

    Les bases de données no-sql n'ont pas vocation à remplacer les SGBDR classique, mais à remplir des besoins spécifique (en général gagner en scalabilité). D'ailleurs il existe plusieurs types de bases nosql, très différente les unes des autres.

    Voici une page qui donne une comparaison des différentes bases nosql les plus populaire : http://kkovacs.eu/cassandra-vs-mongo...uchdb-vs-redis

  15. #15
    Expert éminent
    Citation Envoyé par pcaboche Voir le message
    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 !
    Il manque un aspect important des base no SQL(ou aussi newSQL), la capacité de faire du sharding.

    Dans la boite ou je travaille, on est en train de tout virtualiser. ca nous fait gagner beaucoup en automatisation, en réactivité et sur les opérations manuelles.
    Le plus gros problème, c'est que la scalabilité en virtuel est horizontale, et non verticale. Si tu as besoin de plus de puissance, tu ajoute une node a un cluster au lieu d'une nouvelle barette de RAM.

    Et la, les solutions oracle, mysql, postgres sont larguées. Seul NoSQL semble capable de faire ca pour le moment, et des truc newSQL comme nuoDB, mais ou l'on a peu de recul.(et peu de modules, comme un connecteur PDO pour php, doctrine, hibernate, etc...)

    Bref, les bases SQL souffrent chez nous à cause de ce simple fait... et on est en train de choisir les solutions noSQl pour de mauvaises raisons.
    Mon profil linked in

    Chez Adaptive, nous cherchons un dev senior python / Cloud sur Toulouse sud.
    Nous diffusons de la presse digitale à bord des avions avec les plus beaux partenaires !

    Envoyez moi un mp

  16. #16
    Membre à l'essai
    Ce problème est récurrent depuis l'arrivée des bases de données noSQL. A savoir que comme on ne participe pas à une course de voiture avec un tracteur, on ne va pas labourer un champ avec une formule un.
    Il est surtout nécessaire de choisir le bon outil pour répondre à la problématique initiale. Et il est sûr que vouloir faire du relationnel avec du noSQL mènera sûrement à l'échec du projet. D'ailleurs en grande partie dû à des problèmes de performances alors que c'est ce qu'on vient chercher en premier quand on se lance dans l'aventure du noSQL.

    Choisir une base orientée document comme mongoDB, c'est vouloir travailler avec des documents souvent non structurés d'ailleurs. Ou encore faire beaucoup plus d'écritures que de lectures. Bref faire souvent du data minning dans des terra de données même si de tels systèmes ne se limitent pas à ça. Tout ça avec des performances époustouflantes par rapport à du SGDB classique. SGDB classique qui rivalisent d'ingéniosité pour offrir des fonctionnalités du type "Big Data" avec des choses comme "Columnstore Indexes" ou autre. Tout ça parce que ce genre de système bat des records en scalabilité.

    Il existe une multitude de bases de données noSQL, orientées graph, clef/valeur, document, colonne, ... qui répondent à une multitude de problématiques. Il est sûr que choisir le mauvais outil ou le mauvais modèle de données, c'est se tirer une balle dans le pied directement. Le discours de ce monsieur est surtout un aveu d'échec face à la mauvaise solution qu'il à choisi.

    Pour conclure il est plus facile de critiquer une base de données parce qu'elle n'apporte pas ce qu'elle promet que d'avouer que la solution que l'on a choisi n'était pas du tout adaptée...

  17. #17
    Nouveau membre du Club
    A chacun son emploi
    Je rejoins un peu les commentaires précédents précisant qu'il est plus judicieux d'analyser en amont les données qui devront être traitées pour faire le bon choix de SGBD.

    Je fais même l'analogie avec le secteur automobile. Les voitures électriques sont bien présentes mais représentent encore un faible % comparées aux véhicules à moteur thermique. Les 2 types de véhicules cohabitent mais pour l'instant, l'un n'est pas prêt de remplacer l'autre.

    Donc à chacun de voir ce qu'il souhaite en faire comme usage avant de se lancer tête baissée parce que c'est juste à la mode et que les grands groupes l'utilisent.

  18. #18
    Rédacteur

    A chaque problème sa solution, il faut arrêter de comparer deux types de stoquage de données aussi différent.
    Un exemple avec twitter qui utuilise les deux : SGBDR (mysql/mariaDb) + noSQL(cassandra)
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  19. #19
    Membre expérimenté
    Raison d'être du NO SQL
    La raison d'être du NoSQL est de créer des bases de données plus rapide que celle SQL en évitant certaines contraintes liés au SQL. Par exemple une base qui ne gère pas de droits d'accès et d'utilisateur gagne peu de temps mais cela peu parfois être utile. De même une base, NoSQL, qui n'a pas comme contrainte la jointure du SQL peut stocker / restituer plus rapidement les données. C'est le cas des bases clé/valeurs. Alors oui on gagne a utiliser du NoSQL si on a pas ces contraintes. Par contre remettre ces contraintes autre part, c'est perdre du temps, c'est réinventer la roue, c'est perdre en sécurité et efficacité (car on aura pas utilisé une méthode éprouvé)...
    Une autre raison du NoSQL c'est de gérer de nouvelles contraintes comme celle des bases graphes. Cela permet de gérer la contrainte de jointure graphique et de résoudre des problème très simplement (Meilleur chemin par exemple) car la solution est intégrer dans la base.
    Il y a des outils meilleurs que d'autres (MariaDB > MySQL > "SQL Server" ) mais il n'y a pas d'outils universel.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  20. #20
    Membre chevronné
    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 :


    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
    C'est du Javascript, quoi. Ce qui rallonge beaucoup, c'est la phase de mapping, puisque MongoDB est schemaless.

    Après, si on veut modifier la structure des données qu'on veut stocker, ça se fait de manière transparente, sans interruption du système, par exemple. Pas besoin de faire un ALTER TABLE plutôt acrobatique quand on fait ça sur une table avec 10 millions d'entrées.

    On peut multiplier les exemples dans les deux sens sans rien démontrer...
    J'appelle "Point Traroth" le moment dans une discussion où quelqu'un parle des Bisounours. A partir de ce moment, toute discussion sérieuse devient impossible, puisque la légitimité d'une des parties pour exposer son point de vue est mise en cause. C'est juste un anathème, un moyen de décrédibiliser les autres sans avoir à discuter.

###raw>template_hook.ano_emploi###