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

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é?

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.

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

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.

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.