OCTO talks ! » NoSQL

Une base de données purement fonctionnelle

Sebastian de Bellefon — Tue, 31 Jan 2012 09:24:44 +0000

Le modèle relationnel est né à une époque où l’espace était rare, et fut donc conçu pour minimiser le niveau de redondance des données: il était plus économique de stocker une indirection vers une chaine de caractères que de stocker cette chaine deux fois.
Aujourd’hui, cette contrainte d’espace ne tient plus. On achète un Teraoctet pour 100 dollars, la RAM est abondante, et les disques flash aux performances élevées vont bientôt rejoindre le prix des disques durs rotatifs.

Deux limitations fondamentales du stockage ont donc disparu: le coût de la redondance et le coût de la non-localité pour le traitement de structures de données complexes. Il est maintenant possible de concevoir de nouvelles bases de données plus riches et plus sûres.

Update in place is a poison apple.
- Jim Gray, Turing Award 1998

Le choix d’une base de données mutables n’est plus optimal. Les bases de données purement fonctionnelles n’existent pas encore, mais je pense que les utilisateurs de bases de données auraient déjà intérêt à envisager le stockage read-only et le versioning manuel.

Que veut-on dire par « base de données mutables »? Il s’agit d’une BDD dans laquelle chaque donnée peut être modifiée à tout moment, et dans laquelle on ne garde pas l’historique de ses modifications. Les modifications sont faites « sur place », de manière destructive.

Que veut-on dire par « base de données purement fonctionnelle »? Il s’agirait d’une BDD dans laquelle chaque structure de donnée serait purement fonctionnelle, c’est-à-dire immuable par défaut et ne ferait référence qu’à des données immuables. Pour prendre une analogie programmatique, cette BDD serait une interface vers des snapshots versionnés. Une sorte de Git!

Vers une implémentation plus adaptée

Les données d’une BDD méritent un traitement différencié en fonction de leurs patterns d’usage. Pourquoi par exemple, chez un grand opérateur téléphonique, devrait-on utiliser le même objet « table » pour référencer les monnaies, gérer la liste des clients et la liste des appels? Examinons leurs particularités. A partir de ces trois exemples simplifiés nous allons inférer plusieurs mécanismes fondamentaux d’une base de données purement fonctionnelle.

La liste de référence des monnaies est peu volumineuse. Elle est mise à jour quelques fois par an, tout au plus.
La liste des clients de l’opérateur est moyennement volumineuse. Elle est mise à jour quotidiennement, avec quelques ajouts, suppressions et modifications aléatoires.
La liste des appels est très volumineuse. Elle est mise à jour quotidiennement, mais seulement en insertion.

Nous avons donc au moins trois cas d’usage très différents. Or dans une BDD classique, ces trois données sont stockées de la même manière, c’est-à-dire sous la forme de listes mutables et indexées.
Beaucoup d’effort a été investi pour améliorer les performances de ces tables avec le matériel donné, mais les solutions proposées sont encore très génériques.

Revenons à nos trois données. Il est possible de les implémenter autrement, en faisant appel à trois types d’objets:

Des listes immuables (de type homogène, et implémentées par exemple par des hashtables sur la clef primaire)
Des deltas sur ces listes
Quelques métadonnées peu volumineuses qui serviront à articuler l’ensemble.

La table des monnaies est l’exemple typique d’une liste simple et immuable. La liste d’aujourd’hui s’appelle la ‘v1′. Si demain une union monétaire est créée en Amérique du sud, nous créerons une copie modifiée qui s’appellera la ‘v2′. Pour des raisons de performance, la v1 et la v2 devront être copiées intégralement sur tous les noeuds de la base de données. La performance en update de cette implémentation est médiocre, mais toutes les lectures pourront être faites sans aucun mécanisme de synchronisation.

La table des clients est un peu plus volatile. Tous les jours quelques clients arrivent ou s’en vont, et quelques clients existants peuvent modifier leur adresse postale. Nous pouvons stocker la liste des clients comme une liste immuable ‘v1′, accompagnée par une séquence chronologique de deltas. D’ici à quelques mois, l’accumulation des deltas commencera à affecter la vitesse de lecture: il faudra alors matérialiser la liste, la nommer ‘v287′ et archiver la v1. Dans le cas d’une machine seule, nous retrouvons presque exactement la manière dont Git stocke son historique. Dans le cas d’un cluster, il est bien sûr préférable de partitionner/sharder cette liste sur tous les nœuds.
Selon quelle politique va-t-on vouloir archiver une version, la compresser ou la supprimer? Et selon quelles modalités? Chaque utilisateur doit prendre cette décision en fonction de ses besoins métier. Il est agréable, en tout cas, de remarquer que le Data Lifecycle Management est offert sur un plateau par les BDD fonctionnelles.

La table des appels téléphoniques est différente. Chaque jour elle reçoit des milliers de nouvelles lignes, lesquelles sont parfaitement indépendantes des lignes antérieures. Cette liste est segmentable par journée, et chacun des segments quotidiens est une liste immuable. Nous devrions en plus partitionner chaque segment de manière à coller à la liste des clients: l’ID du client devient alors la clef de partitionnement des appels téléphoniques.

En résumé, à travers ces mécanismes de mise à jour, on accepte de consommer un peu plus d’espace disque, et de réduire la localité des données (car une nouvelle version ne sera probablement pas écrite à côté de l’ancienne). Tout cela pour garder une information plus riche.
Remarquez bien que ces trois idées de versioning s’appliquent aussi bien à l’implémentation d’une nouvelle base de données qu’à une implémentation manuelle, basée sur les outils d’aujourd’hui.

Conséquences

Voilà pour les bases. Observons maintenant les conséquences positives de ces nouveaux choix d’implémentation.

Il devient possible par exemple:

d’attribuer un identifiant unique à une version complète de la BDD, donc d’exécuter des requêtes de lecture sur une version du passé
d’effectuer un rollback à tout moment, en reprenant une ancienne version. Pas besoin d’attendre des heures pour recharger!
de paralléliser le requêtage à l’infini (car les listes immuables et les deltas sont triviaux à copier)
de hasher cryptographiquement le contenu (à la Git), pour un usage légal ou contractuel
de connaitre la séquence des processus qui ont fait évoluer la base ou une ligne en particulier
de diminuer le coût du backup et du Plan de Reprise d’Activité. Réaliser trois copies vers des disques sur étagère coûte peu (car les deltas sont copiables via des écritures non-aléatoires, donc rapides, et sans consommer de CPU)
de cacher le résultat de toute sorte de traitements, à la manière de vues matérialisées (filtrage, agrégation..)
de stocker dans la même BDD des objets classiques relationnels, et des objets plus variés (key-value store..)

En l’absence d’ « état global », nous offrons aux processus d’alimentation et d’interrogation de la BDD tous les bénéfices de la programmation purement fonctionnelle. Ces processus deviennent référentiellement transparents (donc sans effet de bord), d’où une meilleure lisibilité pour les équipes de développement et de maintenance, et une diminution du risque d’erreur. De plus, nous avons la garantie que l’ordre d’exécution des processus n’a plus aucune importance.
La qualité de transparence référentielle nous aide aussi à implémenter proprement le pattern Command-Query Separation (CQS), qui conseille de séparer les processus de requêtage des processus d’écriture. Les nombreux « lecteurs » opèrent sur des données immuables, éventuellement disséminées dans un cluster, alors que le processus « modificateur » agit sur les données de référence pour leurs ajouter des deltas.

Quelles sont les contreparties? Il devient plus couteux de réaliser de nombreuses modifications aléatoires sur une grande table. Une BDD purement fonctionnelle ne serait donc pas adaptée à la table d’inventaire d’Amazon, même si l’usage de disques SSD permettrait d’annuler une grande partie de la dégradation de performance.

Remarquez encore une fois qu’une grande partie de ces bénéfices/contreparties s’applique telle quelle dans le cas d’un versioning manuel.

Conclusion

Le choix historique d’implémenter les BDD à l’aide de données mutables n’est plus optimal. Le besoin de protéger les mises à jour dans un environnement concurrent nuit à la scalabilité, et l’absence d’historique et de points de retour rend toute manipulation périlleuse.
Une base de données purement fonctionnelle serait intrinsèquement plus sûre, et offrirait une meilleure scalabilité pour de nombreuses applications. En outre, ses besoins seraient tout à fait compatibles avec les bénéfices des disques flash.
Mon pari est qu’une telle base de données va réellement exister dans les années à venir. Le monde académique en parle depuis les années 80; voir notamment la thèse de Phil Trinder qui avait déjà identifié les conséquences de la transparence référentielle dans les bases de données, puis ouvert la voie vers le requêtage monadique (LINQ) avec ses collègues de l’université de Glasgow. Il ne lui manquait que du matériel plus performant.
Aujourd’hui, la startup RethinkDB et la base in-memory HANA utilisent déjà une partie de cette technologie et atteignent de belles performances.
En attendant l’arrivée et la maturation de ces nouveaux outils, il est déjà possible d’enrichir manuellement nos BDD pour bénéficier, en partie, de leurs avantages.

Bibliographie

http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3330.html (Histoire du disque dur IBM 3330)
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-TN-1997-018.pdf (Génèse du SQL)
www.cs.ox.ac.uk/files/3404/PRG82.pdf: Phil Trinder « A functional database »
http://www.quora.com/What-would-be-the-main-advantages-of-a-(purely-)-functional-database
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
http://research.microsoft.com/~gray/papers/theTransactionConcept.pdf (Implémentations d’une transaction)

Suggestion d'articles :

Vidéo du petit-déjeuner NoSQL : « l’Extreme Transaction Processing » devient une réalité

Lina Benhalouche — Wed, 28 Dec 2011 14:14:17 +0000

Jeudi 15 décembre, OCTO organisait un petit-déjeuner NoSQL : « l’Extreme Transaction Processing, devient une réalité ».

Aujourd’hui, la multiplication des systèmes connectés à Internet (smartphone, tablette, TV connectée, véhicule connecté) et l’émergence des nouveaux flux de données issus notamment du web social (Facebook commerce, mobile-to-mobile, etc) vont pousser un peu plus les Systèmes d’Information vers l’Extreme Transaction Processing (XTP).

(Pour plus d’informations sur le contenu, veuillez cliquer ici)

Grâce à la vidéo de l’évènement disponible sur You Tube, vous pouvez découvrir les divers points abordés lors de ce Petit-Déjeuner, à savoir :

les concepts et les opportunités métiers autour de l’ »Extreme Transaction Processing«
les enjeux d’architecture et d’exploitation
les fonctionnalités et l’implémentation faite par les solutions VMware Gemfire et SQLFire

Pour tout autre renseignement, contactez nous sur : contact@octo.com

Cliquez sur l’image pour lancer la vidéo

Suggestion d'articles :

La crise économique, une opportunité à ne pas rater !

Julien Cabot — Wed, 14 Dec 2011 09:35:59 +0000

La crise économique, une opportunité à ne pas rater !
L’actualité financière et les perspectives économiques mettent sous pression les budgets des DSI. Les coups de rabot budgétaires ont le mérite de mettre en évidence les sujets perçus comme les plus importants et urgents.
Arbitrer entre maintenir à flot l’activité métier ou la transformer est un choix difficile pour chaque Direction : « run the business or change the business » ? Les investissements SI sont soumis également à ce dilemme.
Néanmoins, les entreprises qui sauront mettre à profit cette période troublée pour se transformer sauront en bénéficier plus tôt. Alors que celles, qui ne le feront pas, n’auront pas eu le temps de le faire avant la prochaine crise, qui les paralysera à nouveau.
Dans une logique de recentrage des investissements SI, la question est donc de bien identifier les sujets qui permettent d’obtenir une réduction significative des coûts opérationnels et de rentabiliser à court terme la transformation des activités. Il faut bien l’admettre, cet exercice nécessite une bonne dose de créativité et d’innovation.

