Base des données orientées-graphe: migration du relationnel vers le noSQL

II.3. CRITERES DE MIGRATION VERS LE NOSQL

C'est une évidence de dire qu'il convient de choisir la bonne technologie en fonction du besoin. Il existe cependant certains critères déterminants pour basculer sur du NoSQL.

· Taille : Nous sommes dans un monde où il y a des données ayant une masse considérable (qu'on appelle infobésité). Il sied d'avoir alors un système pouvant supporter un nombre important des opérations, d'utilisateurs, des données, etc. de manière optimale. Bien que tous les systèmes NoSQL ne soient pas conçus pour cette problématique, il est possible d'en trouver sans problème.

· Performance en écriture : Intérêt principal du géant Google, Facebook (135 milliards de messages par mois), Twitter (7TB de données par jour). Des données qui augmentent chaque année. A 80MB/s cela prend une journée pour stocker 7TB, donc l'écriture doit être distribuée sur un cluster, ce qui implique du MapReduce, réplication, tolérance aux pannes, consistance,... Pour des performances en écriture encore plus puissante, il convient de se tourner vers les systèmes in-memory.

· Performance en lecture clé-valeur : Certaines solutions NoSQL ne possèdent pas cet avantage mais comme il s'agit d'un point clé, la plupart d'entre elles en sont dotées.

· Type de données flexibles : Les solutions NoSQL supportent de nouveaux types de données et c'est une innovation majeure. Divers types de données, souvent des données complexes ne peuvent pas être mis sous forme de données relationnelles, d'où l'adaptation à un nouveau type des données.

· ACID : Bien que ce ne soit pas le but premier du NoSQL, il existe des solutions permettant de conserver certains (voire tous) aspects des propriétés ACID. Se référer au théorème CAP plus haut et aux propriétés BASE.

· Simplicité de développement : L'accès aux données est simple. Bien que le modèle relationnel soit simple pour les utilisateurs finaux (les données sont restituées selon la structure de la base), il n'est pas très intuitif pour les toujours être celle d'embauche d'un administrateur de base de données, le développeur devrait pouvoir être en mesure de le résoudre.

· Parallel Computing : Les solutions NoSQL améliorent les calculs parallèles.

II.4. CRITERES DE CHOIX POUR MIEUX CHOISIR LE TYPE DE BASE DE DONNEES [LE14]

Nous avons décrit les types des bases des données NoSQL au chapitre précédent. Certaines comme HBase, MongoDB ou Neo4j apparaissent régulièrement dans l'actualité et sont toutes libellées en tant que NoSQL. Il existe cependant des différences significatives entre elles, liées notamment au théorème de CAP. Ainsi, nous proposons le critère de choix suivant lorsque nous sommes buttés au choix d'un système de gestion de base de données du type NoSQL :

Ø Choisir une base de données orientées-document car elle s'adapte aux données non planes (type profil utilisateur).

Document

Champ1	Valeur
Champ2	valeur

Document

Champ1	Valeur
Champ2	valeur
Champ3	Valeur

Document

Champ1

Valeur

Document

Champ1	Valeur
Champ2	Valeur
Champ3	Valeur
Champ4	Valeur
Champ5	Champ5.1		Valeur
	Champ5.2		valeur
Clé
CLE2012
CLE2013
CLE2014
CLE2015
CLE...

Figure 2.2 : Illustration d'une base de données orientées-document

Quelques SGBD orientées-document :

· MongoDB : Développé en C++. Les API officielles pour beaucoup de langages.Protocole personnalisé BSON. Réplication master/slave. Licence AGPL (commercial et libre) ;

· CouchDB : Développé en Erlang. Protocol http. Réplication master/master. Licence Apache.

Ø Choisir une base de données orientées-colonne car elle s'adapte mieux au stockage des listes (messages, postes, commentaires, ...).

Figure 2.3 : Illustration d'une base de données orientées-colonne

Source : [LE14]

Quelques SGBD orientées-colonnes :

· HBase : Utilise un API Java. Adopte un design CA. Présence de quelques SPOF.

· Cassandra : Beaucoup d'API disponibles. Adopte un design AP avec consistance éventuelle. Aucun SPOF^3(*) car réplication master/master. Moins performant que HBase sur les insertions de données.

Ø Choisir une base de données orientées-graphe car pour mieux gérer les relations multiples entre objets (comme des relations dans un réseau social).

Figure 2.4 : Illustration d'une base de données orientées-graphe

Source : [LE14]

Quelques SGBD orientées-graphe :

· Neo4J : Développé en Java. Supporte beaucoup de langages. Réplication master/slave. Propriétés ACID possibles. Langage de requêtes personnalisé «Cypher».

· Titan : Haute disponibilité avec réplication master/master. Prise en compte d'ACID avec consistance éventuelle. Intégration native avec le framework TinkerPop.

Ø Choisir une base de données orientées-clé-valeur car elle permet d'accéder rapidement aux informations pour la gestion des caches.

Valeur 2012

Valeur 2013

Valeur 2014

Valeur 2015

Clé

CLE2012

CLE2013

CLE2014

CLE2015

CLE...

Figure 2.5 : Illustration d'une base de données orientées-clé-valeur

Quelques SGBD orientées-clé-valeur :

· DynamoDB : Solution d'Amazon à l'origine de ce type de base. Design de type AP selon le théorème de CAP mais peut aussi fournir une consistance éventuelle.

· Voldemort : Implémentation open-source de Dynamo. Il y a possibilité d'en faire une base embarquée.

* ³ C'est un point d'un système informatique dont le reste du système est dépendant et dont une panne entraîne l'arrêt complet du système.