Bases de la conception de bases de données - Comparaison de PostgreSQL, Cassandra et MongoDB

Bonjour mes amis. Avant de partir pour la deuxième partie des vacances de mai, nous partageons avec vous le matériel que nous avons traduit la veille du lancement d'un nouveau stream au rythme du «SGBD relationnel» .



Les développeurs d'applications passent beaucoup de temps à comparer plusieurs bases de données d'exploitation pour choisir celle qui convient le mieux à leur charge de travail prévue. Les besoins peuvent inclure une modélisation des données simplifiée, des garanties transactionnelles, des performances de lecture / écriture, une mise à l'échelle horizontale et une tolérance aux pannes. Par tradition, le choix commence par une catégorie de base de données, SQL ou NoSQL, car chaque catégorie fournit un ensemble clair de compromis. Des performances élevées en termes de faible latence et de débit élevé sont généralement considérées comme une exigence de compromis et sont donc nécessaires pour toute base de données de l'échantillon.

Le but de cet article est d'aider les développeurs d'applications à faire le bon choix entre SQL et NoSQL dans le contexte de la modélisation des données d'application. Nous examinerons une base de données SQL, à savoir PostgreSQL et deux bases de données NoSQL - Cassandra et MongoDB, pour parler des bases de la conception de bases de données, telles que la création de tables, leur remplissage, la lecture des données de la table et leur suppression. Dans le prochain article, nous examinerons certainement les index, les transactions, les JOIN, les directives TTL et la conception de bases de données basées sur JSON.

Quelle est la différence entre SQL et NoSQL?

Les bases de données SQL augmentent la flexibilité des applications grâce aux garanties transactionnelles ACID, ainsi que leur capacité à interroger des données à l'aide de JOIN de manière inattendue en plus des modèles de bases de données relationnelles normalisées existantes.

Compte tenu de leur architecture monolithique / à nœud unique et de l'utilisation d'un modèle de réplication maître-esclave pour la redondance, les bases de données SQL traditionnelles n'ont pas deux caractéristiques importantes - l'évolutivité linéaire de l'enregistrement (c'est-à-dire le fractionnement automatique en plusieurs nœuds) et la perte de données automatique / nulle. Cela signifie que la quantité de données reçues ne peut pas dépasser le débit d'écriture maximal d'un nœud. De plus, certaines pertes de données temporaires doivent être prises en compte lors de la tolérance aux pannes (dans une architecture sans partage de ressources). Ici, vous devez garder à l'esprit que les validations récentes n'ont pas encore été reflétées dans la copie esclave. Les mises à jour sans interruption sont également difficiles à réaliser dans les bases de données SQL.

Les bases de données NoSQL sont généralement distribuées par nature, c'est-à-dire en eux, les données sont divisées en sections et réparties sur plusieurs nœuds. Ils nécessitent une dénormalisation. Cela signifie que les données saisies doivent également être copiées plusieurs fois afin de répondre aux demandes spécifiques que vous envoyez. L'objectif global est d'obtenir des performances élevées en réduisant le nombre de fragments disponibles lors de la lecture. Il suit la déclaration selon laquelle NoSQL vous oblige à modéliser vos requêtes, tandis que SQL vous oblige à modéliser vos données.

NoSQL se concentre sur la réalisation de hautes performances dans un cluster distribué, et c'est la principale justification de nombreux compromis de conception de base de données qui incluent les ACID de perte de transaction, les JOIN et les index secondaires mondiaux cohérents.

On pense que bien que les bases de données NoSQL offrent une évolutivité d'écriture linéaire et une tolérance élevée aux pannes, la perte de garanties transactionnelles les rend inadaptées aux données critiques.

Le tableau suivant montre en quoi la modélisation des données dans NoSQL diffère de SQL.



SQL et NoSQL: Pourquoi les deux sont-ils nécessaires?