En période de crise, faut-il ignorer les innovations technologiques ?
La question n’est pas tant la technologie, mais plutôt si les signaux de changement concernent la technologie. L’année 2012 sera-t-elle technologique ? Nous en sommes convaincus en considérant les évolutions suivantes :
• L’émergence du « big data ». Le buzzword BigData, qui existe depuis 10 ans, prend une forme réelle aujourd’hui dans les télécommunications, la banque et le commerce en ligne pour exploiter les immenses quantités de données clients (tickets de communication, opérations bancaires, parcours internet, etc.) pour mieux les adresser.
• L’émergence des nouveaux canaux – Smartphone et Tablette – de distribution et de relation client, qui passent du statut d’outils de communication d’entreprise à celui de canal de distribution et de relation client, à l’instar des sites Internet il y a 10 ans. Les investissements sur ces canaux vont devoir se pérenniser et les applications mobiles devront s’inscrire durablement dans les stratégies multicanales des entreprises.
• L’analyse et la simulation deviennent une réponse nécessaire pour faire face aux bouleversements des contextes économiques et financiers. Mes marges sont-elles toujours positives en cas d’une augmentation des taux de financement du Besoin en Fonds de Roulement ?
Ces 3 évolutions majeures entrainent avec elles des défis technologiques importants, qui nécessiteront toute l’attention des meilleurs talents de la DSI.
Le management des SI ne pourra plus se résumer à un alignement sur les processus métiers. Il devra reconnecter l’innovation technologique et ses opportunités aux enjeux et aux perspectives business. Et ça, c’est une bonne nouvelle !
La maitrise des usages et des opportunités technologiques appliquées au business deviendra la clef qui permettra de faire la différence en sortie de crise ou avant le commencement d’une nouvelle.

Sur quels sujets technologiques investir ?
Les sujets technologiques sont nombreux. Il convient d’aborder la réflexion sur l’usage métier avant de se lancer dans une veille « à tout-va ». A notre avis, les sujets suivants seront incontournables :
• L’écosystème NoSQL qui sert de fondation au Big Data : batch distribué Hadoop, bases de données spécialisées (contenu, graph, clef/valeur, multidimensionnelle, grille), traitement de flux d’évènements (CEP)
• La convergence entre grille de données et grille de calculs, qui fournit une nouvelle génération de serveurs d’applications capables de supporter les systèmes mutualisés de très grande taille
• La programmation parallèle pour tirer profit des évolutions matérielles des multi-core, GPU et grid computing et rendre abordable les systèmes de calculs et de simulation
• L’industrialisation des développements Smartphones et Tablettes pour iOS, Android, Windows Phone et Blackberry tout en alliant l’excellence de l’expérience utilisateur à la pérennisation des investissements sur des plateformes techniques encore en pleine mutation
• La multiplication des connexions des objets physiques à l’Internet (smartphone, tablette, table, TV, véhicule, …) va permettre de suivre et de faire interagir le monde de l’information avec celui des actifs physiques, sans intermédiaire humain.
• L’évolution des infrastructures Cloud, qui devront renforcer leurs solutions permettant l’intégration entre « SI Cloudifié » et SI existant et le durcissement des systèmes de sécurité applicative au fur et à mesure du déploiement de nouveaux services complexes.
• L’hégémonie de HTML5 sur les technologies IHM et l’impérative nécessité de maitriser industriellement les technologies Javascript

La contrainte : aller vite
Indépendamment des sujets choisis, la pression budgétaire augmente celle sur les délais d’obtention de résultats rapides. Il devient donc impératif d’être efficace dans l’identification des usages sectoriels et la maitrise des nouvelles technologies.
La R&D OCTO est orientée dans ce sens, en structurant transversalement l’analyse des opportunités technologiques et l’identification des usages dans les secteurs : Banque, Assurance, Télécoms, Media, Internet, Energie, Distribution et Services.

Suggestion d'articles :

La meilleure façon de rater son projet grâce à Maven2

Petit-déjeuner NoSQL : « l’Extreme Transaction Processing » devient une réalité

Lina Benhalouche — Tue, 29 Nov 2011 13:03:16 +0000

OCTO organise le jeudi 15 décembre à partir de 8h45 un petit déjeuner gratuit NoSQL : « l’Extreme Transaction Processing » devient une réalité, aux salons Wagram.

Pour vous inscrire cliquez ici . Découvrez le descriptif de l’évènement et les intervenants dans ce billet.

Les années 2000, avec l’avènement d’Internet comme nouveau canal pour les entreprises, avaient fortement secoué les Systèmes d’Information et les serveurs d’applications avaient permis de faire face aux enjeux d’ouverture et d’augmentation de traffic sur les systèmes (Transaction Processing).

Aujourd’hui, la multiplication des systèmes connectés à Internet (smartphone, tablette, TV connectée, véhicule connecté) et l’émergence des nouveaux flux de donnéesissus notamment du web social (Facebook commerce, mobile-to-mobile, etc) vont pousser un peu plus les Systèmes d’Information vers l’Extreme Transaction Processing (XTP).

Les technologies XTP (généralement classées sous les acronymes « noSQL », « Data Grid ») existent et même si elles étaient jusqu’alors réservées à des secteurs de niche (Marchés financiers, Défense, Industrie du web), l’évolution des architectures techniques permet aujourd’hui de mettre en place ces solutions transactionnelles hautement performantes et abordables dans des secteurs comme la banque, l’assurance, les médias, les télécommunications et le e-commerce. Les bases de données relationnelles se font challenger par ces nouvelles solutions et technologies tant sur le rapport coût/puissance que sur leur simple pertinence technologique.

En qualité d’architectes de Systèmes d’Information, OCTO présentera les enjeux métiers et principes d’architecture technique nécessaires à l’Extreme Transaction Processing afin de vous donner une vision claire des principaux enjeux, des compromis nécessaires et du positionnement des solutions du marché.

En partenariat, les experts de la division vFabric de VMware vous présenteront des cas concrets d’usage et de déploiements XTP avec GemFire et SQLFire basés sur plus de 10 ans d’expérience en production.

A l’issue de ce séminaire, vous aurez découvert :

Les concepts et les opportunités métiers autour de l’ »Extreme Transaction Processing«
Les enjeux d’architecture et d’exploitation
Les fonctionnalités et l’implémentation faite par les solutions VMware Gemfire et SQLFire

Ce séminaire s’adresse aux architectes techniques et aux décideurs IT qui souhaitent faire passer leur entreprise dans une nouvelle décennie en conduisant des projets d’étude, de déploiement ou de réflexion autour des architectures XTP, à haute volumétrie et faible latence, sans sacrifier la rentabilité de leurs investissements.

Ce petit-déjeuner sera présenté par :

Julien CABOT, OCTO, Associé
Olivier MALLASSI, OCTO, Architecte Senior
Alexandre VASSEUR, VMware, Expert vFabric

Cliquez ici pour vous inscrire au petit-déjeuner : NoSQL

Suggestion d'articles :

GemFire et traitement distribué

Nicolas Colomer — Fri, 07 Oct 2011 07:30:37 +0000

Les enjeux autour de la donnée sont en train de changer par rapport à ce que l’on connait depuis les SGBDR : volume de plus en plus important, nombre d’utilisateur croissant, accès concurrents et transactionnels intensifs à la fois en lecture et en écriture, haute disponibilité à des niveaux coûts acceptables, coût de licence. Dans un tel contexte, les bases de données traditionnelles peuvent montrer leurs limites.

Parmi les différentes réponses à ces enjeux que l’ont a vu émerger ces dernières années, deux d’entre elles se sont révélées particulièrement efficaces :

L’utilisation d’architectures distribuées permet de répartir non seulement la charge mais aussi les données sur plusieurs fournisseurs de données. Les éditeurs de SGBD proposent d’ors et déjà des versions clusterisées de leurs solutions (Oracle RAC, MySQL Cluster, PGCluster, SQL Server cluster) et de nouvelles solutions « scalable-ready » apparaissent, portées par la mouvance NoSQL (Cassandra, HBase, MongoDB, CouchDB).
L’utilisation de cache, pour chaque fournisseur de données, permet d’accélérer drastiquement les performances d’accès aux données. Certaines solutions appelées « memcache » ont été spécifiquement conçues pour proposer de tels systèmes. On peut citer par exemple Redis ou encore Memcached. Ces caches restent (encore bien souvent) limités à des architectures orientées « lecture ».

Les data grids ont challengé les SGBDR en réunissant les deux précédentes réponses : du partitionnement et du stockage mémoire (suivant les configurations choisies). Les acteurs sont multiples : Oracle, Gigaspaces mais également GemStone (VMWare)

1. GemFire, kesako ?

GemFire est la solution de cache distribué éditée par GemStone Systems, récemment acquis par VMWare. Encore appelé « VMware vFabric GemFire », GemFire est un composant de l’écosystème vFabric de VMware.

Cette solution propose, en plus de son framework, des mécanismes avancés de partitionnement (« sharding »), de persistance et de réplication. Ecrit en Java, GemFire peut fonctionner sur une JVM 32 ou 64 bits, c’est à dire sur n’importe quel OS compatible. Les clients peuvent être écrits à la fois en C++, C# ou Java grâce aux API fournies.

GemFire est un cache orienté-objet qui offre les services d’une base de donnée traditionnelle : OQL (une extension orientée objet du langage SQL), transactions (implémente l’interface JTA), cohérence des données (selon le paramétrage choisi), persistance sur disque (via les mécanismes de write behind ou write through), ou encore tolérance aux pannes.

En plus de ces fonctionnalités classiques, on retrouve également des mécanismes plus spécifiques comme le « continuous querying » permettant d’être notifié lorsque le résultat d’une requête a changé, ou le « function execution », permettant de distribuer un traitement au sein du clustrer GemFire. Ce sujet sera l’objet de la deuxième partie de cet article

1.1. Architecture de Gemfire

Un système distribué GemFire se compose de membres, des processus Java connectés les uns aux autres au travers d’un réseau. Chaque membre embarque un cache, fonctionnant soit en mode stockage (« data host ») soit en mode proxy (« data accessor »). Dans le premier cas, des données peuvent être écrite localement puis propagées ; dans l’autre cas, le cache agira comme une simple passerelle vers les données distantes contenues dans la grille de données.

On distingue ainsi deux types de membre :

Le client, généralement une application embarquant un cache GemFire et connecté au système via une API.
Le serveur (ou « cacheserver »), un membre spécialisé dans le stockage de données qui s’exécute de façon autonome dans une JVM dédiée.

Ces membres se découvrent entre eux de deux façons :

Par l’intermédiaire de Locators. Ces sont des membres spécialisés qui maintiennent à jour une liste des membres composant l’architecture distribuée.
Par multicast. Chaque nouveau membre manifeste sa présence en émettant sur une IP et un port préalablement défini.

Dans le schéma précédent, on observe que le système distribué peut adopter plusieurs topologies :

Peer-to-peer : les données sont partagées entre plusieurs clients (liens bleus).
Client/serveur : les données sont partagées au sein d’un cluster dédié de serveurs sur lequel peuvent se connecter les clients (liens verts et gris).
Multi-site : plusieurs systèmes distribués sont reliés entre eux via un ou plusieurs membres déclarés en tant que « gateway hubs » (non représenté).

Pour synchroniser les différents nœuds, GemFire propose une API de propagation par delta permettant de réduire les échanges sur le réseau, surtout dans le cas de régions fortement répliquées.

1.2. La sémantique

Dans GemFire, le concept principal est celui de région. Une région, encore appelé « data set », est un groupe logique dans lequel sont stockées les données.

Chaque région possède sa propre configuration (modèle de données, type de partitionnement, présence de réplication, nature de la persistance, gestion des événements). Cette configuration devra être déclarée à l’identique dans chacun des membres utilisant la région. Elle se fait via un descripteur XML ou programmatiquement, au travers de l’API GemFire.

Toute région implémente la bien-connue interface java.util.Map : la manipuler ne devrait pas poser de problème ! Les données y sont donc stockées sous forme de clef/valeur. Clefs et valeurs prennent toutes deux la forme d’un objet Java, toutefois, la clef sera le plus souvent une simple chaine de caractères.

On dénombre 4 types de régions :

Locale, la région n’est accessible que par le membre qui l’a déclaré et ne sera donc partagé avec aucun autre membre.
Distribuée, chaque membre stock localement les données qu’il créé, mais les partages avec les autres membres du système.
Répliquée, chacun des membres du système détient une copie complète de toutes les données de la région.
Partitionnée, les données sont réparties au travers des différents membres de la région, soit équitablement, soit selon des règles de partitionnement préalablement définies. Il est de plus possible de répliquer ces données (« redundant copies ») sur un ou plusieurs membres, afin de garantir leur haute disponibilité. Ainsi chaque membre est responsable d’une partition et héberge n réplicas d’autres partitions.

