L’état de l’art NoSQL

Etienne CHAUCHOT, Architecte chez PALO IT, a suivi une formation sur les “Bases de données NoSQL : enjeux et solutions” dispensée par Orsys, spécialiste de la formation aux technologies numériques. Les bases de données NoSQL et NewSQL proposent une nouvelle approche répondant à des besoins de volumétrie et de nouveaux types de données. Quels en sont les bénéfices et les limites ?

 

I. Constat : lacune des systèmes de gestion de base de données relationnelle (SGBDR)

 

A. L’évolutivité faible

Le schéma d’une base relationnelle est prévu pour répondre à toutes les requêtes possibles mais en contrepartie de cette généricité il est très structuré : non duplication de données, jointures entre les tables, colonnes des tables normalisées, contraintes d’intégrité, etc. La structure ne peut pas être modifiée (ajout, suppression, modification de tables, de jointures, de colonnes) sans modifier le code de l’application. La réciproque est également vraie : les modifications du code de l’application nécessitent souvent de modifier le schéma de base de données.

En synthèse, le couplage entre l’application et son schéma est très fort, ce qui rend la partie données d’une application coûteuse à faire évoluer.

B. Faible adaptation aux typologies de données modernes

Certaines applications ont besoin d’ingérer des données de différentes sources, par exemple : tweets, données de localisation, emails, etc. Cependant ces données ne sont pas structurées. Pour les intégrer dans un schéma relationnel, il faut utiliser des palliatifs pour plaquer les données sur un schéma préexistant, ce qui génère alors des problèmes de performance.

C. Scalabilité limitée : capacité à monter en charge

Le design en formes normales des schémas relationnels impose la non-duplication des données qui, elle-même, impose de faire des jointures entre plusieurs tables. L’exécution d’une jointure peut entraîner un full scan sur une table ou un index scan. Ces scans dépendent, en effet, de la quantité de données. La performance de l’exécution des jointures peut donc se dégrader au fur et à mesure que la quantité de données augmente. Les contraintes d’acidité liées aux bases relationnelles, notamment la contrainte de cohérence et d’isolation des transactions, imposent au SGBDR de déposer des verrous sur les données lorsqu’une transaction s’exécute. L’attente de la libération de ces verrous ralentit la base de données. En effet, plus le nombre de transactions est élevé, plus les performances se dégradent, ce qui est dû, entre autres, à l’attente de libération des verrous.
Au-delà d’une certaine volumétrie et d’un certain nombre de transactions, il faut donc donner plus de ressources au SGBDR afin de garantir les performances. La scalabilité des SGBDR peut être horizontale (multiplication du nombre de serveurs comme dans des solutions type Oracle RAC) mais uniquement en lecture, à cause des contraintes de cohérence. Le modèle de scalabilité est vertical : le coût des serveurs n’augmente pas de façon linéaire mais exponentielle, surtout lorsqu’on passe une certaine gamme. La scalabilité verticale peut donc coûter très cher. En outre, cette technique de scalabilité est limitée par la configuration maximale des serveurs.

La synthèse des points précédents est la suivante : les temps de réponse ne sont pas constants donc non prédictibles car ils dépendent de la quantité de données et du nombre de requêtes. Cet état de fait rend certaines applications incompatibles avec le modèle relationnel.

 

II. Réponse aux limites : orientations du NoSQL

 

Pour répondre aux limites du SGBDR, l’approche du NoSQL est de baisser les contraintes qui pèsent sur les SGBDR. En ce sens, la bonne traduction du NoSQL est plus « non relationnel » que « Not Only SQL ».

A. Relâchement de l’acidité

Le but est d’accepter de baisser l’exigence de cohérence (cohérence différée – eventually consistent) afin de garantir la disponibilité des données : lecture de la donnée sur plusieurs nœuds afin d’être tolérant aux pannes, amélioration du temps de réponse par l’absence de lock, etc. La cohérence peut-être, par exemple, gérée par des mécanismes basés sur les réplicas (lire n réplicas parmi m et prendre la version la plus récente de la donnée).

Théorème CAP (Cohérence Availability Partitionnability)

Cohérence : tous les nœuds donnent la même version de la donnée à un même moment.
Availability : chaque requête reçoit une réponse.
Partitionnability : les données sont « partitionnables » sur un cluster et le système continue de fonctionner même si une fraction des données n’est plus accessible.

Le théorème prouve qu’on ne peut choisir que 2 des 3 critères en environnement distribué. Et les différentes solutions de base de données ont choisi des compromis.

B. Données semi-structurées

Le schéma peut changer sans grand impact sur l’application : il est souple en évolution mais le modèle est plus ou moins structuré en fonction des bases noSQL. La dé-normalisation signifie l’orientation acceptant la duplication de données pour augmenter les performances (par exemple : création de tables d’indexes, clés composites, jointures applicatives par encapsulation, etc.).

