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.

• Les NoSQL (Cassandra, HBase, MongoDB…)
• Parallèlement, les systèmes distribués (Hadoop, Gearman…)
• MariaDB
• Les produits Talend
• Les outils de qualité logicielle open-source (Hudson, PHP Under Control…)
• Le framework symfony, toujours et encore

Comme l’objectif de Ze-Technology n’a jamais été d’écrire des articles superficiels et sans intérêt, je souhaite avoir un minimum de recul sur chacune de ces technologies avant de pouvoir écrire quoi que ce soit d’intéressant (ou d’inintéressant, vous en jugerez !). Je tombe bien chaque jour sur des dizaines de liens tous plus passionnants les uns que les autres, mais ce blog ne peut se résoudre à devenir une simple liste de liens. Cher public, vous qui m’aimez, la  caisse attend votre générosité un peu de patience…

Il y a eu toutes sortes d’expériences autour du réseau social qui fait tant parler de lui. Je vous en propose une nouvelle. Mon but était d’établir un état des lieux des comportements des utilisateurs envers une demande d’ami inconnu. Le procédé fût fort simple : la première étape fût la création d’un compte d’un personnage complètement fictif et inconnu, qu’on appellera Jean-Claude. Suite à ça, ce sont quelques 250 personnes qui ont été sollicitées pour faire partie du réseau d’amis. 250 personnes de toutes origines, tous pays, sélectionnées complètement aléatoirement.

Une semaine plus tard, les résultats sont là. Il y a déjà 119 personnes qui se sont déclarées ami(e)s avec mon Jean-Claude. Sur ces 119 individus, seulement 6 ont envoyé un message pour connaître mon identité. Après avoir répondu, 2 m’ont retiré de leur liste d’amis. Jean-Claude aurait donc 113 personnes qui le connaissent vraiment ? En tout cas, Jean-Claude a accès à toutes les informations de ses amis : photos, statuts, quizz, etc.

Des conséquences qu’à titre personnel, je considère désastreuses. Ok, je ne suis pas mal intentionné. Mais qu’en savent ces « amis » ? De même, rien ne semble m’empêcher de dresser une liste d’habitudes, de comportements. Ces problèmes de confidentialité ne sont pas nouveaux, je ne vais les déballer ici, mais ce qui m’intrigue surtout au plus haut point, c’est cette facilité déconcertante de rentrer dans le cercle de connaissances de n’importe qui. Une sensibilisation des utilisateurs ne ferait de mal à personne…

Comment augmenter sa productivité ? Celle de ses employés ? C’est une question à laquelle un peu tout le monde s’attache ou du moins peut s’attacher.  Il y a des pistes purement organisationnelles (méthodologie – Scrum a le vent en poupe -, hiérarchie dans l’entreprise, workflow général…) mais un certain nombre de petites choses peuvent venir agrémenter le quotidien d’un travailleur. D’un point de vue très général, j’identifierai :

• Changer le volume de la musique (fond sonore, « fort », son coupé…)
• Changer le type de musique (relaxante, variété, « hard »…)
• Changer souvent de position (très droit, avachi…)
• Changer de temps en temps les postes de travail : leur position, l’orientation
• Modifier les affiches / photos sur les murs

Autant de modifications qui peuvent paraître extrêmement anodines mais qui tiennent constamment l’esprit en alerte. Sans jouer au neurologue expert, le cerveau identifie inconsciemment un changement et relance l’attention, la créativité. En dehors de ces dispositions inhérentes au poste de travail, on peut s’attaquer à l’outil de travail en lui même. En prenant le cas – fréquent – d’un intranet fréquemment consulté par les employés, on pourrait ainsi imaginer un changement, global ou mineur, de l’apparence de cet intranet.

Des changements menés à bien

Effectuer des changements sur un outil de travail est un art qui s’il est manié sans précaution peut très vite venir semer la zizanie. Un bouton déplacé, un champ qui n’apparaît que dans certaines conditions, des menus ré-organisés… voilà de bien bonnes manières de diviser par 2 la productivité !

Bien que des choses comme ITIL existent pour aider à mener à bien ce genre de changement, je ne souhaitais évoquer ici que les modifications purement visuelles, sans engendrer un seul impact fonctionnel. Changer les couleurs du bandeau principal, mettre un fond aux couleurs de noël ou d’halloween, faire jaillir de l’écran une photo « volée » qu’un employé souhaitait partager (attention aux dérives !) autant de petites modifications qui peuvent venir casser le train-train des employés manipulant constamment l’outil et se lassant du jeu de couleur bleu et blanc. À condition, bien sûr, d’avoir un outil un tant soi peu personnalisable.

