Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 4 sur 4

Discussion: Nosql scale up?

  1. #1
    Invité de passage
    Profil pro tarek
    Inscrit en
    février 2011
    Messages
    7
    Détails du profil
    Informations personnelles :
    Nom : tarek

    Informations forums :
    Inscription : février 2011
    Messages : 7
    Points : 1
    Points
    1

    Par défaut Nosql scale up?

    Bonjour,
    J'ai trouvé dans le net que le scale up (l'ajout de ressources CPU ou Ram par exple à un serveur) ne marche pas avec les SGBDs relationnelles classiques, est ce vrai ?
    Source Design Patterns for Distributed Non-Relational Databases@@AMEPARAM@@ssplayer2.swf?doc=nosql-090612013018-phpapp01&stripped_title=design-patterns-for-distributed-nonrelational-databases@@AMEPARAM@@nosql-090612013018-phpapp01@@AMEPARAM@@design-patterns-for-distributed-nonrelational-databases 3ème page du slideshare.
    J'ai lu aussi que le scale out est faisable théoriquement mais pratiquement c'est difficile de le réaliser.
    Merci d'avance pour vos réponses.

  2. #2
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2008
    Messages
    62
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2008
    Messages : 62
    Points : 24
    Points
    24

    Par défaut

    C'est pas qu'on ne puisse pas, c'est surtout qu'à un certain point cela ne va plus suffire à supporter le traffic. Après on peut effectivement le faire, mais cela à un coût et cela ne peut pas se faire à l'infini. L'étape suivante est bien sûr de scale out, comme précisé dans ton slide. Mais cela a aussi ses limites (complexe à mettre en place notamment).
    Au bout du compte on en arrive à envisager d'autres solutions, comme par exemple les bases de données non-relationnelles.

  3. #3
    Modérateur
    Avatar de al1_24
    Homme Profil pro Alain
    Ingénieur d'études décisionnel
    Inscrit en
    mai 2002
    Messages
    5 628
    Détails du profil
    Informations personnelles :
    Nom : Homme Alain
    Âge : 53
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 5 628
    Points : 13 737
    Points
    13 737

    Par défaut

    Citation Envoyé par Shinosha Voir le message
    Au bout du compte on en arrive à envisager d'autres solutions, comme par exemple les bases de données non-relationnelles.
    Ou des SGBDR architecturés pour des traitements massivement parallèles (Teradata ou Greenplum par exemple)
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  4. #4
    Membre du Club

    Inscrit en
    janvier 2009
    Messages
    53
    Détails du profil
    Informations forums :
    Inscription : janvier 2009
    Messages : 53
    Points : 62
    Points
    62

    Par défaut

    Pour ajouter aux points precedents...

    Il est possible de scaler horizontalement une base SQL (RDBMS) mais c'est souvent couteux et compliqué car le modele relationnel se s'y prete pas bien.

    - comment partitionner de facon simple et efficace les données lorsqu'elles sont reparties sur plusieurs tables?
    - comment gerer de facon simple et efficace les transactions sur differentes tables lorsqu'elles sont distribuees sur plusieurs serveurs?

    Voila 2 raisons qui rendent la scalabilité horizontale compliqué.

    Dans le cas des base NoSQL qui ont ete concues pour cela (notamment les bases orientes Documents, Table, K/V) la scalabilité horizontale est plus simple a gerer:
    - une entité (document, row, ...) contient toutes les informations (pas de "relations physique") et il est donc simple de le stocker et de partitionner les données sur leur clé par exemple.
    - la transaction se fait au niveau de l'entité (document par exemple) et donc simpler a gerer.

    Ce n'est pas parceque sur le "papier" les base NoSQL sont "scalables" que ca marche tout seul il faut également prendre en compte des points importants:
    - comment reagit ton cluster et tes applications lorsque tu ajoutes des noeuds a ton cluster? (partionnement/rebalancing des données, ton cluster est-il toujours disponible en lecture? ecriture? impacte sur les peformances?)
    - que ce passe-t-il lorsqu'il y a une failure ? (partionnement/rebalancing des données, ton cluster est-il toujours disponible en lecture? ecriture? impacte sur les peformances?)
    ...

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
  •