SlideShare une entreprise Scribd logo
Hibernate
        vs.
le Cloud Computing
Qui suis-je?
   Julien Dubois

   Co-auteur de « Spring par la
    pratique »

   Ancien de SpringSource

   Directeur du consulting chez Ippon
    Technologies

   Suivez-moi sur Twitter : @juliendubois

                     http://creativecommons.org/licenses/by-nc-nd/3.0/
Nous allons parler
          de ....

   Bases de données
    relationnelles

   Hibernate

   Cache

   NoSQL
Commençons par deux
   idées fausses...
Idée #1: Hibernate est
                  magique

   Il optimise tout seul
    les requêtes SQL

   Plus besoin d’être
    compétent!
Idée #2: Le cloud est magique


   Le cloud permet d'ajouter
    automatiquement des machines
    en fonction des besoins

   Il permet de tenir ainsi les pics
    de charge sans rien avoir à faire
La réalité est différente
   Ne croyez pas 01 Informatique
       Votre base de données ne monte pas
        en charge
       Et Hibernate n'y peut rien...
Les données sont votre
                    problème
   Dans 90% des applications, la base de données est
    le principal point de contention
   Ces données sont stockées dans une base
    relationnelle :
       Transactions
       Sécurité
       Intégrité
   Mais ces qualités ont un coût : vous ne pouvez pas
    monter en charge facilement
Exemple: quels amis viennent au BreizhCamp?
     Problème
    Vous avez une table «utilisateurs» avec 1 million de lignes
    Chaque utilisateur est ami avec un certain nombre d’autres
     utilisateurs (many-to-many)
    Chaque utilisateur peut aller à des événements (many-to-many)
    Quand un utilisateur va sur la page d’un événement, on veut lui
     présenter la liste de ses amis qui y vont

     Solution «Oracle simple»

    Deux jointures: une pour sélectionner l’événement, une autre
     pour sélectionner l’utilisateur en cours
Que penser de cette solution?
   Très sécurisée: transactions, intégrité...

   Très simple à mettre en place avec Hibernate

   Ne monte pas en charge si on a beaucoup
    d’utilisateurs dans la base

   Va poser problème s’il y a beaucoup d’écritures

   Ne monte pas en charge si on a beaucoup de lectures

   Tout est sur la même machine (Single Point of Failure)
Vos données dans les
      nuages
   Le problème, c'est
    qu'une base de
    données relationnelle
    n'est pas scalable
       On ne peut pas rajouter de
        nœuds « à chaud »
       Sa scalabilité n'est pas du tout linéaire : pour
        maintenir ses transactions et son intégrité, elle est
        forcée de locker des ressources
       Sur une vraie base de données (Oracle), ce lock est
        au niveau d'une ligne
Cela a même été prouvé

 Le théorème de CAP (ou théorème de Brewer)
 Votre système ne peut avoir que 2 des 3

  caractéristiques suivantes
    Cohérent (Consistent)


    Disponible (Available)


    Tolérant aux pannes réseau (Partition Tolerance)


 Conséquence : votre base de données

  relationnelle va mal monter en charge
Mais que fait Oracle?
   1ère solution : faire monter en charge la machine
   Partitionning
     Une table peut être

      découpée sur
      plusieurs disques
      durs
     Réduit les

      problèmes d'I/O
     Ne résout pas les

      problèmes de crash
      machine
   Cher
     Option payante


     Matériel coûteux
Application sur notre exemple
    Problème
   Quels sont mes amis qui viennent au JUG?



Solution Oracle «partitionning»
   On utilise le champs date pour l’événement, et on partitionne
    par mois
   Réduction du nombre de lignes requêtées: on ne fait les
    requêtes (lecture/écriture) que sur le mois en cours
Que penser de cette solution?
   Mêmes qualités:

       Très sécurisée: transactions, intégrité...

       Très simple à mettre en place avec Hibernate

   Peut résoudre les problèmes d’IO si les données le
    permettent... Mais ce n’est pas vraiment le cas de
    notre exemple!

   Tout est sur la même machine: Single Point of Failure
    (SPoF)
Mais que fait Oracle? (2)
   2ème solution : Oracle RAC
   Permet de monter en charge « linéairement » d'après la publicité: résout le
    problème du crash machine
   En fait la base locke toujours les ressources en écriture
      Pose problème si vous avez beaucoup d'écritures

       (de toute manière, c'est
       rarement la lecture qui
       pose problème)
      Pose des problèmes de

       latence réseau :
       géo-cluster non
       recommandé
   Très cher
      Option payante très

       coûteuse
      Matériel (dont réseau)

       très coûteux
Application sur notre exemple
    Problème
   Quels sont mes amis qui viennent au JUG?


     Solution Oracle «RAC»

   Même requête qu’au début, avec deux jointures
   Cette requête est exécutée sur l’un des noeuds de la grille
Que penser de cette solution?
   Mêmes qualités que précédemment...

   Va résoudre certains problèmes en
    lecture: les requêtes sont réparties sur
    chaque noeud

   Plus de Single Point of Failure (SPoF)

   Mais toujours un problème en écriture...
On m’aurait menti?
   Oui, votre application Java monte en
    cluster facilement, « dans le cloud »
      Tant que vous utilisez des « sticky

       sessions »
      Ou que vous stockez votre état

       ailleurs (cookie ou base de
       données?)
   Non, votre base de données ne
    monte pas en cluster
      Or, c'était déjà probablement elle

       qui était le point de contention
   En conclusion, le « Cloud » ne vous
    sert pas à grand chose
Et Hibernate?
   Hibernate s'appuie sur les SGBDR
       Il souffre donc des mêmes problèmes de scalabilité
       Il faut même le configurer pour qu'il utilise
        correctement leurs
        fonctionnalités
        avancées
        (partitionning)
   Donc, votre application
    Hibernate ne devrait pas
    monter en charge
