Étiquette : noSQL

Note de lecture : Designing Data-Intensive Applications, par Martin Kleppmann

Le par addinquydans Notes de lecture2 commentaires

Note : 10 ; Monumental! Book of the year 2021 !

Une somme de connaissances, cet imposant ouvrage, n’est pas moins que cela. Le titre laisse présager que l’on va parler big data. C’est plus subtil que cela, car il s’agit avant tout les principes et mécanismes fondamentaux des grosses architectures data, certes en faisant référence aux classiques du marché, pour comprendre les spectres d’utilisation des différentes solutions. On va donc y parler stockage, systèmes réparties, transactions, streaming, etc. Et ce n’est pas du léger.

Léger, l’ouvrage ne l’est clairement pas vu de l’extérieur (et comme nous le verrons, cela va se gâter à l’intérieur) : 550 pages divisées en 3 parties pour un total de 12 chapitres. Nous avons donc des chapitres très conséquents, il n’y a aucun doute. La première partie traite des fondamentaux. Cela couvre 150 pages sur 4 chapitres. C’est une introduction en douceur, le propos y est tout à fait abordable. Le premier chapitre, fort d’une vingtaine de pages, nous invite à comprendre ce qu’est un système fiable, scalable et maintenable. Il ne s’agit pas juste de généralités, car l’auteur y présente ainsi la structure des données dans les SGBDR, dans un système de streaming tel que Storm. On y apprend ce qu’est un percentile et beaucoup d’autres choses. Bref, un chapitre en douceur mais solide, épaulé par une trentaine de références bibliographiques.

En débutant le chapitre 2, j’ai été frappé par la gravure représentant la table des matières du chapitre. Le premier chapitre en avait une aussi, ainsi qu’en fait tous les chapitres du livre ! Modèles de données et langages de requêtes sont au menu de ce chapitre diablement passionnant. Non seulement on rentre en profondeur dans les structures des différents modèles de données et les paradigmes des langages de requêtes, qu’ils soient déclaratifs ou impératifs, mais l’auteur nous donne un éclairage historique remontant au Codasyl. Brillant.

Lire la suite →
Publicité

Note de lecture : Seven Databases in Seven Weeks, par Eric Redmond & Jim R. Wilson

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; 7 livres compressés en un seul.

Je sais que j’aurais dû, mais non je n’ai pas pris plaisir avec ce livre. Mais reprenons depuis le début. Cet ouvrage est calqué sur l’approche de « Seven Languages… ». Le principe est simple : les auteurs abordent 7 bases de données en nous proposant une initiation à chacune d’entre-elle sur 3 jours.

Chaque chapitre est consacré à une base de données, et chacun d’entre-eux est effectivement structuré en 3 parties, soit 9 chapitres en comptant introduction et conclusion pour un total de 310 pages environ. Le tout est très dense et la pente est rude pour chaque chapitre. Elle est d’autant plus rude pour moi que les langages de prédilection choisis sont Ruby et JavaScript (même quand ce n’est pas le langage naturel de la base), que je ne connais pas plus que je ne les apprécie car il s’agit de langages dynamiques.

Je passe l’introduction qui dresse un panel des différentes bases et des paradigmes sur lesquels elles s’appuient. Le second chapitre est consacré à PostgreSQL. C’est du relationnel, je suis en terrain connu. Les premier et second jour vont assez bien, même si on monte assez vite dans les tours avec les fondements mathématiques, les Windows functions et autres triggers. On ne perd pas de temps ! Le 3ème jour nous conduit directement dans les spécificités de PostgreSQL avec les cubes multidimensionnels et l’indexation full text. Je me retrouve aux limites de mes connaissance bien plus vite que prévu.

Lire la suite →

Note de lecture : A Little Riak Book 2.0, par Eric Redmond & John Daily

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 2 ; Un livre à décoder plutôt qu’à lire !

Edité à compte d’auteur par un (gros) contributeur Riak, ce livre est assurément petit car il dépasse à peine la centaine de pages. Il n’a pas non plus d’ISBN ce qui est hélas un premier indice sur sa qualité éditoriale. Autant le dire tout de suite : elle est médiocre.

