web-dev-qa-db-fra.com

Pourquoi NoSQL est-il meilleur pour la «mise à l'échelle» que le SGBDR?

J'ai lu le texte suivant dans un blog technique discutant des avantages et des inconvénients de NoSQL

" Pendant des années, pour améliorer les performances des serveurs de base de données, les administrateurs de bases de données ont dû acheter des serveurs plus gros à mesure que la charge de la base de données augmente (mise à l'échelle) au lieu de distribuer la base de données sur plusieurs "hôtes" au fur et à mesure que la charge augmente (mise à l'échelle). Les SGBDR ne se développent généralement pas facilement, mais les nouvelles bases de données NoSQL sont en fait conçues pour se développer facilement pour tirer parti de nouveaux nœuds et sont généralement conçues à faible coût matériel de base à l'esprit. "

Je suis devenu confus au sujet de l'évolutivité du SGBDR et de NoSQL.

Ma confusion est:

  1. Pourquoi les SGBDR sont moins capables d'évoluer? Et la raison d'acheter des serveurs plus gros au lieu d'acheter des serveurs plus bon marché.
  2. Pourquoi NoSQL est-il plus capable d'évoluer?
nosqlscalabilityrdbms
31
xiaohan2012

Les SGBDR ont ACID ( http://en.wikipedia.org/wiki/ACID ) et prend en charge les transactions. La mise à l'échelle avec le SGBDR est plus difficile à mettre en œuvre en raison de ces concepts.

Les solutions NoSQL offrent généralement une atomicité au niveau de l'enregistrement, mais ne peuvent pas garantir qu'une série d'opérations réussira (transaction).

Cela se résume à: pour conserver l'intégrité des données et prendre en charge les transactions, un SGBDR multi-serveur aurait besoin d'un canal de communication backend rapide pour synchroniser toutes les transactions et écritures possibles, tout en évitant/gérant les blocages.

C'est pourquoi vous ne voyez généralement qu'un seul maître (écrivain) et plusieurs esclaves (lecteurs).

30
Martin Samson

J'ai donc essayé de comprendre moi-même le résultat réel en ce qui concerne NoSQL vs SGBDR, et je me retrouve toujours avec une réponse qui ne suffit pas. Dans ma recherche, il y a vraiment 2 différences principales entre NoSQL et SQL, une seule étant un véritable avantage.

  1. ACID vs BASE - NoSQL laisse généralement de côté certaines des fonctionnalités ACID de SQL, une sorte de "triche", c'est un moyen d'améliorer les performances en laissant cette couche d'abstraction au programmeur. Cela a déjà été couvert par les affiches précédentes.

  2. Mise à l'échelle horizontale - Le véritable avantage de NoSQL est la mise à l'échelle horizontale, c'est-à-dire le sharding. Étant donné que les "documents" NoSQL sont en quelque sorte un objet "autonome", les objets peuvent être sur différents serveurs sans se soucier de joindre les lignes de plusieurs serveurs, comme c'est le cas avec le modèle relationnel.

Disons que nous voulons retourner un objet comme celui-ci:

post {
    id: 1
    title: 'My post'
    content: 'The content'
    comments: {
      comment: {
        id: 1
      }
      comment: {
        id: 2
      }
      ...

    views: {
      view: {
        user: 1
      }
      view: {
        user: 2
      }
      ...
    }
}

Dans NoSQL, cet objet serait essentiellement stocké tel quel, et peut donc résider sur un seul serveur comme une sorte d'objet autonome, sans avoir besoin de se joindre aux données d'autres tables qui pourraient résider sur d'autres serveurs de base de données.

Cependant, avec les bases de données relationnelles, la publication devrait être jointe avec les commentaires de la table comments, ainsi que les vues de la table views. Ce ne serait pas un problème dans SQL ~ JUSQU'À ~ que la base de données soit divisée en fragments, auquel cas 'comment 1' pourrait être sur un serveur de base de données, tandis que 'comment 2' encore sur un autre serveur de base de données. Cela rend beaucoup plus difficile la création du même objet dans un SGBDR qui a été mis à l'échelle horizontalement que dans une base de données NoSQL.

Des experts de la base de données pourraient-ils confirmer ou argumenter ces points?

26
jessedrelick

Les SGBDR typiques offrent de solides garanties de cohérence. Cela nécessite d'étendre la communication entre les nœuds pour chaque transaction. Cela limite la capacité d'évoluer, car plus de nœuds signifie plus de communication

Les systèmes NoSql font différents compromis. Par exemple, ils ne garantissent pas qu'une deuxième session verra immédiatement les données validées par une première session. Découplant ainsi la transaction de stockage de certaines données du processus de mise à disposition de ces données pour chaque utilisateur. Google "finalement cohérent". Ainsi, une seule transaction n'a pas besoin d'attendre une communication inter-nœuds (ou beaucoup moins). Par conséquent, ils peuvent utiliser beaucoup plus facilement un grand nombre de nœuds.

8
Jens Schauder

Dans le SGBDR, lorsque les données deviennent énormes, il peut arriver que les tables soient réparties sur plusieurs systèmes et, dans ce cas, les opérations telles que JOIN sont très lentes.

Dans le cas de NoSQL en général, les données associées sont stockées ensemble sur la même machine (soit dans un seul document - dans des bases de données orientées document ou dans le cas d'une banque de données à colonnes larges, les colonnes associées sont sur la même machine). D'où sa facilité de mise à l'échelle sur un certain nombre de machines bas de gamme, évidemment dans ce cas, il y aura des données en double à plusieurs endroits, ce qui n'est pas le cas dans le SGBDR.

0
Anuj Mehta