Une solution: le cache de
              2ème niveau
   Hibernate possède un système de cache
      Cache de 1er niveau : la transaction en cours


      Cache de 2ème niveau : les données en base


   Ce cache de deuxième niveau permet d'éviter les
    requêtes en lecture sur la base
      Tant que les requêtes sont simples (lecture d'une

       ligne en utilisant sa PK)
      Ou qu'on utilise Hibernate de manière

       intelligente : faire n+1 requêtes sur le cache peut
       être plus performant qu'un outer join
      Et que les données sont bien réparties...
La loi de Zipf
   Initialement une loi sur les mots utilisés
      Certains sont beaucoup plus courants

       que d'autres
      D'où une distribution très particulière

       des données
   Empiriquement, on retrouve le même
    phénomène dans de nombreuses
    applications
                                                   Georges Kingsley Zipf
      Une petite partie des données est tout le       (1902-1950)
       temps utilisée
      Le reste n'est presque jamais lu

   Si votre application suit cette loi, votre
    cache sera très performant
Application sur notre exemple
    Problème
   Quels sont mes amis qui viennent au JUG?



        Solution «Cache»

   Plusieurs solutions possibles, en voici une
   Mettre les participants d’un événement en cache
   Mettre les amis de l’utilisateur en cours en cache
   Faire la jointure en Java
   ... et stocker le résultat en cache!
Que penser de cette solution?
   Mêmes qualités que précédemment...

   Résout beaucoup de problèmes de lecture (à condition
    de suivre la loi de Zipf): on stocke les résultats en
    cache!

   Mais on ajoute des problèmes de désynchronisation du
    cache...

   On a toujours un problème en écriture

   Et il y a à nouveau un SPoF
Le cache distribué
   Ce cache peut être distribué sur un cluster
       Ehcache (simple)
       Terracotta, Coherence, Gemfire : produits
        commerciaux, hauts de gamme
   Réduit considérablement les problèmes de
    désynchronisation du cache
   Cela résout les problèmes de montée en charge
    d'applications avec beaucoup de lectures
       Solution concurrente d'Oracle RAC, en moins cher,
        plus performant, plus intelligent
Le write-behind
 La plupart des caches distribués
  (Terracotta, Coherence) sont
  transactionnels
    On committe dans le cache, qui se charge

     ensuite de gérer la base de données
 Les données sont insérées en base par

  batch, de manière asynchrone
    Plus de performance

    Moins de lock
Application sur notre exemple
    Problème
   Quels sont mes amis qui viennent au JUG?



    Solution «Cache distribué»

   Idem que pour un cache «simple»
   Mais on peut avoir plusieurs serveurs en parallèle
   En même faire un batch en parallèle, qui utilise le même cache
Que penser de cette solution?
   Mêmes qualités que précédemment...

   Résout quasiment tous les problèmes en lecture, et
    certains problèmes en écriture

   Mais à certaines conditions:

       Acheter une solution de clustering (prix raisonnable
        par rapport à Oracle RAC)

       Ajouter du monitoring (pour éviter le syndrome du
        « split brain »)
Et si on cassait
     tout pour
reprendre à zéro?
Le NoSQL

   Derrière ce terme se cachent de nombreuses
    solutions et
    concepts différents



   Nous allons nous
    focaliser sur
    Apache Cassandra
      L'une des solutions les plus populaires
Cassandra
 Cassandra est une base de données
  distribuée, orientée colonne
 Cassandra n’a pas de schéma

 En fait, il n’a ni transaction, ni

  intégrité référentielle
 Pour reprendre le théorème

  de CAP: Cassandra est hautement disponible,
  tolérant aux pannes réseau, mais pas toujours
  cohérent
 Il peut donc être scalable, sans single point of failure

  (spof)
 Il est particulièrement efficace en écriture
BASE
   Encore un nouvel acronyme
    amusant
   Basically Available, Soft-state,
    Eventually consistent
   Opposé de ACID
   Quizz : que veut dire ACID ?
«Eventual Consistency»
 Comment ça, pas «coherent»?
 « Eventual » est un faux ami en français : cohérence

  « au final »
 A un moment donné la base n'est peut-être pas

  cohérente, mais à terme elle le sera
 En fait Cassandra vous donne le choix entre :

    Une application très cohérente, mais lente en

     écriture
    Une application très rapide en écriture, mais avec des

     risques au niveau de la cohérence
 Les valeurs par défaut vous proposent une solution

  très rapide, avec des risques très limités
Exemple typique
1. Vous écrivez sur un nœud
2. Cette écriture met du temps à se répliquer
   sur un deuxième nœud (on parle en
   millisecondes)
3. Quelqu'un lit sur ce deuxième nœud, en
   préférant la rapidité à la consistance (c'est
   son choix)
4. Cette personne obtient donc une donnée
   ancienne
5. En background, Cassandra valide la donnée et
   répare cette erreur
Mais que fait l’HADOPI?




 Cassandra fait du P2P entre ses différents nœuds
 On peut facilement en rajouter ou en enlever un


 Les données sont réparties entre ces nœuds

  automatiquement
 Mais si on veut une « bonne » répartition, les choses

  deviennent plus compliquées (ce n'est pas magique non
  plus)
Les problèmes en
       production
   La qualité des données :
      Monitoring & production

       ne sont pas au même
       niveau que sous Oracle
        − Mais les outils sont
          nettement plus simples à
          utiliser
        − Offre commerciale : DataStax
      Il peut y avoir des données non consistantes à un moment

       donné
      Il n'y a ni transaction, ni intégrité référentielle

   Tout dépend de ce que vous faites : cela n'est pas nécessairement
    grave
