Face à cette variété de sujets, j’ai décidé de créer Born to Segfault, un blog 1) en anglais 2) qui ne parlera pas de 10000 choses différences 3) qui essaiera autant que possible de balancer du contenu intéressant.

Bref, à vos bookmarks,

Equipé depuis plusieurs années d’un réflexe, force est de constater qu’il m’était impossible d’emporter ce dernier partout avec moi. Quand bien même je suis un adepte de la focale fixe, notamment mon 28mm très peu encombrant, on sacrifie la compacité pour jouir d’une qualité et réactivité accrue. Réalisant que je « manquais » beaucoup trop de photos juste parce que je n’avais pas le bon outil au bon moment, j’ai décidé de trouver mon compagnon photographique idéal.

Aux premières annonces du Fujifilm X100 — le grand frère du X10 — je sentais le vent tourner. Enfin un retour aux fondamentaux de la photographie ! De beaux boitiers, bien construits, avec des modes manuels. Quand Fujifilm a continué sur sa lancée pour sortir le X10, j’étais conquis. Présentation rapide, pour les non initiés : il s’agit d’un compact haut de gamme, qui a pour lui un viseur optique exceptionnellement clair et large, un capteur d’excellente facture qui, bien que plus petit que les réflex se montre 2 fois plus grand que ses concurrents, et propose de maîtriser le zoom manuellement, comme sur un objectif de réflex. Avec toutes ces spécifications, le Fujifilm X10 ne tient certes pas dans une poche, mais se trimballe facilement n’importe où.

Mon avis

Les spécifications papier, c’est bien, mais à quel point suis-je séduit en pratique ? Mes premières craintes se portaient sur l’utilisation du viseur optique. Me voilà bien obligé de reconnaître que ce dernier est largement utilisable. Il n’y a certes pas de correction des problèmes de parallaxe, et aucune information n’est affichée en surimpression, mais sur des plans larges et des sujets éloignés, on peut parfaitement lui faire confiance. Et quel confort d’en profiter ! Pour des sujets rapprochés, si on commence à s’approcher des 112mm que couvre le zoom, le défaut de parallaxe est bien présent et il faut s’y accoutumer, avec un peu de pratique.

Le second critère décisif pour moi était la réactivité de l’appareil. J’étais prêt à sacrifier une partie de la qualité des réflex (je ne suis pas un adepte des images parfaites au piqué absolu), mais certainement pas la réactivité ! Là encore, je suis tout sauf dérouté. L’autofocus se montre faste comme peu d’autres, et le déclenchement franchement réactif. A confirmer, mais je devrais pouvoir faire sans soucis de la photo de rue ou évènementiel avec un tel compact.

Bien évidemment, cela ne fait que quelques semaines que je vagabonde avec mon X10. Le temps me dira si cet appareil est robuste et aussi fiable qu’il en a l’air. Gageons que dans le pire des cas, la marque ait démontré qu’il y a une véritable attente autour de ce créneau.

Lien : Site officiel Fujifilm X10

Mon dernier article laissait penser que je reprenais goût pour la programmation fonctionnelle, ayant apprécié mes études à bases d’OCaml. Depuis, j’ai effectivement eu l’occasion de jouer avec Scala, avec Haskell. Je ne suis pas spécialement un pro-FP ou un anti-POO, ni même l’inverse. Ce qui m’intéresse, ce sont les enjeux derrière chaque paradigme. Que vais-je pouvoir tirer de telle ou telle techno ? Au fond, qu’est-ce que je veux vraiment faire ?

Why learning Haskell/Python makes you a worse programmer ?

L’auteur évoque ses difficultés de revenir à la réalité, à la réalité du Python, du C#, du Java ou du C++ (pour les plus chanceux). Je vais dans ce billet donner mon point de vue. De la philosophie de la programmation fonctionnelle, je retiens notamment la gestion des listes et structures récursives, le pattern matching, l’immutabilité, les monades, la lazy-evaluation. J’en oublie, mais ce sont là les éléments que j’estime utiliser régulièrement, au naturel.

Sans prétention, la manipulation de ces concepts fait que le programmeur acquière une certaine gymnastique qui n’est — à mon sens — que bénéfique. Gestion de la concurrence ? Modularité ? Travail en équipe avec d’autres adeptes de la FP ? Du bonheur. Je ne parle pas spécialement de performances, mais seulement d’architecture logicielle.

