Accueil > Big Data, Forums et Salons > NoSQL Matters 2014 – avenir des solutions NoSQL

NoSQL Matters 2014 – avenir des solutions NoSQL

Nous (Sandèné NDAO et moi) avons eu l’opportunité de participer du 29 au 30 avril 2014 à la conférence NoSQL Matters 2014 à Cologne en Allemagne. Notre expérience dans le domaine NoSQL étant clairement du niveau débutant/curieux, nous avons profité de ces 2 jours de « talks » pour découvrir des use cases  du NoSql, mais également,  avoir un prélude assez riche d’outils NoSQL face à ces use cases. Nous vous racontons par ce billet notre ressenti en rétrospective de cette conférence. Il est à noter qu’autant Sandèné et moi assistions à notre première conférence internationale. Concernant le voyage, l’hôtel ou nous avons séjourné était idéalement placé à 5 min a pied du Inn Mediapark où se déroulait l’évènement.

La conférence

Le programme de la conférence était bien chargé avec 3 « talks » de 45 min de différents niveaux en simultané (7 sessions pour chaque journée). Les thématiques abordées par « talk » étaient effectivement assez variées allant des présentations de produits (majoritairement des sponsors de l’évènement), des use cases, des sessions de live code, des réflexions sur les best practices d’implémentation … https://twitter.com/ghostGuiggs/status/461047316674523136

Ted Dunning a ouvert le bal des talks en dressant un bilan de l’utilisation des nombreuses bases NoSQL (plus de 150 recensées).

Il a aussi évoqué les challenges que ces bases ont à relever dans les années à venir afin de mieux concurencer les bases SQL classiques à savoir les transactions.

Introduction au monde NoSQL

Pour démarrer cette conférence, la présentation intitulée « When to NoSQL and When to Know SQL » de Simon Elliston Ball semblait fortuite. Avec la variété des technologies NoSQL,  ce fut l’occasion de se faire une idée assez claire des outils qui répondent au mieux à la cette thématique. En prélude, il a présenté les technologies de stockage de données, avant et après l’ère SQL, en insistant sur l’enjeu du NoSQL face à l’augmentation et la variété des données mais aussi sur ses avantages à savoir la rapidité de développement, la facilité de migration et les applications analytiques connexes. Parmi ces technologies, on retrouve :

  • Les bases de données NoSQL orientée document telles que MongoDB, CouchBase, RavenDB … Il a souligné la rapidité de mise en place d’une infrastructure sur ces technologies ainsi que la facilité de manipulation des documents JSON en insistant sur le fait que la prise en main nécessitait de se familiariser à de nouveaux langages de manipulation de données et qu’il fallait revoir ses données sous une autre perspective : dénormalisée.
  • ElasticSearch qui est un outil de recherche et de découverte d’informations. Il a présenté l’un des atouts majeurs de cet outil qui est la navigation à facette sous deux angles : un angle SQL montrant toutes les limites de la requête réalisant cette fonctionnalité en termes de performances et un angle NoSQL, tel qu’il est développé sous ElasticSearch.
  • Cassandra qui est une base de données NoSQL orientée colonne et qui offre la possibilité de gérer nativement la cohérence des données pour les opérations de lecture et d’écriture.
  • Les bases de données orientées graphes telles que Neo4j, GraphX et Apache GIRAPH… https://twitter.com/ghostGuiggs/status/461422950521274368
    Un cas d’utilisation (Neo4J) de graphes présenté a été celui des algorithmes des sites de rencontres

Un focus a été fait sur les raisons qui pourraient motiver, pour une application, le choix d’une technologie NoSQL. On note en premier la scalabilité qui est l’apanage de la majorité des bases NoSQL mais qui nécessite tout de même une gestion appropriée des différents clusters. Ensuite, ce choix pourrait être motivé par les utilisateurs finaux de l’application qui peuvent être des analystes, des développeurs ou bien des data scientists.

Coexistence des bases SQL et NoSQL