Les problèmes en développement
 Une manière très différente de gérer ses données
 Pas d'API de haut niveau

  (Hibernate), ni même
  d'API générique (JDBC)
 Il faut donc coder des

  DAOs à la main de
  manière assez fastidieuse,
  comme avant JDBC
  (bon courage)
 Pas de lazy-loading, etc :

  gros retour en arrière
Exemple de code
ColumnSlice<String, String> result =
   createSliceQuery("MY_KEYSPACE ", stringSerializer,
   stringSerializer, stringSerializer)
          .setColumnFamily("UTILISATEURS")
          .setKey(email)
          .setColumnNames(
                 "first_name",
                 "last_name",
                 "last_login")
          .execute()
          .get();
Application sur notre exemple
    Problème
   Quels sont mes amis qui viennent au JUG?


      Solution «Cassandra»

   Faire une «Column Family» qui pour un utilisateur lui permet de
    retrouver tous ses amis
   Faire une autre « Column Family» qui stocke tous les utilisateurs
    qui participent à un événement
   Bien mélanger...
Que penser de cette solution?
 Plus aucune des qualités précédentes:
  transactions, intégrité, facilité de
  développement...
 Les données sont directement insérées dans


  un format proche des besoins métier
 Résout les problèmes en lecture (mais un


  cache reste le bienvenu)
 Résout les problèmes en écriture


 Pas de Single Point of Failure
Et Hibernate dans tout ça?
Hibernate OGM
 Utilisation des APIs d'Hibernate sur des bases
  NoSQL
 Officiel depuis aujourd’hui (17/06/2011)
Kundera

 http://code.google.com/p/
  kundera/
 Permet de faire du JPA

  directement
   Spécifique Cassandra à l’origine

   HBase et MongoDB en alpha
Mais il y a des limitations

   Il reste difficile avec ces outils d’utiliser
    pleinement les possibilités de Cassandra
     Gestion des «wide rows» par exemple




   Ces outils sont encore très jeunes
     Essentiellement du CRUD pour l’instant
Quizz
   Parmi les solutions étudiées, laquelle vous parait
    la plus pertinente pour notre exemple?
     Oracle «simple»


     Oracle «partitionning»
     Oracle «RAC»


     Cache
     Cache distribué


     Cassandra
     Une autre solution?
Conclusion
   Ne laissez pas tomber votre base de données
    relationnelle
      Transactions, intégrité, sécurité

      Largement suffisante pour des besoins normaux

      Avec des outils inégalés en productivité (Hibernate)

   Travaillez sur le cache, et en particulier le cache de
    2 nd niveau d'Hibernate

   Le NoSQL sert à des besoins spécifiques
      Certaines solutions (Cassandra) sont très bien

       adaptées au Cloud
      A terme vous pourrez y accéder avec Hibernate/

       JPA
Questions? Réponses!
   Des questions sur le contenu de cette
    présentation ?

   Des ajouts ?

   Des commentaires ?

   N'hésitez pas à échanger et partager sur
    Twitter : @juliendubois



                     http://creativecommons.org/licenses/by-nc-nd/3.0/

Contenu connexe

Tendances

Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Présentation Rex GWT 2.0
Présentation Rex GWT 2.0
Ippon
 
Formation Gratuite Total Tests par les experts Java Ippon
Formation Gratuite Total Tests par les experts Java Ippon Formation Gratuite Total Tests par les experts Java Ippon
Formation Gratuite Total Tests par les experts Java Ippon
Ippon
 
Nouveau look pour une nouvelle vie, version spéciale Ippon
Nouveau look pour une nouvelle vie, version spéciale IpponNouveau look pour une nouvelle vie, version spéciale Ippon
Nouveau look pour une nouvelle vie, version spéciale Ippon
Julien Dubois
 
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et MobileNouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
Ippon
 
JPA avec Cassandra, grâce à Achilles
JPA avec Cassandra, grâce à AchillesJPA avec Cassandra, grâce à Achilles
JPA avec Cassandra, grâce à Achilles
Ippon
 
Breizhjug spring batch 2011
Breizhjug spring batch 2011Breizhjug spring batch 2011
Breizhjug spring batch 2011
Olivier BAZOUD
 
Spring Batch - concepts de base
Spring Batch - concepts de baseSpring Batch - concepts de base
Spring Batch - concepts de base
Spring User Group France
 
Quoi de neuf pour JHipster en 2016
Quoi de neuf pour JHipster en 2016Quoi de neuf pour JHipster en 2016
Quoi de neuf pour JHipster en 2016
Ippon
 
Formation html5 CSS3 offerte par ippon 2014
Formation html5 CSS3 offerte par ippon 2014Formation html5 CSS3 offerte par ippon 2014
Formation html5 CSS3 offerte par ippon 2014
Ippon
 
Tutoriel java
Tutoriel javaTutoriel java
Tutoriel java
Kalilou DIABY
 
Seminaire Portail Open Source
Seminaire Portail Open SourceSeminaire Portail Open Source
Seminaire Portail Open Source
Ippon
 
Presentation hibernate nfe103
Presentation hibernate nfe103Presentation hibernate nfe103
Presentation hibernate nfe103
MRamo2s
 
Devoxx 2018 Après Java 8, Java 9 et 10
Devoxx 2018 Après Java 8, Java 9 et 10Devoxx 2018 Après Java 8, Java 9 et 10
Devoxx 2018 Après Java 8, Java 9 et 10
Jean-Michel Doudoux
 
WS User Group - Spring Batch - Xebia
WS User Group - Spring Batch - XebiaWS User Group - Spring Batch - Xebia
WS User Group - Spring Batch - Xebia
Olivier BAZOUD
 
