1. Java et les bases de données
Etat de l’art
14 juin 2012
2. ARESU (Architectures, réseaux, Expertise & Support aux unités)
Appui et accompagnement des projets
P. 2
Veille technologique
Capitalisation des compétences techniques
Participation aux communautés informatique
Guillaume HARRY
11 ans d’expérience en tant que DBA
7 ans d’expérience en J2E
Expertise accès aux données
Responsable des cellules « Bases de données » et
« Gestion des identités »
Participation à la cellule « Développement »
Étude sur les failles de sécurité des applications Web
https://aresu.dsi.cnrs.fr/IMG/pdf/failles_de_securite_v1-3.pdf
Guillaume HARRY l ARESU
3. P. 3
1. Introduction
2. Bases de données relationnelles
3. La mouvance NoSQL
4. Conclusion
SOMMAIRE
Guillaume HARRY l ARESU
4. P. 4
Java et la sérialisation
1. INTRODUCTION
Guillaume HARRY l ARESU
5. 1. Introduction : Java et la sérialisation
P. 5 Modèle en couche
L’interface graphique ne doit pas manipuler directement
les données stockées
La couche d’accès aux données doit être la seule
responsable de la sérialisation des objets métiers
Qu’est-ce que la sérialisation ?
Rendre les objets persistants
Ecrire des données présentes en mémoire vers un flux
de données binaires
Guillaume HARRY l ARESU
6. 1. Introduction : Java et la sérialisation
P. 6 Développement spécifique
XML
Structure le contenu
Pas de véritable outil de gestion des données
SGBDOO
Outil idéal mais ne s’est pas imposé
NoSQL
Outil idéal pour un besoin bien défini
Pas de standards (langage, interface d’accès)
Conclusion
SGBD Relationnel reste un standard
Guillaume HARRY l ARESU
7. 1. Introduction : Java et la sérialisation
P. 7 Pour les bases de données relationnelles
Standard d’accès : JDBC
Langage SQL largement répandu
Maintenance couteuse
SQL propre à chaque SGBDR
Besoin de redévelopper les frameworks de gestion des
accès
Développement spécifique au SGBDR utilisé
Guillaume HARRY l ARESU
8. 1. Introduction : Java et la sérialisation
P. 8 JDO (JSR243)
Interface standard pour la sérialisation
Indépendance vis-à-vis de la solution de stockage
Trop complexe à mettre en œuvre
Peu d’implémentations
Guillaume HARRY l ARESU
9. P. 9
1. Besoins
2. ORM
3. JPA
4. Les limites
2. BASES DE DONNÉES
RELATIONNELLES
Guillaume HARRY l ARESU
10. 2.1 Bases de données relationnelles : Besoins
P. 10 Faciliter le développement de la couche DAO
Ne pas gérer les accès à la base de données
Automatiser la corrélation Objet ↔ Base de données
Guillaume HARRY l ARESU
11. P. 11
1. Besoins
2. ORM
1. Modèle
2. Exemple avec Hibernate
3. JPA
4. Limites
2. BASES DE DONNÉES
RELATIONNELLES
Guillaume HARRY l ARESU
12. 2.2 Bases de données relationnelles : ORM
P. 12 Objectifs
Faciliter
Ne pas gérer
Automatiser
Modèle
Implémentations Java
Hibernate (Jboss)
TopLink (Oracle)
MyBatis (mapping par requête et non par table)
Guillaume HARRY l ARESU
13. 2.2 Bases de données relationnelles : ORM
P. 13 Exemple avec Hibernate
Configuration
1 fichier de configuration Hibernate (hibernate.cfg.xml)
Déclaration de l’entité
Guillaume HARRY l ARESU
14. 2.2 Bases de données relationnelles : ORM
P. 14 Exemple avec hibernate
Mapping
1 fichier de description XML (classe.hbm.xml) par classe
Guillaume HARRY l ARESU
15. 2.2 Bases de données relationnelles : ORM
P. 15 Exemple avec Hibernate
Outil
Hibernate Tools pour faciliter la génération JavaXML et SGBDRJava
Gestion des accès au SGBDR
Guillaume HARRY l ARESU
16. 2.2 Bases de données relationnelles : ORM
P. 16 Exemple avec Hibernate
Gestion des accès au SGBDR
• 1 classe HibernateUtil pour obtenir
une session dans la base de données
• Génération automatique des ordres SQL
Guillaume HARRY l ARESU
17. P. 17
1. Besoins
2. ORM
3. JPA
1. Modèle
2. Exemple
4. Limites
2. SÉRIALISER DANS UN SGBDR
Guillaume HARRY l ARESU
18. 2.3 Bases de données relationnelles : JPA
P. 18 Objectifs
Bénéficier des avantages des frameworks ORM
Indépendance du framework utilisé
Langage standard JP-QL (inspiré de HQL)
Modèle
Implémentations Java
Hibernate (Jboss)
TopLink (Oracle)
EclipseLink (Fondation Eclipse)
Guillaume HARRY l ARESU DataNucleus Access Platform
19. 2.3 Bases de données relationnelles : JPA
P. 19 Exemple
Configuration
1 fichier de description
• Contexte de persistance
• Déclarations des classes
Déclaration de l’entité
Permet de faciliter la gestion des contextes de test
Guillaume HARRY l ARESU
20. 2.3 Bases de données relationnelles : JPA
P. 20 Exemple
Mapping
Déclaration de l’entité
Déclaration de l’identifant
Guillaume HARRY l ARESU
21. 2.2 Bases de données relationnelles : JPA
P. 21 Exemple
Outil
Plugin Eclipse inclus dans Eclipse WTP
Gestion des accès au SGBDR
Avec Hibernate
Guillaume HARRY l ARESU
22. 2.2 Bases de données relationnelles : JPA
P. 22 Exemple avec Hibernate
Gestion des accès au SGBDR
• Avec Hibernate
• Génération automatique des ordres SQL
Guillaume HARRY l ARESU
23. P. 23
1. Besoins
2. ORM
3. JPA
4. Limites
2. SÉRIALISER DANS UN SGBDR
Guillaume HARRY l ARESU
24. 2.4 Bases de données relationnelles : Limites
P. 24 Complexité du modèle
Implémentation des associations
Implémentation de l’héritage
• 1seule table, somme de tous les attributs des classes filles (par défaut)
• 1 table par classe
Persistance par transitivité
Performances
Comment faire avec des données non structurées ?
Guillaume HARRY l ARESU
25. P. 25
1. Technologies
2. Limites
3. Et JPA alors?
3. LA MOUVANCE NOSQL
Guillaume HARRY l ARESU
26. 3.1 NoSQL : Technologies
P. 26 Not Only SQL
Répondre aux besoins
Explosion du volume de données (Big Data)
Données non structurées
Gestion des relations entre les données
Guillaume HARRY l ARESU
27. 3.1 La mouvance NoSQL : Technologies
P. 27 Clé-valeur
Données représentée par couple clé/valeur
Accès rapides
Type de données simples
…
Exemple :
Clé 1
stockage de résultats d’expérience, statistiques valeur
Système de cache
Clé 2 valeur
Implémentations
Voldemort (LinkedIn) Clé 3 valeur
Redis
Riak …
MySQL Cluster 7.2
Guillaume HARRY l ARESU
28. 3.1 La mouvance NoSQL : Technologies
P. 28 Orientée document
Ensemble de clés-valeurs stockées dans un document
Données semi-structurées Document
Pas de support des transactions Champ 1 valeur
Champ 2 valeur
Exemple :
Champ 3 valeur
Catalogue de produits
Champ 4 valeur
CMS …
Implémentations Clé 1 Document
MongoDB Champ 1 valeur
CouchDB Clé 2 Champ 2 valeur
OrientDB
Clé 3
Document
Champ 1 valeur
…
Champ 2 valeur
Champ 3 valeur
Guillaume HARRY l ARESU
29. 3.1 La mouvance NoSQL : Technologies
P. 29 Orientée colonne
Contrairement aux SGBDR,
colonnes différentes pour chaque ligne
Ecritures rapides
Evite des colonnes à NULL SuperColonne
SuperColonne
Exemple Nom CNRS
Valeur
Stockage de journaux d’activité
Colonne
Implémentation Nom Organisme
Hbase Valeur CNRS
Cassandra
BigTable (google) Colonne
Nom Secteur
Valeur public
Guillaume HARRY l ARESU
30. 3.1 La mouvance NoSQL : Technologies
P. 30 Orientée graphe
Information représentée par des nœuds et des relations
entre nœuds Nœud
Accès aux données par les liaisons Champ 1 valeur
Exemple : Arc
Champ 2 valeur
Champ 3 valeur
Réseaux sociaux : apprend
Libellé
Champ 4 valeur
Implémentation
Neo4j Nœud
HypergraphDBChamp 1 valeur
FlockDB Champ 2 valeur
OrientDB
Nœud
Arc Champ 1 valeur
Libellé : connait
Champ 2 valeur
Champ 3 valeur
Guillaume HARRY l ARESU
31. 3.1 La mouvance NoSQL : Technologies
P. 31 Choix de la technologie dépend du besoin, pas du volume à
gérer
Ne sont pas NoSQL
Orientées objet
Hierarchique
Datagrids (hors clé-valeur)
Guillaume HARRY l ARESU
32. P. 32
1. Technologies
2. Limites
3. Et JPA alors?
3. LA MOUVANCE NOSQL
Guillaume HARRY l ARESU
33. 3.2 La mouvance NoSQL : Limites
P. 33 NoSQL est encore récent
Pas de solution idéale
Théorème CAP
Cohérence
Availability
Chaque client a la
Partition tolerance même vue de
chaque donnée à
tout instant
Systèmes CP Systèmes AC
Le système Chaque client
fonctionne malgré la peut toujours lire
partition physique Systèmes AP et écrire
des données
Guillaume HARRY l ARESU
34. P. 34
1. Technologies
2. Limites
3. Et JPA alors ?
3. LA MOUVANCE NOSQL
Guillaume HARRY l ARESU
35. 3.3 La mouvance NoSQL : Et JPA alors?
P. 35 OrientDB est nativement écrit en JPA
Datanucleus : JPA et JDO pour accès
SGBDR,
MongoDB,
Hbase,
LDAP,
Excel,
XML …
Guillaume HARRY l ARESU
37. Conclusion
P. 37 JPA et ORM
Orientés CRUD
Tuning complexe dépendant du framework
Moins performants que des accès bas niveau
NoSQL
Ne remplace pas SGBDR
Administration/exploitation non triviale
Guillaume HARRY l ARESU
38. Java et les bases de données
Etat de l’art
14 juin 2012
Notas do Editor
faire correspondre de manière bijective une table (appelée aussi relation) à une liste d’objets une ligne d’une table (appelée aussi tuple) à un objet un champs de base de données à un attribut d’objet une valeur d’un champs à une valeur d’attribut d’un objet Des modifications du modèle de données ont des répercussions sur les requêtes aux bases, ce qui implique de faire évoluer individuellement les appels jdbc. La maintenance est de ce fait couteuse.
Faciliter le développement de la couche DAO Ne pas gérer les accès à la base de données Automatiser la corrélation Objet ↔ Base de données
On voit que la maintenance est difficile pour la gestion du mapping
Il est possible migrer facilement en utilisant le fichier hibernate.cfg.xml On peut utiliser plusieurs contextes en parallèle pour utiliser plusieurs référentiels de données
La représentation en clé-valeur est la plus simple et est très adaptée aux caches ou aux accès rapides aux informations. Elle considère la valeur stockée comme un bloc de données opaque, la base de données étant agnostique de son contenu. Ce postulat permet en général d’atteindre des performances bien supérieures dans la mesure où les lectures et écritures sont réduites à un accès disque simple.
La représentation en clé-valeur est la plus simple et est très adaptée aux caches ou aux accès rapides aux informations. Elle considère la valeur stockée comme un bloc de données opaque, la base de données étant agnostique de son contenu. Ce postulat permet en général d’atteindre des performances bien supérieures dans la mesure où les lectures et écritures sont réduites à un accès disque simple.
La représentation en document est particulièrement adaptée au monde du Web. Il s’agit d’une extension du concept de clé-valeur qui représente la valeur sous la forme d’un document. Un document contient des données organisées de manière hiérarchique à l’image de ce que permettent XML ou JSON. Étant consciente du contenu qu’elle stocke, la base de données peut alors effectuer des indexations de différents champs et offrir des requêtes plus élaborées.
La représentation orientée colonnes s’oppose à la représentation des tables dans les bases de données relationnelles. En effet, les SGBDR manipulent les colonnes d’une ligne d’une manière statique. Les bases de données orientées colonnes ont une vision bien plus flexible permettant d’avoir des colonnes différentes pour chaque ligne et de multiplier de manière conséquente le nombre de colonnes par ligne. Il en résulte une capacité à stocker des listes d’informations pour chaque clé, et à accéder à des intervalles de colonnes.