Si vous avez suivi les tendances du développement backend et du Big Data, vous avez probablement déjà remarqué le buzz autour des bases de données NoSQL ces dernières années. Certaines personnes sont inspirées par cette approche de la base de données, tandis que d'autres pensent qu'elle cache une sorte d'astuce : les modèles de données qu'elles contiennent ne sont pas les mêmes que dans les bases de données relationnelles habituelles, les interfaces de programmation d'applications sont inhabituelles et les les applications sont souvent incompréhensibles. Dans cet article, je vais vous expliquer pourquoi ces bases de données NoSQL ont été créées, quels problèmes elles résolvent et pourquoi tant de bases de données différentes sont soudainement nécessaires. Si vous êtes nouveau dans NoSQL, vous pourriez être particulièrement intéressé par la dernière partie de l'article, qui répertorie les types de bases de données NoSQL qui, à mon avis, méritent d'être explorés en premier pour acquérir une compréhension approfondie du domaine.
Pourquoi avons-nous soudainement besoin d’une nouvelle base de données ?
Vous serez peut-être perplexe lorsque vous demanderez : quel est le problème avec les bases de données relationnelles ? Le fait est qu’ils ont très bien travaillé pendant de nombreuses années, mais il y a maintenant un problème qu’ils ne peuvent plus résoudre. Selon certaines prévisions, en 2018, l’humanité générera 50 000 gigaoctets de données par seconde. C’est une quantité colossale de données ! Son stockage et sa manipulation posent un sérieux défi technique. Ce qui est encore pire, c’est que ce volume ne cesse de croître. Il s’avère que les bases de données relationnelles sont mal adaptées au travail avec de très gros volumes de données. Ils sont conçus pour fonctionner sur une seule machine, et si vous souhaitez traiter plus de requêtes, la seule option est d'acheter un ordinateur avec plus de RAM et un processeur plus puissant. Malheureusement, le nombre de requêtes qu'une machine peut traiter est limité et pour un travail distribué sur plusieurs machines, nous avons besoin d'une technologie de base de données différente. Bien sûr, certains lecteurs riront à ce stade et diront qu'il existe deux méthodes largement utilisées pour utiliser plusieurs machines dans le cas d'une base de données relationnelle : la réplication et le partitionnement. C’est vrai, mais ces méthodes ne suffisent pas pour faire face à nos tâches. La réplication en lecture est une technique dans laquelle chaque mise à jour de la base de données est propagée à d'autres machines qui ne peuvent gérer que les demandes de lecture. Dans ce cas, toutes les modifications sont effectuées par un serveur, appelé nœud maître, tandis que d'autres serveurs, appelés réplicas en lecture, ne conservent que des copies des données. L'utilisateur peut lire sur n'importe quelle machine, mais modifier les données uniquement via le nœud maître. Il s'agit d'une méthode pratique et très populaire, mais elle vous permet uniquement de traiter davantage de demandes de lecture et ne résout en aucun cas le problème du traitement des volumes de données requis.
Dans la figure :
Leader (lecture et écriture) : nœud principal (lecture et écriture)
Réplicas en lecture (lecture seule) : réplicas en lecture (lecture seule)
Le partage est une autre approche populaire qui utilise plusieurs instances d'une base de données relationnelle. Chacun d'eux gère les opérations d'écriture et de lecture pour une partie des données. Si une base de données stocke des informations sur les clients, par exemple à l'aide du partitionnement, une machine peut gérer toutes les demandes des clients dont les noms commencent par A, une autre machine peut stocker toutes les données des clients dont les noms commencent par B, et ainsi de suite.
Dans la figure :
Multi-maître (lecture et écriture d'une partie des données) : Plusieurs nœuds maîtres (lecture et écriture d'une partie des données)
Bien que le sharding vous permette d'enregistrer davantage de données, la gestion d'une telle base de données est un véritable cauchemar : vous devez aligner les données sur toutes les machines et faire évoluer le cluster dans les deux sens selon les besoins. Bien que cela semble simple en théorie, y parvenir est assez difficile.
Les bases de données relationnelles peuvent-elles être améliorées ?
Je pense que vous en êtes déjà venu à penser que les bases de données relationnelles ne sont pas les mieux adaptées au volume de données générées dans le monde moderne. Cependant, vous vous demandez peut-être encore pourquoi personne n'a encore créé une « meilleure » base de données relationnelle capable de fonctionner efficacement sur plusieurs machines. Il peut sembler que cette technologie n'a tout simplement pas encore été développée et que des bases de données relationnelles distribuées apparaîtront très prochainement. Hélas, cela n'arrivera pas. C’est mathématiquement impossible et on ne peut rien y faire. Pour comprendre pourquoi il en est ainsi, vous devez examiner le théorème dit du CAP (alias théorème de Brewer). Il a été prouvé en 1999 et indique qu'une base de données distribuée exécutée sur plusieurs machines peut avoir les trois propriétés suivantes : Cohérence - toute opération de lecture renvoie les résultats de la dernière opération d'écriture correspondante. Si le système est cohérent, après avoir écrit de nouvelles données, il est impossible de lire les anciennes données déjà écrasées. Disponibilité ( Une disponibilité) - un système distribué peut répondre à une demande entrante à tout moment et renvoyer une réponse sans erreur. Tolérance de partition : la base de données continue de répondre aux demandes de lecture et d'écriture même lorsque certains de ses serveurs sont temporairement incapables de communiquer entre eux. Cette panne temporaire est appelée panne de connectivité réseau et peut être provoquée par divers facteurs, allant de problèmes physiques de réseau dus à un serveur lent à des dommages physiques à l'équipement réseau. Toutes ces propriétés sont certainement pratiques, et nous aimerions vraiment qu'une base de données les combine toutes. Aucun développeur sensé ne voudrait renoncer, par exemple, à l’accessibilité sans rien obtenir en retour. Malheureusement, le théorème CAP stipule également qu’il est impossible que les trois propriétés soient valables simultanément. Réaliser cela n’est peut-être pas facile, mais c’est possible. Premièrement, si nous avons besoin d’une base de données distribuée, elle doit être « tolérante aux déconnexions ». Cela n’est même pas discuté. Les déconnexions se produisent tout le temps et notre base de données doit fonctionner malgré cela. Comprenons maintenant pourquoi nous ne pouvons pas atteindre à la fois cohérence et disponibilité. Imaginez que nous ayons une simple base de données fonctionnant sur deux machines : A et B. N'importe quel utilisateur peut écrire sur l'une ou l'autre machine, après quoi les données sont copiées sur l'autre.
Imaginez maintenant que ces machines soient temporairement incapables de communiquer entre elles et que la machine B soit incapable d'envoyer ou de recevoir des données de la machine A. Si pendant cette période la machine B reçoit une demande de lecture d'un client, elle a deux options :
Récupérez vos données locales, même si ce ne sont pas les dernières. Dans ce cas, la préférence est donnée à la disponibilité (pour restituer au moins certaines données, même obsolètes).
Erreur de retour. Dans ce cas, la cohérence est privilégiée : le client ne recevra pas de données obsolètes, mais il ne recevra aucune donnée.
Dans la figure :
Partition réseau : perte de connectivité réseau
Les bases de données relationnelles s'efforcent d'incarner simultanément les propriétés de « cohérence » et de « disponibilité » et ne peuvent donc pas fonctionner dans un environnement distribué. Essayer d'implémenter toutes les capacités d'une base de données relationnelle dans un système distribué sera soit irréaliste, soit tout simplement irréalisable . D’un autre côté, les bases de données NoSQL accordent une grande importance à l’évolutivité et aux performances. Ils manquent généralement de fonctionnalités « de base » telles que les connexions et les transactions, et le modèle de données s’avère complètement différent, peut-être même limitant d’une certaine manière. Tout cela permet de stocker de plus grands volumes de données et de traiter plus de requêtes que jamais auparavant.
Comment les bases de données NoSQL équilibrent-elles cohérence et disponibilité ?
Il peut vous sembler que si vous choisissez une base de données NoSQL, vous recevrez toujours soit des données obsolètes, soit une erreur en cas de panne. En pratique, la disponibilité et la cohérence ne sont en aucun cas les seules options disponibles. Il existe un large éventail d'options parmi lesquelles vous pouvez choisir. Les bases de données relationnelles ne disposent pas de ces options, mais NoSQL vous permet de contrôler l'exécution des requêtes de la même manière. D'une manière ou d'une autre, ils vous permettent de définir deux paramètres lors de l'exécution d'opérations d'écriture ou de lecture dans une base de données NoSQL : W - combien de machines du cluster doivent confirmer la sauvegarde des données lors de l'exécution d'une opération d'écriture . Plus le nombre de machines sur lesquelles vous écrivez vos données est grand, plus il sera facile de lire les données les plus récentes lors de la prochaine opération de lecture, mais aussi plus cela prendra de temps. R – sur combien de machines vous souhaitez lire les données . Dans un système distribué, la distribution des données à toutes les machines d'un cluster peut prendre un certain temps, de sorte que certains serveurs disposeront des données les plus récentes tandis que d'autres seront en retard. Plus le nombre de machines à partir desquelles les données sont lues est élevé, plus les chances de lire les données actuelles sont élevées. Regardons un exemple pratique. Si vous avez cinq ordinateurs dans votre cluster et que vous décidez d'écrire des données sur un seul, puis de lire les données d'un ordinateur sélectionné au hasard, il y a 80 % de chances que vous lisiez des données périmées. En revanche, cela utilisera un minimum de ressources. Donc, si les données héritées vous conviennent, ce n’est pas une si mauvaise option. Dans ce cas, les paramètres W et R sont égaux à 1.
D'un autre côté, si vous écrivez des données sur les cinq machines d'une base de données NoSQL, vous pouvez lire les données de n'importe quelle machine et être assuré d'obtenir des données à jour à chaque fois. Effectuer la même opération sur un plus grand nombre de machines prendra plus de temps, mais si des données à jour sont importantes pour vous, vous pouvez choisir cette option. Dans ce cas, W = R = 5. Quel est le nombre minimum de lectures et d’écritures requis pour la cohérence de la base de données ? Voici une formule simple : R + W ≥ N + 1 , où N est le nombre de machines dans le cluster. Cela signifie qu'avec cinq serveurs, vous pouvez choisir soit R = 2 et W = 4, soit R = 3 et W = 3, soit R = 4 et W = 2. Dans ce cas, peu importe sur quelles machines les données sont transférées. est écrit, la lecture sera toujours effectuée depuis au moins une machine avec des données à jour.
D'autres bases de données, telles que DynamoDB, ont des restrictions différentes et autorisent uniquement des écritures cohérentes. Chaque élément de données est stocké sur trois serveurs et lorsque des données sont écrites, elles sont écrites sur deux des trois machines. Mais lors de la lecture des données, vous pouvez choisir l'une des deux options suivantes :
Lecture strictement cohérente, dans laquelle les données sont lues sur deux machines sur trois et renvoient toujours les données écrites les plus récemment.
Une éventuelle lecture cohérente, dans laquelle une machine est sélectionnée au hasard à partir de laquelle lire les données. Cependant, cela peut temporairement renvoyer des données obsolètes.
Pourquoi y a-t-il autant de bases de données NoSQL ?
Si vous suivez l'actualité du développement logiciel, vous avez probablement entendu parler de nombreuses bases de données NoSQL différentes, telles que MongoDB, DynamoDB, Cassandra, Redis et bien d'autres. Vous vous demandez peut-être : pourquoi avons-nous besoin de tant de bases de données NoSQL différentes ? La raison est simple : différentes bases de données NoSQL sont conçues pour résoudre différents problèmes. C'est pourquoi le nombre de bases de données concurrentes est si important. Les bases de données NoSQL se répartissent en quatre catégories principales :
Bases de données orientées documents
Ces bases de données offrent la possibilité de stocker des documents imbriqués complexes, alors que la plupart des bases de données relationnelles ne prennent en charge que les lignes unidimensionnelles. Cette fonctionnalité peut être utile dans de nombreux cas, par exemple lorsqu'il est nécessaire de stocker des informations sur un utilisateur ayant plusieurs adresses dans le système. Lorsque vous utilisez une base de données orientée document, dans ce cas, vous pouvez simplement stocker un objet complexe comprenant un tableau d'adresses, alors que dans une base de données relationnelle, vous devrez créer deux tables : une pour les informations sur l'utilisateur et une pour les adresses. Les bases de données orientées document comblent le fossé entre le modèle objet et le modèle de données. Certaines bases de données relationnelles, telles que PostgreSQL, prennent désormais également en charge le stockage orienté document, mais la plupart des bases de données relationnelles ne disposent toujours pas de cette fonctionnalité.
Bases de données clé/valeur
Les bases de données clé/valeur implémentent généralement le modèle NoSQL le plus simple. Essentiellement, ils vous fournissent une table de hachage distribuée , vous permettant d'écrire des données sur une clé donnée et de les relire en l'utilisant. Les bases de données clé/valeur sont hautement évolutives et ont une latence nettement inférieure à celle des autres bases de données.
Bases de données graphiques
De nombreux domaines, par exemple les réseaux sociaux ou les informations sur les films et les acteurs, peuvent être représentés sous forme de graphiques. Bien que le graphique puisse être représenté à l’aide d’une base de données relationnelle, cela est difficile et peu pratique. Si vous avez besoin de données graphiques, il est préférable d'utiliser une base de données de graphiques spécialisée, qui peut stocker des informations sur le graphique dans un cluster distribué et permet d'implémenter efficacement des algorithmes sur des graphiques.
Bases de données en colonnes
La principale différence entre les bases de données en colonnes et les autres types de bases de données réside dans la manière dont les données sont stockées sur le disque. Les bases de données relationnelles créent un fichier pour chaque table et stockent les valeurs de toutes les lignes de manière séquentielle. Les bases de données en colonnes créent un fichier pour chaque colonne de vos tables. Cette structure vous permet d'agréger les données et d'exécuter certaines requêtes plus efficacement, mais vous devez vous assurer que les données correspondent aux limites de ces bases de données.
Quelle base de données choisir ?
Le choix d’une base de données est généralement un problème frustrant, et avec autant d’options disponibles, cela peut sembler une tâche écrasante. La bonne nouvelle est qu’il n’est pas nécessaire d’en choisir un seul. Au lieu de créer une seule application monolithique qui implémente toutes les fonctionnalités et a accès à toutes les données du système, vous pouvez utiliser un autre modèle moderne appelé microservices : diviser l'application en un ensemble de services indépendants. Chaque service résout son propre problème et utilise uniquement sa propre base de données, la plus adaptée pour résoudre ce problème.
Comment es-tu censé apprendre tout cela ?
Avec autant de bases de données , les apprendre toutes peut sembler une tâche impossible. Bonne nouvelle : vous n’êtes pas obligé de faire cela. Il n’existe que quelques types de bases de données NoSQL, et si vous comprenez leur fonctionnement, les autres seront beaucoup plus faciles à comprendre. De plus, certaines bases de données NoSQL sont utilisées beaucoup plus souvent que d'autres, il est donc préférable de concentrer vos efforts sur les solutions les plus populaires. Voici une liste des bases de données NoSQL les plus couramment utilisées que vous devriez consulter :
MongoDB . Probablement la base de données NoSQL la plus populaire du marché. Si une entreprise n'utilise pas de base de données relationnelle comme magasin de données principal, elle utilise probablement MongoDB. Il s’agit d’un stockage de documents flexible doté d’un bon ensemble d’outils. Au début de sa carrière, MongoDB avait la mauvaise réputation de perdre des données dans certains cas , mais depuis lors, sa stabilité et sa fiabilité se sont considérablement améliorées. Jetez un œil à ce cours MongoDB si vous souhaitez en savoir plus.
DynamoDB . Si vous utilisez Amazon Web Services (AWS), vous feriez mieux d'en apprendre davantage sur DynamoDB. Il s'agit d'une base de données extrêmement fiable, évolutive et à faible latence, dotée d'un riche ensemble de fonctionnalités et d'une intégration avec de nombreux autres services AWS. Le meilleur, c’est que vous n’êtes pas obligé de le déployer vous-même. La configuration d'un cluster DynamoDB évolutif capable de gérer des milliers de requêtes se fait en quelques clics. Si cela vous intéresse, vous pouvez jeter un œil à ce cours .
Néo4j . La base de données de graphiques la plus courante. Il s'agit d'une solution évolutive et stable adaptée à ceux qui souhaitent utiliser un modèle de données graphique. Si vous souhaitez en savoir plus, commencez par ce cours .
Redis . Alors que les autres bases de données décrites ici sont utilisées pour stocker les données principales des applications, Redis est principalement utilisé pour implémenter des caches et stocker des données auxiliaires. Dans de nombreux cas, l'une des bases de données mentionnées ci-dessus est utilisée en tandem avec Redis. Pour en savoir plus, consultez ce cours.
En 2018 avec NoSQL
Les bases de données NoSQL constituent un domaine vaste et en croissance rapide. Ils vous permettent de stocker et de traiter des quantités de données auparavant inimaginables, mais cela a un prix. Ces bases de données ne possèdent pas beaucoup de fonctionnalités que vous connaissez dans les bases de données relationnelles, et il peut être difficile de se préparer à les utiliser. Mais une fois que vous les maîtrisez, vous pouvez créer des bases de données distribuées et évolutives capables de gérer des volumes étonnants de requêtes de lecture et d'écriture, ce qui peut être extrêmement important à mesure que des volumes de données de plus en plus importants sont générés. Original : https://simpleprogrammer.com/guide-nosql-software-developers/
GO TO FULL VERSION