pourquoi les bases de données noSQL sont-elles plus évolutives que SQL?

100

Récemment, j'ai beaucoup lu sur les SGBD noSQL. Je comprends le théorème CAP , les règles ACID , les règles BASE et la théorie de base. Mais aucune ressource n'a été trouvée sur la raison pour laquelle noSQL est plus facilement évolutif que le SGBDR (par exemple, dans le cas d'un système nécessitant de nombreux serveurs de base de données)?

J'imagine que garder les contraintes et les clés étrangères coûte des ressources et que lorsqu'un SGBD est distribué, c'est beaucoup plus compliqué. Mais je pense qu'il y a beaucoup plus que cela.

Quelqu'un peut-il expliquer s'il vous plaît comment noSQL / SQL affecte l'évolutivité?

ducin
la source
7
"Je suppose que le maintien des contraintes et des clés étrangères coûte des ressources et que lorsqu'un SGBD est distribué, c'est beaucoup plus compliqué. Mais je m'attends à ce qu'il y ait beaucoup plus que cela." - En fait, c'est tout. Plus précisément, c’est la caractéristique commune qui rend la plupart des solutions NoSQL plus évolutives que leurs cousins ​​SQL (pour certains modèles de données). Mais NoSQL est un terme extrêmement vague. Différentes familles de bases de données NoSQL ont des caractéristiques différentes qui les rendent plus évolutives.
Yannis
8
Bien sûr, les bases de données SQL s’intègrent parfaitement dans des milliards d’enregistrements. Elles ont juste besoin de quelques compétences pour les concevoir et les configurer, ce que les développeurs d’applications n’ont pas. Et généralement un ensemble assez coûteux de matériel et de licences.
HLGEM
6
À mon avis, cette question ne fait pas double emploi avec l'une ou l'autre. La question de mongodb est (à part un mauvais titre le rendant plus spécifique) de demander quelque chose d'autre qui est en fait plus général. Voté pour rouvrir.
Joeri Sebrechts

Réponses:

79

Les bases de données noSQL offrent une quantité énorme de fonctionnalités qu'une base de données SQL vous confère par nature.

Des choses comme l’application automatique de l’intégrité référentielle, les transactions, etc. Ce sont des choses très pratiques pour certains problèmes, et qui nécessitent des techniques intéressantes pour évoluer en dehors d’un serveur unique (pensez à ce qui se passe si vous devez verrouiller deux tables pour une transaction atomique, et ils sont sur des serveurs différents!).

Les bases de données noSQL n'ont pas tout cela. Si vous avez besoin de ce matériel, vous devez le faire vous-même, mais si vous n'en avez PAS besoin (et de nombreuses applications n'en ont pas), vous avez de la chance. La base de données n'étant pas obligée d'effectuer toutes ces opérations complexes et de verrouiller une grande partie de l'ensemble de données, il est donc très facile de partitionner un élément sur de nombreux serveurs / disques / peu importe et de le faire fonctionner très rapidement.

Michael Kohne
la source
2
Je ne savais pas que c'était aussi simple que cela
Abdul
7
cette réponse acceptée omet totalement de mentionner la fonctionnalité de partage NoSQL manquante dans SQL. La fragmentation est ce qui rend NoSQL adaptable horizontalement.
hyankov
8
@HristoYankov Et cela fonctionne parce que le système NoSQL ne fait pas tout ce qui ne fonctionne pas bien avec le sharding.
user253751
1
@HristoYankov: la base de données SQL peut être fractionnée horizontalement et toutes les bases de données NoSQL ne peuvent pas être fractionnées horizontalement facilement. L'éclatement n'est pas vraiment la raison pour laquelle vous voulez utiliser NoSQL.
Lie Ryan le
@HristoYankov La réponse acceptée va plus loin que votre remarque "échouant totalement à mentionner la fonctionnalité de partage NoSQL manquante dans SQL". La réponse acceptée, à juste titre, parle de POURQUOI le partage horizontal est plus difficile avec les bases de données SQL. En fait, j'ai passé 20 bonnes minutes à chercher la réponse à cette question et pratiquement tout le monde déploie simplement les "ohh NoSQL shards better", sans donner la moindre raison. Réponse totalement inutile. Les réponses acceptées ici répondent parfaitement à la question - bien que très brièvement. Ce serait bien d'avoir plus de raisons listées aussi.
Phoeniyx
176

Il ne s'agit pas de NoSQL vs SQL, mais de BASE vs ACID.

Scalable doit être décomposé en ses composants:

  • Lecture mise à l'échelle = gérer des volumes plus élevés d'opérations de lecture
  • Write Scaling = gérer des volumes plus élevés d'opérations d'écriture

Les bases de données compatibles ACID (comme les SGBDR traditionnels) peuvent mettre à l'échelle les lectures. Elles ne sont pas intrinsèquement moins efficaces que les bases de données NoSQL car les goulots d'étranglement (possibles) en termes de performances sont introduits par des éléments manquants (parfois) par NoSQL (comme les jointures et les restrictions éventuelles) que vous pouvez choisir de ne pas utiliser. Les SGBDR SQL en cluster peuvent mettre à l'échelle les lectures en introduisant des nœuds supplémentaires dans le cluster. Il existe des contraintes quant à la capacité des opérations de lecture à être redimensionnées, mais elles sont imposées par la difficulté de dimensionner les écritures lorsque vous introduisez plus de nœuds dans le cluster.

Ecrire mise à l'échelle est l'endroit où les choses deviennent velues. Le principe ACID impose diverses contraintes que vous ne voyez pas dans les architectures finalement cohérentes (BASE):

  • Atomicité signifie que les transactions doivent être terminées ou échouées dans leur ensemble. Il faut donc effectuer une grande comptabilité dans les coulisses pour le garantir.
  • Les contraintes de cohérence impliquent que tous les nœuds du cluster doivent être identiques. Si vous écrivez sur un nœud, cette écriture doit être copiée sur tous les autres nœuds avant de renvoyer une réponse au client. Cela rend un cluster de SGBDR traditionnel difficile à mettre à l'échelle.
  • Les contraintes de durabilité signifient que pour ne jamais perdre une écriture, vous devez vous assurer qu'avant de renvoyer une réponse au client, l'écriture a été vidée sur le disque.

Pour augmenter les opérations d'écriture ou le nombre de nœuds dans un cluster au-delà d'un certain point, vous devez être en mesure d'assouplir certaines exigences ACID:

  • Supprimer Atomicity vous permet de raccourcir la durée pendant laquelle les tables (ensembles de données) sont verrouillées. Exemple: MongoDB, CouchDB.
  • La perte de cohérence vous permet d’augmenter l’écriture sur les nœuds de la grappe. Exemples: riak, cassandra.
  • La perte de durabilité vous permet de répondre aux commandes d’écriture sans passer sur le disque. Exemples: memcache, redis.

Les bases de données NoSQL suivent généralement le modèle BASE au lieu du modèle ACID. Ils renoncent aux exigences A, C et / ou D et améliorent en retour l'évolutivité. Certains, comme Cassandra, vous permettent de souscrire aux garanties d'ACID lorsque vous en avez besoin. Cependant, toutes les bases de données NoSQL ne sont pas toujours plus évolutives.

L'API SQL ne dispose pas d'un mécanisme permettant de décrire les requêtes pour lesquelles les exigences d'ACID sont assouplies. C'est pourquoi les bases de données BASE sont toutes NoSQL.

Note personnelle: un dernier point que je voudrais dire est que dans la plupart des cas où NoSQL est actuellement utilisé pour améliorer les performances, une solution serait possible sur un SGBDR approprié en utilisant un schéma correctement normalisé avec des index appropriés. Comme le prouve ce site (propulsé par MS SQL Server), les SGBDR peuvent s’adapter à des charges de travail élevées, si vous les utilisez correctement. Les personnes qui ne comprennent pas comment optimiser les SGBDR doivent rester à l'écart de NoSQL, car elles ne comprennent pas les risques qu'elles prennent avec leurs données.

Mise à jour (2019-09-17):

Le paysage des bases de données a évolué depuis la publication de cette réponse. Bien qu'il existe encore une dichotomie entre le monde du SGBDR ACID et le monde de NoSQL BASE, la ligne est devenue plus floue. Les bases de données NoSQL ont ajouté des fonctionnalités issues du monde des SGBDR, telles que les API SQL et la prise en charge des transactions. Il existe même des bases de données promettant SQL, ACID et la mise à l'échelle en écriture, telles que Google Cloud Spanner, YugabyteDB ou CockroachDB. Généralement, le diable se cache dans les détails, mais dans la plupart des cas, il s’agit d’un "assez ACID". Pour une plongée plus en profondeur dans la technologie de base de données et son évolution, vous pouvez jeter un coup d'œil à cette diapositive (les notes de la diapositive contiennent l'explication correspondante).

Joeri Sebrechts
la source
Bien que je convienne que certains magasins NoSQL remplacent ACID par BASE, cette fonctionnalité n’est toujours pas commune à tous les magasins de la catégorie "NoSQL", ce qui est une définition mal définie à l’origine. Après un certain temps, l'interprétation du terme est passée de "Pas de SQL" à "Non seulement de SQL", mais comme de nombreuses bases de ce type ont encore des JOIN ou ont commencé à implémenter des dialectes SQLesque, Mark Madsen a reformulé le terme pour signifier autre chose. son histoire des bases de données en résumé : "Non, SQL" ;-)
Lukas Eder
2
Pour éviter les jointures, nous aurons des données dé-normalisées dans NoSQL, ce qui conduit à la répétition et à davantage de stockage. Mais dans le SGBDR, on peut faire la même chose si la dénormalisation est acceptable. Ainsi, "Joins" ou "no Joins" dépend du DBA et non du type de base de données. Correct ?
Kaushik Lele
2
@dynamic Ces sites utilisent la mise en cache intensive ou une partition. Ces conceptions placent la complexité de la mise à l'échelle des données en dehors de la base de données. Vous pouvez aussi bien utiliser nosql dans un tel cas, car c’est exactement le compromis que nous avons fait.
Joeri Sebrechts
1
"L'API SQL ne dispose pas d'un mécanisme permettant de décrire les requêtes lorsque les exigences d'ACID sont assouplies". Techniquement vrai, mais SQL Server a fait un pas timide dans cette direction. SQL 2014 introduit la durabilité différée, assouplissant le D dans ACID, en échange d'une réduction de la pression du journal d'écriture.
EBarr
3
Cela devrait être la réponse acceptée imo. C'est très clair avec des exemples mais on parvient à rester concis.
Olshansk
4

Il est vrai que les bases de données NoSQL (MongoDB, Redis, Riak, Memcached, etc.) ne conservent pas les contraintes de clé étrangère et que les opérations atomiques doivent être spécifiées plus explicitement. Il est également vrai que les bases de données SQL (SQL Server, Oracle, PostgreSQL, etc.) peuvent être dimensionnées pour gérer des exigences de performances très élevées par des administrateurs de base de données expérimentés.

Les bases de données NoSQL permettent aux programmeurs expérimentés, qui connaissent bien les conditions de concurrence et les opérations atomiques, de renoncer à une grande quantité de traitement requise dans un faible pourcentage du code d'application Web actuel. Les bases de données NoSQL ont certainement des opérations atomiques et la plupart des exigences transactionnelles présentes dans les bases de données SQL peuvent également être obtenues des bases de données NoSQL. La différence est le niveau d'abstraction. Les bases de données NoSQL suppriment les niveaux d'abstraction les plus élevés et confèrent cette possibilité au programmeur d'application, ce qui permet un code plus rapide dans son ensemble, avec une probabilité accrue de corruption des données par les programmeurs non expérimentés.

En conséquence, nous sommes beaucoup plus susceptibles de voir que les bases de données NoSQL sont de plus en plus utilisées dans l’espace des applications Web, où le temps de développement et les performances sont très importants. Les logiciels financiers et d'entreprise conserveront probablement leur héritage SQL car les performances matérielles sont relativement peu coûteuses, ils possèdent des administrateurs de base de données expérimentés et le risque accru causé par des programmeurs non expérimentés n'est pas acceptable.

RandomProgrammer
la source
2
Je ne suis pas sûr d’être d’accord avec la partie concernant les transactions atomiques, au sens ACID (bien qu’il soit difficile de commenter "NoSQL", car il faut débattre de ce que nous entendons exactement). La plupart des gains de performances dans les bases de données NoSQL "typiques" sont obtenus par un relâchement des garanties de cohérence (voir: cohérence éventuelle , ACID par rapport à BASE). Si la cohérence éventuelle est suffisante pour une application (ce qui est souvent le cas), cela permet une mise à l'échelle horizontale beaucoup plus efficace.
Daniel B
4

De IBM developerWorks: fournissez une évolutivité des données au niveau du cloud avec des bases de données NoSQL

L’évolutivité est le système qui devrait pouvoir prendre en charge des bases de données très volumineuses avec des débits de requêtes très élevés et une latence très faible.

Les systèmes NoSQL ont un certain nombre de caractéristiques de conception communes:

  • La capacité d'évoluer horizontalement sur plusieurs serveurs.
  • Une interface ou un protocole simple au niveau appel (contrairement à une liaison SQL).
  • Prise en charge de modèles de cohérence plus faibles que les transactions ACID dans la plupart des SGBDR classiques.
  • Utilisation efficace des index distribués et de la RAM pour le stockage de données.
  • Possibilité de définir de manière dynamique de nouveaux attributs ou un nouveau schéma de données.

Pourquoi les bases de données relationnelles peuvent ne pas être optimales pour la mise à l'échelle

En général, les systèmes de gestion de bases de données relationnelles sont considérés depuis des décennies comme une "solution unique pour la persistance et la récupération des données". Ils ont mûri après d'importants efforts de recherche et développement et ont créé avec beaucoup de succès un vaste marché et des solutions dans différents domaines d'activité.

Les besoins sans cesse croissants en évolutivité et les nouvelles exigences des applications ont créé de nouveaux défis pour le SGBDR classique, notamment un mécontentement face à cette approche unique pour certaines applications à l'échelle Web. La solution à ce problème a été une nouvelle génération de logiciels de bases de données peu onéreux et hautes performances, conçus pour défier la domination des systèmes de gestion de bases de données relationnelles. Une des principales raisons du mouvement NoSQL réside dans le fait que les différentes applications d'applications Web, d'entreprise et de cloud computing ont des exigences différentes en matière de base de données. Par exemple, chaque application ne nécessite pas une cohérence des données stricte.

Autre exemple: pour les sites Web à volume élevé comme eBay, Amazon, Twitter ou Facebook, l'évolutivité et la haute disponibilité sont des exigences essentielles qui ne peuvent être compromises. Pour ces applications, la moindre panne peut avoir des conséquences financières importantes et nuire à la confiance des clients.

Au-dessus de DBA.SE: Qu'est-ce que la mise à l'échelle horizontale signifie?

La mise à l'échelle horizontale consiste essentiellement à créer au lieu de monter. Vous n'allez pas acheter un serveur plus gros et y placer toute votre charge, mais plutôt acheter un ou plusieurs serveurs supplémentaires et répartir votre charge entre eux.

La mise à l'échelle horizontale est utilisée lorsque vous avez la possibilité d'exécuter plusieurs instances simultanément sur des serveurs. En règle générale, il est beaucoup plus difficile de passer d’un serveur à deux, puis de 2 à 5, 10, 50, etc.

Une fois que vous avez résolu les problèmes liés à l'exécution d'instances parallèles, vous pouvez tirer pleinement parti des environnements tels qu'Amazon EC2, le service de cloud de Rackspace, GoGrid, etc. vous n'utilisez pas uniquement pour couvrir ces pics de charge.

Les bases de données relationnelles sont l’un des éléments les plus difficiles à exécuter en lecture / écriture complète en parallèle.

Md Mahbubur Rahman
la source