Seulement voilà, dans la vraie vie, difficile de débarquer, imposer une industrialisation de Haskell ou d’OCaml. Difficile de dire à des développeurs ayant l’habitude d’imbriquer trois niveaux de boucles for ou while de réfléchir par récursion. Difficile de remettre en question les modélisations objets de projets industrialisés recoupant plusieurs dizaines ou centaines de développeurs, sous prétexte que de nombreux bugs pourraient être évités en appliquant des mécanismes d’immutabilité.

C’est bien là le problème. Renouer avec les fonctions impures à outrance (se dit des fonctions à effet de bord), les API approximatives de Java ou PHP n’est pas synonyme de plaisir. L’argument de la « démotivation » lancé par Luke sur son blog est réel. On écrit du code bizarre, rien n’est séduisant.

En revanche, j’estime que ça me force à comprendre comment le langage fonctionne, et à ne jamais faire confiance à son fonctionnement. En 2 mois de temps, j’ai appris un nombre impressionnant de choses sur Java, notamment sur sa gestion de la concurrence (faut-il que je me sente honteux de tout juste découvrir que le langage propose des CountdownLatch ?) En tout état de cause, c’est mon arme contre la démotivation.

Un compromis intéressant me semble émaner de Scala. Son interopérabilité parfaite (?) avec Java lui donne l’avantage instantané de participer à toutes les logiques d’industrialisation. Scala, pour rappel, est un langage multi-paradigme, qui aime la POO autant que la FP ou l’AOP. Un méli-mélo, vous dîtes ? C’est sans doute vrai. Et je n’aime pas les mélanges incohérents, vraiment pas. Mais en pratique, force est de constater que, pour le moment, c’est un moyen assez élégant de faire en sorte que chacun puisse y trouver son compte. Il m’est arrivé, par exemple, de parcourir un graphe en Scala et d’appliquer un traitement en une ligne de code, via le paradigme map/reduce (mais pas distribué, cette fois-ci). Scala peut également obliger les développeurs à formaliser leurs types de retours en Option[Integer] si la fonction peut retourner l’équivalent de null ; tout en conservant la possibilité d’écrire des boucles itératives aux moments opportuns, ou de modéliser ses concepts sous formes de classes, sans rien changer — ou presque — des habitudes prises en Java.

Oh, et tant qu’on en parle, je vous invite à lire le billet de Marwan sur la FP. C’est aussi un élément déclencheur de cet article.

Non mais sérieusement, vous trouvez ça pratique, vous, de signer au dos de la carte bleue ? Vous utilisez quoi comme stylo ? Je n’arrive jamais à trouver un stylo correct qui ne bave pas. C’est absolument inutilisable. Stylo à bille, gel, crayon de papier, stabilo rose… rien.
On est en 2012, ne peut-on vraiment pas faire mieux ?

Un tel snippet semblera peut-être quelque peu ambitieux pour ceux qui ne jurent que par la programmation impérative. PHP, Java, C++ et consort. C’est pourtant une ligne parfaitement valide en Haskell. Bienvenue dans l’univers de la programmation fonctionnelle. On ne gère plus des changements d’états, mais des évaluations de fonctions.

Des bouquins

C’est un univers que j’avais découvert avec OCaml durant mes classes prépa, et voilà que je replonge dedans. La « faute » à un excellent bouquin, « Hasard et complexité en mathématiques », écrit par Grégory-J Chaitin, le découvreur du nombre oméga « Ω » – mon nombre préféré, mais ce n’est pas le sujet ici.

Dans son ouvrage, Grégory Chaitin avoue son amour sans nom à Lisp, un des plus anciens langages apportant le paradigme de programmation fonctionnelle. Un amour qu’il a ma foi su fort bien communiquer puisqu’il ma donné envie de remettre en questions mes développements actuels.