L’apparition du NoSQL ajoute tout de même une couche de complexité au sein de l’écosystème IT. En effet, tirer entièrement profit du NoSQL nécessite d’assurer la coexistence et de maintenir la cohérence entre ces nouvelles technologies et le système existant (datawarehouse et ODS). C’est dans cette optique que s’ est inscrit la présentation du Dr. Ernst-Georg Schmid intitulée  » Single Point of Entry: Integrating relational and semi-structured data with PostgreSQL ». Il y illustra un moyen technique de centraliser des données sur une seule et unique source, qu’elles soient structurées ou non. Cela a attiré toute l’attention de Sandèné qui avait travaillé sur un projet similaire où il fallait récupérer des tweets depuis l’API REST de Twitter et les stocker sur MongoDB. L’idée était de faire des analyses sur ces tweets avec OBIEE et cela impliquait d’avoir en source une structure relationnelle. Nous avions, in fine, créé un modèle de données relationnel, dans une base Oracle, pouvant héberger au mieux les tweets au format JSON avec comme hypothèse : la structure du document JSON est fixe. Le Dr. Ernst-Georg Schmid présenta donc une manière de mapper des données non structurées dans une base relationnelle, à savoir PostgreSQL. Un tel procédé pourrait sembler utopique car d’après le Dr. Schmid, toutes les organisations ayant essayé d’intégrer leurs données au sein d’une seule base ont malheureusement échoué. Néanmoins, l’intérêt de ce procédé serait d’avoir :

  • Un unique point d’accès aux données
  • SQL comme langage d’exploitation des données quelles que soient leurs natures
  • Une prise en charge de divers drivers
  • Une minimisation des opérations de migration des données

En dehors du fait qu’il soit le SGBD open source le plus avancé du monde, le choix de PostgreSQL se légitime par l’existence de nouveaux types de données adaptés au paysage du NoSQL. Parmi ces types, on retrouve entre autres :

  • JSON pour stocker un document JSON dans une colonne d’une table relationnelle.
  • HSTORE pour stocker des ensembles de paires clefs-valeurs, sachant que chaque clef dans un HSTORE doit être unique.
  • JSONB qui est la fusion des types JSON et HSTORE.
  • CSTORE pour stocker un datastore de type colonne.

PostgreSQL fournit également des fonctions de transformation de données (relationnelles vers ces types et vice versa),  des fonctions de manipulation et d’agrégation. Cependant, les colonnes de ces types ne peuvent pas être indexées de manière transparente. Il est également possible de mapper de manière transparente des données externes, qu’elles soient structurées ou pas, dans PostgreSQL avec les Foreign Data Wrappers (FDW). Ces derniers existent pour les bases de données NoSQL suivantes : MongoDB, CouchDB, MonetDB, Redis, Neo4j et Tycoon. Les données mappées sont de ce fait accessible via les opérations régaliennes d’une base de données relationnelle à savoir SELECT, INSERT, UPDATE ou DELETE.

Thumbs up

« Self healing data step by step » par Uwe Friedrichsen

Un des plus grands défis de la plupart des bases de données NoSQL est le manque de transactions ACID. Ainsi il est très probable de se retrouver avec des données incohérentes tôt ou tard. Le propos de cette présentation était d’offrir aux développeurs 2 outils puissants qui peuvent  aider à se débarrasser des données incohérentes pour de bon dans une base de données NoSQL : Quorums et CRDT (Conflict-free Replicated Data Types).

Quorums aide à éviter la lecture de données périmées et d’affiner la disponibilité par rapport à des exigences de cohérence pendant que les CRDTs donnent un pouvoir d’auto-guérison des données via le partitioning de réseau.

« Building a SPA (Single Page App) in 30 minutes »

Un grand nombre de navigateur Web existe pour rendre faciliter la tâche de créer une application Web monopage pour un développeur. Pour la plupart des cas, seul un backend minimaliste est nécessaire. NoSQL correspond parfaitement pour la création de ce type d’application, car permettant de mettre le modèle de données directement dans la BDD.

Pendant cette session de live code, Mickael Hackstein présentait le framework web  « Foxx » permettant la création d’une application Web monopage. Avec Angular.js pour le frontend, il nous a montré la facilité de modéliser une API backend pointant sur une base de données ArangoDB.

Conclusion

Comme le disait Akhma Chaudri, toute technologie innovante suit un certain cycle de vie et les bases NoSQL ne dérogent pas à cette règle. Elles sont actuellement dans une phase de « Hype » sur la voie de la maturité. Le défi est donc de vulgariser leur adoption par les business.

Plusieurs aspects attirent de plus en plus les utilisateurs vers ces bases NoSQL. D’abord le fait que les bases NoSQL sont « developer friendly ». Comme le montre ce classement mensuel de popularité des base de données, les prédictions de croissance pour l’adoption de ces bases NoSQL sont meilleures que celles qui avaient été faites pour les bases relationneles il y a 20 ans. Ce fut un très intéressant voyage pour tous les 2 où nous avons beaucoup appris. La prochaine étape sera d’avoir la possibilité de tester/implémenter dans un cas client une solution NoSQL adéquate. Tous les supports ont été recueillis auprès des intervenants et ont été postés ici. Vous retrouvez les photos de la conférence ici

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


− deux = 5