Post on 27-Apr-2018
Panorama des solutions NoSQL
AVRIL 2014
Au delà de Hadoop
2
QUI SOMMES NOUS ?
Avril 2014 Au delà de Hadoop
3
SMILE, EN QUELQUES CHIFFRES
1er INTÉGRATEUR EUROPÉEN DE SOLUTIONS OPEN SOURCE
4
5
NOS EXPERTISES ET NOS CONVICTIONS
DANS NOS LIVRES BLANCS
6
EXPERTISE
NOS PRINCIPALES SOLUTIONS
7
QUE FAIT-ON POUR VOUS ?
CONSEIL Cadrage / Audits / Benchmark
AGENCE Identité visuelle / Ergonomie
Accessibilité / Stratégie
Éditoriale / Référencement
EXPLOITATION Hosting / Infogérance /
Maintenance corrective et
évolutive / Support
FORMATION Accompagnement au changement
Formation intra et inter entreprises
INGÉNIERIE Conception / Développement /
Paramétrage
DES SERVICES DE
GRANDE QUALITÉ
POUR UNE
COUVERTURE À 360°
DE VOS PROJETS
8
NOTRE SAVOIR FAIRE
2 livres blancs
Articles sur le blog des experts Smile
Exemples de projets Big Data réalisés
SMILE ET LE BIG DATA
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
9
NOSQL
Avril 2014 Au delà de Hadoop
QU-EST CE QUE C’EST ?
10
NOSQL
QU-EST CE QUE C’EST ?
Avril 2014 Au delà de Hadoop
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)
11
BESOIN N°1
D’une manière générale, il est
préférable de privilégier la scalabilité
horizontale :
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
DISTRIBUER LES DONNEES ET LEUR TRAITEMENT
VS
Scalabilité verticale
Scalabilité horizontale
Avril 2014 Au delà de Hadoop
12
RDBMS ET SCALABILITE HORIZONTALE
Deux problèmes principaux :
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
Le maintien de l’intégrité
référentielle (contraintes) est très
couteux dans une système
distribué.
RDB PICK
TWO OF
THREE
Consistency
Availability Partition
tolerance
RDBMs
CAP Theorem
Avril 2014 Au delà de Hadoop
13
BESOIN N°2
NoSQL ne prône pas l’abandon de SQL mais bel et bien la spécialisation des bases de données
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
SPECIALISATION DES BASES DE DONNEES
NoSQL = Not Only SQL
Avril 2014 Au delà de Hadoop
14
BESOIN N°3
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
ADAPTATION AU CONTRAINTES DE DURABILITE / COHÉRENCE
Avril 2014 Au delà de Hadoop
15
BESOIN N°4
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) ?
ADAPTATION AUX PROBLEMATIQUE D’INFRASTRUCTURE
Janvier 2014 NoSQL : Les concepts
NOSQL
A chaque cas
d’usage
correspond un
type de base
NoSQL
LES DIFFÉRENTS TYPE DE BASES
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)
Avril 2014 Au delà de Hadoop
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
Avril 2014 Au delà de Hadoop
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
Avril 2014 Au delà de Hadoop
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 2014 Au delà de Hadoop
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 2014 Au delà de Hadoop
22
HADOOP ET NOSQL
Avril 2014 Au delà de Hadoop
DEUX MONDES
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 …
SYSTÈME OPÉRATIONNEL
NoSQL et bases relationnelles
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
SYSTEME DECISIONNEL
Hadoop et OLAP
DEUX TECHNOLOGIES
Export des données opérationnelles pour analyse Export des analyses pour utilisation
opérationnelle
MIDDLEWARES
24
NOSQL ET HADOOP
SÉLECTION DE MIDDLEWARES
Avril 2014 Au delà de Hadoop
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
25
APPLICATIONS CONCRÈTES
Avril 2014 Au delà de Hadoop
QUELQUES
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)
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 :
http://github.com/Smile-SA/mongogento
E-COMMERCE
MOTEUR D’OPTIMISATION
Objectif :
• Peser sur l’offre
présentée aux clients
pour vendre plus et
mieux
• Rétroaction des
comportements
utilisateurs
• Fonctionnalités de
recommandations
Collecte de données
•Tracker classique :
•80 variables suivies (session et page)
Agrégation des logs
•Transfert des logs vers Hadoop (HDFS) via Flume
•Script Pig :
•Consolidation par session utilisateur
•Lutte contre le spam de pixel
Valorisation des données
•Script Pig
•ProductRank (popularité de fond + tendance)
•Association terme de recherche + attributs produits
•Scoring autocomplétion
Utilisation
•Indexation :
•Ajout des données valorisées à l’index produits (ElasticSearch)
•Utilisation des données valorisées dans les requêtes
REAL USER METRICS
COMPRENDRE LES PERFORMANCES DE VOTRE SITE
Objectif :
• Comprendre l’impact
des performances sur
les métriques business
• Décider d’un plan
d’action et mesurer
son efficacité
• Offre SaaS mutualisée
• Permettre l’exploration
des données par les
utilisateurs
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
CRM
VISION A 360° DU CLIENT
Objectif : • Niveau d’information
permettant le conseil adéquat
• Déploiement large :
• Service client
• Terminaux mobiles dans les magasins
• …
• Restitution au client
(agrégation de profil)
• Alimentation par import ou API (ESB idéalement)
Couchbase Achat sur le
site
Réclamations
Paiement
Demande de support
…
Vue service client
Vue vendeur
Vue SAV Vue
compta
MERCI !!!