GemFire offre 3 modes de distribution (ou « scope ») des données permettant d’assurer différents niveaux de cohérence :

Distributed-no-ack : aucune contrainte n’est imposée lors de la propagation d’opérations. Ce niveau offre les meilleures performances, mais est sujet aux problèmes de concurrence.
Distributed-ack : les opérations distribuées sont validées par un système d’acquittement. Ce niveau est moins exposé aux problèmes de concurrence
Global : les entrées d’une région sont automatiquement verrouillées lorsqu’elles sont modifiées. C’est le seul scope permettant d’assurer une cohérence forte des données, mais c’est aussi le moins performant.

2. Distribuer un traitement

Le requêtage des données d’une région se fait via OQL. Ce langage répond à des besoins standard en autorisant l’utilisation de clauses SQL bien-connues telles que SELECT, FROM ou WHERE. Il est également possible de réaliser des jointures entre régions et des indexes.

Toutefois, les requêtes OQL sont soumises à certaines limitations qui dépendent principalement du type de région sur lequel on les exécute. Ces limitations concernent entre autre la cohérence des résultats dans le cas de régions répliquées ou distribuées. En effet, pour ces deux types de région, les requêtes sont effectuées sur les données contenues dans le cache local, qui peut, dans certains cas (race conditions, selon la stratégie de propagation), ne pas être cohérentes à un instant donné.

Lorsque l’on aborde la question du traitement au sein d’une architecture distribuée, on entend souvent parler de MapReduce. Le concept est simple : au lieu de rapatrier les données sur un nœud pour traitement, c’est la fonction réalisant ce traitement qui est envoyé sur chacun des nœuds, c’est à dire au plus proche de la donnée. Ceci offre l’avantage de paralléliser l’exécution de la fonction sur différents nœuds tout en diminuant les échanges au niveau du réseau.

Le « function execution service » fourni par GemFire, bien qu’assez éloigné de MapReduce, s’inspire de ce mécanisme. En voici les détails.

2.1. Mécanismes mis en jeu

Toute fonction distribuée doit être préalablement déclarée et déployée sur chaque membre d’une région partitionnée lors de son déploiement (descripteur + classpath). Cela implique que ces fonctions aient été préalablement codées en Java, compilées puis éventuellement packagées.

Lorsqu’un client déclenche l’exécution d’une fonction distribuée (action non bloquante pour le client), le serveur (data host) auquel il est connecté va notifier tous les autres serveurs du cluster, contenant localement une partie des données à traiter, d’engager l’exécution de ladite fonction.

Dans le cas ou la fonction retourne des résultats, les différents serveurs vont les soumettre à un collecteur de résultat contenu dans le serveur directement connecté au client. Ce collecteur accumule les résultats jusqu’à ce que chaque serveur ait notifié l’envoie du dernier résultat.

Le client peut alors les récupérer :

de manière bloquante : attente de la totalité des résultats, possibilité de spécifier un timeout.
de manière non bloquante : le résultat récupéré par le client est alors potentiellement incomplet.

La documentation ne spécifie aucun mécanisme de callback permettant de notifier de manière asynchrone la disponibilité d’un résultat complet.

Ces différentes étapes se résument dans le schéma suivant :

Remarque : le client peut restreindre l’exécution à un, une partie ou tous les membres d’une région. Il peut également spécifier directement les clefs qui seront soumise au traitement. Ces possibilités sont très utiles, par exemple lorsqu’a été défini une politique de partitionnement spécifique.

2.2. Contexte de l’exemple

Afin d’expérimenter le traitement distribué, nous nous sommes placé dans le contexte d’un service web. Cet exemple entre dans la continuité d’un POC réalisé en interne chez Octo. Nous avons souhaité calculer à la demande des informations statistiques sur la vitesse de véhicules au travers de données brutes remontées par ces derniers.

L’architecture visée se compose des éléments GemFire suivants :

Deux CacheServer et un Locator, déployés sur une machine virtuelle
Une application web JEE, déclenchant l’exécution de la fonction distribuée à la demande d’un utilisateur

2.3. Réalisation de la fonction distribuée

L’exécution de notre fonction distribuée va nécessiter 4 classes :

SpeedAverageFunction, représente la fonction à exécuter sur chacun des nœuds du cluster. Cette fonction récupère dans la partition locale toutes les vitesses instantanées pour un véhicule donné. Ces données sont transmises au SpeedAverageCollector via l’objet ResultSender.
SpeedAverageCollector, doit collecter les résultats retournés par les différents nœuds du cluster (action 4 dans le schéma précédent).
SpeedAverageResult, permet de stocker les résultats prétraités. C’est l’objet qui sera renvoyé par le collecteur au client.
GemFireManager, récupère et fournit une instance de la région. Elle permet de déclencher l’exécution de notre fonction distribuée, en spécifiant en argument l’identifiant du véhicule dont la vitesse moyenne doit être calculé.

Détaillons tour à tour chacune de ces 4 classes.

2.3.1. SpeedAverageFunction

Cette classe contient le traitement a effectuer par chacun des data hosts auxquels elle sera soumise. Toute fonction distribuée doit implémenter les interfaces Function et Declarable, cette dernière interface permettant d’être déclarée au sein d’un descripteur XML (voir la partie déploiement). Ci-après, le code commenté de la classe SpeedAverageFunction.

import com.gemstone.gemfire.cache.Declarable;
import com.gemstone.gemfire.cache.Region;
import com.gemstone.gemfire.cache.execute.Function;
import com.gemstone.gemfire.cache.execute.FunctionContext;
import com.gemstone.gemfire.cache.execute.RegionFunctionContext;
import com.gemstone.gemfire.cache.execute.ResultSender;
import com.gemstone.gemfire.cache.partition.PartitionRegionHelper;
import com.gemstone.gemfire.cache.query.SelectResults;
import com.gemstone.gemfire.cache.query.TypeMismatchException;
import com.octo.rtf.ws.model.VehicleMessage;

public class SpeedAverageFunction implements Declarable, Function {

	@Override
	public void init(Properties props) {
		// Distributed function name extracted from XML descriptor
		functionName = props.getProperty("name");
	}

	@Override
	public void execute(FunctionContext fc) {
		RegionFunctionContext context = (RegionFunctionContext) fc;
		// Get local region data
		Region localRegion = PartitionRegionHelper.getLocalDataForContext(context);
		// Get the result collector
		ResultSender resultSender = context.getResultSender();
		// Retrieve arguments
		String[] args = (String[]) context.getArguments();

		try {
			// Execute the query
			SelectResults queryResults = localRegion.query(formQuery(args));
			// Extract the results
			Map results = queryRouteAverage(queryResults);
			for (String key : results.keySet()) {
				Integer[] data = results.get(key);
				// Send each result to the collector
				resultSender.sendResult(new Object[] {key, data[0], data[1]});
			}
			resultSender.lastResult(null);
		} catch (
	}

	@Override
	public boolean hasResult() {
		// Does the function return results ?
		return true;
	}

	@Override
	public boolean isHA() {
		// Is the high availability option set ?
		return false;
	}

	@Override
	public boolean optimizeForWrite() {
		// Does the function write results on region ?
		return false;
	}
}

2.3.2. SpeedAverageCollector

Cette classe implémente l’interface ResultCollector. T correspond à l’objet en entrée, c’est à dire retourné par les data hosts lorsqu’ils récupèrent des données (dans le cas de notre SpeedAverageCollector, un tableau d’objet), et S correspond à l’objet en sortie, c’est à dire retourné au client (ici, un objet SpeedAverageResult).

Ci-après, le code commenté de la classe SpeedAverageCollector.

import com.gemstone.gemfire.cache.execute.FunctionException;
import com.gemstone.gemfire.cache.execute.ResultCollector;
import com.gemstone.gemfire.distributed.DistributedMember;

public class SpeedAverageCollector implements ResultCollector  {

	SpeedAverageResult sar = new SpeedAverageResult();

	public SpeedAverageCollector() {}

	@Override
	public void addResult(DistributedMember memberID,
			Object[] resultOfSingleExecution) {
		// Executed when a member return a result
		if (resultOfSingleExecution == null) return;
		String type = (String) resultOfSingleExecution[0];
		int value = (Integer) resultOfSingleExecution[1];
		int weight = (Integer) resultOfSingleExecution[2];
		sar.addResult(type, value, weight);
	}

	@Override
	public void clearResults() {
		// When the function is reexucted
		sar = new SpeedAverageResult();
	}

	@Override
	public void endResults() {
		// When a member sends its last result
	}

	@Override
	public SpeedAverageResult getResult() throws FunctionException {
		// Return the result (blocks until the last result is sent)
		return sar;
	}

	@Override
	public SpeedAverageResult getResult(long timeout, TimeUnit unit)
			throws FunctionException, InterruptedException {
		// Returns the result (blocks until timeout)
		return getResult();
	}
}

2.3.3. SpeedAverageResult

Cette classe va contenir l’ensemble des résultats et leurs accesseurs. Elle doit implémenter l’interface Serializable afin de pouvoir transférée aux data hosts via le réseau. Ci-après, le code commenté de la classe SpeedAverageResult.

public class SpeedAverageResult implements Serializable {

	private Map results;

	public SpeedAverageResult() {
		results = new HashMap();
	}

	public void addResult(String type, int value, int weight) {
		if (!results.containsKey(type)) {
			results.put(type, new Integer[] {value, weight});
		} else {
			Integer[] data = results.get(type);
			data[0] += value;
			data[1] += weight;
		}
	}

	public Double getAverage() {
		int sum = 0, num = 0;
		for (String type : results.keySet()) {
			Integer[] data = results.get(type);
			sum += data[0];
			num += data[1];
		}
		if (num == 0) return new Double(0);
		else return (double) (sum / num);
	}

	public Map getAverageByHighway() {
		Map result = new HashMap();
		for (String type : results.keySet()) {
			result.put(type, getAverageForHighway(type));
		}
		return result;
	}

	public Double getAverageForHighway(String type) {
		Integer[] data = results.get(type);
		return (double) (data[0] / data[1]);
	}
}

2.3.4. GemFireManager

Cette classe va permettre de se connecter en tant que client au système distribué GemFire. Elle va récupérer et fournir une instance de la région qui permettra de stocker les messages de nos véhicules connectés. La méthode getSpeedAverageFromVin() permettra de déclencher l’exécution de la fonction distribuée sur notre région. Ci-après, le code de la classe GemFireManager

import com.gemstone.gemfire.cache.Region;
import com.gemstone.gemfire.cache.client.ClientCache;
import com.gemstone.gemfire.cache.client.ClientCacheFactory;
import com.gemstone.gemfire.cache.client.ClientRegionShortcut;
import com.gemstone.gemfire.cache.execute.Execution;
import com.gemstone.gemfire.cache.execute.FunctionService;
import com.octo.rtf.ws.model.VehicleMessage;

public class GemFireManager {

	private static final String LOCATOR_IP = "192.168.56.101";
	private static final int LOCATOR_PORT = 55221;
	private static final String REGION_NAME = "VehicleMessageRegion";
	private static final String FUNCTION_SPEEDAVERAGE = "SpeedAverage";

	private static ClientCache cache;
	private static Region region;

	public GemFireManager() {
		// Create a local client cache
		cache = new ClientCacheFactory()
			.addPoolLocator(LOCATOR_IP, LOCATOR_PORT)
			.set("log-level", "error").create();
		// Get the region
		region = cache.createClientRegionFactory(ClientRegionShortcut.PROXY)
			.create(REGION_NAME);
	}

	public SpeedAverageResult getSpeedAverageFromVin(String vin) {
		Execution execution = FunctionService
			.onRegion(region)
			.withCollector(new SpeedAverageCollector())
			.withArgs(new String[] {vin});
		SpeedAverageCollector collector = (SpeedAverageCollector) execution
			.execute(FUNCTION_SPEEDAVERAGE, true, false, false);
		return collector.getResult();
	}
}

2.4. Configuration et déploiement des composants

2.4.1. Définissons la région

La région que nous allons créer ici devra stocker l’ensemble des messages remontés par les véhicules. Ces messages contiennent des données brutes, parmi lesquels un timestamp, la vitesse instantanée et le type de route emprunté.

Pour définir cette région, utilisons un descripteur XML :

"1.0" encoding="UTF-8"?>


	"VehicleMessageRegion" refid="PARTITION">
		
