Je crée un nouveau projet. Vais-je prendre une base NoSql, c’est « In », à la mode, up-to-date, best-practise, plus performant ?
Non !!!!
Mais alors ?
Les bases NoSql sont une autre catégorie de stockage, dont l’objectif n’est pas le même que les bases traditionnelles, utilisant le language Sql.
Vous choisirez la catégorie, ( et sous catégorie pour une base NoSql ), puis la solution ( le serveur ), selon vos besoin.
Pour faire simple, dans les grandes lignes ?
Les bases Sql ( de type OLTP ), sont parfaites pour garantir la cohérence des données. Vous pourrez éventuellement partitionner vos fichiers ou répliquer vos bases pour de la performance, ou de la plus haute disponibilité, éventuellement.
Les bases NoSql sont utilisez dans des stockages de gros volumes de données, avec réplication pour la haute performance ou la répartition géographique. Elles n’offrent pas de garantie de cohérence des données.
Par exemple ?
– Une application de petites annonces en ligne en mode OLTP pour une grande communauté d’utilisateurs ( cf, le boncoin 😉 ) devra utiliser un serveur unique extrêmement puissant, et une annonce validée sera tout de suite ( dans la nano seconde qui suit ) vue par tout le monde.
– Une application de petites annonces en ligne en mode NoSql pour une grande communauté d’utilisateurs ( cf, eBay 🙂 ) utilisera des serveurs hétérogènes, répartis à travers la planète, et une annonce validée sera visible un peu plus tard, si tout va bien – ce qui est normalement le cas, par les autres utilisateurs, selon leur emplacement géographique, entres autres…
Dois-je donc choisir la catégorie selon mon application, architecture, besoins ?
Oui ! Il est hors de question d’utiliser une grappe de serveurs NoSql pour une application comptable par exemple ! Et il n’est pas raisonnable d’envisager héberger la base de données Amazon sur un gros serveur… y compris sa charge !
Alors, comment choisir ?
Avant toute chose, prenez connaissance du théorème de CAP :
– C : Cohérence ( Les données sont les mêmes partout )
– A : Disponibilité ( Availability )
– P : Partitionnement ( Répartition des données pour une haute performance )
Il est simplement impossible d’avoir 3 de ces facteurs en même temps.
Quelques scénarios :
– Une nouveau serveur, OLTP ou NoSql : Vous avez le C
– Un serveur OLTP avec réplication : Vous avez le C et A
– Plusieurs serveurs OLTP donc chacun se partage une partie des données : Vous avez le C et P ( le cas des magasins qui répliquent leurs données la nuit, par exemple )
– « Un serveur » NoSql avec répartition de charge dans DataCenter : Vous avez le C et P ( toutes les données sont toujours lisibles rapidement au sein du datacenter )
– Des serveurs NoSql répartis géographiquement et qui encaissent une forte charge : Vous aurez le A et P ( Toutes vos données seront toujours accessible, même en cas de problème, partout. Par contre, pas de cohérence garantie ! ( doublons, manquement de données, … )
Pourquoi ce terme « NoSql » ?
Vis à vis de l’expérience que j’ai, ce que j’ai lu, et mis en oeuvre, le terme NoSql n’est ni un refus du Sql, ni vraiment un « Not Only Sql »…
Comment fonctionnaient les serveurs relationnels historiques avant Oracle ? Sans le Sql ! C’est la même chose !
- Dans la catégorie des serveurs de type column-store ( exemple : Cassandra ) :
- La première version était accessible uniquement en API, aucun Sql-like
- A partir de la version 2, apparition du CQL ( Cassandra Query Language ), un Sql-like, pour simplifier la manipulation des gros volumes, pour faciliter la transition des « Squlistes », et parce que finalement, c’est bien pratique…
- Dans la catégorie des autres serveurs ( Graphe, KeyStore, … )
- Mettre en oeuvre du sql ne me semble pas possible !
Mais il y a aussi d’autres factures : Un moteur Sql est lourd dans le code, moins performant à interpréter ( génération du plan d’exécution-like ), voir impossible à mettre en oeuvre.
Il y a des catégories de serveurs NoSql ?
Quid des serveurs Historiques et des parts de marché ?
Ils intègrent des fonctionnalités NoSql like !
– MySql : Intégration du moteur de stockage Cassandra, MySql est une interface pour stocker les données dans ce format. Un joli pied de nez, mais cela ne vaut pas la mise en oeuvre d’un Cassandra Had-oc.
– Postgres : Un stockage du type columnstore est en cours de conception au moment de l’écriture de ces lignes, chaque table pourra utiliser ou non ce type de stockage.
– MS Sql Serveur : Stockage dans des tables du type column-store avec gestion des fichiers data et log à l’image des serveurs noSql. Objectif : Booster incroyablement ( facteur 100, pour un ordre d’idée à la louche ) la performance d’accès aux très gros volumes de données, au détriment de quelques fonctionnalités en moins pour ces tables, sans bénéficier de la réplication de datacenters.
Quelles sous-catégories de moteurs NoSql ?
Selon vos besoin, vous choisissez une sous catégorie de moteur NoSql, et dans cette sous catégorie, vous choisirez alors la solution qui vous semble la mieux adaptée :
- Moteur de type Graph, qui se focalise sur les relation entre des entités : Quel client a consulté quel produit, quand, … ?
- Moteur de type Hash : Stockage de clef-valeur de type hash, recherche par clef uniquement : moteurs de cache, …
- Moteur de type document : vous stockez un document dans un format exploitable, par clef. Ce document peut avoir n’importe quelle structure, des modifications, indexations et recherches par contenu sont possible : catalogue en ligne de produits et de fournisseurs hétérogènes, variable, …
- Moteur de type column-store : Qui ressemble beaucoup aux tables, mais sans relations ni jointures.
- …
Patterns et anti patterns ?
Normaliser une base de données NoSql est un anti pattern !
De grâce, ne cherchez pas à établir des relations, des jointures, a définir un schéma statique, … Les bonnes pratiques deviennent mauvaises en NoSql, il faudra donc apprendre les mauvaises pratiques, pour les vieux routards transactionnels 🙂
Ne rigolez pas, un Geek expert en MongoDb devra toujours être bien surveillé si il travaille sur un projet Relationnel, et préparez-vous a de longues heures d’argumentations pour lui réexpliquer qu’une roue est bel et bien ronde…
Un projet peut-il intégrer aussi un une base NoSql que transactionnelle, ou il faut absolument choisir l’une ou l’autre ?
Se fixer comme contrainte de n’utiliser qu’une solution peut être une erreur ! Il peut être totalement justifié d’utiliser conjointement un serveur Oltp et NoSql dans une même solution.
