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 théorème CAP , ACIDE règles, BASE règles et la théorie de base. Mais vous n'avez trouvé aucune ressource sur la raison pour laquelle NoSQL est évolutif plus facilement que RDBMS (par exemple, dans le cas d'un système qui nécessite beaucoup de serveurs de base de données)?
Je suppose que garder les contraintes et les clés étrangères coûte des ressources et quand un SGBD est distribué, c'est beaucoup plus compliqué. Mais je pense qu'il y a bien plus que cela.
Quelqu'un peut-il expliquer comment noSQL/SQL affecte l'évolutivité?
les bases de données noSQL renoncent à une énorme quantité de fonctionnalités qu'une base de données SQL vous offre par sa nature même.
Des choses comme l'application automatique de l'intégrité référentielle, les transactions, etc. Ce sont toutes des choses très pratiques à avoir pour certains problèmes, et qui nécessitent des techniques intéressantes pour évoluer en dehors d'un seul serveur (pensez à ce qui se passe si vous devez verrouiller deux tables pour une transaction atomique, et elles sont sur des serveurs différents!).
les bases de données noSQL n'ont pas tout cela. Si vous avez besoin de ce truc, vous devez le faire vous-même, mais si vous n'en avez pas besoin (et il y a beaucoup d'applications qui ne le font pas), alors bon sang, quelle chance avez-vous. La base de données n'a pas à effectuer toutes ces opérations complexes et à se verrouiller sur une grande partie de l'ensemble de données, il est donc très facile de partitionner la chose sur de nombreux serveurs/disques/autres et de la faire fonctionner très rapidement.
Il ne s'agit pas de NoSQL vs SQL, il s'agit de BASE vs ACID.
Extensible doit être décomposé en ses constituants:
- Echelle de lecture = gérer des volumes plus élevés d'opérations de lecture
- Mise à l'échelle en écriture = gérer des volumes plus élevés d'opérations d'écriture
Les bases de données conformes à ACID (comme les SGBDR traditionnels) peuvent adapter les lectures. Ils ne sont pas intrinsèquement moins efficaces que les bases de données NoSQL car les (possibles) goulots d'étranglement des performances sont introduits par des choses qui manquent (parfois) à NoSQL (comme les jointures et les restrictions) que vous pouvez choisir de ne pas utiliser. Les SGBDR SQL en cluster peuvent faire évoluer les lectures en introduisant des nœuds supplémentaires dans le cluster. Il existe des contraintes quant à la mesure dans laquelle les opérations de lecture peuvent être mises à l'échelle, mais elles sont imposées par la difficulté de mettre à l'échelle les écritures lorsque vous introduisez davantage de nœuds dans le cluster.
La mise à l'échelle de l'écriture est l'endroit où les choses deviennent velues. Il existe diverses contraintes imposées par le principe ACID que vous ne voyez pas dans les architectures finalement cohérentes (BASE):
- L'atomicité signifie que les transactions doivent aboutir ou échouer dans leur ensemble, donc beaucoup de comptabilité doit être effectuée en coulisses pour garantir cela.
- Les contraintes de cohérence signifient 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 SGBDR traditionnel difficile à mettre à l'échelle.
- Les contraintes de durabilité signifient que pour ne jamais perdre d'é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 pouvoir assouplir certaines des exigences ACID:
- La suppression de l'atomicité vous permet de raccourcir la durée pendant laquelle les tables (ensembles de données) sont verrouillées. Exemple: MongoDB, CouchDB.
- La suppression de la cohérence vous permet d'intensifier les écritures sur les nœuds de cluster. Exemples: riak, cassandra.
- La suppression de la durabilité vous permet de répondre aux commandes d'écriture sans vidage 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 en retour ils améliorent l'évolutivité. Certains, comme Cassandra, vous permettent de bénéficier des garanties ACID lorsque vous en avez besoin. Cependant, toutes les bases de données NoSQL ne sont pas toujours plus évolutives.
L'API SQL n'a pas de mécanisme pour décrire les requêtes où les exigences d'ACID sont assouplies. C'est pourquoi les bases de données BASE sont toutes NoSQL.
Note personnelle: un dernier point que j'aimerais souligner 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 évoluer vers des charges de travail élevées, si vous les utilisez correctement. Les personnes qui ne savent pas comment optimiser les SGBDR devraient 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 toujours une dichotomie entre le monde RDBMS ACID et le monde NoSQL BASE, la ligne est devenue plus floue. Les bases de données NoSQL ont ajouté des fonctionnalités du monde RDBMS comme les API SQL et le support des transactions. Il existe désormais même des bases de données qui promettent une mise à l'échelle SQL, ACID et, comme Google Cloud Spanner, YugabyteDB ou CockroachDB. Typiquement, le diable est dans les détails, mais pour la plupart des buts ce sont "assez ACIDE". Pour une plongée plus approfondie dans la technologie de base de données et comment elle a évolué, vous pouvez jeter un œil à ce diaporama (les notes de la diapositive ont l'explication qui l'accompagne).
Il est vrai que les bases de données NoSQL (MongoDB, Redis, Riak, Memcached, etc.) ne conservent pas de contraintes de clé étrangère, et 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 mises à l'échelle pour gérer des exigences de performances très importantes par des DBA chevronnés.
Les bases de données NoSQL permettent aux programmeurs aguerris, qui connaissent bien les conditions de concurrence et les opérations atomiques, de renoncer à une grande quantité de traitement requis uniquement dans un petit pourcentage du code d'application Web d'aujourd'hui. 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. La différence est le niveau d'abstraction. Les bases de données NoSQL suppriment les niveaux d'abstraction plus élevés et remettent cette capacité au programmeur d'application, ce qui entraîne un code global plus rapide avec une probabilité accrue de corruption de données par des programmeurs non assaisonnés.
En conséquence, nous sommes beaucoup plus susceptibles de voir les bases de données NoSQL être 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 bon marché, ils ont des DBA chevronnés à portée de main et le risque accru causé par des programmeurs non assaisonnés n'est pas acceptable.
De IBM developerWorks: Fournir une évolutivité des données au niveau du cloud avec des bases de données NoSQL
L'évolutivité est le système qui devrait être capable de prendre en charge de très grandes bases de données avec des taux de demande très élevés à une latence très faible.
Les systèmes NoSQL ont un certain nombre de caractéristiques de conception en commun:
- La capacité d'évoluer horizontalement le débit sur de nombreux serveurs.
- Une interface ou un protocole de niveau d'appel simple (contrairement à une liaison SQL).
- Prise en charge de modèles de cohérence plus faibles que les transactions ACID dans la plupart des SGBDR traditionnels.
- Utilisation efficace des index distribués et RAM pour le stockage des données.
- La possibilité de définir dynamiquement 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 ont été considérés comme une "solution universelle pour la persistance et la récupération des données" depuis des décennies. Ils ont mûri après d'importants efforts de recherche et développement et ont créé avec succès un grand marché et des solutions dans différents domaines d'activité.
Le besoin toujours croissant d'évolutivité et les nouvelles exigences des applications ont créé de nouveaux défis pour les SGBDR traditionnels, y compris une certaine insatisfaction à l'égard de cette approche unique dans certaines applications à l'échelle du Web. La réponse à cela a été une nouvelle génération de logiciels de base de données à faible coût et hautes performances conçus pour contester la domination des systèmes de gestion de bases de données relationnelles. L'une des principales raisons du mouvement NoSQL est que les différentes implémentations d'applications Web, d'entreprise et de cloud computing ont des exigences différentes de leurs bases de données - toutes les applications ne nécessitent pas une cohérence rigide des données, par exemple.
Autre exemple: pour les sites Web à haut volume comme eBay, Amazon, Twitter ou Facebook, l'évolutivité et la haute disponibilité sont des exigences essentielles qui ne peuvent être compromises. Pour ces applications, même la moindre panne peut avoir des conséquences financières importantes et avoir un impact sur la confiance des clients.
Plus sur DBA.SE: Que signifie la mise à l'échelle horizontale?
La mise à l'échelle horizontale se construit essentiellement au lieu d'augmenter. Vous n'allez pas acheter un plus gros serveur plus costaud et y déplacer toute votre charge, au lieu de cela, vous achetez 1+ serveurs supplémentaires et répartissez votre charge entre eux.
La mise à l'échelle horizontale est utilisée lorsque vous avez la possibilité d'exécuter simultanément plusieurs instances sur des serveurs. Typiquement, il est beaucoup plus difficile de passer de 1 serveur à 2 serveurs que de passer 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 d'environnements comme Amazon EC2, le service cloud de Rackspace, GoGrid, etc. vous n'utilisez pas simplement 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.