			com.octo.rtf.ws.model.VehicleMessage
		
	
	
		
			com.octo.rtf.ws.gemfire.SpeedAverageFunction
			SpeedAverage

Le descripteur est plutôt explicite : nous définissons ici un cache contenant une région partitionnée nommée VehicleMessageRegion, dont la valeur sera un objet VehicleMessage. La clef sera une simple chaine de caractère (non spécifiée donc nature par défaut). Enfin nous spécifions une fonction exécutable au travers de son identifiant « SpeedAverage ».

2.4.2. Dépendances Java

Locator et CacheServer sont des processus Java indépendants. Afin d’être lancés, déclarons quelques variables d’environnement permettant de régler définitivement le problème des dépendances.

# VARIABLES GEMFIRE
GF_JAVA=$JAVA_HOME/bin/java; export GF_JAVA
PATH=$PATH:$JAVA_HOME/bin:$GEMFIRE/bin; export PATH
GEMFIRE=/srv/GemFire6514
CLASSPATH=$GEMFIRE/lib/gemfire.jar:$GEMFIRE/lib/antlr.jar:$GEMFIRE/lib/gfSecurityImpl.jar:$CLASSPATH; export CLASSPATH

2.4.3. Initialisation du Locator

Afin de déployer notre système distribué GemFire, choisissons la méthode du locator (par opposition à la méthode multicast). Le locator est un processus à l’écoute d’un port, réalisant la coordination entre les différents membres du système distribué GemFire. Le Locator peut être respectivement lancé et arrêté au travers des commandes suivantes.

gemfire locator-stop -port=55221 -address=192.168.56.101
gemfire locator-start -port=55221 -address=192.168.56.101

2.4.4. Lancement des cacheserver

Pour fonctionner, un cacheserver a besoin d’un répertoire de travail dans lequel il persistera les données (si l’option est spécifiée) ainsi que les différents logs.

Démarrons deux cacheservers dans deux répertoires distincts.

mkdir ./server1 ./server2
cacheserver start locators=192.168.56.101[55221] mcast-port=0 cache-xml-file=.. /server.xml -server-bind-address=192.168.56.101 -server-port=0 -dir=./server1
cacheserver start locators=192.168.56.101[55221] mcast-port=0 cache-xml-file=../server.xml -server-bind-address=192.168.56.101 -server-port=0 -dir=./server2

Pour stopper ces deux cacheserver, il suffit d’utiliser les commandes suivantes

cacheserver stop -dir=./server1
cacheserver stop -dir=./server2

Le système est maintenant prêt à opérer. Pour voir un exemple du résultat, n’hésitez pas à consulter le screencast disponible dans la deuxième partie de l’article concernant le push web.

3. Conclusion

Nous avons pu constater au travers de cet article que :

Les efforts à fournir pour déployer une telle architecture sont loin d’être insurmontables.
L’exécution de fonctions distribuées est particulièrement simple à mettre en œuvre.

Les fonctions distribuées ne forment cependant qu’une partie de ce que propose GemFire. Le framework offre également d’autres outils, comme la propagation par deltas pour réduire la charge sur le réseau ou le mécanisme de « Continuous Querying » qui permet d’être notifié sur changement du résultat d’une requête ou de l’état d’une région…

Suggestion d'articles :

Transactions et traitement métier en Grails

BigData : la fin des architectures basées sur les processus métiers?

Julien Cabot — Tue, 17 May 2011 08:00:51 +0000

Le BigData, une nouvelle (r)évolution pour les entreprises?

McKinsey a publié récemment un rapport sur l’avènement du BigData comme nouveau paradigme de compétition entre les entreprises.

L’analyse massive et le développement du capital informationnel (le BigData) deviendrait un nouveau levier pour la productivité, l’innovation et la croissance.

Le rapport met en évidence 5 clefs pour tirer profit du concept de BigData :

Make big data more accessible and timely. Transparency, enabled by big data, can unlock a great deal of value. In the public sector, increasing access to data across separate departments can sharply reduce search and processing times. In manufacturing, integrating data from R&D, engineering, and manufacturing units to facilitate concurrent engineering can cut time to market.

Use data and experiments to expose variability and raise performance. As organizations create and store more transactional data in digital form, they can collect more accurate and detailed performance information on everything from product inventories to sick days.

Segment populations to customize. Big data allow organizations to create ever-narrowing segmentations and to tailor services precisely to meet customer needs. This approach is well known in marketing and risk management but can be revolutionary in areas such as the public sector.

Use automated algorithms to replace and support human decision making. Sophisticated analytics can substantially improve decision making, minimize risks, and unearth valuable insights that would otherwise remain hidden. Such analytics have applications from tax agencies to retailers.

Innovate with new business models, products, and services. To improve the development of next-generation offerings and to create innovative after-sales services, manufacturers are leveraging data obtained from the use of products. The emergence of real-time location data has created a new set of location-based mobile services from navigation to people tracking.

Y aura-t-il un impact dans la manière de concevoir les SI?

Les technologies de stockage et de traitement de données sont en train de connaitre probablement une évolution aussi importante que l’apparition des serveurs d’applications. Le monde des technologies NoSQL, CEP et BI est en train de vivre sa révolution. Mon point ne porte pas tellement sur l’émergence de nouvelles technologies challengeant l’hégémonie des bases de données relationnelles traditionnelles, mais plutôt l’implication de BigData en matière d’architecture de SI.

Depuis 20 ans, nous concevons des SI alignées sur les processus métiers des organisations pour permettre l’amélioration de la productivité des entreprises par l’automatisation des processus. Ce même souhait nous a fait aboutir à des systèmes d’informations segmentés par grandes familles de processus (front, back , support, pilotage, transverse, etc.)

Sans le dire, BigData nous fait passer d’une logique de commoditisation des processus métiers à celle de l’exploitation d’un actif (mal identifié) de l’entreprise : l’Information.

Dans un précédent article, je mettais en lumière la double position du SI en tant que commodité ET actif de l’entreprise.
Le BigData met un mot pour qualifier un SI, actif stratégique, capable de faire émerger les nouvelles opportunités business, de tarifier au plus fin sur la base des comportements réels des clients, de casser les asymétries d’information qui freinent la collaboration entre les entités des organisations,etc.

Comment pouvons bâtir de tels SI en utilisant des principes d’architecture qui favorisent le cloisonnement plutôt que le partage de l’information et qui repose sur la mise en œuvre d’expression de besoin pré-identifiée?

Un SI qui maximise la valeur de l’information d’une entreprise peut-il avoir une architecture cloisonnée entre informations front office et back office? La construction à-côté d’un SI Décisionnel alimenté par le SI Opérationnel pourra-t-il permettre de réagir suffisamment vite et de prendre des décisions rapidement?

Comment définir un SI qui tire profit des BigData?

L’article suivant identifie des caractéristiques clefs de l’information en tant qu’actif de l’entreprise.

Un SI BigData devrait donc être

Partagé : Tout le monde accède à la même source d’information
Utilisé : Utilisé par tous – collaborateurs, clients, partenaires, fournisseurs, …
A date : La notion de courant/historisé disparaît au profit d’une notion de date d’événement, proche de celle de la date de valeur (passée, présente et futur)
Précis : Toutes les données brutes sont présentes et rattachées aux informations de plus haut niveaux
Comparable/Combinable : Les informations reposent sur les mêmes données brutes pour pouvoir être comparées et combinées?
Piloté par la valeur : le traitement de l’information (par opposition à celui des données) est consommateur en temps et énergie, il convient de choisir ses informations pour ne pas perdre en productivité
Réutilisable : l’information doit pouvoir servir de base à une autre

Conclusion
Avec le BigData, la forme de nos systèmes d’information pourrait bien changer. Imaginez le SI d’une banque avec un immense nuage mondial de données d’événements de gestion de compte qui permettrait aux front de connaitre le comportement de chaque client, de proposer des produits totalement personnalisés, de décloisonner conseiller agence, banque en ligne, conseiller en patrimoine, etc.

Suggestion d'articles :

Vers des API haut niveau pour Java et NoSQL avec Spring Data

Michel Domenjoud — Sun, 01 May 2011 14:47:03 +0000

A l’heure où les nouvelles technologies de stockage de données regroupées sous les termes NoSQL et Distributed Data Grid deviennent populaires, il est intéressant de suivre l’évolution de cet écosystème et notamment des librairies d’intégration avec ces outils.
Des librairies apportant un certain niveau d’abstraction émergent, avec l’espoir de voir apparaître des solutions de haut niveau comparables aux ORM que nous utilisons pour les bases relationnelles. Nous allons nous intéresser aujourd’hui au projet Spring Data, qui propose une certaine unification pour les accès aux bases de données dites NoSQL.

Spring Data

Spring Data est un projet en développement et lancé en 2010, visant à simplifier l’utilisation des bases NoSQL, des frameworks Map-Reduce, ou d’apporter des extensions pour le support des bases relationnelles. Le projet intègre aussi progressivement le framework Hades qui apporte la notion de repository pour une approche Domain Driven Developpment.

Spring Data regroupe déjà plusieurs sous-projets dédiés à des implémentations particulières :

JPA, qui apporte de nouvelles fonctionnalités pour une approche DDD avec des bases relationnelles,
Graph, avec une implémentation pour Neo4j,
Document, avec une implémentation pour MongoDB,
Key – Value, des implémentations pour Redis et Riak,
Extensions JDBC.

Dans l’ensemble, les projets existants consistent à apporter une couche d’abstraction facilitant la manipulation de données avec les différents systèmes de stockage. L’apport principal de ce projet est bien sûr de faciliter l’intégration de ces technologies à un applicatif Spring, et de profiter des facilités de configuration du framework : injection de beans, configuration xml et programmation orientée aspect.

Nous allons voir ce que peuvent apporter ces librairies par rapport à une utilisation directe des connecteurs existants. L’équipe prévoit également le support d’autres produits tels qu’Amazon S3, Cassandra ou Hadoop.

En parallèle, le projet Spring Data Mapping, actuellement hébergé côté Groovy, aurait pour objectif d’apporter une solution générique de mapping Objet-Base pour plusieurs bases NoSQL.

Spring Data JPA et Domain-Driven-Developpment

Une des vocations du projet Spring Data est d’apporter le support pour une approche Domain Driven Developpment (DDD) et l’utilisation du pattern Repository. Spring Data JPA en est la première implémentation, dédiée aux bases relationnelles. Le projet est directement repris depuis le framework Hades, dont les fonctionnalités sont progressivement intégrées au socle commun de Spring Data, et doit permettre à terme une approche DDD pour les différents types de stockage supportés.

Génération de Repository

Le développement d’un Repository est facilité en générant automatiquement les fonctions de CRUD les plus communes d’un service d’accès aux données :

save
findById
findAll (avec gestion de résultats paginés)
count
delete
exists

L’utilisation de l’API est plutôt simple, il suffit de définir son repository via une interface étendant l’interface JpaRepository de base, et le framework se chargera du reste.

public interface PersonRepository extends JpaRepository { … }

De plus, l’API permet, comme cela se fait en Groovy et Rails, de générer les méthodes de requêtes à partir du nom de la méthode ou en utilisant une requête nommée (@NamedQuery). Par exemple, si on souhaite ajouter une méthode de recherche par nom à notre PersonRepository :

public interface PersonRepository extends JpaRepository {
 List findByLastname(String lastname);
}

Le bean injecté par Spring comportera alors une méthode générée avec l’exécution de la requête correspondante : « SELECT * FROM User WHERE lastname = ? ».

La librairie permet principalement de réduire le volume de code à écrire lorsque l’on code un Repository, mais Spring Data JPA apporte d’autres fonctionnalités intéressantes:

L’approche DDD est facilitée grâce aux supports des Specifications, qui utilisent des closures pour définir des prédicats, tout en utilisant l’API Criteria de JPA2.

public static Specification isPersonMinor() {
	return new Specification() {
		Predicate toPredicate(Root root, CriteriaQuery query,
			CriteriaBuilder builder) {
			LocalDate date = new LocalDate().minusYears(18);
			return builder.lessThan(root.get(Person_.birthDate), date);
		}
	};
}

Ajout de fonctions pour la gestion des transactions au niveau Repository
Entités auditables (suivi des dates et utilisateurs de création et modification). Il s’agit d’un sujet classique en entreprise lorsque le suivi des modifications de données est stratégique. Il sera intéressant de comparer cette fonctionnalité à son équivalent Hibernate Envers.
Support de la librairie Querydsl.

Spring Data Graph

Ce projet est dédié aux bases proposant une implémentation de type graphe et fournit une implémentation pour Neo4j.
Neo4j est une base de données graphe, qui répond également aux enjeux traditionnels d’une base de données (ACIDité des transactions, gestion des accès concurrents,rollback de transaction, haute disponibilité). Pour avoir un rapide tour d’horizon de ce qu’apporte une base de données graphe et plus particulièrement Neo4j, voir ici.

Spring Data Graph propose une véritable couche d’abstraction permettant un mapping entre un modèle objet utilisé dans l’application Java et les entités stockées physiquement dans la base graphe. Spring Data Graph définit donc les notions suivantes pour la modélisation au niveau des objets (les exemples proviennent de la documentation officielle, qui propose par ailleurs un exemple complet d’une application web utilisant les différents composants de Spring) :

Annotations pour définir noeuds (@NodeEntity) et relations (@RelationshipEntity)
Gestion des index (@Indexed)

@NodeEntity
class Movie {
 @Indexed
 int id;