J’étais assez rebuté par la lisibilité du code en Lisp et après pas mal de lectures auxiliaires, je découvre à quel point Haskell est séduisant autant dans ses concepts que dans sa syntaxe. Gérer des ensembles infinis, ou des nombres à précision potentiellement infinie n’est sans doute pas une situation que tous les développeurs rencontrent tous les jours, mais c’est toujours source de nombreux problèmes dès que le cas fait surface. Ceux qui aiment les problématiques de typage seront ravis d’apprendre que Haskell est, parait-il, muni d’un système de typage à toute épreuve. J’aurai sans doute l’occasion de vous en dire un peu plus une fois mon apprentissage approfondi. Toujours est-il que j’ai commandé au monsieur tout-en-rouge le livre de la collection d’O'Reilly :

Voir sur O’Reilly

Un autre langage, qui fait sans doute plus parler de lui : Scala. Comme OCaml, il est multi-paradigme. Utilisé notamment chez Twitter, LinkedIn, Foursquare ou d’autres grands noms de la toile, on peut sûrement expliquer cette nouvelle popularité par son interopérabilité avec Java. Le langage fonctionne en effet tout aussi bien sous forme de scripts que de bytecode compilé à destination de la JVM, et il est en ce sens possible – et aisé – d’exécuter du code Java depuis Scala. Sans avoir encore trop farfouillé, j’ai tout de même l’impression que l’approche est assez différente de ce qu’on retrouve en Haskell ; j’ai ainsi constaté que beaucoup de codes ne pouvait s’offrir le luxe de faire l’impasse sur le cas des valeurs null. Peut-être du travail à faire du côté des monades ? J’en saurai sûrement davantage après une vraie découverte du langage et une lecture approfondie de cette autre idée cadeau :

Voir sur O’Reilly

Pourquoi quitter le monde impératif ?

Pourquoi un attrait si soudain pour la programmation fonctionnelle ? Pourquoi devriez-vous essayer, à votre tour, de voir autrement vos suites de 0 et de 1 ? En ce qui me concerne, le livre de Grégory Chaitin fut le véritable élément déclencheur, mais c’est aussi le désir de remettre plein de choses en question, de continuer à se maintenir éveillé sur ce qui se fait de nouveau (Scala), et peut-être de reprendre davantage de plaisir à développer en utilisant de nouvelles approches lorsque cela est nécessaire.

Je suis par exemple régulièrement amené à développer de nouveaux outils statistiques (des simples moyennes arithmétiques ou harmoniques aux matrices de covariance) et il n’est pas rare d’observer que le langage fait parfois partie integrante du problème que de la solution, pour reprendre l’expression de certains auteurs : dépassement de capacité des types integer et assimilés ; jonglage fréquent entre types signés, non signés, flottants ; impossibilité de redéfinir l’opérateur « + » dans certains langages, etc.

Je ne sais pas vraiment ce que j’attends de la programmation fonctionnelle dans mon usage quotidien, ou si Haskell sera strictement supérieur à Scala dans mon cas ou s’il sera juste un complément pertinent. Des concepts tels que les flèches me laissent penser que mes systèmes hautement concurrents pourraient s’en retrouver un peu plus concis et formels qu’avec les actuels langages impératifs. Alors, je vous donne rendez-vous pour de prochains billets pour de nouvelles critiques !

Je n’écris plus beaucoup, et j’en suis le premier désolé. Frustré. J’aime écrire, mais le temps me manquait, les préoccupations étant ailleurs ces derniers temps. Mais certains commentaires m’ont re-motivé au plus haut point, alors je vais tenter de reprendre l’exercice, en douceur.

Pour ce premier nouvel article, j’aimerais reprendre quelques points sur Hadoop, le géant des systèmes distribués, et adopter ici une nouvelle orientation, plus orientée « revue de presse ». Il y a de la littérature formidable sur Internet, et plutôt que chacun ne perde son temps à se perdre dans les dédales des blogs et e-magazines, je vous propose des rapides résumés et ressentis.

« Hadoop Doesn’t Solve All Problems (lien) »

est le nom de l’article qui a suscité mon attention. Ces dernières semaines, à plusieurs reprises, j’ai pu entendre LA question : « est-ce qu’Hadoop me permet de faire ceci, cela ?« . La publication des exploits d’eBay et autres géants a certainement contribué au succès grandissant d’Hadoop. Néanmoins, il ne faut pas oublier que l’utilisation en production de la plate-forme libre de « Big-Data » au sein de ces entreprises se fait en connaissance de cause.