C. Le schéma est défini d’après l’application

Le modèle de données est défini d’après les questions posées dans l’application. Il n’est plus défini et prévu pour répondre à toutes les questions possibles.

D. La tolérance aux pannes est intégrée dans le logiciel

Dans les architectures SGBDR standard, c’est souvent l’infrastructure qui est responsable de gérer la tolérance aux pannes, par exemple par la mise en place d’un clustering système et la mise en place de SAN répliqué. Dans les architectures noSQL, la base de données elle-même intègre des mécanismes de tolérance aux pannes, comme par exemple répliquer chaque donnée n-fois sur n-serveurs du même cluster et la topologie du cluster. Par exemple, la répartition en salle machine et dans les baies peut-être configurée dans la base de données elle-même.

E. Scalabilité horizontale plutôt que scalabilité verticale

Les données sont découpées en shards et réparties entre les serveurs d’un cluster. Pour la lecture et l’écriture, le serveur est choisi à partir de la clé primaire de la donnée par un hash, qui fournit un identifiant au serveur et ainsi chaque serveur gère un range de données.

F. Matériel peu onéreux

En SGBDR, l’architecture standard pour fournir de grandes performances est plutôt un couple de serveurs high-end puisque le modèle de scalabilité est vertical avec du SAN, surtout pour la tolérance aux pannes. Les architectures standard noSQL sont composées de serveurs de petite ou moyenne gamme avec du stockage interne sans SAN car la réplication n’a pas à être prise en charge par l’infrastructure.

G. Le modèle Open Source

Le modèle est l’Open Source avec une société en support (par exemple, Datastax pour Cassandra, avec pour OS de prédilection Linux).

H. L’administration réduite

Les charges d’administration des bases NoSQL sont souvent relativement faibles : ajout de membre aux clusters, définition de la topologie du cluster (Datacenter, racks, pays), choix des paramètres de réplication (nb de réplications, nb de lectures, nb d’écritures pour cohérence et de répartition).

 

III. Les types de bases NoSQL

 

A. La base clé-valeur

Il s’agit d’une map qui est composée d’une clé et d’un champ libre binaire non structuré. Le requêtage se fait par la clé.

Les solutions les plus populaires : Memcached (base mémoire) et Redis.
Exemple d’utilisation : gestion de cache.

B. La base colonnes

Les tables ont un nombre variable de colonnes qui peuvent être vides, regroupées en familles ou familles de familles. Chaque cellule est un champ libre qui peut être binaire ou typé. Chaque ligne peut avoir un schéma différent : colonnes, types de données différentes.

Solutions les plus populaires fondées sur Google BigTable : Hbase (supporté par Apache) ; Cassandra (développé par Facebook, supporté par Apache et Datastax).
Exemple d’utilisation : Google :BigTable clé=url_renversée de la page, colonnes=pages_référençant_la page, valeur=contenu_page ; Facebook (Cassandra puis Hbase) ; Twitter ( Cassandra) ; Ebay.

C. La base documents

Elle est composée d’une clé et d’un document JSON ou BSON. Les documents peuvent être imbriqués ou regroupés.

Solutions les plus populaires : MongoDB.
Exemple d’utilisation : Amazon EC2 (MongoDB).

D. La base graphe

Elle est fondée sur la théorie des graphes : nœud, arc, attribut arc, sens. Elle est donc adaptée aux réseaux, aux problèmes de chemins et d’itinéraires. Elle est similaire à une base clé-valeur mais avec une modélisation des liens entre les nœuds et des attributs pour ces liens. Le contenu est un document ou une liste d’objets. Contrairement aux autres bases noSQL, elle n’est compatible qu’avec le modèle de scalabilité verticale car on ne peut pas découper un graphe. L’équivalent des jointures SGBDR se fait naturellement car les liens sont stockés en tant qu’objets. Le stockage interne à cette base est fait sous forme de triplet : nœud, arc, nœud.

Solutions les plus populaires : Neo4j ; Riak.
Exemple d’utilisation : Facebook graph ; travail autour des chemins (itinéraires par exemple) ; modélisation de la connaissance (état des lieux) ; modélisation réseau (humain, technique, objets, messages) ; recherche de motifs et d’associations (ex détection de fraudes…) ; recherche contextuelle ; catalogue (ex produits avec ses constituants).

 

IV. Comparaison des bases noSQL par types d’usages techniques

 

Capacité à modéliser des données complexes vs volumétrie de données.

Crédit : Orsys

Crédit : Orsys

Extensibilité du modèle vs richesse fonctionnelle du modèle.

Extensibilité du modèle vs richesse fonctionnelle du modèle.

Crédit : Orsys

Share
Etienne CHAUCHOT
Etienne CHAUCHOT

1637

Leave a Reply

Your email address will not be published. Required fields are marked *