Jpa(1)
Jpa(1)Jpa(1)
Jpa(1)
Assad Lion
 
Tutoriel java
Tutoriel javaTutoriel java
Tutoriel java
Kalilou DIABY
 
Plongée au cœur du Framework .NET 4.5
Plongée au cœur du Framework .NET 4.5Plongée au cœur du Framework .NET 4.5
Plongée au cœur du Framework .NET 4.5
Microsoft
 
Support formation vidéo : OCA Java SE 8 Programmer (1Z0-808) (1)
Support formation vidéo : OCA Java SE 8 Programmer (1Z0-808) (1)Support formation vidéo : OCA Java SE 8 Programmer (1Z0-808) (1)
Support formation vidéo : OCA Java SE 8 Programmer (1Z0-808) (1)
SmartnSkilled
 

Tendances (20)

Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Présentation Rex GWT 2.0
Présentation Rex GWT 2.0
 
Formation Gratuite Total Tests par les experts Java Ippon
Formation Gratuite Total Tests par les experts Java Ippon Formation Gratuite Total Tests par les experts Java Ippon
Formation Gratuite Total Tests par les experts Java Ippon
 
Nouveau look pour une nouvelle vie, version spéciale Ippon
Nouveau look pour une nouvelle vie, version spéciale IpponNouveau look pour une nouvelle vie, version spéciale Ippon
Nouveau look pour une nouvelle vie, version spéciale Ippon
 
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et MobileNouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
Nouveau look pour une nouvelle vie : HTML5, Spring, NoSQL et Mobile
 
Presentation JPA
Presentation JPAPresentation JPA
Presentation JPA
 
JPA avec Cassandra, grâce à Achilles
JPA avec Cassandra, grâce à AchillesJPA avec Cassandra, grâce à Achilles
JPA avec Cassandra, grâce à Achilles
 
Breizhjug spring batch 2011
Breizhjug spring batch 2011Breizhjug spring batch 2011
Breizhjug spring batch 2011
 
Spring Batch - concepts de base
Spring Batch - concepts de baseSpring Batch - concepts de base
Spring Batch - concepts de base
 
Quoi de neuf pour JHipster en 2016
Quoi de neuf pour JHipster en 2016Quoi de neuf pour JHipster en 2016
Quoi de neuf pour JHipster en 2016
 
Formation html5 CSS3 offerte par ippon 2014
Formation html5 CSS3 offerte par ippon 2014Formation html5 CSS3 offerte par ippon 2014
Formation html5 CSS3 offerte par ippon 2014
 
Tutoriel java
Tutoriel javaTutoriel java
Tutoriel java
 
Seminaire Portail Open Source
Seminaire Portail Open SourceSeminaire Portail Open Source
Seminaire Portail Open Source
 
Presentation hibernate nfe103
Presentation hibernate nfe103Presentation hibernate nfe103
Presentation hibernate nfe103
 
Devoxx 2018 Après Java 8, Java 9 et 10
Devoxx 2018 Après Java 8, Java 9 et 10Devoxx 2018 Après Java 8, Java 9 et 10
Devoxx 2018 Après Java 8, Java 9 et 10
 
Spring Batch ParisJUG
Spring Batch ParisJUG Spring Batch ParisJUG
Spring Batch ParisJUG
 
WS User Group - Spring Batch - Xebia
WS User Group - Spring Batch - XebiaWS User Group - Spring Batch - Xebia
WS User Group - Spring Batch - Xebia
 
Jpa(1)
Jpa(1)Jpa(1)
Jpa(1)
 
Tutoriel java
Tutoriel javaTutoriel java
Tutoriel java
 
Plongée au cœur du Framework .NET 4.5
Plongée au cœur du Framework .NET 4.5Plongée au cœur du Framework .NET 4.5
Plongée au cœur du Framework .NET 4.5
 
Support formation vidéo : OCA Java SE 8 Programmer (1Z0-808) (1)
Support formation vidéo : OCA Java SE 8 Programmer (1Z0-808) (1)Support formation vidéo : OCA Java SE 8 Programmer (1Z0-808) (1)
Support formation vidéo : OCA Java SE 8 Programmer (1Z0-808) (1)
 

En vedette

Stateful is beautiful
Stateful is beautifulStateful is beautiful
Stateful is beautiful
Ippon
 
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
Ippon
 
CDI par la pratique
CDI par la pratiqueCDI par la pratique
CDI par la pratique
Ippon
 
Atelier TDD (Test Driven Development)
Atelier TDD (Test Driven Development)Atelier TDD (Test Driven Development)
Atelier TDD (Test Driven Development)
Ippon
 
Offre 2015 numeriq_ippon
Offre 2015 numeriq_ipponOffre 2015 numeriq_ippon
Offre 2015 numeriq_ippon
Ippon
 
Présentation Ippon DGA Liferay Symposium 2011
Présentation Ippon DGA Liferay Symposium 2011Présentation Ippon DGA Liferay Symposium 2011
Présentation Ippon DGA Liferay Symposium 2011
Ippon
 
Formation Usine Logicielle gratuite par Ippon 2014
Formation Usine Logicielle gratuite par Ippon 2014Formation Usine Logicielle gratuite par Ippon 2014
Formation Usine Logicielle gratuite par Ippon 2014
Ippon
 
Présentation du retour d'expérience sur Git
Présentation du retour d'expérience sur GitPrésentation du retour d'expérience sur Git
Présentation du retour d'expérience sur Git
Ippon
 
Mule ESB Summit 2010 avec Ippon
Mule ESB Summit 2010 avec IpponMule ESB Summit 2010 avec Ippon
Mule ESB Summit 2010 avec Ippon
Ippon
 
