Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 21 à 39 sur 39
  1. #21
    Membre régulier
    Profil pro Nicolas Labrot
    Inscrit en
    juillet 2006
    Messages
    76
    Détails du profil
    Informations personnelles :
    Nom : Nicolas Labrot

    Informations forums :
    Inscription : juillet 2006
    Messages : 76
    Points : 82
    Points
    82

    Par défaut

    En même temps Oracle n'a pas tort.

    Quid de MongoDB dans 2 ans ? Bcp l'utilisent car il est "gratuit" mais la santé de 10gen n'est pas celle d'Oracle

  2. #22
    Membre Expert Avatar de StringBuilder
    Homme Profil pro Sylvain Devidal
    Chef de projets Générix
    Inscrit en
    février 2010
    Messages
    1 671
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets Générix
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 671
    Points : 2 217
    Points
    2 217

    Par défaut

    Je découvre le NoSQL avec ce topic.

    Une question que je me pose : mais pourquoi bon sang les SGBD n'intègrent-ils pas une gestion NoSQL ?

    En effet, le NoSQL seul est très limité en terme de contraintes d'intégrité, il y a de la réplication de partout, etc.
    Et les SGBD sont eux, très limité lorsque la volumétrie devient importante (quoique).

    Pourquoi ne pas proposer des nouveaux types de tables dans les SGBD actuels, qui soient en mode NoSQL, avec possibilité de les référencer depuis les tables du modèle relationnel ?

    Ainsi, certains objets en grand nombre, pourraient être gérés dans une table NoSQL, alors que le reste serait, au sein de la même base, dans une structure relationnelle classique.

    J'imagine par exemple ce site :
    - Toute les gestion des comptes utilisateurs, l'arborescence des forums, des articles, etc. resterait dans des tables relationnelles classiques.
    - Et l'ensemble des éléments du forum et des articles seraient dans des tables NoSQL.

    Personnellement, cela ne me choquerait pas : on bénéficierait des avantages des deux solutions, qui pourrait tout à fait cohabiter, non ?

  3. #23
    Membre expérimenté
    Homme Profil pro Arnaud Benhamdine
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Nom : Homme Arnaud Benhamdine
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 504
    Points
    504

    Par défaut

    Toujours pas compris l'intérêt de ce NoSQL...

    Mais bon je suis prêt changer d'avis si quelqu'un a de vrais arguments.

    Qu'est ce qui vous oblige à faire du relationnel dans un SGBDR ? C'est vous qui faites le modèle, c'est pas le SGBD qui vous l'impose !
    Si vous avez envie de tout mettre dans une seule table, libre à vous...

    Si vous voulez avoir une table avec juste une colonne de type id et une colonne de type XML ou JSON pour stocker une donnée structurée, vous pouvez...

    Ca me fait rire les arguments sur le volume de données... vous croyez que les SGBDR "classiques" ne gèrent pas de gros volumes de données ??? Mais les SGBDR gèrent des BDD bien plus volumineuses que les bases des plus gros sites d'e-commerce...

    Et on parle de ne pas respecter les principes ACID... mais bon sang quel peut être l'intérêt de ne pas respecter un principe qui permet d'avoir des transactions atomiques, des données cohérentes et intègres, des accès concurrentiels cohérents... etc... ??? alors là j'aimerai bien savoir...

    Cdlt, Arnaud.

  4. #24
    Membre Expert Avatar de StringBuilder
    Homme Profil pro Sylvain Devidal
    Chef de projets Générix
    Inscrit en
    février 2010
    Messages
    1 671
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets Générix
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 671
    Points : 2 217
    Points
    2 217

    Par défaut

    Je ré-itère : je ne connais pas du tout NoSQL, et j'ai juste rapidement lu une petite définition trouvée dans Google.

    Oui, les SGBD actuels permettent de stocker un très grand nombre d'éléments, avec de très gros volumes.

    Mais à l'image de MySQL quand il fonctionne avec un système de fichiers n'acceptant pas les transaction "InnoDB" je crois, un moteur de base de données écrit spécifiquement pour ne pas tirer partie des transactions et autres règles d'intégrité des SGBDR est bien plus rapide qu'un Oracle ou un SQL Server par exemple.

    C'est là que NoSQL gagne à être utilisé (de ce que je comprends).

    Pour le reste, tu as raison, rien n'empêche de stocker du bordel dans une table poubelle dans un SGBDR. Reste que le moteur du SGBDR n'est pas optimisé pour gérer/indexer efficacement cette structure.

    D'où mon interrogation/suggestion quant à l'éventuelle intégration de NoSQL dans les moteurs des SGBDR.

  5. #25
    Membre régulier
    Profil pro Nicolas Labrot
    Inscrit en
    juillet 2006
    Messages
    76
    Détails du profil
    Informations personnelles :
    Nom : Nicolas Labrot

    Informations forums :
    Inscription : juillet 2006
    Messages : 76
    Points : 82
    Points
    82

    Par défaut

    Citation Envoyé par Arnaud B. Voir le message
    Toujours pas compris l'intérêt de ce NoSQL...

    Mais bon je suis prêt changer d'avis si quelqu'un a de vrais arguments.

    Qu'est ce qui vous oblige à faire du relationnel dans un SGBDR ? C'est vous qui faites le modèle, c'est pas le SGBD qui vous l'impose !
    Si vous avez envie de tout mettre dans une seule table, libre à vous...

    Si vous voulez avoir une table avec juste une colonne de type id et une colonne de type XML ou JSON pour stocker une donnée structurée, vous pouvez...

    Ca me fait rire les arguments sur le volume de données... vous croyez que les SGBDR "classiques" ne gèrent pas de gros volumes de données ??? Mais les SGBDR gèrent des BDD bien plus volumineuses que les bases des plus gros sites d'e-commerce...

    Et on parle de ne pas respecter les principes ACID... mais bon sang quel peut être l'intérêt de ne pas respecter un principe qui permet d'avoir des transactions atomiques, des données cohérentes et intègres, des accès concurrentiels cohérents... etc... ??? alors là j'aimerai bien savoir...

    Cdlt, Arnaud.
    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.

    Un JSOn ou un XML n'est pas recherchable (exception faite pour le XML avec les gros SGBDR).

    Les bases NoSQL ont des transactions, des données cohérentes, des accès concurrents...

    Le NoSQL ne s’érige pas contre le SQL, il offre en alternative à un modèle tout sql (NotSQL = not only sql). L'idée c'est d'utilisé la techno adaptée à ses besoins.

  6. #26
    Expert Confirmé Sénior
    Avatar de shenron666
    Homme Profil pro Tony BAYART
    Ingénieur développement logiciels
    Inscrit en
    avril 2005
    Messages
    2 316
    Détails du profil
    Informations personnelles :
    Nom : Homme Tony BAYART
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : avril 2005
    Messages : 2 316
    Points : 4 511
    Points
    4 511

    Par défaut

    Citation Envoyé par Arnaud B. Voir le message
    Qu'est ce qui vous oblige à faire du relationnel dans un SGBDR ? C'est vous qui faites le modèle, c'est pas le SGBD qui vous l'impose !
    reste que le moteur est prévu et optimisé pour gérer du relationnel, que tu en fasse ou pas

    [/quote]Si vous avez envie de tout mettre dans une seule table, libre à vous...[/quote]
    aucun intérêt ni aucun rapport avec le nosql
    c'est juste se tirer une balle dans le pied

    Ca me fait rire les arguments sur le volume de données... vous croyez que les SGBDR "classiques" ne gèrent pas de gros volumes de données ??? Mais les SGBDR gèrent des BDD bien plus volumineuses que les bases des plus gros sites d'e-commerce...
    et les sites d'e-commerce dont tu parles, est-ce qu'ils ont réellement besoin du côté relationnel ?
    si c'est jute pour stocker des informations, une base nosql donnerait peut-être de meilleures performances

    Et on parle de ne pas respecter les principes ACID... mais bon sang quel peut être l'intérêt de ne pas respecter un principe qui permet d'avoir des transactions atomiques, des données cohérentes et intègres, des accès concurrentiels cohérents... etc... ??? alors là j'aimerai bien savoir...
    parce que trop de limite provoque parfois trop de contraintes
    et les contraintes ACID qui font qu'une BDR est efficace pour ce qu'elle fait font aussi que ces mêmes BDR ont des limitations

    une simple question : pourquoi stocker un champs vide ?
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  7. #27
    Membre Expert Avatar de StringBuilder
    Homme Profil pro Sylvain Devidal
    Chef de projets Générix
    Inscrit en
    février 2010
    Messages
    1 671
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets Générix
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 671
    Points : 2 217
    Points
    2 217

    Par défaut

    Citation Envoyé par shenron666 Voir le message
    une simple question : pourquoi stocker un champs vide ?
    Si t'as un champ vide, c'est parceque ta base est mal modélisée :o

  8. #28
    Expert Confirmé Sénior
    Avatar de shenron666
    Homme Profil pro Tony BAYART
    Ingénieur développement logiciels
    Inscrit en
    avril 2005
    Messages
    2 316
    Détails du profil
    Informations personnelles :
    Nom : Homme Tony BAYART
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : avril 2005
    Messages : 2 316
    Points : 4 511
    Points
    4 511

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    Si t'as un champ vide, c'est parceque ta base est mal modélisée :o
    donc toutes les bases ayant un champ nullable sont mal modélisées pour toi ?
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  9. #29
    Membre expérimenté
    Homme Profil pro Arnaud Benhamdine
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Nom : Homme Arnaud Benhamdine
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 504
    Points
    504

    Par défaut

    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 ?

  10. #30
    Membre expérimenté
    Homme Profil pro Arnaud Benhamdine
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Nom : Homme Arnaud Benhamdine
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 504
    Points
    504

    Par défaut

    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.

  11. #31
    Membre expérimenté
    Homme Profil pro Arnaud Benhamdine
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Nom : Homme Arnaud Benhamdine
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 504
    Points
    504

    Par défaut

    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...

  12. #32
    Membre régulier
    Profil pro Nicolas Labrot
    Inscrit en
    juillet 2006
    Messages
    76
    Détails du profil
    Informations personnelles :
    Nom : Nicolas Labrot

    Informations forums :
    Inscription : juillet 2006
    Messages : 76
    Points : 82
    Points
    82

    Par défaut

    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.

  13. #33
    Membre Expert Avatar de StringBuilder
    Homme Profil pro Sylvain Devidal
    Chef de projets Générix
    Inscrit en
    février 2010
    Messages
    1 671
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets Générix
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 671
    Points : 2 217
    Points
    2 217

    Par défaut

    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.

  14. #34
    Membre Expert Avatar de kain_tn
    Homme Profil pro
    Inscrit en
    mars 2005
    Messages
    664
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations forums :
    Inscription : mars 2005
    Messages : 664
    Points : 1 534
    Points
    1 534

    Par défaut

    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.
    Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


    Code C :
    1
    2
    3
    4
    5
    6
    7
    #include <stdio.h>
     
    int main(int argc, char **argv) {
     
        printf("So long, and thanks for the fish, Dennis...\n");
        return 0;
    }

  15. #35
    Membre régulier
    Profil pro Nicolas Labrot
    Inscrit en
    juillet 2006
    Messages
    76
    Détails du profil
    Informations personnelles :
    Nom : Nicolas Labrot

    Informations forums :
    Inscription : juillet 2006
    Messages : 76
    Points : 82
    Points
    82

    Par défaut

    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.

  16. #36
    Expert Confirmé Sénior
    Avatar de shenron666
    Homme Profil pro Tony BAYART
    Ingénieur développement logiciels
    Inscrit en
    avril 2005
    Messages
    2 316
    Détails du profil
    Informations personnelles :
    Nom : Homme Tony BAYART
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : avril 2005
    Messages : 2 316
    Points : 4 511
    Points
    4 511

    Par défaut

    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"
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  17. #37
    Membre expérimenté
    Homme Profil pro Arnaud Benhamdine
    Consultant
    Inscrit en
    octobre 2004
    Messages
    253
    Détails du profil
    Informations personnelles :
    Nom : Homme Arnaud Benhamdine
    Localisation : France

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2004
    Messages : 253
    Points : 504
    Points
    504

    Par défaut

    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.

  18. #38
    Membre régulier
    Profil pro Nicolas Labrot
    Inscrit en
    juillet 2006
    Messages
    76
    Détails du profil
    Informations personnelles :
    Nom : Nicolas Labrot

    Informations forums :
    Inscription : juillet 2006
    Messages : 76
    Points : 82
    Points
    82

    Par défaut

    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

  19. #39
    Invité régulier
    Inscrit en
    mai 2011
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : mai 2011
    Messages : 13
    Points : 9
    Points
    9

    Par défaut

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •