Etude de cas: Cassandra¶
S1: Cassandra, une base relationnelle étendue¶
Supports complémentaires
Cassandra est un système de gestion de données à grande échelle conçu à l’origine (2007) par les ingénieurs de Facebook pour répondre à des problématiques liées au stockage et à l’utilisation de gros volumes de données. En 2008, ils essayèrent de le démocratiser en founissant une version stable, documentée, disponible sur Google Code. Cependant, Cassandra ne reçut pas un accueil particulièrement enthousiaste. Les ingénieurs de Facebook décidèrent donc en 2009 de faire porter Cassandra par l’Apache Incubator. En 2010, Cassandra était promu au rang de top-level Apache Project.
Apache a joué un rôle de premier plan dans l’attraction qu’a su créer Cassandra. La communauté s’est tellement investie dans le projet Cassandra que, au final, ce dernier a complètement divergé de sa version originale. Facebook s’est alors résolu à accepter que le projet - en l’état - ne correspondait plus précisément à leurs besoins, et que reprendre le développement à leur compte ne rimerait à rien tant l’architecture avait évolué. Cassandra est donc resté porté par l’Apache Incubator.
Aujourd’hui, c’est la société Datastax qui assure la distribution et le support de Cassandra qui reste un projet Open Source de la fondation Apache.
Cassandra a beaucoup évolué depuis l’origine, ce qui explique une terminologie assez erratique qui peut prêter à confusion. L’inspiration initiale est le système BigTable de Google, et l’évolution a ensuite plutôt porté Cassandra vers un modèle proche du relationnel, avec quelques différences significatives, notamment sur les aspects internes. C’est un système NoSQL très utilisé, et sans doute un bon point de départ pour passer du relationnel à un système distribué.
Installation¶
Avec Docker, il vous sera possible d’utiliser Cassandra dans un environnement virtuel. C’est de loin le mode d’installation le plus simple, il est rapide et ne pollue pas la machine avec des services qui tournent en tâche de fond et dont on ne se sert pas.
Le serveur¶
Reportez-vous au chapitre Préliminaires: Docker pour l’introduction à Docker. Vous pouvez utiliser le desktop, ou la ligne de commande. C’est cette dernière que je vous montre pour plus de clarté et de simplicité. Entrez:
docker run --name mon-cassandra -p 3000:9042 -d cassandra:latest
On communique avec Cassandra via un langage, CQL, dont les
commandes doivent être transmises au port 9042 du conteneur. Dans l’instruction
ci-dessus, ce port est renvoyé sur le
port 3000 du système hôte avec l’option -p.
Normalement, tout cela est clair, sinon relisez encore
et encore le chapitre sur Docker.
L’image Docker de cassandra est alors téléchargée et instanciée. Vérifiez-le en listant vos conteneurs:
$ docker ps
Vous pouvez obtenir l’adresse IP (champ IPAddress) de la machine Docker.
$ docker inspect <id-conteneur>
Il est donc possible de se connecter à Casandra soit sur le port
3000 de la machine hôte (donc, localhost si vous travaillez
sur votre ordinateur personnel),
soit sur le port 9042 du conteneur.
Nous sommes prêts à nous connecter au serveur Cassandra et à interagir avec la base de données.
Le client¶
Il vous faut un client sur la machine hôte. L’application cliente de base est l’interpréteur de commandes
cqlsh, ce qui nécessite une installation des binaires Cassandra.
Des clients graphiques existent. Datastax propose des outils, dont le Datastax Studio qui est assez agréable à utiliser mais l’installation est un peu lourde. Un « petit » utilitare graphique assez complet DbVisualizer, disponible en version gratuite à l’adresse https://www.dbvis.com/. Il permet classiquement de créer des connexions, d’inspecter un schéma et de transmettre des requêtes.
DbVisualizer peut être utilisé avec beaucoup de bases de données (dont MongoDB
et ElasticSearch que nous découvrirons plus loin). Selon le système choisi,
il faut télécharger des connecteurs spécifiques (drivers). Cela se fait
de manière assez intuitive via DbVis lui-même. Dans le cas de Cassandra,
il faut prendre le driver Cassandra DataStax.
Fig. 24 Le client DevCenter fourni par la société Datastax.¶
La Fig. 10 montre l’interface, après création d’un keyspace, de tables et de données. Commençons par expliquer tout cela.
Le modèle de données¶
Cassandra est un système qui s’est progressivement orienté vers un modèle relationnel étendu, avec typage fort et schéma contraint. Initialement, Cassandra était beaucoup plus permissif et permettait d’insérer à peu près n’importe quoi.
Note
Méfiez-vous des « informations » qui trainent encore sur le Web, où Cassandra est par exemple qualifié de « column-store, avec une confusion assez générale due en partie aux évolutions du système, et en partie au fait que certains se contentent de répéter ce qu’ils ont lu quelque part sans se donner la peine de vérifier ou même de comprendre.
Comme dans un système relationnel, une base de données Cassandra est constituée de tables. Chaque table a un nom et est constituée de colonnes. Toute ligne (row) de la table doit respecter le schéma de cette dernière. Si une table a 5 colonnes, alors à l’insertion d’une entrée, la donnée devra être composée de 5 valeurs respectant le typage. Une colonne peut avoir différents types,
des types atomiques, comme par exemple entier, texte, date;
des types complexes (ensembles, listes, dictionnaires);
des types construits et nommés.
Cela vous rappelle quelque chose? Nous sommes effectivement proche d’un modèle de documents structurés de type JSON, avec imbrication de structures, mais avec un schéma qui assure le contrôle des données insérées. La gestion de la base est donc très contrainte et doit se faire en cohérence avec la structure de chaque table (son schéma). C’est une différence notable avec de nombreux systèmes NoSQL.
Important
Le vocabulaire encore utilisé par Cassandra est hérité d’un historique complexe et s’avère source de confusion. Ce manque d’uniformité et de cohérence dans la terminologie est malheureusement une conséquence de l’absence de normalisation des systèmes dits « No-SQL ». Dans tout ce qui suit, nous essayons de rester en phase avec les concepts (et leur nommage) présentés dans ce cours, d’établir le lien avec le vocabulaire Cassandra et si possible d’expliquer les raisons des écarts terminologiques. En particulier, nous allons utiliser document comme synonyme de row Cassandra, pour des raisons d’homogénéïté avec le reste de ce cours.
Paires clé/valeur (columns) et documents (rows)¶
La structure de base d’un document dans Cassandra est la paire (clé, valeur), autrement dit la structure atomique de représentation des informations semi-structurées, à la base de XML ou JSON par exemple. Une valeur peut être atomique (entier, chaîne de caractères) ou complexe (dictionnaire, liste).
Vocabulaire
Dans Cassandra, cette structure est parfois appelée colonne, ce qui est difficilement explicable au premier abord (vous êtes d’accord qu’une paire-clé/valeur n’est pas une colonne?). Il s’agit en fait d’un héritage de l’inspiration initiale de Cassandra, le système BigTable de Google dans lequel les données sont stockées en colonnes. Même si l’organisation finale de Cassandra a évolué, le vocabulaire est resté. Bilan: chaque fois que vous lisez « colonne » dans le contexte Cassandra, comprenez « paire clé-valeur » et tout s’éclaircira.
Versions
Il existe une deuxième subtilité que nous allons laisser de côté pour l’instant: les valeurs dans une paire clé-valeur Cassandra sont associées à des versions. Au moment où l’on affecte une valeur à une clé, cette valeur est étiquetée par l’estampille temporelle courante, et il est possible de conserver, pour une même clé, la série temporelle des valeurs successives. Cassandra, à strictement parler, gère donc des triplets (clé, estampille, valeur). C’est un héritage de BigTable, que l’on retrouve encore dans HBase par exemple.
L’estampille a une utilité dans le fonctionnement interne de Cassandra, notamment lors des phases de réconciliation lorsque des fichiers ne sont plus synchronisés suite à la panne d’un nœud. Nous y reviendrons.
Un document dans Cassandra est un identifiant unique associé à un ensemble de paires (clé, valeur). Il s’agit ni plus ni moins de la notion traditionnelle de dictionnaire que nous avons rencontrée dès le premier chapitre de ce cours et qu’il serait très facile de représenter en JSON par exemple.
Vocabulaire
Cassandra appelle row les documents, et row key l’identifiant unique. La notion de ligne (row) vient également de BigTable. Conceptuellement, il n’y a pas de différence avec les documents structurés que nous étudions depuis le début de ce cours.
Dans les versions initiales de Cassandra, le nombre de paires clé-valeur constituant un document (ligne) n’était pas limité. On pouvait donc imaginer avoir des documents contenant des milliers de paires, tous différents les uns des autres. Ce n’est plus possible dans les versions récentes, chaque document devant être conforme au schéma de la table dans laquelle il est inséré. Les concepteurs de Cassandra ont sans doute considéré qu’il était malsain de produire des fourre-tout de données, difficilement gérables. La Fig. 25 montre un document Cassandra sous la forme de ses paires clés-valeurs
Fig. 25 Structure d’un document dans Cassandra¶
Les tables (column families)¶
Les documents sont groupés dans des tables qui, sous Cassandra, sont parfois appelées des column families pour des raisons historiques.
Vocabulaire
La notion de column family vient là encore de Bigtable, où elle avait un sens précis qui a disparu ici (pourquoi appeler une collection une « famille de colonnes? »). Transposez column family en collection et vous serez en territoire connu. Pour retrouver un modèle encore très proche de celui de BigTable, vous pouvez regarder le système HBase où les termes column family et column ont encore un sens fort.
Note
Il existe aussi des super columns, ainsi que des super column families. Ces structures apportent un réel niveau de complexité dans le modèle de données, et il n’est pas vraiment nécessaire d’en parler ici. Il se peut d’ailleurs ques ces notions peu utiles disparaissent à l’avenir.
La Fig. 26 illustre une table et 3 documents avec leur identifiant.
Fig. 26 Une table (column family) contenant 3 documents (rows) dans Cassandra¶
Bases (Keyspaces)¶
Enfin le troisième niveau d’organisation dans Cassandra est le keyspace, qui contient un ensemble de tables (column families). C’est l’équivalent de la notion de base de données, ensemble de tables dans le modèle relationnel, ou ensemble de collections dans des systèmes comme MongoDB.
Conception d’un schéma¶
Le modèle de données sur Cassandra est très influencé à l’origine par le système BigTable dont le plus proche héritier à ce jour est HBase. Cassandra en hérite principalement une terminologie assez dérourante et peu représentative d’une organisation assez classique structurée selon les niveaux base, table et document. Une fois dépassée ce petit obstacle, on constate une adoption des principes fondamentaux des systèmes documentaires distribués: des documents à la structure flexible construits sur la cellule (clé, valeur), entités d’information autonomes conçus pour le partitionnement dans un système distribué.
De nombreux conseils sont disponibles pour la conception d’un schéma Cassandra. Cette conception est nécessairement différente de celle d’un schéma relationnel à cause de l’absence du système de clé étrangère et de l’opération de jointure. C’est la raison pour laquelle de nombreux design patterns sont proposés pour guider la mise en place d’une architecture de données dans Cassandra qui soit cohérente avec les besoins métiers, et la performance que peut offrir la base de données.
Cassandra oblige à réfléchir en priorité à la façon dont le modèle de données va être utilisé. Quelles requêtes vont être exécutées? Dans quel sens mes données seront-elles traitées? C’est à partir de ces questions que pourra s’élaborer un modèle optimisé, dénormalisé et donc performant. L’inconvénient d’une démarche basée sur les besoins est que si ces derniers évoluent (ou si une application différente veut accéder à une base existante), l’organisation de la base devient inadaptée. Avec un système relationnel comme MySQL, le raisonnement est opposé: la disponibilité des jointures permet de se fixer comme but la normalisation du modèle de données afin de répondre à tous les cas d’usage possibles, éventuellement de manière non optimale.
En résumé:
Cassandra permet de stocker des tables dénormalisées dans lesquelles les valeurs ne sont pas nécessairement atomiques; il s’appuie sur une plus grande diversité de types (pas uniquement des entiers et des chaînes de caractères, mais des types construits comme les listes ou les dictionnaires).
La modélisation d’une architecture de données dans Cassandra est beaucoup plus ouverte qu’en relationnel ce qui rend notamment la modélisation plus difficile à évaluer, surtout à long terme.
La dénormalisation (souvent considérée comme la bête noire à pourchasser dans un modèle relationnel) devient recommandée avec Cassandra, en restant conscient que ses inconvénients (notamment la duplication de l’information, et les incohérences possibles) doivent être envisagés sérieusement.
En contrepartie des difficultés accrues de la modélisation, et surtout de l’impossibilté de garantir formellement la qualité d’un schéma grâce à des méthodes adaptées, Cassandra assure un passage à l’échelle par distribution basé sur des techniques de partitionnement et de réplication que nous détaillerons ultérieurement. C’est un système qui offre des performances jugées très satisfaisantes dans un environnement Big Data.
Créons notre base¶
À vous de vous retrousser les manches pour créer votre base Cassandra et y insérer nos films (ou toute autre jeu de données de votre choix). Les commandes de base sont données ci-dessous; elles peuvent toutes être entrées directement dans client graphique comme DbVisualizer.
Le keyspace¶
Rappelons que keyspace est le nom que Cassandra donne à une base de données. Cassandra est fait pour fonctionner dans un environnement distribué. Pour créer un keyspace, il faut donc préciser la stratégie de réplication à adopter. Nous verrons plus en détail après comment tout ceci fonctionne. Voici la commande:
CREATE KEYSPACE IF NOT EXISTS Movies
WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor': 3 };
Sous DbVisualizer, les keyspaces apparaissent à gauche de la fenêtre principale (voir figure Fig. 10). Un clic bouton droit permet d’ouvrir un formulaire de création d’un keyspace.
Une fois le keyspace créé, essayez les commandes suivantes
(sous cqlsh uniquement).
cqlsh > DESCRIBE keyspaces;
cqlsh > DESCRIBE KEYSPACE Movies;
Avec un client graphique, il est facile d’explorer un keyspace.
Données relationnelles (à plat)¶
On peut traiter Cassandra comme une base relationnelle (en se plaçant du point de vue de la modélisation en tout cas). On crée alors des tables destinées à contenir des données « à plat », avec des types atomiques. Commençons par créer une table pour nos artistes.
create table artists (id text,
last_name text, first_name text,
birth_date int, primary key (id)
);
Je vous renvoie à la documentation Cassandra pour la liste des types atomiques disponibles. Ce sont, à peu de chose près, ceux de SQL.
L’insertion de données suit elle aussi la syntaxe SQL. Insérons quelques artistes.
insert into artists (id, last_name, first_name, birth_date)
values ('artist1', 'Depardieu', 'Gérard', 1948);
insert into artists (id, last_name, first_name, birth_date)
values ('artist2', 'Baye', 'Nathalie', 1948);
insert into artists (id, last_name, first_name)
values ('artist3', 'Marceau', 'Sophie');
On peut vérifier que l’insertion a bien fonctionné en sélectionnant les données.
select * from artists;
id | last_name | first_name | birth_date
------------+-------------+-----------------------------
'artist1' | Depardieu | Gérard | 1948
'artist2' | Baye | Nathalie | 1948
'artist3' | Marceau | Sophie | null
Sous DbVusualizer, lancer un « SQL commander » et entrer la requête. On se retrouve avec l’affichage de la figure Fig. 10
À la dernière insertion, nous avons délibérément omis de renseigner la colonne birth_date, et
Cassandra accepte la commande sans retourner d’erreur. Cette flexibilité est l’un des aspects
communs à tous les modèles s’appuyant sur une représentation semi-structurée.
Il est également possible d’insérer à partir d’un document JSON en ajoutant le mot-clé JSON.
insert into artists JSON '{
"id": "a1",
"last_name": "Coppola",
"first_name": "Sofia",
"birth_date": "1971"
}';
La structure du document doit correspondre très précisément (types compris) au schéma de la table, sinon Cassandra rejette l’insertion.
Note
Vous pouvez récupérer sur le site http://deptfod.cnam.fr/bd/tp/datasets/ des commandes d’insertion Cassandra pour notre base de films.
Documents structurés (avec imbrication)¶
Cassandra va au-delà de la norme relationnelle en permettant des données dénormalisées dans lesquelles certaines valeurs sont complexes (dictionnaires, ensembles, etc.). C’est le principe de base que nous avons étudié pour la modélisation de document: en permettant l’imbrication on s’autorise la création de structures beaucoup plus riches, et potentiellement suffisantes pour représenter intégralement les informations relatives à une entité.
Note
Le concept de relationnel « étendu » à des types complexes est très ancien, et existe déjà dans des systèmes comme Postgres depuis longtemps.
Prenons le cas des films. En relationnel, on aurait la commande suivante:
create table movies (id text,
title text,
year int,
genre text,
country text,
primary key (id) );
Tous les champs sont de type atomique. Pour représenter le metteur en scène, objet complexe avec un nom, un prénom, etc., il faudrait associer (en relationnel) chaque ligne de la table movies à une ligne d’une autre table représentant les artistes.
Cassandra permet l’imbrication de la représentation d’un artiste dans la représentation d’un film;
une seule table suffit donc.
Il nous faut au préalable définir le type artist de la manière suivante:
create type artist (id text,
last_name text,
first_name text,
birth_date int,
role text);
Et on peut alors créer la table movies en spécifiant que l’un des champs a pour type
artist.
create table movies (id text,
title text,
year int,
genre text,
country text,
director frozen<artist>,
primary key (id) );
Notez le champ director, avec pour type frozen<artist> indiquant l’utilisation d’un
type défini dans le schéma.
Note
L’utilisation de frozen semble obligatoire pour les types imbriqués. Les raisons
sont peu claires pour moi. Il semble que frozen implique que toute modification de la
valeur imbriquée doive se faire par remplacement complet, par opposition à une modification
à une granularité plus fine affectant l’un des champs. Vous êtes invités à creuser
la question si vous utilisez Cassandra.
Il devient alors possible d’insérer des documents structurés, comme celui de l’exemple ci-dessous. Ce qui montre l’équivalence entre le modèle Cassandra et les modèles des documents structurés que nous avons étudiés. Il est important de noter que les concepteurs de Cassandra ont décidé de se tourner vers un typage fort: tout document non conforme au schéma précédent est rejeté, ce qui garantit que la base de données est saine et respecte les contraintes.
INSERT INTO movies JSON '{
"id": "movie:1",
"title": "Vertigo",
"year": 1958,
"genre": "drama",
"country": "USA",
"director": {
"id": "artist:3",
"last_name": "Hitchcock",
"first_name": "Alfred",
"birth_date": "1899"
}
}';
Sur le même principe, on peut ajouter un niveau d’imbrication pour représenter
l’ensemble des acteurs d’un film. Le constructeur set<...> déclare un type ensemble.
Voici un exemple parlant:
create table movies (id text,
title text,
year int,
genre text,
country text,
director frozen<artist>,
actors set< frozen<artist>>,
primary key (id) );
Les acteurs sont donc une liste d’instances du type artist, ce qui correspond
en JSON à la structure suivante:
insert into movies JSON '{
"id": "movie:11",
"title": "Star Wars",
"year": 1977,
"genre": "Adventure",
"country": "US",
"director": {
"id": "artist:1",
"last_name": "Lucas",
"first_name": "George",
"birth_date": 1944
},
"actors": [
{
"last_name": "Hamill",
"first_name": "Mark",
"birth_date": 1951
},
{
"last_name": "Ford",
"first_name": "Harrison",
"birth_date": 1942
},
{
"last_name": "Fisher",
"first_name": "Carrie",
"birth_date": 1956
}
]
}')
Je vous laisse effectuer l’insertion de l’ensemble des films tels qu’ils sont fournis par le site http://deptfod.cnam.fr/bd/tp/datasets/cassandra, avec tous les acteurs d’un film. Il suffit de récupérer le fichier contenant l’ensemble des commandes d’insertion et de l’exécuter comme un script. Nous nous en servirons pour l’interrogation CQL ensuite.
En résumé:
Cassandra propose un modèle relationnel étendu, basé sur la capacité à imbriquer des types complexes dans la définition d’un schéma, et à sortir en conséquence de la première règle de normalisation (ce type de modèle est d’ailleurs appelé depuis longtemps N1NF pour Non First Normal Form);
Cassandra a choisi d’imposer un typage fort: toute insertion doit être conforme au schéma;
L’imbrication des constructeurs de type, notamment les dictionnaires (nuplets) et les ensembles (set) rend le modèle comparable aux documents structurés JSON ou XML.
La suite du cours complètera progressivement la présentation de Cassandra.
Mise en pratique¶
MEP MEP-S3-1: mise en route de Cassandra
Votre tâche est simple: installer Cassandra, un client de votre choix
(DbVisualizer recommandé),
reproduire les commandes ci-dessus et créer une base movies avec nos films
récupérés sur http://deptfod.cnam.fr/bd/tp/datasets/.
Profitez-en pour vous familiariser avec l’interface graphique.
Exercices¶
Exercice Ex-S2-1: document = graphe
Représenter sous forme de graphe le film complet « Pulp Fiction » donné précédemment.
Exercice Ex-S2-2: Privilégions les artistes
Reprendre la petite base des films (les 3 tables données ci-dessus) et donner un document structuré donnant toutes les informations disponibles sur Quentin Tarantino. On veut donc représenter un document centré sur les artistes et pas sur les films.
Exercice Ex-S2-3: Comprendre la notion de document structuré
Vous gérez un site de commerce électronique et vous attendez des dizaines de millions d’utilisateurs (ou plus). Vous vous demandez quelle base de données utiliser: relationnel ou NoSQL?
Les deux tables suivantes représentent la modélisation relationnelle pour les utilisateurs et les visites de pages (que vous enregistrez bien sûr pour analyser le comportement de vos utilisateurs).
id |
nom |
|
|---|---|---|
1 |
Serge |
|
2 |
Benoît |
idUtil |
page |
nbVisites |
|---|---|---|
1 |
2 |
|
2 |
1 |
|
1 |
1 |
Proposez une représentation de ces informations sous forme de document structuré
en privilégiant l’accès par les utilisateurs;
en privilégiant l’accès par les pages visitées.
Exercice Ex-S2-4: extrait de l’examen du 16 juin 2016
Le service informatique du Cnam a décidé de représenter ses données sous forme de documents structurés pour faciliter les processus analytiques. Voici un exemple de documents centrés sur les étudiants et incluant les Unités d’Enseignement (UE) suivies par chacuns.
{ "_id": 978, "nom": "Jean Dujardin", "UE": [{"id": "ue:11", "titre": "Java", "note": 12}, {"id": "ue:27", "titre": "Bases de données", "note": 17}, {"id": "ue:37", "titre": "Réseaux", "note": 14} ] } { "_id": 476, "nom": "Vanessa Paradis", "UE": [{"id": "ue:13", "titre": "Méthodologie", "note": 17, {"id": "ue:27", "titre": "Bases de données", "note": 10}, {"id": "ue:76", "titre": "Conduite projet", "note": 11} ] }
Sachant que ces documents sont produits à partir d’une base relationnelle, reconstituez le schéma de cette base et indiquez le contenu des tables correspondant aux documents ci-dessus.
Proposez une autre représentation des mêmes données, centrée cette fois, non plus sur les étudiants, mais sur les UEs.
Avec les documents semi-structurés, on choisit de privilégier certaines entités, celles qui sont proches de la racine de l’arbre. En centrant sur les UEs, on obtient le même contenu, mais avec une représentation très différente.
Exercice Ex-S5-5: passer du relationnel aux documents complexes
Vous trouverez la description d’une base relationnelle dans le chapitre de mon cours sur SQL http://sql.bdpedia.fr/relationnel.html#la-base-des-voyageurs. Elle décrit des voyageurs séjournant dans des logements. Notre but est de transformer cette base en une collection de documents JSON.
Proposez un document JSON représentant toutes les informations disponibles sur un des logements, par exemple U Pinzutu. On devrait donc y trouver les activités proposées.
Proposez un document JSON représentant toutes les informations disponibles sur un voyageur, par exemple Phileas Fogg.
Proposez un schéma JSON pour des documents représentant les logements et leurs activités mais pas les séjours.
Vérifiez la validité syntaxique et insérez les documents dans MongoDb en effectuant une validation avec le schéma.
Pour aller plus loin (optionnel)¶
Exercice Ex-S5-1: des schémas pour valider les documents JSON
Il est facile de transformer MongoDB en une poubelle de données en insérant n’importe quel document. Depuis la version 3.2, MongoDB offre la possibilité d’associer un schéma à une collection et de contrôler que les documents insérés sont conformes au schéma.
La documentation est ici: https://docs.mongodb.com/manual/core/schema-validation
À vous de jouer: définissez le schéma de la collection des films, et appliquez la validation au moment de l’insertion. Vous pouvez commencer avec une collection simple, celle des artistes, pour vous familiariser avec cette notion de schéma.
Exercice Ex-S3-2: modélisation d’une base Cassandra
Maintenant, vous allez modéliser une base Cassandra pour stocker les informations sur le métro parisien. Voici deux fichiers JSON:
http://b3d.bdpedia.fr/files/metro-lines.json, les lignes de métro
http://b3d.bdpedia.fr/files/metro-stops.json, tous les arrêts de métro
Proposez un modèle Cassandra, créez la ou les table(s) nécessaires, essayez d’insérer quelques données, voire toutes les données (ce qui suppose d’écrire un petit programme pour les mettre au bon format).
Ce cours de Philippe Rigaux est mis à disposition selon les termes de la licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.
Table Of Contents
- Introduction
- Préliminaires: Docker
- Modélisation de bases NoSQL
- Recherche exacte
- Etude de cas: Cassandra
- Cassandra - Travaux Pratiques
- Recherche approchée
- Travaux pratiques ElasticSearch
- Traitements par lot
- Le cloud, une nouvelle machine de calcul
- Systèmes NoSQL: la réplication
- Systèmes NoSQL: le partitionnement
- Calcul distribué: de Hadoop à Spark
- Pig : Travaux pratiques
- Annales des examens
Recherche
Saisissez un ou plusieurs mots-clés.