 String title;
 int year;    

 @RelatedTo(elementClass = Actor.class, type = "ACTS_IN", direction = Direction.INCOMING)
 Set cast;

 @RelatedToVia(elementClass = Role.class, type = "ACTS_IN", direction = Direction.INCOMING)
 Iterable roles;
}

@NodeEntity
class Actor {    

 @Indexed
 int id;
 String name;

 @RelatedTo(elementClass = Movie.class, type = "ACTS_IN")
 Set cast; 

 public Role playedIn(Movie movie, String roleName) {
 Role role = relateTo(movie, Role.class, "ACTS_IN");
 role.setRole(roleName);       
 return role;
 }
}

@RelationshipEntity
class Role {
 @EndNode
 Movie movie;

 @StartNode
 Actor actor;

 String role;
}

Utilisation du pattern Repository, avec des implémentations pour gérer des opérations de CRUD, index et recherches; ainsi que les algorithmes de parcours de graphes.

GraphRepository graphRepository = graphRepositoryFactory.createGraphRepository(Person.class);

Spring Graph apporte également une couche d’abstraction sur des aspects plus techniques, entre autres:

Gérer des recherches:
- en utilisant des algorithmes spécifiques de parcours de graphe (Traversal)
- en utilisant le système de recherche indexée avec un moteur d’indexation séparé (Apache Lucene est inclus par défaut).

Pour cela, il suffit d’annoter le champ à indexer: @Indexed(fulltext = true, indexName = « search »), puis d’appeler la méthode findAllByQuery(indexedField, query))

Gérer les transactions avec la configuration Spring standard et SpringTransactionManager
Gestion de la persistance des entités avec la méthode persist()
Validation de beans (JSR 303) via les annotations de définition de contraintes (@Min, @Max, @Size, @Email, …)

Définition d’entités cross-store

Un autre aspect très intéressant dans cette API est le support multi-base en définissant des entités partielles, qui permet d’utiliser plusieurs systèmes de stockage pour une même entité. Actuellement, il est possible de définir une entité dont une partie des champs sera géré via JPA dans une base relationnelle classique, tandis que l’autre partie est gérée dans une base de données graphe.

L’exemple suivant est une modélisation simpliste d’un système de vente dans lequel les articles et les ventes sont stockés dans une base relationnelle classique, hormis les liens entre les objets vendus (« Les acheteurs qui ont acheté ce produit ont également acheté…), ainsi que le total des ventes pour chaque article.

@Entity
@Table(name = "product")
@NodeEntity(partial = true)
class Product {
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	@Column(name = "id")
	private Long id;

	private String name;
	private String description
	private Double price;

	@GraphProperty
	Double totalSales;

	@RelatedTo(elementClass = Product.class, type = "SAME_SALE", direction = Direction.INCOMING)
	private Set linkedSales;

	@RelatedToVia(elementClass = SaleConnection.class, type = "SAME_SALE", direction = Direction.INCOMING)
	private Iterable salesConnections;

	@OneToMany
	private Set sales;

	@Transactional
	public SaleConnection soldTogether(Product item) {
		SaleConnection connection = relateTo(item, SaleConnection.class, "SAME_SALE");
		connection.incrementLinkWidth();
		return connection;
	}
}

@RelationshipEntity
class SaleConnection {
	@EndNode
	Product item1;

	@StartNode
	Product item2;

	int linkWidth = 0;

	public void incrementLinkWidth(){
		linkWidth++;
	}
}

@Entity
@Table(name = "sales")
class SoldItem {
	@ManyToOne
	Product productReference;

	Double soldPrice;
}

Spring Data Document

Ce projet est dédié aux bases proposant une implémentation de type document, et fournit pour l’instant une implémentation pour MongoDB.

L’implémentation apporte une surcouche au client Java fourni par Mongo et en reproduit l’essentiel des fonctionnalités en s’intégrant au framework Spring, entre autres :

Configuration Spring via XML ou classes @Configuration pour les instances Mongo et la gestion des replica set
MongoTemplate qui offre des mécanismes d’abstraction pour interagir avec MongoDB et pour gérer la persistance des objets Java avec MongoDB de manière transparente, la gestion des collections, exécuter des commandes shell internes.
Fonctions de recherche avec notamment :
- possibilité d’utiliser des Criteria
- support des requêtes géographiques
- gestion d’index

Par ailleurs, la librairie apporte le support du pattern Repository de manière similaire à Spring Data JPA avec MongoRepository:

Génération des fonctions de CRUD
Gestion de requêtes prédéfinies au format JSON, par exemple:

public interface PersonRepository extends MongoRepository
  @Query("{ 'firstname' : ?0 }")
  List findByThePersonsFirstname(String firstname);
}

Support de Querydsl

Enfin, la dernière version fraichement sortie de l’API propose d’une part un système de mapping à base d’annotations, avec notamment la possibilité de gérer les collections au sein d’un document par référence ou non:

@Document
public class Account {
  @Id
  private ObjectId id;
  private Float total;
}

@Document
public class Person {
  @Id
  private ObjectId id;
  @Indexed
  private Integer ssn;
  @DBRef
  private List accounts;
}

D’autre part, cette dernière release apporte comme l’API Graph un support cross-store persistence, permettant d’utiliser conjointement plusieurs systèmes de stockage de données.

Cette librairie semble plutôt aboutie et vient sans doute concurrencer sérieusement les librairies existantes comme Morphia, qui propose également des fonctions de mapping notamment.

Spring Data Key-Value

Le projet Key-Value (SDKV) est dédié aux bases proposant une implémentation clé-valeurs, et fournit des implémentations pour Redis et Riak.

Il s’agit pour l’instant essentiellement d’une couche d’abstraction au dessus des librairies de bas niveau existantes, qui permet principalement de tirer avantage d’une configuration Spring. Ces deux librairies semblent encore à un niveau de maturité assez faible et n’apportent pour l’instant pas beaucoup par rapport à une utilisation directe des connecteurs.

Redis

L’implémentation SDKV pour Redis est une surcouche aux connecteurs Jedis, JRedis et RJC, qui apporte notamment:

Configuration simple via XML, par exemple :

Utilisation d’objets plutôt que de dialoguer directement avec Redis grâce à la classe RedisTemplate
- classes correspondant aux opérations de Redis (Value, List, Set, ZSet, Hash et Bound*)
- fonctions de messaging (Send/Publish/Subscribe)
Possibilité d’utiliser différents mécanismes de sérialisation pour stocker des objets

Plusieurs articles on déjà été publiés sur le sujet:

Riak

Là aussi, SDKV propose une surcouche au client Java développé par Basho (la société derrière Riak). Une base de données Riak est nativement accédée via une API REST/HTTP, utilisant les drivers Apache Commons.

La librairie apporte notamment :

Configuration simple par XML, par exemple:

Utilisation d’objets plutôt que de dialoguer directement avec Riak grâce à la classe RiakTemplate
- pour les fonctions d’accès et de stockage
- l’utilisation de l’algorithme Map/Reduce
- les fonction de liaison entre les entrées et de parcours des listes liées
Gestion asynchrone des échanges avec la base de données avec des callbacks
Utilisation de services personnalisés de conversion d’objets vers Riak ou de ClassLoader depuis Riak

Spring Data JDBC Extensions

Cette partie de Spring Data se situe un peu en marge du reste car il s’agit ici de fournir des extensions de configuration spécifiques à certaines implémentations de bases de données relationnelles.

La première version du projet comporte des extensions pour les bases de données Oracle, qui constituent un portage du code d’un module auparavant payant de Spring, le Advanced Pack for Oracle Database. Cette extension doit notamment permettre un support transparent pour les applications de fonctionnalités telles que le Fast Connection Failover d’Oracle RAC, Advanced Queuing, et des types de données complexes (XML, STRUCT, ARRAY).

Vers une abstraction de plus haut niveau?

Spring Data Mapping

Ce dernier projet plutôt ambitieux vise à fournir un framework mutualisé de mapping objet pour les différents implémentations de stockage de données. C’est finalement une surcouche aux projets précédents qui cherche, j’imagine, à décorréler la modélisation du stockage physique. A l’heure actuelle, le projet est simplement mentionné dans la page du projet Spring Data, il n’y a pas de version SNAPSHOT disponible. Le projet est pour l’instant en Groovy, mais devrait être migré en Java pour s’intégrer à Spring Data.

D’après ce qu’on peut voir des sources existantes, il serait bien possible de définir un mapping d’objets de manière relativement indépendante de la base de données : on trouve un projet core, et des implémentations pour de nombreuses technologies: Gemfire, Hibernate, AppEngine, Redis, Mongo, Cassandra et d’autres…

Hibernate OGM

Hibernate OGM est un projet démarré en juillet 2010 et mené par Emmanuel Bernard chez JBoss. Le projet a été repris d’un essai d’une implémentation JPA-like pour Infinispan, le moteur de grille de données open source de JBoss. A l’heure actuelle, le projet semble être à un stade plutôt expérimental et bien moins avancé que Spring Data, mais il sera intéressant de suivre son évolution et l’orientation qui sera suivie, car les deux projets seront sans doute concurrents.

Concrètement, Hibernate OGM souhaite utiliser Hibernate Core pour stocker des données dans une grille de données distribuée, en l’occurrence Infinispan. L’objectif est de réutiliser l’implémentation existante de JPA plutôt que de repartir de zéro, pour mapper des entités et des relations.

Pour conclure

Pour l’instant, en dehors de l’API Graph, Spring Data est en cours de développement et il n’est donc pas encore question d’utiliser ces librairies en production. Néanmoins, l’avancement actuel des différentes librairies laisse déjà présager de plusieurs atouts à leur utilisation :

intégration au framework Spring et apport de ses facilités de configuration.
abstraction par rapport aux implémentations des différentes solutions de stockage NoSQL et apport de surcouches aux connecteurs, notamment grâce aux systèmes de mapping par annotations. Il y a encore du travail sur ce point pour offrir toutes les fonctionnalités de chaque base de données et y gagner réellement par rapport à l’utilisation d’une API de plus bas niveau.
développement facilité dans une approche orientée Domain-Driven-Developpment.

Mais la perspective la plus intéressante est l’émergence de solutions unifiées de mapping objet/base permettant de limiter les spécificités à chaque base. Spring Data et Hibernate OGM ont un potentiel intéressant car ils ouvrent la voie vers une abstraction de plus haut niveau pour des implémentations et surtout des concepts de stockage de données très divers.

En s’attaquant à ces problématiques de mutualisation, ces projets attaquent la question complexe des frontières entre ces différents concepts :

Peut-on espérer avoir une abstraction suffisante pour passer d’une manière transparente d’une implémentation relationnelle à certains modes de stockage NoSQL?

Spring Data tente d’adresser ce problème avec le socle commun du framework et le projet Spring Data Mapping, de même qu’Hibernate OGM en réutilisant Hibernate Core pour Infinispan. Mais il faudra être très prudent sur ce point et ne pas tomber dans le piège de vouloir faire du relationnel classique dans une base clé-valeur ou document par exemple, en risquant de perdre les avantages de ces représentations.

Dans quelle mesure peut-on outiller les développements pour utiliser conjointement et de manière transparente plusieurs systèmes de représentation des données?