Tout d’abord, Hadoop tout seul ne répond pas à tous les besoins, et la plus-value se situe sur l’ensemble de l’éco-système. Il faut penser la plate-forme dans son intégralité. Les motifs d’accès aux données ou les calculs à effectuer peuvent influer sur la manière dont seront organisées les données et sur les outils environnants : faut-il stocker des résultats dans une grille analytique ? Dois-je privilégier une approche par flux ou par batch ?

Après Google, Hadoop a complètement démocratisé le Map/Reduce, ou comment effectuer de puissants calculs sur des petabytes de données. Encore faut-il savoir écrire de tels calculs. J’ai eu plusieurs fois l’occasion d’observer des jobs mal pensés, mal définis. La nature de Map/Reduce se prête mal à certains calculs sur des graphes géants comme certains algorithmes de recommendations par exemple, comme mentionné dans l’article (un petit tour du côté de Pregel s’impose…). Mais la non-maîtrise du style fonctionnel de Map/Reduce n’est pas seule la raison des lenteurs ou de le non-utilisabilité du cluster. La mauvaise maîtrise d’Hadoop lui même peut mener à la catastrophe.

Celui qui n’a pas compris que le namenode est source de SPOF, ou qu’un Combiner bien écrit est parfois utile pour limiter le I/O, se rendra vite compte que « Hadoop ne résout pas tous les problèmes ». De même, la connaissance des problèmes « de base » de l’informatique répartie — coût des transmissions vs. coût des calculs, synchronisations, etc. — me semble inévitable pour concevoir une plate-forme pérenne. Maîtriser son architecture technique et chacune des briques me semble bien plus important qu’arriver à écrire des jobs Java pour Hadoop.

Mais en attendant, je vais ici relater mon premier bout de code un petit peu « tricky ». Python propose un lot de méthodes pour accéder aux répertoires/fichiers : os.listdir, walk… Mais ces méthodes ont le défaut de retourner une liste construite des éléments. Du coup, lorsque le temps de traitement devient critique, on aimerait bien pouvoir itérer directement sur les descripteurs de fichiers sans attendre une liste de potentiellement 10 000 éléments. Bref, la possibilité d’accéder aux fonctions Posix opendir() et readdir().

Le soucis ? Python ne propose pas ces fonctions. Mais il y a la possibilité d’accéder à des API du langage C, et dans un environnement Unix, on y retrouve nos chères fonctions si convoitées ! Après avoir étudié cette piste, voilà un snippet fort utile :

#!/usr/bin/python
from ctypes import CDLL, c_char_p, c_int, c_long, c_ushort, c_byte, c_char
from ctypes import Structure, POINTER
from ctypes.util import find_library

class c_dir(Structure):
    """ Defined C struct DIR """
    pass

class c_dirent(Structure):
    """ Directory entry structure equivalent """
    _fields_ = (
        ('d_ino', c_long),  # inode number
        ('d_off', c_long),  # offset to the next dirent
        ('d_reclen', c_ushort), # length of this record
        ('d_type', c_byte),  # type of files; os specific
        ('d_name', c_char * 4096) # filename
        )

c_dirent_p = POINTER(c_dirent)
c_dir_p = POINTER(c_dir)
c_lib = CDLL(find_library("c"))

opendir = c_lib.opendir
opendir.argtypes = [c_char_p]
opendir.restype = c_dir_p

readdir = c_lib.readdir_r
readdir.argtypes = [c_dir_p]
readdir.restype = c_dirent_p

closedir = c_lib.closedir
closedir.argtypes = [c_dir_p]
closedir.restype = c_int

def listdir(path):
    """
    A generator to return the names of files in the directory passed in
    """
    dir_p = opendir(".")
    try:
        while True:
            p = readdir(dir_p)
            if not p:
                break
            yield p.contents.d_name
    finally:
        closedir(dir_p)

Attention, listdir() retournera les répertoires « . » et « .. » ! Notez l’utilisation du yield pour définir ici un générateur (sujet d’un autre article). De ce fait, notre fonction s’utilise comme cela :

if __name__ == "__main__":
    for name in listdir("."):
        print name

En espérant que ça puisse servir à quelqu’un d’autre…