Scrum et forfait
Scrum et forfaitScrum et forfait
Scrum et forfait
Ippon
 
Formation GIT gratuite par ippon 2014
Formation GIT gratuite par ippon 2014Formation GIT gratuite par ippon 2014
Formation GIT gratuite par ippon 2014
Ippon
 
Agilité, n’oublions pas les valeurs
Agilité, n’oublions pas les valeursAgilité, n’oublions pas les valeurs
Agilité, n’oublions pas les valeurs
Ippon
 
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
Ippon
 
Multi criteria queries on a cassandra application
Multi criteria queries on a cassandra applicationMulti criteria queries on a cassandra application
Multi criteria queries on a cassandra application
Ippon
 
Cassandra Java Driver : vers Cassandra 1.2 et au-delà
Cassandra Java Driver : vers Cassandra 1.2 et au-delàCassandra Java Driver : vers Cassandra 1.2 et au-delà
Cassandra Java Driver : vers Cassandra 1.2 et au-delà
Ippon
 
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
Ippon
 

En vedette (17)

Stateful is beautiful
Stateful is beautifulStateful is beautiful
Stateful is beautiful
 
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
Realtime Web avec Akka, Kafka, Spark et Mesos - Devoxx Paris 2014
 
CDI par la pratique
CDI par la pratiqueCDI par la pratique
CDI par la pratique
 
Atelier TDD (Test Driven Development)
Atelier TDD (Test Driven Development)Atelier TDD (Test Driven Development)
Atelier TDD (Test Driven Development)
 
Offre 2015 numeriq_ippon
Offre 2015 numeriq_ipponOffre 2015 numeriq_ippon
Offre 2015 numeriq_ippon
 
Présentation Ippon DGA Liferay Symposium 2011
Présentation Ippon DGA Liferay Symposium 2011Présentation Ippon DGA Liferay Symposium 2011
Présentation Ippon DGA Liferay Symposium 2011
 
Formation Usine Logicielle gratuite par Ippon 2014
Formation Usine Logicielle gratuite par Ippon 2014Formation Usine Logicielle gratuite par Ippon 2014
Formation Usine Logicielle gratuite par Ippon 2014
 
Présentation du retour d'expérience sur Git
Présentation du retour d'expérience sur GitPrésentation du retour d'expérience sur Git
Présentation du retour d'expérience sur Git
 
Mule ESB Summit 2010 avec Ippon
Mule ESB Summit 2010 avec IpponMule ESB Summit 2010 avec Ippon
Mule ESB Summit 2010 avec Ippon
 
Scrum et forfait
Scrum et forfaitScrum et forfait
Scrum et forfait
 
Formation GIT gratuite par ippon 2014
Formation GIT gratuite par ippon 2014Formation GIT gratuite par ippon 2014
Formation GIT gratuite par ippon 2014
 
Agilité, n’oublions pas les valeurs
Agilité, n’oublions pas les valeursAgilité, n’oublions pas les valeurs
Agilité, n’oublions pas les valeurs
 
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
One Web (API?) – Alexandre Bertails - Ippevent 10 juin 2014
 
Multi criteria queries on a cassandra application
Multi criteria queries on a cassandra applicationMulti criteria queries on a cassandra application
Multi criteria queries on a cassandra application
 
Cassandra Java Driver : vers Cassandra 1.2 et au-delà
Cassandra Java Driver : vers Cassandra 1.2 et au-delàCassandra Java Driver : vers Cassandra 1.2 et au-delà
Cassandra Java Driver : vers Cassandra 1.2 et au-delà
 
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
Système d’Information à l’Apec : un nouveau coeur de métier mis en place avec...
 
Editorial 3
Editorial 3Editorial 3
Editorial 3
 

Similaire à Hibernate vs le_cloud_computing

Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - Introduction
Blandine Larbret
 
Big Data ou comment retrouver une aiguille dans une botte de foin
Big Data ou comment retrouver une aiguille dans une botte de foinBig Data ou comment retrouver une aiguille dans une botte de foin
Big Data ou comment retrouver une aiguille dans une botte de foin
PALO IT
 
Multi-Threading Et Cocoa
Multi-Threading Et CocoaMulti-Threading Et Cocoa
Multi-Threading Et Cocoa
CocoaHeads France
 
L' Open data vu du Cloud computing
L' Open data vu du Cloud computing L' Open data vu du Cloud computing
L' Open data vu du Cloud computing
Jonathan Le Lous
 
Big data: NoSQL comme solution
Big data: NoSQL comme solutionBig data: NoSQL comme solution
Big data: NoSQL comme solution
JEMLI Fathi
 
Présentation de Apache Zookeeper
Présentation de Apache ZookeeperPrésentation de Apache Zookeeper
Présentation de Apache Zookeeper
Michaël Morello
 
Cache
CacheCache
Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !
Société ELOSI
 
Bien sécuriser et gérer ses données
Bien sécuriser et gérer ses donnéesBien sécuriser et gérer ses données
Bien sécuriser et gérer ses données
Com'3elles - www.com3elles.com
 
SQL Server et les développeurs
SQL Server et les développeurs SQL Server et les développeurs
SQL Server et les développeurs
Microsoft
 
Design patterns
Design patternsDesign patterns
Design patterns
CocoaHeads.fr
 
NoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler SofteamNoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler Softeam
TelecomValley
 
Des solutions de synchronisation de données
Des solutions de synchronisation de donnéesDes solutions de synchronisation de données
Des solutions de synchronisation de données
pprem
 
Présentation Big Data et REX Hadoop
Présentation Big Data et REX HadoopPrésentation Big Data et REX Hadoop
Présentation Big Data et REX Hadoop
Joseph Glorieux
 