Je m’attendais à un petit tutorial pour mettre le pied à l’étrier. Si c’est effectivement la cible de ce texte, l’objectif est quand à lui bien raté. La prose fait de nombreux raccourcis qui nous font rater une bonne compréhension. Ainsi l’articulation entre bucket et bucket-type reste-t-elle nébuleuse. L’auteur semble parler de clés hiérarchiques mais … finalement non. Quand aux « rings » on en est encore à se demander comment cela fonctionne. L’ouvrage n’est pas dénué d’illustration ou d’extraits de code ou de configuration, mais c’est plutôt du matériel brut ne soulignant pas ce qu’il y a à voir. Bref : encore raté.

Le chapitre 1 est une courte introduction. Il liste les fonctionnalité de Riak 1 et met en évidence les nouveautés de Riak 2 avec des concepts qui ne sont pas expliqués, donc incompréhensibles. On est bien avancés. Le chapitre 2 aborde les concepts : ce devrait être le chapitre le plus intéressant. Mais là aussi les auteurs parviennent à introduire de la confusion. Il reste toutefois le chapitre le plus instructif.

Lire la suite →

Note de lecture : Neo4J : Des données et des graphes, 2. Déploiement, par Sylvain Roussy, Nicolas Rouyer & Nicolas Mervaillie

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Au théâtre ce soir, avec Sylvain, Patricia, Philippe, Christophe et Brian !

Ce second volume ne s’inscrit pas directement dans la continuité du premier. Le prérequis en est un peu d’expérience solide de Neo4J, lorsque le précédent s’adressait aux grands débutants. En fait, le titre induit un peu en erreur : il ne s’agit pas seulement d’adresser le volet exploitation (qui comptera au nombre des sujets), mais en fait d’aborder son utilisation dans un véritable cas d’étude !

On compte 220 pages pour ce volume de format plutôt réduit, donc plutôt environ 170 pages dans un format plus classique. A cela il faudra rajouter les annexes dont nous reparlerons. Pour cette partie principale on comptera seulement 5 chapitres. Je préfère généralement des chapitres assez courts, ce n’est pas le cas ici, mais le style adopté efface ce que je considère habituellement comme un inconvénient. Parlons-en justement. Le story telling est une technique puissante, qui a la vertu de nous immerger dans le texte, mais peu d’auteurs l’emploient. Ceux de ce volume vont plus loin : l’ensemble du livre (hors annexes) est une pièce de théâtre où l’on découvre la mise en œuvre de Neo4J avec ses fonctionnalités dans les échanges entre les impétrants. On soupçonnera que Sylvain, le sénior de l’équipe ressemble beaucoup à l’auteur principal dont il partage le prénom. Sans doute Christophe et Philippe incarnent-ils donc les deux autres co-auteurs ? Patricia la chef de projet et Ilko le commercial ont des rôles plus marginaux qui servent à l’introduction et au débriefe de chaque chapitre (deux excellentes idées, au passage). N’oublions pas non plus Brian, le stagiaire, qui lui semble complètement idiot.

Lire la suite →

Note de lecture : Neo4J : Des données et des graphes, 1. Prise en main, par Sylvain Roussy

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Un tutorial (vraiment) amélioré.

On a besoin de tutoriaux. Mais en tant que livres, ils n’atteignent pas chez moi des notes très élevées. Mais il arrive qu’on en rencontre de très correctes. Ce volume est de ceux-ci. L’objet lui-même accuse un format plus petit que les éditions habituelles du même genre, tout en étant nettement plus grand que le format poche. Pratique pour lire dans les transports. Toutefois, si la finition extérieure est correcte, la qualité est un peu faible. C’est probablement le prix à payer d’un tout petit éditeur. C’est malheureusement aussi vrai de la mise en page et de l’impression qui sont assez moyennes. Mention spéciale aux polices grisées vraiment peu lisibles. Pour les diagrammes c’est pire : ils se décodent avec peine et le texte à l’intérieur est illisible.
Heureusement pour nous, le fond prédomine sur la forme et là c’est nettement mieux.

Comme je l’ai dit, l’ouvrage est de petit format. Il compte 220 pages, mais seulement 190 pour le texte principal, le reste constituant des annexes. De ces dernières, seul l’aide-mémoire Cypher m’a semblé de quelque utilité. Le texte s’adresse aux grands débutants, aussi si l’on a quelques connaissances de Neo4J, le livre s’avale assez vite. Tant mieux car question découpage, ce n’est pas ça : on compte seulement 4 chapitres pour tout le livre !