Alors que l’on parle plus que jamais de casino en ligne, de paris sportif, poker ou des fameux « bonus » de casino sans dépôt, l’été dernier a été pour moi l’occasion de retourner de l’autre côté de la barrière. L’occasion de collaborer à nouveau avec mon ancien (excellent) employeur en matière de gambling. La mission qui m’était confiée était la suivante : partager mes expériences en matière de QA pour les projets PHP, et sensibiliser/développer tout un lot de bonnes pratiques auprès de l’équipe technique en place.

Pour formaliser un peu le périmètre, ces 2 mois devaient permettre de dérouler un état de l’art des tests unitaires, fonctionnels, de performances, sur l’intégration continue et les bonnes pratiques de développement « modernes » appliquées au PHP.

Ma plus grosse crainte était résolument celle de voir ces pratiques rejetées, jugées « inutiles », ou « trop lourdes » à appliquer au quotidien. Je savais que j’avais alors 2 mois pour démontrer tout l’intérêt de ces pratiques, pour prouver que les métriques de phpcs, phpcpd ou phpunit étaient bien plus que des simples chiffres.

L’approche

Mon approche fût la suivante : adapter chaque point au cas précis des développeurs de l’entreprise, et les impliquer le plus tôt possible dans un processus « d’auto-formation », pour assurer une pérennité à la politique qualité, une fois ces 2 mois – à mi temps – terminés. Craignant des rejets du type : « les tests, c’est pas pour nous ! », je me suis efforcé de résoudre TOUS les problèmes qui pourraient m’être posé. L’exemple le plus concret concerne un refactoring de classes PHP. L’une d’entre elle mélangeait logique métier, logique d’accès aux données, logique utilisateur… L’argument avancé était que le code devait être comme cela, que ça avait été pensé et que finalement, ça marchait très bien.

Sans forcément rejeter cette idée (après tout, un code qui marche, c’est déjà beaucoup de nos jours !) j’ai accordé le temps qu’il fallait au problème en décortiquant chaque ligne. Après avoir expliqué ma méthodologie (qui en est une à peu près standard parmi tant d’autres), on obtenait un code iso-fonctionnel, mais :

• avec des portions beaucoup plus courtes
• beaucoup plus facilement testable
• plus ordonné par « logiques », au lieu d’emboîter des appels procéduraux
• et donc, plus facilement maintenable

Je pense que cet exemple concret a été le déclencheur sur la prise de conscience de la part de l’équipe. L’exemple qui a montré que le changement n’est pas impossible, et, mieux encore, peut être pas si coûteux que  ça en temps s’il est fait rigoureusement.

Des acteurs impliqués

Une fois la théorie abordée et l’exemple donné, j’avais dédié une partie à la « pratique » collaborative. Les mains dans le cambouis, comme on dit. Des micro-tâches étaient assignées entre les différents développeurs, afin qu’ils s’approprient les outils et différents outils, et intégrer les bons réflexes. Ajout d’une nouvelle métrique à Hudson, modification d’un test unitaire, relecture du code d’autrui, consultation de la documentation… Autant de minutes dépensées à bon escient.

La finalité

J’ai oublié de vous dire : c’était ma première vraie expérience en « formation ». Je ne peux me targuer d’avoir 10 ans d’expérience en QA ou en pédagogie, mon but était d’apporter mon regard et de partager ce que je savais. Le pari est apparemment réussi. Les 2 points clés (exemple concret autour des besoins réels et implication des acteurs) ont l’air d’avoir porté leurs fruits. La plate-forme d’intégration continue fonctionne… en continue. Voilà 2 mois bien rentabilisés !

Pour rappel,  Sebastian avait eu pas mal de plaintes d’utilisateurs réclamant la disparition du $this pour effectuer les différentes assertions.

Source

Cela fait maintenant quelques temps que je donne plus de nouvelles, plus un signe de technologie, de recherche. Et pourtant, de la recherche, il y en a eu ! Après avoir passé une longue période à essayer les différents outils de QA dédiés au web, j’ai passé ces derniers mois à essayer – et exploiter – les NoSQL. La littérature est déjà bien large sur le sujet dans ses généralités. Cassandra, HBase, Voldemort, Redis… tout y passe, du plus ancien dépôt clé/valeur au plus évolué système orienté graphe ou document. Je vais parler ici finalement de MongoDB, que j’ai pu torturer en long, en large et en travers, et qui appartient justement à la catégorie des NoSQL orienté document.

