#nosql , decisionnel et #forumdecideo

Je suis intervenu au forum decideo lien ici , cet évenement a été d'une très grande qualité et très bien organisé (philippe Nieuwbourg) . Un intervenant avant moi : renaud FINAZ de Micropole Univers a fait une intervention brillante sur l'état de l'art dans le domaine du stockage des données au sens large du terme.

Je partage son analyse dans les grandes lignes:

Le volume de stockage n'est plus un problème : le Tera est accessible à tous pour moins de 100 euros.

Le volume d'information produit pour Internet en deux ans (2009/2009) est plus important que tout le volume d'information existant (X 5)


(source http://gigaom.com/2010/03/16/northscale/)

Toute cette information est en grande partie déstructurée.

Ainsi, ce n'est plus la donnée qui fait la richesse d'une entreprise c'est sa faculté de traiter cette donnée.

Le problème des performances.

Il y a deux point de contention possibles: alimentation et l'indexation (structuration) pour la restitution.

L'alimentation.
L'alimentation d'une base de données /entrepôt à partir des différentes sources de données.
Comment intégrer, contrôler , agréger des millions de lignes de données. Actuellement ces fonctions sont traités par des programmes en mode itératifs ligne par ligne ou en mode ensembliste par des opérations portant sur un ensemble de données.

Il es possible de paralléliser les traitements à conditions mais il faut le prévoir au préalablement. Ce parallélisme est rudimentaire : j'ai N sources de données je vais les traiter par N programmes lancés en même temps. Cette méthode est naïve car elle ne fait que déplacer le problème sur le moteur de la base qui lui traite les opérations en mode file d'attente (voir page sur ACID)

Il faut donc utiliser un système d'alimentation basé sur des traitements fortement 'concurrents' qui traitent avec des bases de données qui respectent le modèle ACID mais tout en étant capable de s'affranchir du modèle file d'attente (voir le théorème de CAP) de Brewer






Concernant les langages à utiliser.
Il n'y a pas de secret , regardons ce qui se fait chez les entreprise full web 2.0 (Facebook, twitter , amazon et google).

Les langages fonctionnels: Haskell mais surtout Erlang qui nativement est capable de travailler sur plusieurs nœuds de machine et de gérer la perte de serveur.
Scala le langage fonctionnel de twitter basé sur une JVM

Les langages hybrides: Ruby et Python

Tous ces langages possèdent des fonctions puissantes de MAP/REDUCE


L'indexation et la structuration des données.

Le calcul des agrégats ou la création des index est réalisable au moment du chargement des données ou a posteriori . Pour les agrégats et les index , il sera possible de paralléliser massivement les opérations de Map /Reduce.

Les bases à utiliser.



Tout sera fonction du type d'information à stocker .

• Pour des restitutions de documents!: CouchDB ou mongoDB (plutot hierarchique)
• Pour des cubes: prendre des bases orientées colonnes : cassandra, htable..