Télécharger

Quels choix de base de
données pour vos projets
Big Data ?
Big Data ?
Le terme "big data" est très à la mode et naturellement un terme si générique
est galvaudé. Beaucoup de promesses sont faites, et l'enthousiasme pour la
nouveauté technologique et pour les nouvelles opportunités qui s'ensuivent
tendent à faire passer les éventuelles limitations et contraintes au second
plan. Quand on gratte un peu, beaucoup de technologies prometteuses
viennent avec des limitations qu'on aurait tort d'ignorer.
Cette présentation proposera une vue pratique du domaine du big data, en
définissant le problème et en présentant d'une manière succincte les
solutions existantes – avec leurs qualités et leurs défauts.
Avant tout, il faudra trouver une définition pour le "big data". Car en définitive,
quand peut-on réellement parler de big data? Quand on parle de téraoctets,
de peta-octets, d'exa-octets? Ou est-ce que certains projets de la taille du
gigaoctet peuvent être qualifiés de "big data"? Et au fond, est-ce que la taille
des données est le seul critère important? Est-ce même réellement un critère
majeur?
Quels usages pour les données
Une question fondamentale est "que faire avec les données massives".
Il ne s'agit pas simplement de se dire "nous avons beaucoup de
données, faisons du big data".
Plus sérieusement, beaucoup de projets – big data ou pas – sont
lancés sans avoir une vision claire d'où on veut arriver.
L'usage qu'on veut faire des données est une décision fondamentale
pour lancer un projet big data.
A quel niveau de complexité les données Big Data
peuvent-elles prétendre?
Quoi qu'on en dise, il y a toujours un problème d'échelle. La technologie est
encore loin de pouvoir résoudre des problèmes à la fois de complexité et de
taille quelconques.
Le "big data" a ses limites, on pourrait presque parler d'un "principe d'incertitude
d'Heisenberg": plus on a de données, plus la complexité de leur structure et du
traitement qu'on en fait sera limitée en pratique.
Les ordinateurs quantiques promettent de résoudre cette difficulté, mais on
n'est pas encore tout-à-fait prêts à les trouver dans un Apple store…
Le Big Data est il pertinent et / ou réalisable pour
types d’applications
La technologie impose actuellement une série de limitations pratiques aux
solutions big data. Les solutions big data sont rarement entièrement
transactionnelles au sens où on l'entend dans les bases de données disons
"traditionnelles" (c'est-à-dire applicatives).
Les bases de données applicatives restent pour l'instant le paradigme majeur en
informatique (ERP, applications de comptabilité, applications spécifiques dans
divers domaines…) Une base de données à transaction reportée n'est tout
simplement pas envisageable dans un environnement applicatif traditionnel (qu'il
soit client-serveur ou multi-tiers).
Un autre problème typique est celui de la complexité des schémas de données.
Pour un traitement efficace, la complexité (càd par exemple l'intégrité référentielle)
limite la taille des données pouvant être traitées en pratique.
Ces points et d'autres ne posent pas de difficultés pour certains types de
problèmes typiquement traités par les projets big data – mais empêchent ces
solutions de prétendre à l'universalité.
Quid des données non structurées
La question qui vaut de l'or – littéralement.
Malgré une structuration et une codification de plus en plus poussée
des données, 70 à 80% des données (en fonction des analystes:
Gartner, IDC) restent non-structurées (texte libre, documents de type
traitement de texte ou tableur, PDF, rapports en tous genres et en
tous formats, etc.)
ça représente une quantité énorme de données potentiellement
utiles – et utilisables (c'est-à-dire monnayables).
Qu'est-ce que le "Big Data"?
• D'après Wikipedia:
"Big data est le terme définissant un ensemble de données
si massif et complexe qu'il devient difficile de les traiter au
moyen d'outils de bases de données classiques ou
d'applications de traitement de données classiques (…)"
http://en.wikipedia.org/wiki/Big_data
Une Nouvelle Ruée vers l'Or
• La popularité de big data tient en
partie dans les "success stories"
de monétisation de l'information client
• Pour beaucoup, Big Data se résume
à trouver un maximum d'aiguilles (en or)
dans une énorme botte de foin
"Big Data is not about the
amounts of data. It's about
the cool stuff you can do
with Big Data"
(Peter Hinssen)
http://datascienceseries.com/assets/blog/GREENPLUM_Information_is_the_new_oil-LR.pdf
Importance de la Qualité de l'Analyse de Données
Bien sûr, le traitement de données massive échappe largement à la
capacité humaine de traiter l'information – avec le risque que les
analyses (souvent heuristiques) produisent des effets de bords pervers
– ou soient utilisées abusivement par certaines sociétés (voire adaptées
délibérément dans ce but). Si l'on met de coté les buts illégitimes, le
recoupement de l'information devient primordial pour affiner les modèles
– par exemple le recoupement entre information structurée et nonstructurée peut se révéler très précieux.
Approches Big Data Aujourd'hui
• Bases de données "traditionnelles" – càd relationnelles (gros
volumes en solution de type "grid" par exemple)
• Outils d'indexation (p.ex. Apache Lucene)
• Outils de traitement parallèle de données massives
(Hadoop Map/Reduce)
• Bases de données dites "NoSQL", principalement:
– Clé/valeur (p.ex. Redis)
– Orientées "document" (p.ex. MongoDB, CouchBase)
– Orientées "colonne" (Google BigTable p.ex. Cassandra)
• Bases de données NoSQL plus orientées complexité que
volume, typiquement bases de données orientées "graphes"
(p.ex. Neo4J)
Tous ces outils (sauf relationnels et peut-être orientés
graphes) sont dédiés à des catégories de problèmes
spécifiques dans des contextes spécifiques
Apache HADOOP
Outil de bas niveau pour le traitement de données massives
• Pas à proprement parler une base de données: plutôt un
registre passif optimisé pour le traitement
• Pas conçu pour l'édition de données, uniquement pour
insertion et traitement
• HADOOP en soi est une solution très technique et demande
un investissement important en développement
– Divers produits basés sur HADOOP existent pour simplifier le
traitement de données: Hive, Pig, Lingual, Cascading…
– Des bases de données NoSQL sont basées sur HADOOP, p.ex.
Cassandra, HBase
HADOOP est conçu pour le "data mining", pas comme base
de données opérationnelle
Bases de Données NoSQL
Les solutions NoSQL clé/valeur, orientées document et
orientées colonne ont des avantages et limitations assez
similaires
• Orientées vers le traitement de grands volumes de données
• Permettent typiquement une distribution de la charge entre
plusieurs serveurs
• Typiquement optimisés pour l'insertion et l'exploitation, pas
la mise à jour (bien qu'elle soit en général possible)
• Supportent un niveau de complexité des données limité
• Transactions généralement pas ACID (consistance reportée)
Bases de Données NoSQL
• Bien que leur utilisation par des moteurs en ligne (Google,
Amazon, Facebook, Twitter…) les ait popularisés, la réalité
est plus complexe:
–
–
–
–
Amazon est principalement sur Oracle DB
Facebook et Twitter sur MySQL (et Cassandra)
Google utilise principalement BigTable (NoSQL)
Wikipedia et YouTube utilisent MySQL
Sauf exception, ces bases de données sont dédiées à des
besoins spécifiques – l'usage global reste sur SQL
Bases de Données Orientées "Graphe"
NomJF: Gurney
Nom: Bouvier
Prénom: Jacqueline
Nom: Bouvier
Prénom: Clancy
Relation: Fille
Relation: Fils
Relation: Fille
NomJF: Bouvier
Nom: Simpson
Prénom: Marge
Relation: Fils
Nom: Simpson
Prénom: Homer
Prénom2: Jay
Relation: Epoux
Depuis: 19/4/1987
Relation: Fils
Relation: Fille
Relation: Fils
Nom:
Prénom:
Prénom2:
Alias:
Nom: Simpson
Prénom: Abraham
Prénom: Mona
Simpson
Bartholomew
Jojo
Relation:
Bart
Relation: Fille
Frère
Nom: Simpson
Prénom: Lisa
Sexe: F
Relation: Fille
Relation: Fille
Relation:
Nom: Simpson
Prénom: Margaret
Soeur Alias: Maggie
Relation: Soeur
Relation: Soeur
Relation: Victime
Relation: Employé
Nom: Burns
Prénom: Montgomery
Alias: Monty
Bases de Données Orientées "Graphe"
• Permettent de stocker et gérer des relations complexes
entre entités
• Prétendent donc à une universalité supérieure aux bases de
données relationnelles
• Support transactionnel typiquement complet
• Nouveau paradigme (maturité?)
• Approches pas toujours consistantes entre produits, pas de
standardisation
• Capacité de supporter des grands volumes peu claire en
pratique
• Possibilités de distribution de charge (scalabilité horizontale)
typiquement très limitées
Modèle prometteur et d'ores et déjà pertinent pour certains
projets, mais encore trop neuf pour un usage général
Fragmentation des Solutions par Cas d'Utilisation
• Les grands acteurs donnent dans beaucoup de cas l'exemple
du "une base de données par usage"
– Par exemple, FaceBook et Twitter utilisent MySQL pour les
données opérationnelles et Cassandra (+Redis: Twitter) pour des
usages spécifiques pour lesquels le relationnel atteint ses limites
• Clairement, ça implique une multiplication des compétences:
un spécialiste Hadoop n'est pas (nécessairement) un
spécialiste Cassandra et n'est (certainement) pas un DBA ou
développeur MySQL
• Ça implique également la mise en place et la maintenance de
plusieurs systèmes très différents
Cette multiplication des compétences et des systèmes est
envisageable pour de très grosses sociétés comme Google,
Facebook, Amazon, Twitter… Moins pour de plus petites
sociétés
Le Cloud est-il une Solution à la Fragmentation?
http://www.datamation.com/cnews/article.php/3851071/Tech-Comics-Cloud-Computing-Consultants.htm
Une Solution à la Fragmentation
• InterSystems propose une solution technologique très complète
en un seul environnement consistant: Caché
Le grand intérêt de Caché en tant que plate-forme de données est
sa très grande flexibilité qui lui permet de répondre efficacement à
une grande variété de problèmes avec des approches
éventuellement diverses mais consolidables
• Caché est une solution éprouvée, en production dans des
dizaines de milliers d'environnements de tous types et de tous
volumes depuis de très nombreuses années
• Caché a été conçu dès le départ pour une mise en place aisée,
des besoins limités en maintenance opérationnelle et en
ressources système pour une performance optimale