Affichage des articles dont le libellé est nosql. Afficher tous les articles
Affichage des articles dont le libellé est nosql. Afficher tous les articles

samedi 21 juin 2014

Opérations avancées avec MongoDB

Dans une video, j'avais présenté une introduction à MongoDB.

Pour faire une suite voici quelques manipulations avec le client mongo ou  l'API Ruby.



Pour commencer: 

Avec le client mongo :
voir toutes les bases : shows dbs 
voir toutes les collections d'une base: show collections

Pour les recherches :


Rechercher à l'aide d'une expression régulière :ATTENTION à réserver que pour les champs 'string'
Toutes les stations de velib dont l'adresse contient le mot 'filles' (ex filles du calvaire )
db.stations.find({address :/.+filles.+/i}).count()

ou en version moins compacte :
db.stations.find({address : $regex :{/.+filles.+/i}}).count()

Pour inverser la sélection : $regex :{/(?!.+filles.+)/i}

Avec l'API Ruby:
rech = @stations.find({:address => /#{Regexp.quote(arr)}/}).each { |p| ...


Rechercher les entrées avec qui n'ont pas un champs précis:
db.stations.find({rem: {$exists : false}})

ou 

db.stations.find({rem: null})  # cette forme ne fonctionne pas si un champs contient la valeur null

Avec l'API Ruby:

rech = @stations.find({:arrondissement => nil})....

Afficher que certain champs en sortie:

db.stations.find({arrondissement: 75001},{'state.total_slots' : 1})

Avec Ruby : utiliser le symbole :fields :


@pgm = @db['jcl'].find({'source' => {'$exists' => true}},{:fields => {'jcl' => 1 , 'source' => 1, '_id' => 0}} ).to_a

(le champs id ou _id est special ,c'est l'identifiant des entrées.  il est toujours retourné sauf si , la valeur de sa clé est mise  à zero.)

Une recherche avec une  condition qui porte sur  deux champs de l'entrée (utilisation de $where et this.
(API Ruby)

@alerte = @coll.find('$where'  => "this.reel['total moe'] >= this.valide['total moe']" , 'semaine' => semaine )

Enfin: un tri
db.stations.find({},{address:1}).sort({'state.total_slots' :-1 }).limit(1)
Ici , le tri combiné à   limit(1) permet de récupérer la valeur la plus grande.

Regroupement d'entrée: 


  • Le plus simple est l'opérateur distinct:

db.stations.distinct('arrondissement')

distinct retourne un array (tableau) , aussi pour connaitre le nombre d élément:
db.stations.distinct('arrondissement').length  



  • L'operateur group:


Un autre manière de déterminer le maxima d'une série

@arr = @coll.group( :initial => {cmax:0} ,:reduce =>  "function(obj,prev) { if(prev.cmax < obj.semaine) prev.cmax = obj.semaine; }" )

un autre exemple avec le client mongo
db.stations.group({initial : {cmax : 0 } ,reduce : function(obj,prev) { if (obj.state.total_slots > prev.cmax) prev.cmax = obj.state.total_slots }})

[ { "cmax" : 72 } ]

Enfin un exemple de regroupement avec cumul intermédiaire et condition :

esi  =@coll.group(:key => :esi ,
                       :reduce => "function(obj,res) {res.pr.push({projet :obj['projet'],v: obj['valide']          ['moed'], r:obj['reel']['moed']  });
                                    res.valideESI += obj['valide']['moed'] ;  
                                    res.reelESI += obj['reel']['moed'] ; }",
                        :initial => {  :pr =>  [],
                                       :valideESI => 0,
                                       :reelESI   => 0 
                         },
                       :cond => {:semaine => max})


samedi 29 mars 2014

Les bases NoSQL pour stocker du XML

Pendant de nombreuses années le XML tenait le haut du pavé dans le domaine de format de fichier: pour les données , les configurations etc. Le XML était partout:

Source : https://delta-xi.net/gfx/xml-landscape.gif

Depuis, on revient à un usage plus raisonnable du XML. Et des formats comme le JSON, le YAML ont  maintenant trouvés leur place.

Comment stocker efficacement des fichiers XML ?.

La solution habituelle.

La solution basique consiste à extraire les informations pertinentes du XML pour les sérialiser dans une base de données. Le format XML se prête mal a des opérations de recherche.
Cette solution à ses limites surtout pour des enregistrements XML de taille variable. L'exemple qui vient à l'esprit est celui de la récente réforme des échanges bancaires: le SEPA.
D'un format fixe de 240 caractères , les nouvelles normes ont évoluées sur des articles XML de taille variable. Le volume est plus important en raison de l'utilisation du XML, du détails des opérations mais d'une taille non prédictible.

 Des solutions à base de NoSQL.


Le principe de ces solutions est de stocker les fichiers XML échangés dans  une base de donnée Nosql. Le choix de cette base se portera sur un dispositif orienté document comme MongoDB.
source:
http://blogs.the451group.com/information_management/2011/04/15/nosql-newsql-and-beyond/

Les informations seront stockées sous deux formes:
Sous la forme d'origine en XML et sous un format JSON avec une succession de  clé / valeur. Les opérations de recherche se feront sur la partie JSON.

Ci-dessous un exemple de programme en Ruby utilisant la librairie nokogiri pour parser le XML:

Le fichier XML est exploré récursivement  puis injecté dans une base NoSQL mongoDB par ce script:


Le fichier XML sera injecté par ailleurs.

Ainsi l'information sera disponible sous deux formes avec une des formes autorisant des recherches multicriteres. Le stockage dans un système sans schéma est particulièrement adapté à des informations hétérogènes.






samedi 13 juillet 2013

mongodb : premiers pas avec cette base nosql

Et une vidéo de plus consacrée à mongodb: Les premières manipulations

Le support est en ligne ici :



La partie vidéo seule est ici:



Les sujets abordés sont les suivants:

j'evoque l'injection massive par la commande mongoimport
La syntaxe est la suivante:

./mongoimport --file ../../stations.json --collection stations --db velibdb --jsonArray


Le dernier paramètre (jsonArray) sert à indiquer que les documents JSON sont  les uns à la suite des autres dans un tableau.

J'utilise un fichier opendata sur l'état des stations  Velib issu du site: http://eaupen.madebymonsieur.com/velib



Le programme ruby  servant à mettre à jour  les informations des stations est donné ci-dessous:



Les prochaines vidéos porteront sur les recherches dans une base mongoDB.

lundi 8 juillet 2013

Une première introduction à la base NOSQL mongodb

J'ai mis en ligne une nouvelle vidéo consacrée à  mongodb.
Le site de mongodb est ici.



 Le support complet slides et vidéo est sur le site de partage slideshare



Mongodb introduction from eric german


MongoDB et Haddop sont deux compagnons.  Hadoop permet de stocker des volumes importants  et mongoDG s'occupe de la restitutions d'extraction de données venant d'hadoop.
Dans le sens inverse, mongodb peut utiliser la puissance des JVM pilotée par Hadoop pour réaliser des traitements par lots (ex Map-reduce).

MongoDB est une base NOSQL  de type document un peu comme couchDB. Son langage de commande est le Javascript.  Le projet se compose d'une série de programme dont 'mongod' : le serveur de la base et 'mongo' : un client sous la forme d'une console shell.

J'ai mis ici un exemple de script de lancement du service mongod pour ubuntu
 

Et ici le fichier de configuration:

vendredi 5 juillet 2013

Bientôt des vidéos et des articles sur la base NoSQL MongoDB

Voila plusieurs semaines que je bricole avec MongoDB l'étoile montante des bases NoSQL  (Not Only  SQL).

 Après avoir essayé: CouchDB , Redis , Riak , étudié Cassandra et Hadoop (voir les posts ou les vidéos)
(source : http://germanlinux.blogspot.fr/2012/12/la-carte-hadoop-pour-ne-pas-se-perdre.html )

Posts :



C'est lors de la journée des utilisateurs Hadoop France en decembre 2012 que j'ai compris l'importance du rôle de MongoDB.

Il y a d'un coté le BigDATA:
Il   répond à un besoin de stocker un nombre vertigineux de données et surtout à offrir un cadre pour réaliser des traitements parallèles (map-reduce)

De l'autre  coté le mouvement NoSQL qui cherche à assouplir  l'architecture applicative et à simplifier les modèles de données. Le NoSQL souhaite aussi répondre au besoin de stockage de masse engendré par les réseaux sociaux. Ces informations ne sont pas toujours structurées . La disponibilité, le partage des données sont les objectifs principaux, le traitement parallèle est secondaire.

MongoDB fait le lien entre ces deux mondes.
 
Prochaine vidéo

A bientôt.


samedi 28 juillet 2012

installation de la base Nosql redis

Une video (screencast' de plus consacrée  à la base de données nosql  REDIS.
Cette base s'impose comme la successeur  de  memcached.


Redis manipule cinq types de données. 
La vidéo détaille son installatino et les premiers test à faire.
ci dessous l'exemple d'utilisation de l'API  pour  Ruby .


J'ai confectionné l'infographie suivante qui reprend toutes les commandes de Redis.





mercredi 6 juin 2012

Le gouvernement US lance l'administration 2.0



Dans une directive de Mai 2012 ,  Barack OBAMA impose aux agences fédérales de publier leurs données sous une forme lisible par tous où par API web. Ce dernier point est important :l'accès doit pouvoir se faire par des librairies de programmes, par des robots. Cela préfigure l'administration 2.0. 
Il n'est pas question d'un portail d'accès mais bien d'une  mise à disposition par chaque entité. La course à l'opendata est lancée avec des retombées certaines sur les technologies afférentes : stockage (NoSQL) et visualisation.





lundi 9 janvier 2012

#Hadoop, les limites des #nosql


Le système complet de la famille de stockage NOSQL , HADOOP vient de sortir en version 1.0
Le phénomène NOSQL commence à diffuser au sein des directions informatiques grandes ou petites.
Le sujet des bases nosql soulève deux questions:
Quels sont les cas d'utilisation à retenir ?
 Sur le site http://www.saama.com  une infographie  propose une réponse à cette question.

Le nombre de cas d'utilisation est reduit et les risques d'erreur important.
Les applications métier de gestion sont à écarter, surtout si elles reposent sur un bon vieux framework MVC J2E.
A mon sens l'utilisation d'une base NoSQL se justifie pour des usages :

  • très simples. 

Exemple: l'application ne sert qu'a afficher ou a manipuler quelques table sans valeur ajoutée. Les tables seront regoupées dans une seule entité d'une base NOSQL avec de la denormalisation et de la redondance assumée.

  • Des architectures d'infrastructure  avec des fortes contraintes de volume  ou de disponibilité : Un serveur de session, un gestionnaire de message par l'exemple  
  • Des applications qui mettent en oeuvre des opérations d'indexation ou de comptage. C'est ici qu'intervient le map/reduce mis en avant  par google. 

En conclusion: Le Nosql est en passe de devenir le nouveau truc à vendre par les SSII. Il y très peu de projets candidats.  

Vous avez envie de vous lancer dans l'aventure. 

La tentation est forte de commencer par hadoop: Ce projet a 6 ans d'age, labélisé par La fondation Apache.
 Hadoop se présente  comme un assemblage de plusieurs sous-projet avec à la base  un système de fichier HDFS et HBASE pour le stockage. Avec hadoop les données et les fichiers sont distribués sur plusieurs serveurs. Les opérations de map-reduce se passent sur chaque fragment eléméntaire de données.

Aussi, je vous conseille de commencer avec des produits NOSQL plus modestes comme Riak ou mongodb.
Leur spectre d'utilisation est plus grand que celui d'hadoop.
Avec les produits NOSQL il faudra souvent passer par du javascript (meme pour hadoop) qui s'impose comme le langage 'utilitaire' de ces nouvelles bases.




Les bases NOSQL vont aussi se retrouver au niveau du client,  cette  adoption est favorisée par l'adoption du HTML5 et de la décentralisation des traitements. Votre poste de travail mobile va extraire les informations geo-localisées depuis une base de données centrale. Puis votre terminal travaille sur les données locales pour une re-synchronisation future.

Mais attention.

Pouvoir stocker plus de données c'est bien, mais pour en faire quoi ? Une entreprise ne sait se servir que de moins de 5% de ses données. La donnée doit etre structurée, indexée et tracée  et non pas déversée en vrac dans un entrepot ou une base de données sinon elle sera perdue.
En 2020 , l'écart entre le volume d'information et la capacité de stockage va se creuser : en clair il faudra compresser la donnée et ne sélectionner que l'information pertinente.
Aussi de la même facon qu'il y a des DSI , il y aura de Data manager assurant la gouvernance des données au sein des SI. Après l'urbanisation des SI , c'est le tour des données.



mercredi 10 août 2011

LevelDB :un projet google pour une librairie key-value

Google vient de sortir un nouveau système de stockage intermédiaire: LevelDB. C'est une librairie de bas niveau destinée à des bases de données NOSQL  de type key-value. Le système encapsulant cette librairie écrite en 'C' est à développer. Un portage existe pour le système ANDROID. 
La documentation est ici.

Illustration : http://blog.nahurst.com/visual-guide-to-nosql-systems

Pour rappel le site ici qui recense toutes les bases de données nosql.



jeudi 30 décembre 2010

2010 année du NoSQL


Dans cette présentation , Kevin Weil responsable du secteur analyse des données chez twitter (lien ici ) détaille comment l'architecture de twitter a évolué pour faire face à l'accroissement des volumes.

Le conférencier use d'un argument massue : Le volume quotidien de donnée sur twitter est de 12 TB. Sachant qu'un disque ne peut traiter que 80 MB/s , il faudrait 41 Heures pour traiter les données d'un journée.
Conclusion : il a été nécessaire de paralléliser les traitements et le stockage des données.
Aussi twitter utilise l'infrastructure distribuée HADOOP d'Apache avec tous les produits dérivés dont le langage 'PIG'.
PIG permet de réduire considérablement la quantité de code à écrire et le temps d'exécution

Ce qui est nouveau dans la démarche , c'est l'hétérogénéité des solutions employées.
Une entreprise cherche normalement à réduire au maximum le nombre de composant de son SI (un seul type de base données, un seul framework etc) . Twitter ou facebook utilisent une kyrielle de produits souvent concurrents (Ruby on Rails , scala , cassandra, HBase, FLockDB).
Alors pourquoi ces choix ? Et comment les assumer au sein de l'entreprise ?.

dimanche 21 novembre 2010

La transition entre les SGBDR et les bases NoSQL



Le contenu des bases NoSQL (Not Only SQL ) n'est pas issu d'une génération spontanée. Une grande partie des informations provient des base de données 'traditionnelles'. Comment passer d'un modèle à un autre ?. Des interfaces vont devoir être développées, voici ma contribution : le module nosql.rb disponible sur Lemon-labs (github).

Ce module rassemble des informations d'une base de données (Postgresql , oracle , mysql etc ) et injecte les données dans une base NoSQL (ici couchdb).

Configuration

Le programme utilise un fichier de syntaxe YaML qui va décrire les sources, les filtres à utiliser et la cible.

Datasource:
adapter: sqlite3
database: db/development.sqlite3
poll: 5
timeout : 5000
Tables:
table_fact: projets
primarykey: id
table_dimension:
filieres:
primarykey: id
foreignkey: filiere_id
technos:
primarykey: id
foreignkey: techno_id
filters:
attributes: id
regexp: create,_id,update
append:
attribute: type,ROW
options:
NoNil: 1
target:
# output: 1
couchdb: http://localhost:5984/projets
Avec les paragraphes suivants:
  • Datasource : c'est l'accès à la base de données relationnelle. Sa syntaxe est celle ActiveRecord de Rails.
  • Table : la première partie décrit la table principale (ou table de fait) . La suivante liste toutes les tables de détails (dimension) et les champs utilisés pour les liens.
  • Filter: le programme constitue un tableau associatif pour la ligne à créer. Les filtres servent à supprimer des champs (exemple : les champs des clés primaires ou étrangères)
  • Append: Cet option ajoute des attributs fixes (exemple : type de ligne)
  • Options : fixe les règles de gestion des champs vides.
  • Target : précise la base NoSQL à charger.

Le programme va récupérer les informations sur les tables, les champs et les liens entre les tables.
Ligne par ligne, le module va entièrement dénormaliser la base pour ensuite l'injecter dans une base NoSQL.


API REST
Le module nosql.rb est associé avec un module nosqlonweb.rb qui lui ajoute un format d'API REST.



Le menu delete_row permet de supprimer toutes les entrées d'une base NoSQL sauf les documents de restitutions.

Le lancement du module web se fait par la commande :
ruby nosqlonweb.rb . Le framework utilisé est 'sinatra'.
L'API retourne ses résultats au format JSON.

Bases supportées
L'utilisation d'active record rend le programme compatible avec la majorité des bases de données. PostgreSQL, Oracle , SQLite, Mysql etc.

dimanche 31 octobre 2010

Comment créer des vues dans couchdb

Chaque base de données de couchdb propose un répertoire '_design' qui hébergera les vues et les listes liées à votre base.
Les vues sont destinées à restituer les données sans formatage. Les 'shows' et les 'lists' mettent en forme les données. Le 'show' ne s'applique qu'a une entrée à l'inverse de la 'list' qui porte sur un groupe de données.

Concrètement le source des vues est un document JSON. Il faut a chaque fois, récupérer le document source, le modifier et le recharger sur couchdb.



{"_id":"_design/tablefait","_rev":"12-bf5c8cb0de5d7c352af03cb8ea45e8b6",
"language":"javascript",
"views":{
"cam-an-mois":{"map":"function(doc)
{if (doc.TYPE ==\"RAW\") {emit ([doc.campagne,doc.annee,doc.mois], doc); } }"}},
"lists":
{"indexml":"function (head, req)
{ var row;
start({ \"headers\":{\"Content-Type\" : \"application/xml\" }
});
send(\"<entries>\");
while(row = getRow())
{
var xml= new XML (\"<entry/>\");
xml.campagne=row.value.campagne; xml.annee=row.value.annee;
xml.mois=row.value.mois; send(xml);
}
send(\"</entries>\");
}"
}
}



Ici 'tablefait' est le nom du groupe de restitution, 'cam-an-mois' est le nom de la vue qui va servir à restituer les entrées suivant des clés d'index. Enfin 'indexml' est la fonction javascript à appliquer pour formater les résultats.





Utilisation d'une vue sans formatage particulier :
Par un navigateur : http.... 5984/db/_design/tablefait/_view/cam-an-mois?[2010,2010,09]


Avec le formatage XML

Par un navigateur : http.... 5984/db/_design/tablefait/_list/indexml/cam-an-mois?[2010,2010,09]


Attention la construction de l'url est fonction de la version de couchDB.


Les difficultés d'écriture d'une fonction de formatage sont les suivantes:

  • Le javascript de la fonction de formatage sera stocké dans une chaine de caractère. Les quotes sont à protéger par des '\'.
  • A chaque mise au point, le numéro de révision sera à ajuster.

Pour gérer ces problèmes plusieurs solutions sont possibles et seront présentées prochainement.

samedi 30 octobre 2010

Pour aller plus loin avec couchdb: la compilation

J'avais fait quelques ( posts sur le sujet) . Très vite, la manipulation de couchdb nécessite des bouts de javascript et du JSON. Je veux par exemple produire des données sous forme XML, ou proposer des vues avec des mises en page. Pour cela il faudra modifier les listes ou les vues dans couchdb.

La première précaution à prendre est de travailler avec la dernière version de couchdB. La gestion des listes et des vues a évolué d'une version à l'autre.
Pour installer une version récente de couchdb , il faudra probablement mettre à jour votre version de Erlang.


Le lancement de la commande ./configure dans l'archive de couchdb doit produire les erreurs suivantes:
La compilation de couchdb va chercher à résoudre les dépendances dont celle ci :
Is the Mozilla SpiderMonkey library installed?

spidermonkey est le moteur javascript de Firefox. Son installation complète se teste par la commande 'js' (librairie et l'interpréteur) .
Son installation se fait par:
apt-get install libmozjs-dev
Puis vient le tour de la librairie 'international character'
apt-get install libicu-dev

Enfin l'utilitaire 'curl' : c'est avec lui que se fait les premiers essais avec couchdb

apt-get install libcurl4-openssl-dev

Tout ca pour arriver au message :
configure: error: The installed Erlang version is less than 5.6.5 (R12B05).

Vous allez devoir vous payer une petite compilation du langage Erlang.

Rien de bien compliqué , juste un configure , make , make install dans le repertoire otp_src_Rnn

Puis revenir à la compilation de couchdb en précisant :
./configure --with-erlang=/usr/local/bin

Ok tout est bon le make et make install terminent l'opération. Le répertoire /usr/local/bin doit contenir au minimum erl et couchdb.





mercredi 16 juin 2010

RDBMS vs noSQL , CAP théorème


Linux journal du mois de juillet (195) propose un article sur le mouvement NoSQL. Cet article est un peu partial en faveur des RDBMS (Relational Database Management System) .

En revanche il reprend les notions de base:

Norme ACID :
  • Atomicity : la transaction se termine complètement avec succès ou on revient à l'état initial
  • Consistency: La base est un dans état stable avant et après la transaction
  • Isolation: Une transaction est indépendante d'une autre. Une file d'attente doit gérer les conflits.
  • Durability: Une fois que la transaction est terminée avec succès, les changements dans la base seront acquis un fois pour toute.


Cette norme est un principe fort de fonctionnement des bases de données.


Théorème de CAP ou de Brewer (eric)

  • Consistency : (diffère du la notion éponyme dans ACID) , Quel que soit le moment de l'écriture d'une donnée, la lecture de cette donnée retournera la dernière version.
Une 'éventuelle consistance' signifie que l'on accepte une différence de version de la donnée.
  • Availability: On peut toujours attendre qu'une base de données réponde à une requête . cette disponibilité peut être réalisée par plusieurs serveurs émulant une seule instance.

  • Partition :(partition tolerance) La base de donnée est accessible en lecture ou en écriture même un des noeuds est inaccessible. Lorsque le service reviens à la normale le noeud est mis à niveau.


Ce théorème démontré par Gilbert et Lynch du MIT en 2002 , montre qu'il est impossible pour un système de données partagées de garantir les trois propriétés simultanément.

Un RDBMS privilégie une consistance forte et une disponibilité assurée par une instance miroir.
Un système NoSQL se contentera d'une 'éventuelle consistance' au regard du flux important d'information (exemple :twitter)

Les systèmes NoSQL sont souvent basés sur des magasins de clés-valeurs. Le langage associé est de plus en plus, le Javascript . On peut noter l'existence d'un projet original 'Friendly' qui permet de faire du NoSQL sur MySQL. Une table est créée par champs : si une table normale possède 5 champs, elle sera éclatée en 5 tables (je simplifie) . Cela permet d'avoir une base de données sans contrainte de schémas.
Les NoSQL sont qualifiés de 'post-moderne' : au lieu de vous donner une réponse 'juste' ils vous donnent la meilleure réponse possible.






vendredi 19 mars 2010

#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



nosql2


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..

lundi 15 mars 2010

forum decideo et nosql



Je vais intervenir cette semaine au forum decideo http://www.forumdecideoeditionopensource.com/.
Ma présentation portera sur :
L'opensource dans un grand compte
* Les bonnes pratiques
* L'animation d'une communauté
* Le support
Opensource et décisonnel
* Retour d'expérience : entrepôt de données
* Les tendances : alimentation , architecture de restitution , le stockage : NoSQL


Les derniers numéros de 01 informatique et de linux journal traitent du sujet nosql .
Both Reuven M. Lerner and Avi Deitcher talk about databases this month. Reuven talks about the NoSQL movement, and Avi discusses jsormdb.
Le numero Linux journal (avril 2010) ici et ici (podcast) .