EA2014-NoSQL

Introduction noSQL

Rappel sur les bases relationnels

Les bases de donnée dit relationnelle stocke les données en utilisant un schéma relationel. Comme son nom indique, le contenu d'un base sont reliés entre eux par des opérations d'algèbre relationnelles par exemple JOIN, IN, AND etc et ainsi obtenu par moyen de ces derniers. Chaque relation dans une base relationelle s'appelle une table et c'est une matrice qui contient un ensemble de groupes de valeurs séparé par des colonnes. C'est une structure très rigide et très restrictif aux évolutions des données.

Le plus connu de ce type de base est mySQL.

Problèmatiques

Depuis l'explosion des grandes applications web comme Google, Amazon, Facebook et eBay, on a constaté une croissance exponentielle au niveau de la taille des données à stocker et à traiter pour le bon fonctionnement de leurs systèmes. Les utilisateur d'une nouvelle application peut peut croître de 0 à quelques millions dans une seule journée. L'utilisation d'une site web peut exploser pendant une période d'affluence forte (par exemple :eBay pendant St Valentin).

On commence à sentir les limitations des bases de données relationnelle pour délivrer un accès plus rapide et un traitement plus performant. La scalabilité verticale ne tient plus dans le monde de BigData et il faut chercher une autre solution car ce modèle ACID ne passe jamais à une telle échelle. On remarque également que les données sur l'internet actuellement sont très variées et n'a pas beaucoup de relations spécifique entre eux pour faire fonctionner une application.

Concept de noSQL

noSQL (not only SQL) est un ensemble de concepts pour modéliser et stocker les données qui s'oppose au modèle relationel, en suivant un schéma plus flexible(schemaless). Au lieu d'utiliser les tables, une bases noSQL prend les données à stocker, les affecte chacun une clé hash unique, et puis les éparpiller sur la base de données. C'est grâce à ces clés hash que les données peut être récuperées efficacement. L'avantage de "schemaless" dans noSQL c'est qu'on peut stocker tous ce qu'on veut dans notre application sans se soucier des évolutions plus tard dans le devéloppement de l'application.

En plus, toutes les bases noSQL sont conçues en tant que systèmes distribués pour permettre une scalabilité horizontale, c'est-à-dire pour répondre à l'augmentation de notre base, il suffit d'ajouter plus de noeuds/serveurs à côté. Au terme de performance, noSQL supporte à priori les requête distribuées(Distributed query support) ou chaque noeud est capable de répondre aux requête des clients, et cela diminue considérablement le charge du système. Il noter que ceci est un trade-off avec les propriétés ACID de la base relationnel.

Théoreme de Brewer

Dans le monde des systèmes distribués, le théoreme de Brewer(connu aussi sous le nom théoreme de CAP) dit qu'il est impossible d'avoir simultanément la garantie des ces 3 propriétés  :

• Consistency(cohérence) - Chaque noeud/serveur voir les même données au même moment
• Availability(disponibilité) - Toutes les requêtes reçoivent use réponse en temps fini
• Partition tolerance(résistance au morcellement) - Apart d'une coupure totale, le système fonctionnement(répondre correctement) même s'il y a des partitionnement généré par des pannes sur un ou plusieur noeuds.

Les architectures noSQL sont distribué par nature et donc ce théoreme s'applique.

Pendant la conception d'une base noSQL, il faut bien choisir 2 parmi ces 3 propriétés qu'on veut et ensuite regarder parmi les marques de noSQL sur le marché lesquelles garanties ces 2 propriétés. (Deux marques noSQL de même type ne garantissent pas forcéments les mêmes propriétés CAP).

Heureusement dans la plupart des cas, c'est les deux dernières qui sont choisies car les données EVENTUELLEMENT cohérente sont suffisante pour notre applications. Le fait d'avoir une donées qui est FORTEMENT cohérente dans un délai de quelques secondes (ou même millisecondes) nous semble moins important que ne pas avoir de résultat du tout.

Sharding

Dans les bases de données distribués comme noSQL, sharding décrire un ensemble de techniques qui découpe une base de données entière en plusieurs shards(tranches/noeuds/serveurs). Imaginons une vitre qui représente une base de données et on la casse en plusieurs morceaux, chaque morceaux contient les données qui ne se trouvent pas dans les autres morceaux (pas de réplication).

Chez les grands applications web qui se charge du stockage de de l'analyse d'énormes quantité de données, il n'est plus possible de tout mettre sur un serveur unique. Une machine quel que soit sa puissance immense n'est pas suffisant pour indexer tout l'internet.

Une bases de données peut être "shardé" horizontalement ou verticalement. La difference c'est que le sharding vertical stocke une ou plusieurs tables dans un noeud et le sharding horizontal stocke des éléments unitaire obtenu à partir des tables. Dans noSQL le dernier est bien sûr plus préféré pour une scalabilité horizontale.

Il y a plusieurs techniques pour 'sharder' une base de données, par exemple :

• MongoDB utilise plusieurs serveurs d'indexe(config servers) pour repérer les données dans un nombre de shards, ensuite redirige les requêtes vers les shards qui contiennet les données demandés.

• CassandraDB utilise un grid de serveurs ou chaque serveur gère un certain nombre de données borné par une intervalle dehash(random hash distribution). Si un shard reçoit une requête pour une intervalle de hash qui n'existe pas localement ou la fin de l'intervalle ne se situe pas localement, il retransfere la requête vers un autre shard dans le réseau.

Les 4 grands types de noSQL

Il existe actuellement 4 grands types de noSQL :

• Clé-valeur
• Orienté-document
• Orienté-colonne
• Orienté-graphe

Clé-valeur

Dans cette base, les éléments sont des couples avec une clé unique et une seule valeur chacun, tout simplement. L’accès à ce type de bases est généralement très rapide grâce au fait que les données sont stockées dans la mémoire vive au lieu de disque. Ce modèle est le plus populaire grâce au constat que les applications présentent nombreux accès à la base de données qui ne sont que des simples lectures ou écritures.

Example de marque : Memcached, Redis, Amazon DynamoDB

Orienté-document

Dans cette base, un élément est un ’document’ (sous forme de JSON habituellement) identifié par une clé unique. Un document peut avoir plusieurs champs JSON récursive comme valeurs. On peut même avoir des references(liens) entre les différents champs pour avoir un JOIN limité.

Exemple de marque : MongoDB, CouchDB

Orienté-colonne

Dans cette base, les éléments sont indexés par ligne comme dans le modèle relationnel mais stocké par colonnes, ce qui implique un accès très rapide pour les données BigData. Ce modèle est très performant dans la collecte des statistiques (des utilisateur par exemple) et les opérations de calcul sur un volume de données énorme (ex calcul de l'age moyenne des utilisateur Facebook).

Alors que les colonnes sont statiques pour une base relationnelle, elles sont dynamiques pour une base de données orientée colonnes, on peut ajouter des colonnes dynamiquement et il n’y a pas de coût de stockage pour les valeurs Null.

Exemple de marque : Cassandra, HBase de Google

Orienté-graphe

Dans cette base, les éléments sont des objets(noeuds) distincts qui peuvent être liées entre eux, en utilisant la théorie des graphes. Ce type de bases est conçu pour les données fortement connectées et évitent les jointures coûteuses en base relationnel.

Exemple de marque : Neo4j, FlockDB de Twitter, GraphDB