Les applications du monde réel avec un grand nombre d'utilisateurs, comme Amazon.com, Netflix, Uber et Airbnb, exécutent des tâches complexes et variées. Par exemple, une application de commerce électronique comme Amazon.com doit stocker des données légères et hautement critiques, telles que des informations sur les utilisateurs, les produits, les commandes, les factures, ainsi que des données lourdes mais moins sensibles, telles que les avis sur les produits, les messages d'assistance , activité des utilisateurs, avis des utilisateurs et recommandations. Naturellement, ces applications reposent sur au moins une base de données SQL avec au moins une base de données NoSQL. Dans les systèmes interrégionaux et mondiaux, la base de données NoSQL fonctionne comme un cache géo-distribué pour les données stockées dans une source de confiance, une base de données SQL, fonctionnant dans n'importe quelle région.

Comment YugaByte DB combine-t-il SQL et NoSQL?

Construit sur un moteur de stockage mixte orienté journal, un partage automatique, une réplication de consensus distribué et des transactions distribuées ACID (inspiré de Google Spanner), YugaByte DB est la première base de données open source au monde à être simultanément compatible avec NoSQL (Cassandra & Redis ) et SQL (PostgreSQL). Comme indiqué dans le tableau ci-dessous, YSQL, l'API de base de données YugaByte compatible Cassandra, ajoute les concepts de transactions ACID à clé unique et multi-clés et les index secondaires globaux aux API NoSQL, ouvrant ainsi l'ère des bases de données transactionnelles NoSQL. De plus, YSQL, une API de base de données YugaByte conforme à PostgreSQL, ajoute la notion de mise à l'échelle linéaire des enregistrements et de tolérance aux pannes automatique à l'API SQL, introduisant les bases de données SQL distribuées dans le monde. Étant donné que la base de données YugaByte DB est essentiellement transactionnelle, l'API NoSQL peut désormais être utilisée dans le contexte de données critiques.



Comme indiqué précédemment dans l'article «Présentation de YSQL: une API SQL distribuée compatible PostgreSQL pour YugaByte DB» , le choix entre SQL ou NoSQL dans YugaByte DB dépend entièrement des caractéristiques de la charge de travail principale:

• Si la charge de travail principale est des opérations multi-clés avec JOIN, alors lorsque vous choisissez YSQL, sachez que vos clés peuvent être réparties sur plusieurs nœuds, ce qui entraînera un délai plus élevé et / ou un débit inférieur à celui de NoSQL.
• Sinon, sélectionnez l'une des deux API NoSQL, en gardant à l'esprit que vous obtiendrez de meilleures performances à la suite de requêtes servies à partir d'un nœud à la fois. YugaByte DB peut servir de base de données opérationnelle unique pour des applications complexes et réelles dans lesquelles vous devez gérer plusieurs charges de travail en même temps.

Le laboratoire de modélisation des données de la section suivante est basé sur les bases de données YugaByte DB compatibles avec PostgreSQL et l'API Cassandra, contrairement aux bases de données source. Cette approche met l'accent sur la facilité d'interaction avec deux API différentes (sur deux ports différents) du même cluster de base de données, par opposition à l'utilisation de clusters complètement indépendants de deux bases de données différentes.

Dans les sections suivantes, nous rencontrerons le laboratoire de modélisation des données pour illustrer les différences et certaines caractéristiques communes des bases de données en question.

Laboratoire de modélisation des données

Installation de la base de données

Étant donné l'accent mis sur la conception d'un modèle de données (plutôt que sur des architectures de déploiement complexes), nous installerons les bases de données dans des conteneurs Docker sur l'ordinateur local, puis nous interagirons avec eux à l'aide de leurs shells de ligne de commande correspondants.

Compatible avec PostgreSQL et Cassandra, base de données YugaByte DB

mkdir ~/yugabyte && cd ~/yugabyte wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl docker pull yugabytedb/yugabyte ./yb-docker-ctl create --enable_postgres 

Mongodb

 docker run --name my-mongo -d mongo:latest 

Accès en ligne de commande

Connectons-nous aux bases de données à l'aide du shell de ligne de commande pour les API correspondantes.

PostgreSQL

psql est un shell de ligne de commande pour interagir avec PostgreSQL. Pour plus de facilité d'utilisation, YugaByte DB est livré avec psql directement dans le dossier bin.

 docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres 

Cassandra

cqlsh est un shell en ligne de commande pour interagir avec Cassandra et ses bases de données compatibles via CQL (Cassandra query language). Pour faciliter l'utilisation, YugaByte DB est livré avec cqlsh dans le bin .