Pour quel impact ?

Encore une fois, c’est une question qui obtient une réponse au cas par cas. Il y aura certains employés qui souhaiteront qu’une habitude ne soit JAMAIS cassée (jamais de musique, ne jamais changer de poste de travail, etc.) et qui ne manqueraient pas de vous le faire savoir, j’en suis certain. Ce billet n’est qu’une réflexion personnelle après une petite analyse introspective de mon comportement, corrélée avec une observation effectuée sur l’ensemble de la population estudiantine comme professionnelle que je peux côtoyer jour après jour.

1) Dans la listes des activités de l’association, on a ainsi le droit à :

• Inspection de la poubelle Albanel
• Gratter le sol avec une brosse à dents
• Epluchage des bludivions à cardans lisses
• Achats des bludivions à cardans lisses
• Vente de yoyos lumineux
• Jouer à Team Fortress 2

2) Parmi les membres :

• Kopter Elie
• Leventreur Jacques

3) Avec des statuts plutôt flatteurs :

• Dieu
• Dieu de tous les Dieux

4) Et enfin, de curieuses dépenses :

• Achat de cannabis
• Pot de vin
• Paiement des alpha-beta testeurs

Mais qui dit vacances dit retour, et dès la rentrée, c’est partie pour…

• De nouveaux « liens de la semaine »
• Des articles et tutoriels sur symfony, PHP
• Des news du côté d’eZ Systems
• Des nouvelles astuces photographiques
• L’évolution du marché de l’Open Source en France et sur la Terre

Mais en attendant tout cela… je vous souhaite de bonnes vacances.

L’excellence de l’Olympus PEN E-P1, sur Digit’Life

Un gros compact, un mini bridge/reflex bien énervant. Énervant pour la concurrence.  Énervant pour tous les modèles qui voient arriver un concurrrent hors-norme. Ce modèle d’Olympus pourrait bien être LE compact que tous les pros attendaient, un compact format 4/3 à objectifs interchangeables, à la manière des reflex.
[source]

Le tour du mois en PHP (juin 2009), par Pascal Martin

L’actualité de PHP fût bien riche durant le mois de juin dernier. Sortie de PHP 5.3, 14 ans du langage de l’éléPHPant, conférences… Pascal Martin revient sur les dernières informations avec concision et intérêt.
[source]

Notification par mail lors d’erreurs symfony, sur Clever-Age

Le méchanisme de gestion d’erreurs que propose symfony est assez complet et permet de manipuler efficacement les différentes exceptions qui pourraient survenir. Clever-Age nous propose ici une manière d’exploiter ce méchanisme pour être systématiquement prévenu des erreurs par mail.
[source]

Présentation de Mozilla Weave, par Pti-Seb (Tux Planet)

La fondation Mozilla a présenté fièrement son produit Weave, destiné à partager efficacement ses données personnelles entre plusieurs installations de Firefox : bookmarks, historiques, mots de passe… tout peut maintenant être centralisé et partagé grâce à la solution Weave. Tux Planet vous explique les intérêts, le fonctionnement et l’utilisation de ce nouveau projet made in Mozilla.
[source]

Ce qui est amusant, c’est de constater à quel point la formation d’ingénieur, intégrant une bonne partie de gestion de projets, peut s’avérer utile pour organiser de tels évènements. En quoi ça peut bien servir ? Quelques éléments de réponses :

• Identification et prévention des risques
• Gestion du temps
• Budgetter correctement la soirée
• Gérer efficacement les effectifs (déléguer des tâches…)

Après cette bonne semaine d’organisation, de réalisation puis de rangement, attendez-vous à retrouver un espace à nouveau vivant.

• C’est plus court à taper
• Meilleur référencement
• Identité propre, sans rattachement à Blogger
• Caprice

Bon, en fait, je vous cache la vraie raison. C’est que je ne compte pas rester éternellement sous la plate-forme Blogspot. Elle est rapide, sympa, relativement fonctionnelle, mais il lui manque plein de choses. À commencer par un éditeur digne de ce nom !! La possibilité de vraiment customiser certains widgets. Et surtout, chose très frustrante pour un développeur, la possibilité d’afficher du code de manière lisible, avec un minimum de coloration syntaxique !

Bref, tout ça pour vous dire que d’ici peu, il y aura sûrement ENCORE du changement. Mais dans la forme, pas dans le fond. Mettez à jour vos favoris. Mais si vous oubliez de le faire, le blog actuel sera automagiquement redirigé vers le nouveau. Au fait, pour ceux que ça intéresse, le domaine a été acheté chez Drim, pour 6 euros par an.

Votre serviteur, qui adore détester changer.