AVRIL Au delà de Hadoop. Panorama des solutions NoSQL

Transcription

1 AVRIL 2014 Panorama des solutions NoSQL

2 QUI SOMMES NOUS? Avril

3 SMILE, EN QUELQUES CHIFFRES 1er INTÉGRATEUR EUROPÉEN DE SOLUTIONS OPEN SOURCE 3

4 4

5 NOS EXPERTISES ET NOS CONVICTIONS DANS NOS LIVRES BLANCS 5

6 EXPERTISE NOS PRINCIPALES SOLUTIONS 6

7 QUE FAIT-ON POUR VOUS? CONSEIL Cadrage / Audits / Benchmark EXPLOITATION Hosting / Infogérance / Maintenance corrective et évolutive / Support DES SERVICES DE GRANDE QUALITÉ POUR UNE COUVERTURE À 360 DE VOS PROJETS AGENCE Identité visuelle / Ergonomie Accessibilité / Stratégie Éditoriale / Référencement FORMATION Accompagnement au changement Formation intra et inter entreprises INGÉNIERIE Conception / Développement / Paramétrage 7

8 NOTRE SAVOIR FAIRE SMILE ET LE BIG DATA 2 livres blancs Articles sur le blog des experts Smile Exemples de projets Big Data réalisés Intégration de MongoDB pour motoriser le catalogue produits du site E-commerce Eclatement de pièces d achat pour rapprochement Mise en œuvre de 2 clusters de données MongoDB 8

9 NOSQL QU-EST CE QUE C EST? Avril

10 NOSQL QU-EST CE QUE C EST? NoSQL prône la spécialisation : Les bases NoSQL sont optimisées pour certains patterns d accès aux données Les contraintes (durabilité, réplication, cohérence, ) adapté au cas d usage Ce sont majoritairement des bases de données opérationnelles : Latence faible Taille moyenne (quelques TO) Remplacement ou complément de SQL (Not Only SQL) Fonctionnalités généralement supportées : Réplication et «eventual consistency» paramétrable Failover automatisé Répartition des données sur un cluster (sharding) 10 Avril 2014

11 BESOIN N 1 DISTRIBUER LES DONNEES ET LEUR TRAITEMENT D une manière générale, il est préférable de privilégier la scalabilité horizontale : Scalabilité verticale VS Matériel moins couteux (commodity hardware) Disponibilité de matériel de machines de rechange. Capacity planning : évolution plus progressive des investissements, ajout de matériel et non remplacement Pour les plus grosse architecture : la limite du scale up est atteinte rapidement Scalabilité horizontale 11 Avril 2014

12 RDBMS ET SCALABILITE HORIZONTALE Deux problèmes principaux : CAP Theorem ACID : les RDBMs classiques sont conçus pour se comporter comme des systèmes transactionnels cohérents. Le maintien de la cohérence des données dans un système distribué n est pas possible en assurant à la fois le partitionnement des données et la disponibilité du système RDBMs Consistency RDB PICK TWO OF THREE Le maintien de l intégrité référentielle (contraintes) est très couteux dans une système distribué. Availability Avril 2014 Partition tolerance 12

13 BESOIN N 2 SPECIALISATION DES BASES DE DONNEES NoSQL ne prône pas l abandon de SQL mais bel et bien la spécialisation des bases de données NoSQL = Not Only SQL Ce n est pas entièrement nouveau : LDAP est un exemple de NoSQL La spécialisation induit de nouveaux paradigmes : Clé-Valeur Documentaire Graphes Orientée Colonnes Les moteurs de recherche 13 Avril 2014

14 BESOIN N 3 ADAPTATION AU CONTRAINTES DE DURABILITE / COHÉREN Toutes les données n ont pas la même valeur La durabilité de la données est l un des critères impactant le plus directement les performances Toutes les solutions n apportent pas les même garanties de durabilité et n utilisent pas les même méthodes Redis dispose d un paramètre général (équivalent à MySQL) MongoDB : laisse au développeur le soin de spécifier la durabilité par requête 14 Avril 2014

15 BESOIN N 4 ADAPTATION AUX PROBLEMATIQUE D INFRASTRUCTURE Deux problématiques distinctes : Distribution des données Réplication des données Le système peut t il être déployé sur plusieurs DataCenter? Impact sur les performances? En cas de perte du lien? Comment est gérée la cohérence entre les différents nœuds? Eventually Consistent (Cassandra)? Localisation du master dépendant des données (MongoDB)? 15 NoSQL : Les concepts Janvier 2014

16 NOSQL LES DIFFÉRENTS TYPE DE BASES A chaque cas d usage correspond un type de base NoSQL Base clé-valeurs Bases documentaires Orienté graphe Base orientée colonne Moteurs de recherche

17 BASE DE DONNÉES CLÉ-VALEUR Offre peu de fonctionnalités : principalement CRUD Performance souvent en pointe grâce à la simplicité du système La plupart des systèmes NoSQL sont avant tout des bases de données clé-valeur Solutions : MemCached Redis Voldemort Amazon Dynamo (SaaS) 17 Avril 2014

18 BASE DE DONNÉES DOCUMENTAIRES Offre plus de fonctionnalités, nottament de requêtes complexes sur les documents : Systèmes de vues : CouchBase, CouchDb Requête MapReduce : MongoDB, Riak Language de requête spécifique MongoDB Mécanisme de hook permettant l extensibilité : CouchDB, Riak Nécessairement, l ajout de ces fonctionnalités à un impact sur les performances Solutions : MongoDB CouchDB CouchBase Riak 18 Avril 2014