Back to the future of java (from 8 to 11 and beyond)
Back to the future of java (from 8 to 11 and beyond)Back to the future of java (from 8 to 11 and beyond)
Back to the future of java (from 8 to 11 and beyond)
Jérôme Tamborini
 
Open Source et Cloud Computing
Open Source et Cloud ComputingOpen Source et Cloud Computing
Open Source et Cloud Computing
Paris, France
 
NoSQL User Group Paris - 21 Juin 2011 - GigaSpaces
NoSQL User Group Paris - 21 Juin 2011 - GigaSpacesNoSQL User Group Paris - 21 Juin 2011 - GigaSpaces
NoSQL User Group Paris - 21 Juin 2011 - GigaSpaces
FastConnect
 
NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptxNOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
EddySHANGA
 
docker.pdf
docker.pdfdocker.pdf
docker.pdf
Jaouad Assabbour
 

Similaire à Hibernate vs le_cloud_computing (20)

Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - Introduction
 
Big Data ou comment retrouver une aiguille dans une botte de foin
Big Data ou comment retrouver une aiguille dans une botte de foinBig Data ou comment retrouver une aiguille dans une botte de foin
Big Data ou comment retrouver une aiguille dans une botte de foin
 
Multi-Threading Et Cocoa
Multi-Threading Et CocoaMulti-Threading Et Cocoa
Multi-Threading Et Cocoa
 
L' Open data vu du Cloud computing
L' Open data vu du Cloud computing L' Open data vu du Cloud computing
L' Open data vu du Cloud computing
 
Big data: NoSQL comme solution
Big data: NoSQL comme solutionBig data: NoSQL comme solution
Big data: NoSQL comme solution
 
Présentation de Apache Zookeeper
Présentation de Apache ZookeeperPrésentation de Apache Zookeeper
Présentation de Apache Zookeeper
 
Cache
CacheCache
Cache
 
Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !
 
Bien sécuriser et gérer ses données
Bien sécuriser et gérer ses donnéesBien sécuriser et gérer ses données
Bien sécuriser et gérer ses données
 
SQL Server et les développeurs
SQL Server et les développeurs SQL Server et les développeurs
SQL Server et les développeurs
 
Design patterns
Design patternsDesign patterns
Design patterns
 
Design patterns
Design patternsDesign patterns
Design patterns
 
NoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler SofteamNoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler Softeam
 
Des solutions de synchronisation de données
Des solutions de synchronisation de donnéesDes solutions de synchronisation de données
Des solutions de synchronisation de données
 
Présentation Big Data et REX Hadoop
Présentation Big Data et REX HadoopPrésentation Big Data et REX Hadoop
Présentation Big Data et REX Hadoop
 
Back to the future of java (from 8 to 11 and beyond)
Back to the future of java (from 8 to 11 and beyond)Back to the future of java (from 8 to 11 and beyond)
Back to the future of java (from 8 to 11 and beyond)
 
Open Source et Cloud Computing
Open Source et Cloud ComputingOpen Source et Cloud Computing
Open Source et Cloud Computing
 
NoSQL User Group Paris - 21 Juin 2011 - GigaSpaces
NoSQL User Group Paris - 21 Juin 2011 - GigaSpacesNoSQL User Group Paris - 21 Juin 2011 - GigaSpaces
NoSQL User Group Paris - 21 Juin 2011 - GigaSpaces
 
NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptxNOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
 
docker.pdf
docker.pdfdocker.pdf
docker.pdf
 