Notez que CQL a été inspiré par SQL et a des concepts similaires aux tables, lignes, colonnes et index. Cependant, en tant que langage NoSQL, il ajoute un certain ensemble de restrictions, dont la plupart seront également couvertes dans d'autres articles.

 docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh 

Mongodb

mongo est un shell de ligne de commande pour interagir avec MongoDB. Il se trouve dans le répertoire bin de l'installation de MongoDB.

 docker exec -it my-mongo bash cd bin mongo 

Création de table

Nous pouvons maintenant interagir avec la base de données pour effectuer diverses opérations à l'aide de la ligne de commande. Commençons par créer un tableau qui stocke des informations sur les chansons écrites par différents artistes. Ces chansons peuvent faire partie d'un album. Attributs également facultatifs pour la chanson - année de sortie, prix, genre et classement. Nous devons considérer les attributs supplémentaires qui pourraient être nécessaires à l'avenir via le champ "tags". Il peut stocker des données semi-structurées sous forme de paires clé-valeur.

PostgreSQL

 CREATE TABLE Music ( Artist VARCHAR(20) NOT NULL, SongTitle VARCHAR(30) NOT NULL, AlbumTitle VARCHAR(25), Year INT, Price FLOAT, Genre VARCHAR(10), CriticRating FLOAT, Tags TEXT, PRIMARY KEY(Artist, SongTitle) ); 

Cassandra