19 BASE DE DONNÉES ORIENTÉE GRAPHE Basiquement une base de données orientée graphe est une base de données clé-valeur ou documentaire à laquelle on ajoute : Un stockage de liens entre les objets Une API permettant de parcourir le graphe ainsi formé Cas d utilisation majeurs : Knowledge Graph Réseaux sociaux Recommandations Solutions : Neo4j OrientDB 19 Avril 2014

20 BASE DE DONNÉES ORIENTÉE COLONNE Reprise sur une base clé-valeur d une idée déjà utilisée pour des bases spécialisées dans l analyse (VerticaDB par exemple) : Stocker ensemble toutes les données d une colonne plutôt que celle d une ligne Performances : Rend les fonctions d agrégation plus efficaces (somme, moyenne) Penalise la lecture et l écriture d un objet complet Solutions : Cassandra HBase Accumulo Avril

21 LES MOTEURS DE RECHERCHE Reprise sur une base clé-valeur d une idée déjà utilisée pour des bases spécialisées dans l analyse (VerticaDB par exemple) : Stocker ensemble toutes les données d une colonne plutôt que celle d une ligne Performances : Rend les fonctions d aggrégation plus efficaces (somme, moyenne) Penalise la lecture et l écriture d un objet complet Solutions : ElasticSearch Solr Avril

22 HADOOP ET NOSQL Avril

23 DEUX MONDES DEUX TECHNOLOGIES SYSTÈME OPÉRATIONNEL SYSTEME DECISIONNEL NoSQL et bases relationnelles Latence faible des requêtes (100ms 1s.) Concurrence élevée Lecture / Ecriture Volume de données faibles (Go, To) Applications : Vue donnes 360, Gestion de commandes, Stocks, Catalogue produits, Content management Hadoop et OLAP Latence importantes des requêtes > 1s. Concurrence réduite Lecture principalement Volumes de données importants (To, Po) Applications : BI, Analytics, Détection fraudes, Etude de risque, Scoring, Search Quality Export des analyses pour utilisation opérationnelle Export des données opérationnelles pour analyse MIDDLEWARES

24 NOSQL ET HADOOP SÉLECTION DE MIDDLEWARES Chargement de données en masse : Apache Sqoop Agrégation de flux de données : Flume, Scribe, Logstash Event processing : Storm, Akka ETLs : Pig : the Hadoop script ETL Talend, Pentaho Data Integration 24 Avril 2014

25 QUELQUES APPLICATIONS CONCRÈTES Avril

26 DÉVELOPPEMENT PHP SESSIONS ET CACHE VIA REDIS Objectif : Sécuriser les sessions utilisateurs en assurant leur persistance Silo de session par DataCenter Traffic important : concurrence élevée Solution préconisée : stockage dans Redis Avantages : Durabilité paramétrable : bon compromis entre performances et sécurité des données Réplication Mise en œuvre rapide Inconvénients : Sharding au niveau applicatif Cross Datacenter difficile (réplicaiton unidirectionnelle et par shard) Failover manuel (Sentinel) Autres utilisations possibles : Stockage de caches applicatifs Middleware basique (pushsub pattern)

27 E-COMMERCE PASSAGE À L ECHELLE DE MAGENTO Objectif : Réduire l impact du modèle de données de Magento sur les performances Gérer des catalogues de plusieurs millions de produits Solutions hybride de stockage des produits : MySQL : stockage de la référence du produit (clé étrangère dans de nombreux) + stock (données typiquement transactionnelle) MongoDB : stockage des attributs du produits Gains : Augmentation drastique des performances de lecture et d écriture (x10 à x20) Meilleure scalabilité (sharding) et failover automatisé OpenSource :

28 E-COMMERCE MOTEUR D OPTIMISATION Objectif : Collecte de données Tracker classique : 80 variables suivies (session et page) Peser sur l offre présentée aux clients pour vendre plus et mieux Rétroaction des comportements utilisateurs Fonctionnalités de recommandations Agrégation des logs Valorisation des données Utilisation Transfert des logs vers Hadoop (HDFS) via Flume Script Pig : Consolidation par session utilisateur Lutte contre le spam de pixel Script Pig ProductRank (popularité de fond + tendance) Association terme de recherche + attributs produits Scoring autocomplétion Indexation : Ajout des données valorisées à l index produits (ElasticSearch) Utilisation des données valorisées dans les requêtes

29 REAL USER METRICS COMPRENDRE LES PERFORMANCES DE VOTRE SITE Objectif : Comprendre l impact des performances sur les métriques business Modification du tracker de moteur d optimisation pour porter les données de performances Indexation dans ElasticSearch de session Utilisation du framework d aggregation d ElasticSearch Décider d un plan d action et mesurer son efficacité Offre SaaS mutualisée Permettre l exploration des données par les utilisateurs

30 CRM VISION A 360 DU CLIENT Objectif : Paiement Niveau d information permettant le conseil adéquat Réclamations Demande de support Déploiement large : Service client Terminaux mobiles dans les magasins Achat sur le site Couchbase Restitution au client (agrégation de profil) Alimentation par import ou API (ESB idéalement) Vue service client Vue vendeur Vue SAV Vue compta

31 MERCI!!!