Hibernate vs le_cloud_computing

  • 1. Hibernate vs. le Cloud Computing
  • 2. Qui suis-je?  Julien Dubois  Co-auteur de « Spring par la pratique »  Ancien de SpringSource  Directeur du consulting chez Ippon Technologies  Suivez-moi sur Twitter : @juliendubois http://creativecommons.org/licenses/by-nc-nd/3.0/
  • 3. Nous allons parler de ....  Bases de données relationnelles  Hibernate  Cache  NoSQL
  • 4. Commençons par deux idées fausses...
  • 5. Idée #1: Hibernate est magique  Il optimise tout seul les requêtes SQL  Plus besoin d’être compétent!
  • 6. Idée #2: Le cloud est magique  Le cloud permet d'ajouter automatiquement des machines en fonction des besoins  Il permet de tenir ainsi les pics de charge sans rien avoir à faire
  • 7. La réalité est différente  Ne croyez pas 01 Informatique  Votre base de données ne monte pas en charge  Et Hibernate n'y peut rien...
  • 8. Les données sont votre problème  Dans 90% des applications, la base de données est le principal point de contention  Ces données sont stockées dans une base relationnelle :  Transactions  Sécurité  Intégrité  Mais ces qualités ont un coût : vous ne pouvez pas monter en charge facilement
  • 9. Exemple: quels amis viennent au BreizhCamp? Problème  Vous avez une table «utilisateurs» avec 1 million de lignes  Chaque utilisateur est ami avec un certain nombre d’autres utilisateurs (many-to-many)  Chaque utilisateur peut aller à des événements (many-to-many)  Quand un utilisateur va sur la page d’un événement, on veut lui présenter la liste de ses amis qui y vont Solution «Oracle simple»  Deux jointures: une pour sélectionner l’événement, une autre pour sélectionner l’utilisateur en cours
  • 10. Que penser de cette solution?  Très sécurisée: transactions, intégrité...  Très simple à mettre en place avec Hibernate  Ne monte pas en charge si on a beaucoup d’utilisateurs dans la base  Va poser problème s’il y a beaucoup d’écritures  Ne monte pas en charge si on a beaucoup de lectures  Tout est sur la même machine (Single Point of Failure)
  • 11. Vos données dans les nuages  Le problème, c'est qu'une base de données relationnelle n'est pas scalable  On ne peut pas rajouter de nœuds « à chaud »  Sa scalabilité n'est pas du tout linéaire : pour maintenir ses transactions et son intégrité, elle est forcée de locker des ressources  Sur une vraie base de données (Oracle), ce lock est au niveau d'une ligne
  • 12. Cela a même été prouvé  Le théorème de CAP (ou théorème de Brewer)  Votre système ne peut avoir que 2 des 3 caractéristiques suivantes  Cohérent (Consistent)  Disponible (Available)  Tolérant aux pannes réseau (Partition Tolerance)  Conséquence : votre base de données relationnelle va mal monter en charge
  • 13. Mais que fait Oracle?  1ère solution : faire monter en charge la machine  Partitionning  Une table peut être découpée sur plusieurs disques durs  Réduit les problèmes d'I/O  Ne résout pas les problèmes de crash machine  Cher  Option payante  Matériel coûteux
  • 14. Application sur notre exemple Problème  Quels sont mes amis qui viennent au JUG? Solution Oracle «partitionning»  On utilise le champs date pour l’événement, et on partitionne par mois  Réduction du nombre de lignes requêtées: on ne fait les requêtes (lecture/écriture) que sur le mois en cours
  • 15. Que penser de cette solution?  Mêmes qualités:  Très sécurisée: transactions, intégrité...  Très simple à mettre en place avec Hibernate  Peut résoudre les problèmes d’IO si les données le permettent... Mais ce n’est pas vraiment le cas de notre exemple!  Tout est sur la même machine: Single Point of Failure (SPoF)
  • 16. Mais que fait Oracle? (2)  2ème solution : Oracle RAC  Permet de monter en charge « linéairement » d'après la publicité: résout le problème du crash machine  En fait la base locke toujours les ressources en écriture  Pose problème si vous avez beaucoup d'écritures (de toute manière, c'est rarement la lecture qui pose problème)  Pose des problèmes de latence réseau : géo-cluster non recommandé  Très cher  Option payante très coûteuse  Matériel (dont réseau) très coûteux
  • 17. Application sur notre exemple Problème  Quels sont mes amis qui viennent au JUG? Solution Oracle «RAC»  Même requête qu’au début, avec deux jointures  Cette requête est exécutée sur l’un des noeuds de la grille
  • 18. Que penser de cette solution?  Mêmes qualités que précédemment...  Va résoudre certains problèmes en lecture: les requêtes sont réparties sur chaque noeud  Plus de Single Point of Failure (SPoF)  Mais toujours un problème en écriture...
  • 19. On m’aurait menti?  Oui, votre application Java monte en cluster facilement, « dans le cloud »  Tant que vous utilisez des « sticky sessions »  Ou que vous stockez votre état ailleurs (cookie ou base de données?)  Non, votre base de données ne monte pas en cluster  Or, c'était déjà probablement elle qui était le point de contention  En conclusion, le « Cloud » ne vous sert pas à grand chose
  • 20. Et Hibernate?  Hibernate s'appuie sur les SGBDR  Il souffre donc des mêmes problèmes de scalabilité  Il faut même le configurer pour qu'il utilise correctement leurs fonctionnalités avancées (partitionning)  Donc, votre application Hibernate ne devrait pas monter en charge
  • 21. Une solution: le cache de 2ème niveau  Hibernate possède un système de cache  Cache de 1er niveau : la transaction en cours  Cache de 2ème niveau : les données en base  Ce cache de deuxième niveau permet d'éviter les requêtes en lecture sur la base  Tant que les requêtes sont simples (lecture d'une ligne en utilisant sa PK)  Ou qu'on utilise Hibernate de manière intelligente : faire n+1 requêtes sur le cache peut être plus performant qu'un outer join  Et que les données sont bien réparties...
  • 22. La loi de Zipf  Initialement une loi sur les mots utilisés  Certains sont beaucoup plus courants que d'autres  D'où une distribution très particulière des données  Empiriquement, on retrouve le même phénomène dans de nombreuses applications Georges Kingsley Zipf  Une petite partie des données est tout le (1902-1950) temps utilisée  Le reste n'est presque jamais lu  Si votre application suit cette loi, votre cache sera très performant
  • 23. Application sur notre exemple Problème  Quels sont mes amis qui viennent au JUG? Solution «Cache»  Plusieurs solutions possibles, en voici une  Mettre les participants d’un événement en cache  Mettre les amis de l’utilisateur en cours en cache  Faire la jointure en Java  ... et stocker le résultat en cache!
  • 24. Que penser de cette solution?  Mêmes qualités que précédemment...  Résout beaucoup de problèmes de lecture (à condition de suivre la loi de Zipf): on stocke les résultats en cache!  Mais on ajoute des problèmes de désynchronisation du cache...  On a toujours un problème en écriture  Et il y a à nouveau un SPoF
  • 25. Le cache distribué  Ce cache peut être distribué sur un cluster  Ehcache (simple)  Terracotta, Coherence, Gemfire : produits commerciaux, hauts de gamme  Réduit considérablement les problèmes de désynchronisation du cache  Cela résout les problèmes de montée en charge d'applications avec beaucoup de lectures  Solution concurrente d'Oracle RAC, en moins cher, plus performant, plus intelligent
  • 26. Le write-behind  La plupart des caches distribués (Terracotta, Coherence) sont transactionnels  On committe dans le cache, qui se charge ensuite de gérer la base de données  Les données sont insérées en base par batch, de manière asynchrone  Plus de performance  Moins de lock
  • 27. Application sur notre exemple Problème  Quels sont mes amis qui viennent au JUG? Solution «Cache distribué»  Idem que pour un cache «simple»  Mais on peut avoir plusieurs serveurs en parallèle  En même faire un batch en parallèle, qui utilise le même cache
  • 28. Que penser de cette solution?  Mêmes qualités que précédemment...  Résout quasiment tous les problèmes en lecture, et certains problèmes en écriture  Mais à certaines conditions:  Acheter une solution de clustering (prix raisonnable par rapport à Oracle RAC)  Ajouter du monitoring (pour éviter le syndrome du « split brain »)
  • 29. Et si on cassait tout pour reprendre à zéro?
  • 30. Le NoSQL  Derrière ce terme se cachent de nombreuses solutions et concepts différents  Nous allons nous focaliser sur Apache Cassandra  L'une des solutions les plus populaires
  • 31. Cassandra  Cassandra est une base de données distribuée, orientée colonne  Cassandra n’a pas de schéma  En fait, il n’a ni transaction, ni intégrité référentielle  Pour reprendre le théorème de CAP: Cassandra est hautement disponible, tolérant aux pannes réseau, mais pas toujours cohérent  Il peut donc être scalable, sans single point of failure (spof)  Il est particulièrement efficace en écriture
  • 32. BASE  Encore un nouvel acronyme amusant  Basically Available, Soft-state, Eventually consistent  Opposé de ACID  Quizz : que veut dire ACID ?
  • 33. «Eventual Consistency»  Comment ça, pas «coherent»?  « Eventual » est un faux ami en français : cohérence « au final »  A un moment donné la base n'est peut-être pas cohérente, mais à terme elle le sera  En fait Cassandra vous donne le choix entre :  Une application très cohérente, mais lente en écriture  Une application très rapide en écriture, mais avec des risques au niveau de la cohérence  Les valeurs par défaut vous proposent une solution très rapide, avec des risques très limités
  • 34. Exemple typique 1. Vous écrivez sur un nœud 2. Cette écriture met du temps à se répliquer sur un deuxième nœud (on parle en millisecondes) 3. Quelqu'un lit sur ce deuxième nœud, en préférant la rapidité à la consistance (c'est son choix) 4. Cette personne obtient donc une donnée ancienne 5. En background, Cassandra valide la donnée et répare cette erreur
  • 35. Mais que fait l’HADOPI?  Cassandra fait du P2P entre ses différents nœuds  On peut facilement en rajouter ou en enlever un  Les données sont réparties entre ces nœuds automatiquement  Mais si on veut une « bonne » répartition, les choses deviennent plus compliquées (ce n'est pas magique non plus)
  • 36. Les problèmes en production  La qualité des données :  Monitoring & production ne sont pas au même niveau que sous Oracle − Mais les outils sont nettement plus simples à utiliser − Offre commerciale : DataStax  Il peut y avoir des données non consistantes à un moment donné  Il n'y a ni transaction, ni intégrité référentielle  Tout dépend de ce que vous faites : cela n'est pas nécessairement grave
  • 37. Les problèmes en développement  Une manière très différente de gérer ses données  Pas d'API de haut niveau (Hibernate), ni même d'API générique (JDBC)  Il faut donc coder des DAOs à la main de manière assez fastidieuse, comme avant JDBC (bon courage)  Pas de lazy-loading, etc : gros retour en arrière
  • 38. Exemple de code ColumnSlice<String, String> result = createSliceQuery("MY_KEYSPACE ", stringSerializer, stringSerializer, stringSerializer) .setColumnFamily("UTILISATEURS") .setKey(email) .setColumnNames( "first_name", "last_name", "last_login") .execute() .get();
  • 39. Application sur notre exemple Problème  Quels sont mes amis qui viennent au JUG? Solution «Cassandra»  Faire une «Column Family» qui pour un utilisateur lui permet de retrouver tous ses amis  Faire une autre « Column Family» qui stocke tous les utilisateurs qui participent à un événement  Bien mélanger...
  • 40. Que penser de cette solution?  Plus aucune des qualités précédentes: transactions, intégrité, facilité de développement...  Les données sont directement insérées dans un format proche des besoins métier  Résout les problèmes en lecture (mais un cache reste le bienvenu)  Résout les problèmes en écriture  Pas de Single Point of Failure
  • 41. Et Hibernate dans tout ça?
  • 42. Hibernate OGM  Utilisation des APIs d'Hibernate sur des bases NoSQL  Officiel depuis aujourd’hui (17/06/2011)
  • 43. Kundera  http://code.google.com/p/ kundera/  Permet de faire du JPA directement  Spécifique Cassandra à l’origine  HBase et MongoDB en alpha
  • 44. Mais il y a des limitations  Il reste difficile avec ces outils d’utiliser pleinement les possibilités de Cassandra  Gestion des «wide rows» par exemple  Ces outils sont encore très jeunes  Essentiellement du CRUD pour l’instant
  • 45. Quizz  Parmi les solutions étudiées, laquelle vous parait la plus pertinente pour notre exemple?  Oracle «simple»  Oracle «partitionning»  Oracle «RAC»  Cache  Cache distribué  Cassandra  Une autre solution?
  • 46. Conclusion  Ne laissez pas tomber votre base de données relationnelle  Transactions, intégrité, sécurité  Largement suffisante pour des besoins normaux  Avec des outils inégalés en productivité (Hibernate)  Travaillez sur le cache, et en particulier le cache de 2 nd niveau d'Hibernate  Le NoSQL sert à des besoins spécifiques  Certaines solutions (Cassandra) sont très bien adaptées au Cloud  A terme vous pourrez y accéder avec Hibernate/ JPA
  • 47. Questions? Réponses!  Des questions sur le contenu de cette présentation ?  Des ajouts ?  Des commentaires ?  N'hésitez pas à échanger et partager sur Twitter : @juliendubois http://creativecommons.org/licenses/by-nc-nd/3.0/