Dans ce sens, Spring Data adresse directement cette frontière, avec la notion d’entités partielles pour l’API Graph : une même application peut être amené à utiliser plusieurs techniques de stockage conjointement, et nous avons besoin d’outils pour faciliter ces développements.

Finalement, les deux projets étudiés ici adressent un point essentiel : le mouvement NoSQL ne propose pas simplement de nouvelles techniques de stockage, mais vise surtout à adresser les solutions adaptées à chaque problème, en arguant le fait qu’il n’existe pas de solution unique parfaite.

L’écosystème autour de NoSQL et du stockage distribué est bien vivant, et surtout il est bien parti pour gagner en maturité et en accessibilité pour les développements Java. On suivra donc avec attention la sortie des premières versions définitives!

Suggestion d'articles :

QCon London 2011: un peu de process, beaucoup d’architecture et de la performance pour passer à l’échelle

Marc Bojoly — Wed, 23 Mar 2011 08:06:48 +0000

Il y a une semaine, avait lieu la 5° édition de QCon, un événement incontournable pour l’architecture de SI, pour sentir les tendances de l’industrie, pour détecter quelques nouveautés. 6 tracks parallèles, un total de 90 sessions. Impossible de participer à tout mais voici ce que nous en avons envie de retenir :

Des sujets d’actualité…voire innovants

Agile, c’est maintenant au tour de l’entreprise

Cela passe par l’organisation des équipes et la keynote d’ouverture par Craig Larman nous le rappelle. Cela confirme également la tendance du marché vers ces pratiques de développement logiciel ou produit (puisque C. Larman a notamment parlé de retours d’expérience chez Xerox) : il ne s’agit plus de convaincre que c’est une manière efficace de “faire du logiciel” mais de voir comment améliorer ces processus et passer à l’échelle. Alors “Features teams are better than component team” Craig Larman dans le texte et il s’agit de privilégier un découpage du produit en domaine qui ont chacun leur organisation scrum, leur PO, leur équipe pluridisciplinaire. En somme une organisation vue du client et pas vue de l’architecture (Loi de Conway). Dès lors, il est néanmoins important de formaliser des “Communities of Practices” : des rencontres d’experts (donc des personnes qui partagent des sujets et des problématiques communs) cross-team et finalement transverses à l’organisation, des lieux et temps de rencontre formalisés pour échanger, partager, progresser, cultiver le sentiment d’appartenance (vous n’avez qu’à regarder toutes les rencontres/échanges que mettent en place les plus grands cuisiniers français…). Enfin, il faut rappeler que le sprint règle et rythme la vie du produit, pas de l’équipe et on tentera de colocaliser les équipes par domaine.

Cela passe également par l’organisation au sein de l’équipe. Roy Osherove l’a vécu et l’affirme « Most team leaders use the wrong kind of leadership for the current team stage”. Il définit ainsi différents niveaux de maturité d’une équipe et rappelle que trop souvent est faite l’hypothèse qu’une équipe agile est auto-organisée et doit seulement être coachée alors que souvent, il s’agit de faire grandir son équipe et adapter son management au niveau de progression de l’équipe.

Cela passera également par la “prod” et c’est dans cette mouvance que s’inscrit le mouvement devops. On notera l’agréable session de Jez Humble qui prolonge des choses que nous avions évoqué lors d’USI 2009. Il y a un enjeu fort à fiabiliser les mises en production et les “remediation patterns” y participent (Cf. plus bas). A noter que Jez Humble sera présent (ainsi que John Allspaw) à USI 2011

Pour aller plus loin, Dan North et Chrid Read (DRW Trading) étaient là pour nous parler de “Agile Operations”, issue de la culture devops (rapprochement entre les pratiques/outils des études et production) et de “Lean Operations” (dirigé par la théorie des contraintes dont l’auteur principal est Eliyahu M. Goldratt) avec pour objectif de réduire les gaspillages. Trois exemples concrets : superviser en une ligne de shell avec ping et mailx (ça rappelle le Taco Bell Programming), automatiser la configuration système à l’aide de Puppet/Chef pour éviter les process complexes et interminables entre la commande et la livraison d’environnements configurées ou encore améliorer la stabilité du système par du test-driven infrastructure (ex: pre-commit hook SVN pour valider la conf réseau avant même de commiter, utiliser sentinel pour tester en continu l’état du réseau, etc.).

Distributed Data Storage & nosql : un sujet d’actualité dans les industries de la Finance et du Web.

Distributed Data Grid et solutions NoSQL ont suivi des chemins différents mais adressent des sujets similaires. D’un côté, on est passé par la mémoire (shared memory), de l’autre par la parallélisation (shared nothing). D’un côté, le besoin d’optimiser la latence (une obsession dans le domaine financier), de l’autre, le besoin d’absorber des débits de requêtes de plus en plus importants, Latence vs. débit. Quoiqu’il en soit, tout cela semble converger, à simplifier le contrat & ACID, à sortir de la contrainte du schéma (imposée par le RDBMS) – car un système de stockage doit être capable de gérer plusieurs versions de données - tout cela cherche à sortir de la contrainte du disque – car les accès mémoire sont 100x plus rapides que les accès disques – c’est d’autant plus vrai que l’infrastructure a évolué depuis les RDBMS avec un offre de RAM de plusieurs Go. Cela n’est pas sans rappeler ces deux papiers de 2008; (1) OLTP Through the Looking Glass, and What We Found There et (2) The End of an Architectural Era.

Alors certes, les Distributed Data Grid ont trouvé leur place dans le monde de la banque et NoSQL dans le monde du web. NetFlix nous a raconté sa stratégie et sa mise en oeuvre de migration vers AWS plutôt que de recontruire un nouveau Data Center. Les difficultés qu’ils ont rencontrés avec SimpleDB semblent corroborer ce qui est écrit dans ce papier. Bref, ce n’était pas de la publicité pour SimpleDB; bien au contraire et, à tort ou à raison, cela semble justifier leur choix de migrer vers Cassandra (et d’inverstir dans des nouveaux développements notamment au niveau des stratégies de réplication). Facebook nous a fait une présentation des travaux qu’ils réalisaient avec HBase. The Guardian, célèbre journal anglais, a mis en oeuvre MongoDB.

Des acteurs qui s’accordent sur le fait qu’il y a des manques tout de même : des APIs clientes encore trop simplistes (pas de timeout…), des limitations autour de l’upgrade du cluster sans interruption de services….
Reste que d’autres comme Twitter restent sur MySQL et semblent satisfaits . Nick Kallen démontre comment Twitter réalise le stockage des tweets, l’affichage de la timeline et la gestion du graph social dans MySQL (avec notamment l’utilisation de FlockDB ou Gizzard) en fonction des contraintes de performance. Pour info, on y retrouve quelques ordres de grandeurs qui permettent de positionner les contraintes auxquelles est soumise l’architecture : à titre d’exemple, 1100 tweets sont écrits par seconde. En revanche, la timeline sert 2,1millions de lectures par seconde (la timeline est pré-calculée et stockée dans memcached), et le graphe social doit gérer 20k modification / sec.

A noter que ce domaine est encore en pleine évolution. La preuve avec cette initiative intéressante de Ben Stopord qui part du constat que certaines données doivent être partitionnées et d’autres répliquées; et c’est évident, cela dépend des cas d’usage. Jusque là, “rien de génial” mais l’innovation dans ODC c’est que ce choix réplication vs. partitionnement, bien que définit par configuration en fonction de l’utilisation qui est faite de la donnée (type de requête…), n’impacte que le stockage de la donnée et absolument pas la modélisation qui peut rester relationnelle… Ainsi ODC, basée sur Cohérence, permet par configuration d’assurer ces deux modes de fonctionnement et du même coup de gérer des jointures, des indexations…

En somme, un domaine d’innovation si on le compare à celui des RDBMS mais qui trouve sa place, son terrain de jeu.

Big Memory : Azul, Terracotta…la limite de la JVM à 3 ou 4Go n’est plus acceptable

Une tendance intéressante qui part du constat que les évolutions d’infrastructure nous amènent à des serveurs pouvant proposer sans problème 50 Go de RAM voir plus. Or nos JVMs (enfin les Garbage Collector) ont bien du mal à dépasser les 3 ou 4 Go ce qui conduit inexorablement à une multitude de process en parallèle… avec ce que cela peut impliquer en terme de supervision.
Azul propose sa JVM Zing qui inclue un GC sans pause. Il n’y a donc plus à avoir peur des minutes où le GC tournerait pour faire le ménage dand la heap d’une JVM de 100GB. La seule (grosse) limite actuelle de cette JVM est qu’il faut un noyau Linux patché ou exécuter son application dans une VM (au sens OS, pas une JVM). Dans ce dernier cas, la JVM est remplacée par une JVM proxy qui renvoie tout vers la JVM Zing présente dans une autre VM (Zing Virtual Appliance) avec un noyau patché.
Terracotta propose des extensions à Ehcache; Big Memory, qui vise à contourner la JVM et à utiliser directement la RAM disponible pour stocker de l’information. BigMemory doit bien entendu être couplé à Terracotta Server qui va ainsi rajouter la couche “scalabilité” et persistence.

Les langages fonctionnels et plus particulièrement la programmation orientée acteur continuent leur « bonhomme de chemin »…

A commencer par Erlang; un langage fonctionnel pensé pour construire des applications concurrentes, distribuées et résilientes. Pour cela, il permet la création de processus légers (appelés acteurs) en taille mémoire nécessaire, en temps de création mais aussi en temps d’ordonnancement. Il est ainsi facilement envisageable d’avoir une application avec plusieurs centaines de millier de ces processus. Ces processus sont gérés (créés et schedulés) directement par la VM Erlang évitant ainsi les allers-retours entre le noyau de l’OS et l’espace utilisateur. La philosophie de la programmation par acteurs est « share nothing », contrairement à la programmation par threads. Chaque acteur communique alors avec les autres en envoyant des messages asynchrones et traite les messages reçus les uns à la suite des autres. Ces acteurs travaillent donc tous en parallèle sur plusieurs coeurs d’un même CPU et sur plusieurs CPU distribuées sur plusieurs machines. Enfin et concernant la résilience, en cas de “crash” d’un des processus, les processus préalablement liés sont notifiés et prennent la décision adéquate. Ainsi des patterns tel que « Supervisor & Worker » permettent de configurer une stratégie de redémarrage des workers (combien de redémarrage successif du même worker avant d’abandonner, relancer seulement le worker qui a planté ou l’ensemble des workers supervisés, …). En plus de cela, un certain nombre d’autres mécanismes tel que le déploiement à chaud d’une nouvelle version d’une application, l’activation de cette nouvelle version, le rollback à une version précédente, … apportent aux applications développées en Erlang une disponibilité maximale.

Ce type de programmation n’est pas sans inspirer le développement de nouveaux produits basés sur l’asynchonisme et des approches orientées évènements (type SEDA). Ces approches – à la Node.js , ou encore Tornado visent à dépasser le “C10k Problem” en découplant requête et réponse (qui sera traité dans une callback) et ainsi assurer une meilleure concurrence.

L’objectif de ces outils est ainsi de pouvoir supporter un très grand nombre de connexions simultanées (grand nombre de requêtes à la seconde ou grand nombre de connexions longues (ex: long polling, websocket, …)) et chacun y va de sa solution :

Node.js propose des API IO asynchrones. En effet Node.js n’exécute le code que sur un seul thread qui traite toutes les requêtes en parallèle et switch de requête dès qu’il exécute un appel IO via une API asynchrone. Ainsi le traitement du résultat de cet appel sera traité dans un handler. Cette approche est dite event-driven programming
Erlang et Haskell (qui utilisent aussi des green-threads légers en mémoire, cpu et context switching) présentent un modèle hybride complètement transparent pour le code. Le code est écrit avec des API IO synchrones (plus simple) mais la VM utilise quand cela est possible des appels IO asynchrones (epoll() par exemple) ou utilise le threading classique niveau OS lorsqu’un appel bloquant est obligatoire (accès fichier par exemple). A noter l’initiative de Basho, éditeur de Riak, qui a développé Web Machine ; un condensé d’HTTP.

Au delà de la performance, un des challenge de ce type d’outil (contrairement à la programmation orientée acteur où le mindset, le paradigme est différent) concerne le développement : comment offrir des APIs qui fonctionnent en asynchrone même si le comportement est synchrone et qui n’impactent pas le code, sa lisibilité? quid de l’outillage, du debug etc…