Un NoSQL, pourquoi ?

Certainement pas par effet de mode. Une prise de décision basée sur ce critère ne serait que folie. Par besoin ? Il va être temps de définir ces besoins. Car on assiste à bon nombre de projets qui tendent à délaisser ces bons vieux SGBDR au profit de leurs cousins non-relationnels. Or, la plupart de ces projets ont – selon moi - surtout un problème de conception et non d’outils. Si ces projets reprochent à MySQL une certaine lenteur, ils feraient bien mieux d’apprendre à tirer profit d’une configuration optimale, et d’une conception sérieuse du modèle de données, avec une stratégie d’indexation adaptée. On ne le dira jamais assez : des bases comme MySQL, PostgreSQL ou autre ont perduré pendant des années. La réplication est fonctionelle. Le partitionnement est possible. Les plus gros l’ont utilisé et continuent à l’utiliser. Twitter avoue même rester sur MySQL après avoir essayé timidement de mettre en place Cassandra. Non, pour moi, une des raison qui peut pousser à envisager une solution NoSQL est ailleurs. La grosse plus value de ces solutions reste toujours leur très bonne disposition à « scaler ». Autrement dit, si on souhaite absorber un déluge de données croissant, on y trouvera un allié puissant pour rapidement doubler, quadrupler la puissance de stockage, sans se lancer dans une trop lourde configuration du partitionnement et/ou de la réplication.

Orienté document, pourquoi ?

Comme d’habitude, nuançons ce point de vue par un autre apport, mais celui-ci est propre au modèle de stockage choisi. On en dénombre 4 :

• dépôts clé/valeur (Voldemort, Redis…)
• orientés colonne (Cassandra, HBase…)
• orientés documents (CouchDB, MongoDB…)
• orientés graphes (Neo4J…)

Chaque modèle répond à des problématiques et stratégies de stockage différentes. MongoDB stocke des « documents ». Un document est un ensemble de paires clé/valeurs, ici décrites au format BSon. Ce format est largement comparable au JSon, modulo quelques types additionnels.

{
blog: http://www.zt.com,
authors: [adrien, robot],
comments:
[
{ author: robert, age: 42 },
{ author: johanna, age: 25 }
]
}


Voolà donc typiquement ce qui peut être stocké dans une collection (= table) MongoDB. Ce stockage est dit « schemaless », traduire par « sans schéma ». Les documents ne correspondent à aucune définition formelle qui aurait été préalablement définie. Ainsi, on pourrait très bien rajouter un autre document « blog » similaire à l’exemple, mais sans champs « authors » et avec une colonne « keywords ». le NewYorkTimes tire partie de ce modèle avec MongoDB en permettant à ses contributeurs d’ajouter des méta-données à la volée pour chaque photo soumise. En effet, on ne retrouve pas forcément les même méta-données entre une photo de lieu et celle d’une star. Certes, la chose reste largement faisable avec les outils actuels. Le modèle document est juste extrémement adapté à ce type de stockage, sans s’occuper d’un modèle relationnel et ses multiples contraintes. Je sais, je viens de donner un argument qui pourrait remettre en cause le premier : certains NoSQL ont un rôle qui dépasse de loin celui d’un entrepôt extensible et redondé.

MongoDB, pourquoi ?

Voyons maintenant le cas particulier de MongoDB. C’est un NoSQL orienté documents, qui se qualifie par l’acronyme « CP » du théorème de CAP.

1) Langage de requêtage intuitif

Tout naturellement, lorsqu’on essaye un système de stockage, nos premiers essais se tournent vers l’insertion et la récupération de données. Pour l’insertion, nous venons de voir qu’elle s’effectuait au format BSon. Concretement, après avoir lancé le shell MongoDB, la commande suivante effectuerait une insertion dans une collection  »test » :

db.test.insert({« name »: « Adrien »});

Et pour requêter nos collections, cela s’effectue également tout naturellement au format BSon ! MongoDB fournit un certain nombre d’opérateurs classiques : >, <, =, >=, IN, NOT IN, etc. Quelques exemples :

