Java et les bases de données

Java et les bases de données
Etat de l’art

14 juin 2012

 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

P. 3

1. Introduction

2. Bases de données relationnelles

3. La mouvance NoSQL

4. Conclusion

SOMMAIRE


P. 4

Java et la sérialisation

1. INTRODUCTION


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



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


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é



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


P. 9

1. Besoins

2. ORM

3. JPA

4. Les limites

2. BASES DE DONNÉES
RELATIONNELLES

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


P. 11

1. Besoins

2. ORM
1. Modèle
2. Exemple avec Hibernate

3. JPA

4. Limites

2. BASES DE DONNÉES
RELATIONNELLES

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)


P. 13  Exemple avec Hibernate
 Configuration
1 fichier de configuration Hibernate (hibernate.cfg.xml)

Déclaration de l’entité



P. 14  Exemple avec hibernate
 Mapping
1 fichier de description XML (classe.hbm.xml) par classe



 Outil
Hibernate Tools pour faciliter la génération JavaXML et SGBDRJava
 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


P. 17

1. Besoins

2. ORM

3. JPA
1. Modèle
2. Exemple

4. Limites

2. SÉRIALISER DANS UN SGBDR


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



P. 19  Exemple
 Configuration
1 fichier de description
• Contexte de persistance
• Déclarations des classes


 Permet de faciliter la gestion des contextes de test



P. 20  Exemple
 Mapping

Déclaration de l’identifant



P. 21  Exemple
 Outil
Plugin Eclipse inclus dans Eclipse WTP
Avec Hibernate



• Avec Hibernate
• Génération automatique des ordres SQL


P. 23

1. Besoins

2. ORM

3. JPA

4. Limites

2. SÉRIALISER DANS UN SGBDR


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 ?


P. 25

1. Technologies

2. Limites

3. Et JPA alors?

3. LA MOUVANCE NOSQL


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


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



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


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



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


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)


P. 32

1. Technologies

2. Limites

3. Et JPA alors?



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


P. 34

1. Technologies

2. Limites

3. Et JPA alors ?



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 …


P. 36

4. CONCLUSION


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


Java et les bases de données

Contenu connexe

Tendances

En vedette

Similaire à Java et les bases de données

Dernier

Java et les bases de données

Notes de l'éditeur