Les bases NoSQL pour mieux soutenir la charge

Lors de la dernière édition de l'IT Press Tour (www.itpresstour.com), nous avons eu l'occasion de rencontrer MarkLogic (www.marklogic.com) et ses dirigeants. Avant de couvrir l'offre de l'éditeur, revenons sur les raisons de ce nouveau modèle NoSQL(Not Only SQL) très en vogue sur le marché avec de nombreuses offres, représentant le réel renouveau du monde de la base de données.
Tout vient des besoins et des limites avec le modèle relationnel actuel dans un monde où la population d'utilisateurs est mondiale avec des applications ayant potentiellement des millions d'utilisateurs et une quantité de données colossales de toute nature:

1. Le premier besoin est donc le support d'un grand nombre d'utilisateurs en évolution rapide. C'est très différent d'une configuration avec une population faible, stable ou limitée comme on pourrait la modéliser avec une population d'une grande entreprise qui totaliserait disons 50000 utilisateurs. Il est donc très différent de supporter 50k utilisateurs et 50 millions - 1000 fois plus - en garantissant un bon temps de réponse et une bonne qualité de service tout au long de cette croissance.
2. Le second critère très lié au précédent est lié à la quantité de données que doit ingérer, indexer et servir le moteur de base de données.
3. Le troisième élément est la capacité à l'outil à supporter plusieurs types de données allant de structuré au non structuré.
4. Le troisième point de design réside dans l'utilisation de composants très standards couplés à un réseau rapide. Le réseau et la mémoire ne coutent pas chers, il est donc naturel de partir sur une philosophie distribué où on vient agréger et unifier les différents systèmes pour former un entité logique de traitement de grande taille.
5. Il s'agit de concrétiser la mutation de systèmes qui finalement automatisaient des tâches traditionnelles (formulaire papier vers formulaire électronique avec des champs bien délimités donc facile à modéliser, optimiser et indexer) vers Internet où le marché est global et les utilisateurs planétaires. On comprend que le modèle unique et rigide explose poussées par la volonté d'intégrer plusieurs sources de données comme par exemple l'Internet des objets.

Les bases de données "classiques" c'est-à-dire relationnelle fonctionnent parfaitement mais ciblent tout simplement un besoin différent. Elles sont aussi d'un design différent qui les limites dans leur capacité d'évolution. On parle ici de modèle Scale-Up on dans certains de Scale-Out mais avec la restriction de ressources partagées comme le stockage et la base de données elle-même. Je fais référence ici à la classique solution Oracle RAC et auparavant Oracle OPS pour ceux qui ont connu l'offre. La caractéristique du modèle relationnel réside dans ce modèle qui impose une rigidité du schéma (table, relations, jointures...). Pour faire évoluer et "casser" cette limite à la scalabilité, le marché a proposé plusieurs alternatives:

1. Le sharding: Il s'agit de créer des partitions de base de données gérer par des serveurs différents et offrir un mécanisme simple de répartition et segmentation au travers d'une clé de sharding. On image ce découpage simplement en disant qu'une base peut être découpée en 3 segments: A à G sur serveur 1, H à P sur serveur 2 et Q à Z sur serveur 3. Même si cette approche est viable, elle l'est surtout pour une base qui évolue peu car quand un "shard" est plein, il n'est pas facile de re-découper la base et re-répartir les données sans toucher l'application et en plus en ligne. L'autre limite est l'absence de jointures entre "shards", les requêtes sont lancées sur tous les noeuds pour une agrégation à postériori dans l'application. Le schéma de la base existe et est identique sur chaque serveur. Cette approche est complexe, sujette à erreur, coûteuse et pas du tout transparente pour l'application.
2. La dénormalisation: Dans ce cas, il n'y a plus de schéma de base, rien à créer, gérer et à faire évoluer. La base est essentiellement une association clé:valeur, la clé étant considéré comme primaire et la valeur le blob de données. le sharding est possible est devient transparent mais l'intérêt d'une SGBD relationnel est perdu.
3. Le cache distribué: Essentiellement représenté par Memcached et largement utilisé par Facebook, cette approche capitalise sur le coût très bas de la mémoire et de réseaux très rapides. la solution est très bonne pour des applications à fort taux de lecture mais introduit un nouveau tier à gérer entre les serveurs web et la base de données.

Le modèle NoSQL n'est pas la panacée mais permet d'adresser es défis des grands volumes - utilisateurs et données - grâce à:

• une absence de schéma,
• un mode auto-sharding naturel et implicite permettant une forte élasticité,
• un design scale-out par nature,
• un mode shared-nothing où chaque noeud est indépendant et contribue globalement au service grâce à ses propres ressources.
• une distribution des requêtes,
• et un caching intégré.

Une bonne idée aujourd'hui représentée par au moins 30 offres où nous trouvons des catégorisations comme les bases orientées clé:valeur, colonne, document ou graphe.