La résilience qui, avec l’efficience des systèmes est certainement un des prochains challenges (enfin…)

Alors la résilience a été au niveau langage avec des plateformes type Erlang qui ont fait leur preuve. La plateforme OTP (Open Telecom Platform) d’Erlang permet de construire une hierarchie de supervision de sous-systèmes à base d’acteurs (en s’appuyant sur le pattern « Supervisor & worker » précédemment décrit) capable de supporter le crash d’un sous-système et de se réamorcer. Ce guide présente plus en détail comment Erlang gère la résilience.

Au niveau des tests où l’on se rend compte que les tests de résilience arrivent très tôt dans le processus de développement, avant même les tests de performance qui nécessitent la mise en place d’infrastructure représentative (voire de réaliser des “parallel runs”)

Mais également au niveau delivery et déploiement avec Jez Humble : les “remediation patterns”. On y trouve des patterns comme :

“feature toggle” qui vise à décorréler le déploiement du code du déploiement d’une fonctionnalité,
le “Canary Releasing” qui vise à déployer une partie de la population sur la nouvelle version de l’application (une solution pour l’A/B testing, les tests de performance…); avec un sujet sur la base de données qui peut être adressé soit en reconciliant les deux bases, soit en stockant des évènements (cf. Event Sourcing) et en rejouant les évènements, soit en assurant la compatibilité ascendante du schéma (certainement la meilleure solution mais celle qui demande le plus de discipline, car le plus important sera de nettoyer le schéma à terme). Ce papier de Google traite malheureusement pas assez en détail de ces sujets.
ou encore l’incremental delivery

Des domaines qui continuent de s’améliorer (et où l’on considère bien souvent que plus rien ne se passe)

La qualité logicielle et la réarchitecturation des systèmes

Rien de nouveau mais ça va mieux en le disant :

“All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”
Grady Booch

Concernant la qualité logicielle, un des sujets est certes de choisir les indicateurs mais surtout de choisir la représentation de ces derniers (et quelques part choisir les façons de communiquer qui seront les plus adaptées). Cela n’est pas sans rappeler le mouvement Data Visualization si cher à notre Joseph national (spécial dédicace :o) ). On utilisera alors à façon treemap facilitant la visualisation de la taille du code, la complexité cyclomatique ou encore des ratios nombre de LOC sur nombre de LOC de tests. A noter qu’il est possible de représenter le code sous forme de ville en 3D avec CodeCity.

Les plateformes telles que Java & .Net continuent de s’améliorer

Alors il y a du classique avec Spring 3.1, Servlet 3.1 ou encore Mono Cecil; une librairie .Net Open Source cross-platform (de .NET à WindowsPhone 7) permettant d’étendre les fonctionnalités de réflexion classiques de la plateforme .NET (par exemple sur les champs masqués derrière une propriété), mais également de manipulation de bytecode. Cela permet de coder simplement des fonctionnalités de type AOP par exemple.

Et du moins classique… Java est adopté dans des environnements sensibles à la performance comme la finance.
StreamBase, un CEP haute fréquence implémenté en Java avec , il faut bien l’avouer, quelques optimisations ou spécificités, notamment sur la gestion du garbage collection ou la génération du bytecode avec Janino (un compilateur à la volée et en mémoire)…. Cameron Purdy, ancien CEO de Tangosol et vice président de Oracle Fusion Middleware a également confirmé cette tendance en présentant plusieurs axes de travail (la sortie de ces travaux n’étant même pas encore confirmée) permettant à Java d’être plus performant (notamment sur la latence, cruciale dans le domaine financier). En bref, pour le moment de la pure R&D, qui sortirait peut-être dans une version 9 de Java, avec notamment

une API pour du bus de message basse latence directement sur RDP/Infiniband ou TCP/IP, JMS étant “trop lourd” dans ce cas. Java chercherai donc à jouer sur le même terrain que ØMQ.
un accès direct et distant à la RAM RDMA sans passer par le noyau (oui, oui vous avez bien compris), pour là encore gagner en latence. Le prix à payer est que ces innovations utilisent très fortement les optimisations (et donc les particularités) de l’OS et du matériel… Les premières implémentations de ces API sont visiblement prévues sur les appliances Exalogic. Issues de la synergie que lui offre désormais un fondeur pour des puces dédiées (Sun), un OS et un hyperviseur maison (Oracle Unbreakable Linux) et une JVM, ces appliances sont les Rolls-Royce d’Oracle sur lesquelles l’éditeur mise beaucoup dans le monde de la finance. Et pour être franc, tout cela sent le “Java propriétaire”…

HTML5 comme plateforme

Mark S. Miller de Google a ainsi présenté les concepts qui sous-tendent la sécurité pour le cross-scripting de ECMAScript (JavaScript) 5. L’objectif est clairement de sortir d’une logique page web et de construire des objets JavaScript qui interagissent entre eux à travers Internet… Un objectif qui n’est pas sans rappeler la notion de “mashup” mais qui surtout nécessitent de repenser la Same Origin Policy.

Même Adobe se positionne sur HTML5 voyant là un standard permettant de cibler le plus grand nombre de plateformes. Cela commence par l’enrichissement de sa gamme de produit; DreamWeaver avec entre autre les nouvelles balises de Sections HTML5, Illustrator capable d’exporter les images en SVG ou Canvas via un plugin. L’apparition de nouveaux outils comme Wallaby confirme cette stratégie permettant aux éditeurs Flash de convertir leurs animations en HTML5 (ciblé bannières publicitaires pour compatibilité iPhone, iPad, etc.), mais aussi de futurs outils à surveiller comme le projet appelé “EDGE prototype” dont l’objectif est de fournir un outil dédié à la construction d’animations orientées timeline, entièrement HTML5 et Javascript, en partenariat avec JQuery. Flash reste dans cette vision la plateforme pour les fonctionnalités innovantes : Peer to Peer, collaboration ou encore 3D (Molehill par exemple).

L’intégration reste un sujet d’actualité (et c’est pas près de s’arrêter avec le Cloud…)

Les frameworks légers type Camel, Spring Integration sont massivement utilisés notamment dans des contextes financiers à très fortes contraintes. John Davies nous a fait une magnifique explication de leur plateforme d’échange qui gère du multi-format, multi-version, du routage et de la conversion FIX, FpML, SWIFT à un niveau de performance impressionnant : 100 000 req/sec avec une latence < 10 ms. Il est clair que la notion Canonical Model a été bien challengé au profit d’un pattern qu’il appelle Integration Object. L’idée est en somme de gérer le routage et la mapping directement en Java (notamment via Jaxen, Saxonica…) et la persistence dans un cache type Coherence ou Gigaspace. En somme de l’ESB ultra léger sur un Data Grid.

Côté exposition de service, l’actualité est largement et encore tournée vers REST. Les maîtres mots étaient contrat minimaliste, souple, plutôt clé/valeur. Le principe REST de navigabilité des ressources trouve une utilisation dans la définition de workflow à travers l’implémentation du système Hypermedia (ici et ici)

Voilà ce que nous avions envie de retenir. Après comme dit l’autre :

“Prediction is very difficult difficult, especially about the future.”
Niels Bohr

Suggestion d'articles :

Exemple d’infrastructure MongoBD : haute disponibilité en lecture

Julien Jakubowski — Tue, 22 Mar 2011 18:20:36 +0000

Imaginons le cas suivant : nous avons une base MongoDB, alimentée exclusivement par des batchs ordonnancés et via un client back office. Les utilisateurs, très nombreux, y accèdent via une application client-serveur. La consistance ne doit être qu’in fine (eventually consistent en anglais). Nous avons donc, en gros, 1 accès en écriture pour 10 accès en lecture. Quelle architecture pourrions-nous mettre en place pour assurer la haute disponibilité de notre base de données et donc nous prévenir de risques comme la perte d’un disque dur ? Comment pourrions-nous nous prémunir facilement contre une corruption et donc adresser la problématique de back up ? Je vais essayer de vous proposer une réponse unique à ces deux questions, en utilisant les fonctionnalités natives de MongoDB alliées aux possibilités offerte par l’utilisation des services proposés par Amazon Web Services…

Préambule

MongoDB en détail

MongoDB est une base données « NoSQL » de type documentaire. Chaque document est stocké sous un format proche du JSON (le « BSON »), dans une collection. Chaque collection est situé dans une base. Un serveur MongoDB expose une ou plusieurs bases.

La particularité fonctionnelle de MongoDB est de pouvoir créer des index, simples ou composites, sur certains attributs de nos documents, et ce, même s’il n’existe pas de schéma. De plus, elle propose un système de requête à base de javascript très simple à la prise en main.

Si vous souhaitez creuser l’utilisation de MongoDB, je vous conseille de jeter un oeil à cet article.

Exemple de cas d’utilisation

Un cas d’utilisation de ce genre d’infrastructure pourrait être la mise en place d’un moteur de recherche sur des données de sources multiples et variées. Notre infrastructure sert à agréger le contenu, à l’exposer à un moteur de recherche puis à l’affichage des résultats de requêtes utilisateurs.

Architecture

Architecture globale

En détail...

La chaîne complète fait intervenir deux environnements: un environnement de pré-traitement, sur lequel se feront les écritures et un environnement « frontal » sur lequel se feront les lectures. Les deux fonctionnent en isolation (d’où la nécessité de deux bases maîtres), le lien étant assuré à l’aide d’un batch de synchronisation. Ce découpage nous permet de concentrer toutes les opérations d’écritures, plus ou moins complexes et donc plus ou moins gourmandes en mémoire et en CPU sur un seul serveur sans impacter la charge en lecture, alors qu’elles se font 24 heures sur 24. Et vice-versa, la charge en lecture (24/24, plusieurs hit/s) n’impactera pas les calculs nécessaires aux opérations d’écriture. L’intégralité des écritures se font sur la base maître du « pré-traitement » alors que l’intégralité des lectures se font sur les esclaves du « frontal ». Enfin, un problème lors de l’intégration des batchs (maître KO, corruption) n’entrainera pas d’impact sur l’accès en lecture, assurant toujours un niveau de haute disponibilité.

Pré traitement

Dans cet environnement, différents batchs ordonnancés alimentent une base MongoDB, à l’aide de données en provenance de services distants et de fichiers. La base MongoDB est répliquée afin de faire face à d’éventuels crashs et de permettre la mise en place d’ un système de sauvegarde sans impacter les opérations d’écritures (voir plus bas). En effet, en cas de corruption de notre base, cette corruption sera répliquée sur l’esclave. Il est donc nécessaire d’avoir une sauvegarde quotidienne afin d’éviter d’avoir à rejouer l’intégralité des batchs. De même, on peut se servir de cette sauvegarde pour alimenter le serveur maître de l’environnement frontal.

Frontaux

Cet environnement est découpé en plusieurs couches. La première consiste en un serveur maître et un premier esclave. Le maître sert exclusivement à la synchronisation avec le pré traitement, afin d’éviter que la synchronisation n’impacte la lecture. L’esclave permet de mettre en place un mécanisme de fail over si le maître venait à crasher. On ferait basculer la synchronisation des autres esclaves vers celui-ci (après l’avoir transformé en maître), ainsi que la synchronisation pré-traitement/frontal.

Les autres esclaves servent à l’exposition des données. Le load balancer aura pour tâche de rediriger les accès sur l’un ou l’autre de ces esclaves.

Et pourquoi pas un Replica Set ?

MongoDB propose un autre mécanisme de réplication, nommé Replica Set. Celui-ci permet de mettre en place un mécanisme de fail over automatique et de load balancing (sur l’écriture) et donc réduit le temps de bascule et d’indisponibilité et améliore les performances. Les serveurs élisent entre eux le Maître. Si celui-ci tombe, une nouvelle élection à lieu pour qu’il soit remplacé. Nous aurions donc pu remplacer l’architecture maître/esclave de notre environnement frontal par celle-ci.

Toutefois, la possibilité de se connecter à un tel montage n’est pas supporté par tous les drivers de langage disponibles (d’après une étude que nous avons fait sur le projet auquel je participe, PHP et Ruby ne le supporte pas à 100%) et c’est relativement complexe à mettre en place. Dans notre cas, cela ne semble pas forcément approprié, n’ayant pas besoin de fail over automatique. En effet si notre maître frontal tombe, les esclaves sont toujours accessibles en lecture et il n’est nécessaire qu’il ne redevienne accessible qu’au moment de la synchronisation entre pré traitement et frontal.