# Tous les utilisateurs "toto"
db.test.find({"name": "toto"});

# Les 3 premiers "Adrien", ayant plus de 23 ans, triés
db.test.find({"name": "Adrien", "age": {$gt: 23}}.sort({"age": -1}).limit(3);

C’est en général le premier point qui ressort de MongoDB par rapport à la plupart de ses rivaux. Son système de requêtage séduisant permet une prise en main extrémement rapide.

2) Auto-sharding

Venons en maintenant à ce qui fait normalement tout l’attrait des NoSQL : leur forte extensibilité et leur mécanisme de réplication. MongoDB offre des possibilités de sharding (partitionnement) afin de distribuer les données au sein de plusieurs  »shards » (bloc venant constituer le cluster, et ne possédant qu’une partie des données). L’auto-sharding reste aujourd’hui (version 1.5.3) en version beta, mais il est possible tout de même de spécifier ses propres pattern de sharding. Par exemple, on peut décider que le champs « name » de nos exemple deviendra une clé de sharding. Il est possible, à l’instar des indexes, de spécifier des clés composées de plusieurs champs. MongoDB calculera un hash de ces clés pour déterminer sur quel shard envoyer tel ou tel document. La configuration du cluster et toutes ses méta-données sont stockées au sein de « serveurs de configuration ». En production, trois serveurs de ce type sont normalement configurés. Si un de ces serveurs tombe en rade, le système continue de fonctionner normalement. Si deux de ces 3 serveurs montrent un dysfonctionnement, le dernier serveur de configuration devient accessible en lecture seulement. Ceci n’empêche pas le cluster complet de fonctionner, mais empêche toute modification de la configuration, et tout déplacement de « chunks » (position des blocs de données, qui est elle aussi stockée dans ces serveurs de configuration).

3) Replica pair, replica sets

Chaque shard peut actuellement être redondé par ce qu’on appelle un système de  »replica pair » : le shard est constitué d’un master et d’un slave. À tout moment, si le master tombe en panne, le slave prend le relai. Les données peuvent être répliquées instantanément ou avec une certaines latence dans le cas d’un système dit « finalement consistant ». Cette paire est bien limitée actuellement en matière de fail-over et laissera place aux « replica sets » avec MongoDB 1.6, qui laissera la possibilité de plus de 2 serveurs de sauvegarde. Dans cette nouvelle situation, en cas de panne du master, l’élection du slave qui deviendra master se fera par la résolution d’un consensus basé sur la disponibilité de chaque noeud, le nombre de serveurs vus par chacun, etc…

4) Map/Reduce

L’algorithme Map/Reduce a le vent en poupe depuis les papiers Google et l’implémentation Hadoop. Et devinez quoi ? MongoDB, à l’instar de CouchDB, offre des possibilités d’interrogation en Map/Reduce. Dans un environnement « shardé », les requêtes sont en effet ciblées ou globales (parallèles ou séquentielles). Pour effecter un certain nombre de calculs efficacement, MongoDB permet l’écriture de fonctions map() et  reduce() – et finalize() – en javascript. Les résultats peuvent être stockées dans des collections temporaires pour conserver un cache des résultats.

5) Autres fonctionnalités

En fait, il y a trop de choses à raconter sur MongoDB. Je vais faire un bon petit lot de petits articles pour détailler chaque point, mais pour ce soir, il faudra se contenter d’une découverte rapide :

• Un moteur d’indexation géographique, que Foursquare utilise à outrance
• Une indexation en background
• Des capped-collections, collections de tailles fixes auto-gérées pour ne conserver que les X derniers éléments insérés (fonctionnement par TTL prévu pour les futures versions)
• Profiling des requêtes
• Interface REST

Conclusion

MongoDB est la solution qui actuellement suscite le plus ma curiosité, et surtout mon intérêt, tant pour ses performances que pour sa conception et ses fonctionnalités. Son plus gros défaut actuel est sa grande jeunesse. Gageons qu’une fois l’auto-sharding et les replica-sets 100% fonctionnels, 10 Gen Confluence arrivera à mettre en place une architecture composée de 1000 shards, son objectif actuel.