Le 15 Janvier 2013 se tenait le Lyon JUG, à l’Epitech. Le lien vers l’événement
Le thème de la session était NoSQL pour les nuls.
M’intéressant à ces technologies, l’occasion était trop belle pour la rater. J’ai donc assisté à cette session, à laquelle Alexis Hassler et Agnes Crepet nous ont fait un accueil très sympathique.
Je vous fais ici un bref retour
de ce qui s’est dit. Les solutions présentées possèdent un grand panel
de fonctionnalités (ne pas s’attendre à toutes les retrouver ici ).
Il a été rappelé les événements à suivre (Lyon JUG le 19/02/2013, le Devoxx à Paris fin Mars et le Mix-it à Lyon fin Avril).
Quant à la présentation, elle a été faite par Rémy Girodon. Rémy est spécialisé dans le développement Java EE chez SQLi, et intervient également en tant que formateur en entreprise ou en écoles d’ingénieurs.
C’est ensuite Sylvain Roussy, ingénieur Java EE chez Hinnoya, qui a pris le micro pour nous parler de la 4ème et dernière partie de la présentation.
Mise en bouche
Le terme NoSQL est générique. « Not Only SQL » (Pas seulement SQL) est employé pour un grand nombre de SGBD, sans qu’il n’y aie trop de rapport entre ceux-ci.
« NoSQL is an umbrella term ». Ils s’agit de SGBD, sans le « R » de Relationnelles.
Les SGBDR sont pensés pour enregistrer des données normalisées (respect des champs, des relations entre les tables).
Les SGBD NoSQL, eux, ont été pensés pour gérer un grand volume de données.
Ils sont également conçus pour contenir des données hétérogènes (qui ne sont pas excessivement liées, inter-dépendantes) et évolutives (dont la structure peut grandement varier).
Ils sont nativement horizontalement scalables : clustering, load balancing.
Ils répondent notamment aux besoins de site à gros trafics, ou à « orientation sociale » : Google, Facebook, Twitter, LinkedIn, etc.
Malgré leurs caractéristiques communes, les SGBD NoSQL se distinguent sur la façon de stocker les données et la façon de les requêter (Data Model + requests).
Chaque système dispose de sa propre façon de requêter .
Il y a quatre grandes familles de bases NoSQL. Le choix se fait en fonction de ce que l’on veut y stocker : bases clefs-valeurs, bases orientées colonnes, bases orientées document, bases orientées graphe.
Les catégories et les solutions associées sont brièvement présentées ici. Ces solutions sont ACID.
1 – Key value stores
Enregistrement de combinaisons clé -> valeur. K1 -> V1. Pour une clé K1, une valeur V1.
Dans cette catégorie se trouve Redis, by VMWare Utilisée comme cache, cette solution propose des temps de réponse en lecture et écriture très bons. Ce qui nous donne schématiquement :
Application <-> Cache <-> Source de données
Avec mise à jour régulière du Cache.
La clé est une String, la valeur peut prendre la forme d’une String, d’une Liste de String, d’un Set de String, d’un Set trié de String, de Hashmap dans laquelle les clés et les valeurs sont des String.
On peut voir ce SGBD comme une grosse Hashmap mono-threadée, toutes les opérations CRUD sont atomiques et l’intégrité est garantie.
Personnellement, je vous conseille de venir voir par ici.
En bref, ici, pas de requête classique avec WHERE. Pour accéder aux données, il suffit d’avoir les bonnes clés.
2 – Column stores
Une clé correspond à N colonnes. Pour cette une même ligne, le nombre N de colonnes peut varier au fil du temps.
Et entre une ligne et une autre, les colonnes peuvent être différentes en nombre et en nom.
Schématiquement :
K -> C1 -> V1
|-> C2 -> V2
C’est le cas de Cassandra, par Apache.
Chaque colonne peut représenter une valeur et peut être porteuse d’information par son nom.
Ce que l’on pourrait voir comme : K -> Valeur1 -> Valeur2
Cassandra est conçu pour stocker comme colonne une valeur, mais également un time-serie. De façon native. Parfait pour un serveur de log.
Par exemple, pour répertorier les connexions à un serveur : clientLambda (login) -> 2013-01-15 19:00:00 (Date de connexion) -> 5.123.123.123 (IP)
Les colonnes sont triées. De ce fait, Cassandra permet par exemple d’effectuer une requête « donne moi tous les clients qui se sont connectés entre 19h et 21h le 15 Janvier »(pendant le Lyon JUG).
Cassandra propose le langage CQL qui apporte une couche de requêtages : possibilité d’écrire des requêtes SQL like. Rémy nous précise que pour pouvoir exécuter un « SELECT id WHERE colonne = ‘x’; », un index doit être positionné sur « colonne ».
Le clustering est également natif avec cette solution.
Rémy nous indique son avis très personnel : Cette solution est très bien adaptée pour le stockage d’information temporelle (cf. l’exemple donné). Mais Cassandra ne semble pas être la plus facile d’accès (sans jeu de mot).
3 – Document stores
MongoDB rentre dans cette catégorie.
Il stocke un ensemble de Collection. Chaque Collection stocke un nombre quelconque de Document.
D1 -> C1 -> V1
|–> C2 -> { C3 -> V3
C4 -> V4 }
Les données sont stockées dans ces Documents. Un Document est un objet structuré, composé d’un ensemble de champ. Chacun de ces champs peuvent contenir des valeurs primitives ou d’autres Documents.
Concrètement, les Documents sont stockés en BSON (= Binary JSON).
Une Collection peut stocker des Documents qui n’ont aucun champ en commun (schemaless).
Par exemple, voici un objet contenu dans une collection Clients :
{
« _id »: ObjectId(« 4efa8d2b7d284dad101e4bc7″),
« Nom »: « PELLERIN »,
« Prénom »: « Franck »,
« Âge »: 29,
« Adresse »:
{
« Rue » : « 1 chemin des Loges »,
« Ville »: « VERSAILLES »
}
}
Ici, le champ Adresse est un Document composé d’un champ Rue et Ville.
(Exemple tiré de Wikipédia).
On pourrait avoir un Document, dans cette même collection, sans le champ Adresse, sans le champ âge, mais avec un champs comme « Numéro de sécurité sociale ».
A chaque objet est attribué un identifiant dans un champ nommé « _id », calculé à l’insertion.
Il n’est à aucun moment spécifié par l’application, MongoDB gère cet identifiant et peut être exploité par l’application.
MongoDB est livré avec de nombreux pilotes .
Je recommande vivement ce lien pour toute personne s’intéressant à MongoDB.
Vous pourrez par exemple tester ceci :
j = { name : « Pierre Martin » }
db.netapsysEmployes.insert( j )
db.netapsysEmployes.find()
{ « _id » : ObjectId(« 4c2209f9f3924d31102bd84a »), « name » : « Pierre Martin » }
MongoDB gère les contraintes telles les clés étrangères via des DBRef (Exemple : Garantir qu’une commande est associé à un client existant, sinon rejeter l’information).
So easy.
4 – Graph stored
Par Sylvain Roussy. La présentation est axée sur Neo4J.
Le principe : imaginez un graphe. Des branches et des noeuds. Un noeud est relié à un autre noeud via une branche, ou une relation.
Une relation entre les noeuds possède un nom. Un noeud « Pierre Martin » possède les champs âge et adresse, et est lié à d’autres personnes Paul ou Jacques, par des relations de type « Amis ».
Nous pouvons voir ce graphe comme un arbre. La différence est que chaque noeud peut être le sommet de cet arbre.
Schématiquement :
N1 -> N2 <- N3 -> N4
|——-^ |
|>N5————
Neo4J permet le stockage d’informations sous forme de graphe. Et apporte, avec son langage CYPHER, le requêtage sur les noeuds
Par exemple, vous consultez un profil PersonneX sur LinkedIn. Une telle base de données permet de connaître rapidement la personne Personne1, qui connaît Personne2, etc. jusqu’à cette PersonneX.
Mais il est également possible de requêter sur le type de la relation. Par exemple, je suis un commerçant et je pars du principe que : « les amis de mes amis sont mes amis ».
Je veux connaître toutes les personnes à qui j’ai déjà « vendu » un produit (relation de type « vendre »), connaissant un de mes amis nommé « Pierre Martin » (relation de type « amis »).
Et leur envoyer par courrier un bon d’achat.
On obtient schématiquement :
Moi <–Est ami avec–> Pierre <–Est ami avec–> Paul
|—————–Avoir Vendu a———————–^
Et ce pour N2, N3…
Cela pourrait s’étendre à toutes les personnes que je connais, et être étendu à plusieurs bonds (moi -> ami -> ami de mon ami -> ami de mon ami de mon ami…).
Ce qui semblait difficile avec un SGBDR standard devient plus simple.
Neo4J répond à ce type de traitement, et est adapté aux sites à orientation sociale (LinkedIn, Viadeo, Facebook…) .
Il permet le calcul d’un chemin à l’intérieur d’un graphe et la reconnaissance de structure : Support de présentation de Neo4J
Je recommande également cet article, réalisé par mes confrères d’Octo : Introduction aux graphes avec Neo4J et Gephi
Pour finir
Une belle introduction au NoSQL par Rémy et Sylvain. Pour compléter, un article sur l’écosystème NoSQL.
Une question principale subsiste : dans quel cas utiliser telle solution ? Ou dans quel cas ne surtout pas l’utiliser ?
J’ai une question, très personnelle, sur l’ensemble de ces solutions. La flexibilité apportée par le NoSQL ne remet-elle pas en cause les automatismes liés aux traitements de données (par exemple: les ETLs) ?
Qu’en est-il de la qualité des données, au sens BI ?
Vos avis sont plus que bienvenus.
Issam El Hachimi 