Mise en place

Réplication

Comment mettre en place nos deux groupes de master/slave, en pré-traitement et en frontal ? MongoDB propose un mécanisme natif et asynchrone pour cela.

Master

Pour démarrer un serveur maître, rien de plus simple ! Dans le répertoire bin de votre version de MongoDB, lancer la commande suivante :
mongod --master [--dbpath "emplacement de vos fichiers BSON"]

Grâce à l’argument –master, notre instance de Mongo générera un journal de transaction, qui pourra être consommé par les différentes bases esclaves. Ceux-ci, chaque seconde, vérifient s’il y a eu une nouvelle écriture, et, le cas échéant, la reproduisent. Attention toutefois, ce journal a une taille limitée. Par défaut, il est de 5% de l’espace disque libre, avec un minimum de 1Go pour une machine de 64 bits, mais seulement 50 Mo pour une machine 32 bits. Toutefois, si nous voulons gérer nous même la taille du journal (par exemple 500 Mo), nous pouvons lancer notre serveur maître avec la commande suivante :
mongod --master --oplogSize 500 [--dbpath "emplacement de vos fichiers BSON"]

Cela peut être nécessaire dans le cas de réplications trop lentes par rapport aux nombres de commandes exécutées sur le maître. Dans notre cas, étant sur un serveur 64 bit, la valeur par défaut nous semble suffisante.

Slave

Démarrer un serveur esclave est presque tout aussi simple qu’un serveur maître. Cela se fait via cette commande :
mongod --slave --source "master_host"[:"master_port"] [--dbpath "emplacement fichiers BSON de l'esclave"]

Si nous ne renseignons pas le port du maître, l’esclave essayera de s’y connecter sur le port 27017 par défaut. Attention, si nous tenons de lancer un esclave sur le même serveur que le maître, il ne faut pas oublier d’utiliser l’option –port « nouveau-port » dans la commande de lancement de notre esclave.

Il est possible de créer autant d’esclave que l’on souhaite pour un seul maître. Toutefois, d’après la documentation officielle, au delà d’une dizaine, les performances de réplication ne risquent plus d’être au rendez-vous. De plus, il n’est pas possible de faire de la réplication d’esclave à esclave, du fait de l’absence de journal de transaction.

Chaque esclave va récupérer en temps réel chaque écriture du journal de transaction du maître. Néanmoins, dans le cas où la consistance entre le maître et le ou les esclave n’est pas prioritaire, il est possible de créer un délai entre chaque scrutation du journal grâce à l’option –slavedelay. Par défaut, celui-ci est d’une seconde. Par exemple, pour un délai d’une minute, la commande serait :
mongod --slave --source "master_host"[:"master_port"] --slavedelay 60 [--dbpath "emplacement fichiers BSON de l'esclave"]

A l’opposé, il peut arriver qu’un esclave ne soit plus synchronisé avec son maître (KO durant un certain temps par exemple) et synchronisable (le journal de transaction a déjà flushé certaines opérations depuis le KO de l’esclave). Pour éviter ce genre de problème, il est nécessaire de lancer l’esclave avec l’option –autoresync. L’esclave copiera alors l’intégralité du contenu du maître s’il est désynchronisé. Attention toutefois à votre volume de donnée. Cette opération peut être dans ce cas relativement couteuse pour la maître et l’esclave. Il est donc important de bien définir la taille du journal de transaction pour éviter un maximum un état de désynchronisation de l’esclave.

Enfin, pour revenir à notre architecture initiale, il faut rendre nos esclaves accessibles en lecture. En effet, ceux-ci n’acceptent aucune requête par défaut. Pour ce faire, il est nécessaire d’utiliser une dernière option, seulement activable via le shell mongo. Lancer donc tout d’abord le shell sur votre serveur esclave.
mongo --host "mon_esclave"
Puis, entrez les commandes suivantes :
use admin db.getMongo().setSlaveOk()

Synchronisation base de pré-traitement / base front office

Comment synchronisez notre environnement de pré-traitement avec celui de front office ? L’utilisation d’un batch faisant un simple dump du pré-traitement pour ensuite l’intégrer au maître « frontal » semble être la solution la plus simple avec MongoDB. Voici en détail comment cela se met en place.

Dump

MongoDB permet de gérer très simplement les actions de sauvegarde et de restauration, en local ou à distance. Dans le cas de notre serveur de pré-traitement, il suffit de se mettre dans le répertoire /bin de votre installation de MongoDB et de rentrer la commande suivante pour faire une sauvegarde :
mongodump --host "mon_serveur_de_staging"

Ce dump aura la forme d’un répertoire « dump » contenant autant de répertoire que de base (dont un pour la base contenant les informations d’administration), contenant chacun un fichier BSON par collection, plus un fichier BSON d’index. L’arborescence pourrait avoir cet aspect là :

dump --base1 ----collection1.bson ----collection2.bson ----system.indexes.bson --base2 ----collection3.bson ----system.indexes.bson --admin

Dans notre cas d’étude, notre serveur n’étant alimenté que par des batchs, il est aisé de savoir si des actions d’écriture sont en cours ou non. Dans le cas contraire, il est nécessaire de « flusher » toute les actions d’écriture en cours et d’empêcher qu’il y en ait d’autres. Toutefois, si on ne veut pas faire tomber nos batchs en erreur, il faut, dans ce genre de cas penser à répliquer le serveur de pré traitement et faire le dump sur le répliqua. Quoi qu’il en soit, pour réaliser ces actions, il faut lancer le shell:
mongo --host "répliqua_de_mon_serveur_de_pretrairement"
Puis lancer les commandes suivantes :
use admin db.runCommand({"fsync" : 1, "lock" : 1})

Vous l’aurez compris, « fsync » force le flush, et « lock » verrouille notre base. Les « 1″ ne servent qu’à indiquer le lancement des commandes. Ensuite, il ne reste plus qu’à lancer le dump sur le répliqua.

Pour déverrouiller la base, toujours dans le shell, il faut lancer les commandes suivantes:
use admin db.$cmd.sys.unlock.findOne()

Restore

Une fois le dump produit, il ne nous reste plus qu’à faire l’action de restauration sur le serveur maître de notre ferme de serveurs frontaux. Il est toutefois nécessaire d’assurer l’intégrité de notre base à l’issue de cette commande. Pour ce faire, il faut associer 2 options au lancement de votre commande. La première, –drop, supprimera tout le contenu de notre serveur d’arrivée. Cela évite d’avoir de la duplication de donnée, des conflits d’ids. La seconde, –indexesLast, forcera la création des indexes seulement une fois le contenu de vos différentes bases et collections inséré. Cela permet de se prémunir d’une mauvaise indexation. Au final, voici la commande qu’il faut lancer, dans le répertoire bin de votre installation de MongoDB:
mongorestore --dbpath "mon_master_frontal" --drop --indexesLast "chemin_vers_mon_repertoire_dump"

Limitations

Ce mode de synchronisation offre toutefois de grosses limitations dans la cadre de bases très volumineuses (plusieurs centaines de milliers de documents) et répliquées. On a pu observer des chutes de performances importantes, voire une impossibilité de solliciter nos bases pendant près d’une heure, le temps que la restauration puis la synchronisation soit terminée. Il est donc nécessaire de limiter la fréquence de ces actions, si c’est le mode de fonctionnement qui est utilisé

Finalement, dans notre cas, nous avons décidé d’utiliser une synchronisation par delta, où nous ne poussons vers le serveur frontal que les données qui ont été mises à jour sur le pré-traitement. MongoDB ne permettant pas nativement un tel mode fonctionnement (ne serait qu’un dump par delta), nous avons dû le faire de façon programmatique. Pour cela, nous avons créé un batch, qui extrait du serveur de pré traitement les données modifiées depuis son dernier lancement, identifiées grâce à un timestamp, pour ensuite transmettre les modifications vers le maître des serveurs frontaux. Grâce à ce mode de fonctionnement, nous pouvons maintenir une fréquence élevée de synchronisation (plusieurs fois par jours), sans chute de performance.

Sauvegarde

Afin de se prémunir de toute corruption des données, notamment en pré traitement, il est nécessaire mettre en place des mécaniques de rejeux de nos batchs et de sauvegarde de nos bases. Nous avons décidé de traiter ces deux problématiques à l’aide d’un bucket S3 loué à Amazon. Cela nous permet de nous assurer que le taux de perte de fichiers soit proche du 0%. Voici les différentes mécaniques associées.

Rejeux

Afin de pouvoir rejouer nos batchs de pré-traitement, toutes nos données disponibles sous forme de fichier sont disposées sur le bucket S3. Chaque batch y scrute un répertoire qui lui est alloué pour récupérer les données qu’il doit insérer. Je vous propose de pousser la donnée manuellement à l’aide d’un plug in firefox, S3Fox Organizer. Nos batchs, quant à eu, récupéreront ses fichiers via l’outil en ligne de commande S3cmd.

Pour récupérer un fichier par exemple, lançons la commande :
s3cmd get s3://"mon_bucket"/"mon_batch"/"mon_fichier"

Back up

Pour ne pas avoir à réintégrer l’intégralité des données fournis par les différents batchs, le mieux reste de sauvegarder régulièrement la base de pré-traitement. Pour ce faire, faisons régulièrement un « dump » sur le répliqua, puis sauvegardons le sur le bucket.

Pour ce faire, il n’y qu’à utiliser S3cmd et la ligne de commande suivante :
s3cmd put staging_dump.tar.gz s3://"mon_bucket"/"mon_répertoire_de_sauvegarde"

Conclusion

J’espère avoir pu vous montrer qu’il est très facile de réaliser ce cas d’étude avec MongoDB, un peu de programmation et une petite aide d’Amazon. Bien sûr, cette architecture n’est valable qu’à 3 conditions:

Notre modèle de donnée est adapté à un stockage documentaire. Dans le cas contraire, il vaut mieux étudier une autre solution NoSQL ou une base de données relationnelles classique
La sollicitation en écriture ne nécessite pas une haute disponibilité. Dans le cas contraire, il faudrait étudier une solution à base de replica set, permettant un fail over automatique (avec les limitations que cela implique sur les technologies permettant de s’y connecter).
Le volume de données d’une collection nous permet d’avoir des temps de traitement correct lors de l’agrégation. Si ce volume venait à augmenter drastiquement et que les temps d’agrégation en entrée devenaient trop long, il faudrait envisager une architecture à base de sharding, ce que propose nativement MongoDB.

Suggestion d'articles :

Scribe, Chukwa…des collecteurs permettant d’alimenter le HDFS

Olivier Mallassi — Sat, 08 Jan 2011 21:15:00 +0000

HDFS, que nous avons déjà évoqué, reste un système de fichier distribué et il faut donc l’alimenter. Il y existe plusieurs options :

à la manière batch. La première option est donc de continuer à collecter les données sur un système de fichier local et de les importer sur le HDFS par vacation. La seconde option serait d’utiliser un ETL. Pentaho a annoncé le support de Hadoop pour sa solution Data Integration Product. Les premiers tests que l’on a réalisé nous montre que cela fonctionne mieux pour extraire de la donnée du HDFS (via Hive) que pour l’importer (après, ce n’est certainement qu’une question de temps avant que Pentaho fasse le nécessaire). La troisième option serait d’utiliser Sqoop. Sqoop permet d’extraire ou d’importer des données depuis votre RDBMS en utilisant un algorithme de Map/Reduce.
à la manière « fil de l’eau ». Dans ce domaine, les solutions se prénomment Flume, Chukwa (qui fait partie du projet Apache Hadoop) ou Scribe. En somme, vous collectez et aggréger des données, de différentes sources, différentes applications, différentes machines « au fur et à mesure ». Toutes ces solutions fonctionnent globalement de la même manière. On peut cependant noter que Flume ou Chukwa proposent une typologie de connecteurs plus riches que Scribe dans la mesure ou par exemple, il est possible de ce connecter en « tail » sur un fichier etc, etc…Chukwa est également plus simplement intégrable avec la stack Hadoop que ce que peut l’être Scribe.

Reste que c’est Scribe, massivement utilisé chez Facebook, que nous allons décortiquer dans cette article (en anglais)…

Suggestion d'articles :

HDFS, Hadoop & co…