La création d'une table dans Cassandra est très similaire à PostgreSQL. L'une des principales différences est le manque de contraintes d'intégrité (par exemple, NOT NULL), mais c'est la responsabilité de l'application, pas de la base de données NoSQL . La clé primaire se compose d'une clé de section (colonne Artist dans l'exemple ci-dessous) et d'un ensemble de colonnes de clustering (colonne SongTitle dans l'exemple ci-dessous). La clé de partition détermine la partition / partition dans laquelle placer la ligne et les colonnes de clustering indiquent comment les données doivent être organisées à l'intérieur de la partition actuelle.

 CREATE KEYSPACE myapp; USE myapp; CREATE TABLE Music ( Artist TEXT, SongTitle TEXT, AlbumTitle TEXT, Year INT, Price FLOAT, Genre TEXT, CriticRating FLOAT, Tags TEXT, PRIMARY KEY(Artist, SongTitle) ); 

Mongodb

MongoDB organise les données dans des bases de données (Database) (similaires à Keyspace dans Cassandra), où il existe des collections (Collections) (similaires aux tableaux), qui contiennent des documents (Documents) (similaires aux lignes d'un tableau). MongoDB ne nécessite fondamentalement pas la définition du schéma d'origine. La commande «utiliser la base de données» illustrée ci-dessous crée une instance de la base de données lors du premier appel et modifie le contexte de la base de données nouvellement créée. Même les collections n'ont pas besoin d'être créées explicitement, elles sont créées automatiquement, simplement lorsque vous ajoutez le premier document à une nouvelle collection. Veuillez noter que MongoDB utilise la base de données de test par défaut, par conséquent, toute opération au niveau de la collection sans spécifier de base de données spécifique y sera effectuée par défaut.

 use myNewDatabase; 

Récupération des informations de table PostgreSQL

 \d Music Table "public.music" Column | Type | Collation | Nullable | Default --------------+-----------------------+-----------+----------+-------- artist | character varying(20) | | not null | songtitle | character varying(30) | | not null | albumtitle | character varying(25) | | | year | integer | | | price | double precision | | | genre | character varying(10) | | | criticrating | double precision | | | tags | text | | | Indexes: "music_pkey" PRIMARY KEY, btree (artist, songtitle) 

Cassandra

 DESCRIBE TABLE MUSIC; CREATE TABLE myapp.music ( artist text, songtitle text, albumtitle text, year int, price float, genre text, tags text, PRIMARY KEY (artist, songtitle) ) WITH CLUSTERING ORDER BY (songtitle ASC) AND default_time_to_live = 0 AND transactions = {'enabled': 'false'}; 

Mongodb

 use myNewDatabase; show collections; 

Publier des données dans une table PostgreSQL

 INSERT INTO Music (Artist, SongTitle, AlbumTitle, Year, Price, Genre, CriticRating, Tags) VALUES( 'No One You Know', 'Call Me Today', 'Somewhat Famous', 2015, 2.14, 'Country', 7.8, '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}' ); INSERT INTO Music (Artist, SongTitle, AlbumTitle, Price, Genre, CriticRating) VALUES( 'No One You Know', 'My Dog Spot', 'Hey Now', 1.98, 'Country', 8.4 ); INSERT INTO Music (Artist, SongTitle, AlbumTitle, Price, Genre) VALUES( 'The Acme Band', 'Look Out, World', 'The Buck Starts Here', 0.99, 'Rock' ); INSERT INTO Music (Artist, SongTitle, AlbumTitle, Price, Genre, Tags) VALUES( 'The Acme Band', 'Still In Love', 'The Buck Starts Here', 2.47, 'Rock', '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}' ); 

Cassandra

En général, l'expression INSERT dans Cassandra ressemble beaucoup à celle de PostgreSQL. Cependant, il y a une grande différence dans la sémantique. Dans Cassandra, INSERT fait une opération UPSERT où les dernières valeurs sont ajoutées à la chaîne au cas où la chaîne existe déjà.

La saisie des données est similaire à PostgreSQL INSERT ci-dessus

Mongodb

Bien que MongoDB soit une base de données NoSQL, comme Cassandra, son opération d'insertion n'a rien à voir avec le comportement sémantique dans Cassandra. Dans MongoDB, insert () n'a pas de capacités UPSERT , ce qui le fait ressembler à PostgreSQL. L'ajout de données par défaut sans _idspecified ajoutera un nouveau document à la collection.

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

Requête de table

La différence la plus importante entre SQL et NoSQL en termes de conception de requêtes est peut-être l'utilisation des instructions FROM et WHERE . SQL vous permet de sélectionner plusieurs tables après une FROM , et une WHERE peut être de toute complexité (y compris les opérations JOIN entre les tables). Cependant, NoSQL a tendance à imposer une restriction stricte sur FROM , et ne fonctionne qu'avec une seule table spécifiée, et dans WHERE , la clé primaire doit toujours être spécifiée. Cela est dû à la volonté d'améliorer les performances de NoSQL, dont nous avons parlé plus tôt. Ce désir conduit à toutes les réductions possibles de toute interaction croisée et croisée. Cela peut entraîner un retard important dans la communication inter-nodale lors de la réponse à une demande et, par conséquent, il est préférable de l'éviter en principe. Par exemple, Cassandra requiert que les requêtes soient limitées à certains opérateurs (seuls =, IN, <, >, =>, <= sont autorisés) sur les clés de partition, sauf lors de la demande d'un index secondaire (seul l'opérateur = est autorisé ici).

PostgreSQL

Trois exemples de requêtes qui peuvent être facilement exécutées par une base de données SQL seront donnés ci-dessous.

• Imprimez toutes les chansons de l'artiste;
• Imprimez toutes les chansons de l'artiste qui correspondent à la première partie du nom;
• Liste toutes les chansons de l'artiste qui ont un mot spécifique dans le titre et ont un prix inférieur à 1,00.

 SELECT * FROM Music WHERE Artist='No One You Know'; SELECT * FROM Music WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%'; SELECT * FROM Music WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%' AND Price > 1.00; 

Cassandra

Parmi les requêtes PostgreSQL ci-dessus, seule la première fonctionnera inchangée dans Cassandra, car l'instruction LIKE ne peut pas être appliquée aux colonnes de clustering telles que SongTitle . Dans ce cas, seuls les opérateurs = et IN sont autorisés.

 SELECT * FROM Music WHERE Artist='No One You Know'; SELECT * FROM Music WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot') AND Price > 1.00; 

Mongodb

Comme indiqué dans les exemples précédents, la principale méthode de création de requêtes dans MongoDB est db.collection.find () . Cette méthode contient explicitement le nom de la collection ( music dans l'exemple ci-dessous), donc la demande de plusieurs collections est interdite.

 db.music.find( { artist: "No One You Know" } ); db.music.find( { artist: "No One You Know", songTitle: /Call/ } ); 

Lire toutes les lignes du tableau

La lecture de toutes les lignes n'est qu'un cas particulier du modèle de requête que nous avons examiné précédemment.

PostgreSQL

 SELECT * FROM Music; 

Cassandra

Similaire à l'exemple de PostgreSQL ci-dessus.

Mongodb

 db.music.find( {} ); 

Modification des données dans une table

PostgreSQL

PostgreSQL fournit une UPDATE pour modifier les données. Il n'a pas de capacités UPSERT , donc l'exécution de cette instruction échouera si la ligne n'est plus dans la base de données.

 UPDATE Music SET Genre = 'Disco' WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love'; 

Cassandra

Cassandra a une UPDATE similaire à PostgreSQL. UPDATE a la même sémantique UPSERT INSERT .

Similaire à l'exemple de PostgreSQL ci-dessus.

Mongodb
L'opération update () dans MongoDB peut mettre à jour complètement un document existant ou mettre à jour uniquement certains champs. Par défaut, il met à jour un seul document avec la sémantique UPSERT . La mise à jour de plusieurs documents et comportements similaires à UPSERT peut être appliquée en définissant des indicateurs supplémentaires pour l'opération. Par exemple, dans l'exemple ci-dessous, le genre d'un artiste particulier est mis à jour par sa chanson.

 db.music.update( {"artist": "The Acme Band"}, { $set: { "genre": "Disco" } }, {"multi": true, "upsert": true} ); 

Suppression de données d'une table

PostgreSQL

 DELETE FROM Music WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World'; 

Cassandra

Similaire à l'exemple de PostgreSQL ci-dessus.

Mongodb

MongoDB a deux types d'opérations pour supprimer des documents - deleteOne () / deleteMany () et remove () . Les deux types suppriment des documents, mais renvoient des résultats différents.

 db.music.deleteMany( { artist: "The Acme Band" } ); 

Supprimer le tableau

PostgreSQL

 DROP TABLE Music; 

Cassandra

Similaire à l'exemple de PostgreSQL ci-dessus.

Mongodb

 db.music.drop(); 

Conclusion

Le débat sur le choix entre SQL et NoSQL fait rage depuis plus de 10 ans. Il y a deux aspects principaux de ce débat: l'architecture du moteur de base de données (monolithique, SQL transactionnel versus distribué, NoSQL non transactionnel) et l'approche de la conception de la base de données (modélisation des données en SQL versus modélisation de vos requêtes en NoSQL).

Avec une base de données transactionnelle distribuée telle que YugaByte DB, le débat sur l'architecture de la base de données peut être facilement dissipé. Comme les volumes de données deviennent plus importants que ce qui peut être écrit sur un seul nœud, une architecture entièrement distribuée qui prend en charge l'évolutivité linéaire des enregistrements avec un partage / rééquilibrage automatique devient nécessaire.

En plus d'être mentionnées dans un article de Google Cloud , les architectures transactionnelles strictement cohérentes sont désormais plus largement utilisées pour offrir une meilleure flexibilité de développement que les architectures non transactionnelles et finalement cohérentes.

Pour en revenir à la discussion sur la conception de bases de données, il est juste de dire que les deux approches de conception (SQL et NoSQL) sont nécessaires pour toute application réelle complexe. L'approche SQL «modélisation des données» permet aux développeurs de répondre plus facilement aux besoins changeants de l'entreprise, tandis que l'approche NoSQL «modélisation des données» permet aux mêmes développeurs de gérer de grandes quantités de données avec une faible latence et un débit élevé. C'est pour cette raison que YugaByte DB fournit des API SQL et NoSQL dans un noyau commun, plutôt que de promouvoir l'une des approches. De plus, en assurant la compatibilité avec les langages de base de données populaires, y compris PostgreSQL et Cassandra, YugaByte DB garantit que les développeurs n'ont pas à apprendre une autre langue pour travailler avec un moteur de base de données distribué et strictement cohérent.

Dans cet article, nous avons compris en quoi les principes fondamentaux de la conception de bases de données diffèrent dans PostgreSQL, Cassandra et MongoDB. Dans les articles suivants, nous allons plonger dans des concepts de conception avancés tels que les index, les transactions, les JOIN, les directives TTL et les documents JSON.

Nous vous souhaitons un merveilleux séjour le reste du week-end et vous invitons à un webinaire gratuit , qui se tiendra le 14 mai.