Le premier chapitre ne compte que 15 pages et nous permet de découvrir Neo4J. Il couvre bien les éléments de base : ce qu’est une base NoSQL en général et une base graphe en particulier, les différentes versions de Neo4J et les bases de son installation. Là où ça se gâte, c’est lorsque l’auteur nous propose des requêtes de base sur l’outil, mais sans expliquer celles-ci. Il s’agit d’un choix délibéré, mais qui me laisse dans l’expectative.

Lire la suite →

Note de lecture : Elasticsearch in Action, par Radu Gheorghe, Matthew Lee Hinman & Roy Russo

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 3 ; Aussi passionnant qu’un manuel de référence !

J’aime bien la série « in action » de chez Manning. On n’y trouve pas les œuvres du siècle, mais grâce à un processus et une discipline éditoriale très strictes, ils sont souvent très bons, plus rarement moyens et rarement dessous. Hélas, le présent ouvrage tombe dans cette dernière catégorie. Je voulais en savoir plus sur Elasticsearch, en comprendre le paradigme, l’architecture et les cas d’utilisation. Les 370 pages de l’ouvrage ont fait un travail médiocre à cet égard. Passé les 3, peut-être les 4 premiers chapitres, ce ne furent plus que litanies pénibles de fonctionnalités, des lignes de cUrl, avec ses Json en entrée et en sortie, le tout jusqu’au bord de l’étouffement. Faisons un (rapide tour de ces 11 chapitres.

Le texte est découpé en 2 parties. La première d’entre-elle contient la majeure partie du texte, c’est à dire 8 chapitres, soit près de 260 pages. Les 20 pages du 1er chapitre donnent une vue de haut niveau du produit, ainsi que des informations pour l’installation. Rien de bien concret, mais c’est agréable à lire. Le chapitre suivant consacre ses 30 pages à rentrer dans le dur : l’architecture et la gestion des clusters, mais aussi la gestion des documents, des index et des shards. Il s’agit probablement de mon chapitre préféré.

Presque 30 pages sont également dédiées au chapitre 3 : création, mise à jour et suppression des index. Si on commence quelque peu avec le « mode catalogue », on n’en souffre pas trop à cette étape, les explications restant claires, et puis on est au cœur du produit ! L’horizon s’assombrit plus avec le chapitre 4 et l’exploration des différentes recherches et des options. Beaucoup de requêtes et de Json, déjà…

Lire la suite →

Note de lecture : Storm Applied, par Sean T. Allen, Matthew Jankowski & Peter Pathirana

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Clair sur la mise en jambe, mais insuffisant sur la gestion en production

J’ai une affection particulière pour Storm, car j’ai activement participé à l’amener dans un projet à une époque où les frameworks Big Data temps réel et plus particulièrement Storm n’étaient pas pris pour acquis. Il aura fallu attendre près de 2 ans de plus pour voir apparaître un ouvrage dédié de bonne facture. Comme nous le verrons, ce dernier ne se limite pas à Storm sensu-stricto.

Le présent ouvrage accuse ses 250 pages totalisant 9 chapitres. Des chapitre relativement longs en moyenne selon mon standard, donc. Le premier d’entre eux ne l’est pas, car il ne pèse que 10 pages. C’est une introduction de haut niveau dont le but est de camper la place de Storm dans le mode du Big Data, et plus précisément dans celui du Big Data temps réel que les auteurs re-segmentent en « stream » et « micro-batching ». En passant, les auteurs positionnent Storm par rapport non seulement à Hadoop, mais à Spark, Samza et Kafka Stream.

Le chapitre 2 est d’avantage dédié architecture et présente les concepts centraux de Storm : Typologie, Tuples, Bolts et Spout. Le tout est abondamment illustré, y compris par des extraits de codes qui ont le bon goût de ne pas être trop longs. L’homme pressé qui n’a pas trop de temps à consacrer pour comprendre Storm y trouvera à se nourrir ! J’avoue que je trouve ce chapitre particulièrement réussi.

Lire la suite →

Note de lecture : Making Sense of NoSQL, par Dan McCreary & Ann Kelly

Le par addinquydans Notes de lectureLaisser un commentaire

Note 4 ; NoSQL plus ou moins décrypté pour le manager

Voici un ouvrage « à priori » destiné aux managers. En tout cas son objectif est de donner une image du paysage NoSQL sans nécessité de voir une ligne de code. Dans le principe, le livre atteint son objectif : il couvre les différents types de bases NoSQL, avec toutefois un biais marqué vers les bases XML (qui ne sont généralement pas considérées comme des bases NoSQL), ces dernières ayant droit à leur propre chapitre contrairement aux autres ! Mais le texte me laisse quand même un sentiment d’inachevé, il ne permet pas vraiment de comprendre les patterns d’usage des différentes bases par manque de parti pris.

L’ouvrage est assez conséquent pour une introduction. Il compte 275 pages réparties sur 12 chapitres. Ceux-ci sont eux-mêmes regroupés en 4 parties. La première d’entre-elle est une introduction, courte d’un peu plus de 30 pages et de deux chapitres. Le premier répond au « pourquoi » en exposant succinctement quelques cas d’études des grands du Web, c’est hélas très superficiel. Le second s’attaque aux concepts : documents, sharding, théorème de CAP, cache, etc… C’est un peu brouillon et j’aurais préféré y voir une bonne exposition des typologies de bases.

Lire la suite →

Waiting for the Storm…

Le par addinquydans Compte-renduLaisser un commentaire

Le Storm User Group, c’est une initiative de quelques collègues autour du « big data temps réel ». Aujourd’hui, nous parlons de Storm et quelques infrastructures qui peuvent s’y connecter. Demain, il s’agira peut-être de Spark ou d’autres…

Halte là ! Je vais peut-être un peu vite ? Et d’abord, Storm, qu’est-ce que c’est ? Voilà une question à laquelle une partie de cette première rencontre va être consacrée.

Oui, Storm, qu’est-ce que c’est ?

C’est Florian Hussonois qui va répondre à cette question. Nous pourrions résumer la chose en déclarant simplement qu’il s’agit d’un Hadoop « temps réel ». Il s’agit en quelque sorte d’un middleware permettant le traitement d’évènements en mode flux.

Un (petit) peu d’historique

Storm a été développé par Nathan Marz chez BackType en 2011. La société est rachetée ensuite par Twitter qui promeut le projet et le passe en Open-Source. La première release officielle date de 2011. En Septembre 2014, le projet devient officiellement « Apache Top Level Project » alors même qu’il n’a pas encore atteint la release 1.0 !

Ecrit principalement en Clojure et en Java, ce « processeur d’évènements » est conçu pour traiter un flux de très nombreux évènements (des tuples dans la terminologie Storm), à savoir 1 millions de tuples par seconde et par noeud (1 seul coeur processeur), avec tolérance aux fautes, gestion de la scalabilité et garantie de traitement !

image

Lire la suite →

Neo4J contre SAP Hana

Le par addinquydans Compte-renduLaisser un commentaire

Il y avait un petit moment que l’on n’avait pas eu de meetup Neo4J sur Paris ! C’est donc avec une façon un peu provocante d’aborder un sujet à connotation BI que nous avons été invités !

Nous étions environ 30 à nous rendre ainsi dans le showroom Zenika.

image

Introduction

Cédric Fauvet, toujours égal à lui-même nous fait son habituelle introduction sur les graphes. Presque habituelle, devrais-je dire, car il fait un peu évoluer son propos de meetup en meetup, tout comme son support.

image

Aujourd’hui, le spectre des problèmes couverts par les bases orientées graphes couvre :

  • La collaboration
  • Le SCM
  • L’analyse géo-spatiale
  • L’étude des interactions moléculaires
  • L’analyse d’impact
  • Le MDM
  • La gestion de lignes-produit
  • Et bien entendu la recommandation et les liens sociaux !

En Juin, Neo4J France devrait nous gratifier d’une présentation d’un projet « Dropbox-like » réalisé par des étudiants !

Cédric attire également notre attention sur le talk de Volker Pacher expliquant pourquoi Neo4J augmentait la capacité de delivery de Shutl (acquis depuis par eBay).

Il est l’heure de la pause pizza, nous allons bientôt attaquer la pièce maîtresse de la soirée !

image

Analyse des tickets de caisse avec Neo4J

Nicolas Mervaillies et Charles Besselièvre nous présentent le projet qu’ils ont développé pour « un grand client retail ». Il s’agit d’un petit projet, c’est à dire moins de 100 j/h, qui devait être développé rapidement. Sur les projets analytiques orientés « real time », cette enseigne s’appuie généralement sur SAP Hana. Mais ce projet tactique présente des échéances de temps incompatibles avec ce type de projet, plus adapté à des solutions légères menées en agile.

image

La problématique est essentiellement simple : trouver des corrélations d’achats. Vous savez, celles qui ont permit de déterminer que les couches culottes sont souvent achetées en même temps que le bière le samedi ou qui ont permit à une enseigne d’apprendre via des bons d’achat à une jeune fille qu’elle était enceinte avant qu’elle même ne le sache ! Ici les corrélations doivent être croisées entre magasins et entre régions. Pour chaque magasin, il faut compter une volumétrie de 300 millions de lignes de ticket par an.

Phase 0 : Prototypage

Pour cela on utilise simplement la console Neo4J ! En fait, on ne représente pas chaque ligne d’achat en liaison avec le ticket de caisse : on agrège ces lignes par sous-familles. Bien sûr, les tickets sont associés à une date, un client et un magasin.

Grâce à cela, on voit avec Cypher si l’on parvient à produire les analyses que l’on souhaite.

Phase 1 : Construction initiale

Premier fonctionnement en production : les données de ticket de caisse sont récupérés tous les mois et injectés avec Spring Batch. Le client peut agréger les données en live via des requêtes Cypher : dans le temps, par famille de produits, par magasin.

Les couplages repérés avec de forts pourcentages sont donc mis en exergue dans certains magasins, on compare les éléments différenciants des magasins ayant de moins bons taux de corrélation !

On a toutefois un problème : trop de lenteurs, dû aux fortes volumétries, mais aussi au déploiement de Neo4J sur des serveurs virtualisés. La virtualisation et les bases de données, ce n’est pas le grand amour, même si certains ingénieurs système essaient de se convaincre du contraire !

Phase 2 : Focus sur le « top 15 »

En analysant les données des différents magasins, on perçoit dans le temps des réccurrences d’association, notamment dans le « top 15 ». Nos artistes choisissent donc de précalculer les associations significatives, celles correspondant au « top 50 » de chaque magasin, mais sans Marc Toesca !

Phase 3 : Optimisation de production

En dernière phase, il faut finalement réaliser des optimisations purement de production : gestion de l’infrastructure, mise en place de cache, etc…

En conclusion…

L’utilisation de Neo4J est parfaitement adaptée à ce type de projet tactique : on a la rapidité de de mise en place et la vitesse d’exécution de ce projet typique d’un projet agile ! Par rapport à SAP Hana, on gagne réellement en time to market !

L’équipe a aussi développé un front-end pour faciliter l’utilisation du système. Mais à la limite, cela aurait pu être omis !

Concernant l’infra : elle a été gérée complètement en interne pour des raisons de non exposition de données sensibles. Toutefois, on a une machine puissante qui ne sert que quelques heures, une fois par mois ! Ce type de configuration se marrie donc bien avec le Cloud.

Enfin, l’aspect communautaire de Neo4J permettant de trouver de l’aide sur les forum a été un plus important !

Faute de disposer du support de présentation, je vous propose ici l’enregistrement de la même session qui s’est déroulée au meetup Neo4J Lillois !

Ce que j’en ai pensé

C’est probablement le meetup Neo4J le plus interactif et le plus convivial auquel j’ai pu assister. Les interventions fort pertinentes d’un connaisseur SAP Hana ont été un gros plus dans la discussion, surtout quand, comme lui, on connait et sait reconnaitre les qualités de ce système. Il est là, juste derrière moi.

Pour clore ce compte-rendu et donner un avis éclairé sur cette confrontation, je le citerai :

« Remplaçons notre argent par notre intelligence ».

Cela me rappelle un peu un slogan des années 70 où il était question de pétrole…