public Blog<Benwit> monblog;

Un article de benwit    2 Commentaires

Passer le stade du simple Hello World, vous aurez besoin de lire et d’écrire des données avec votre application GAE.

Dans ce billet, je vous propose de répondre à quelques questions que vous vous posez sûrement :

• Où sont enregistrées vos données ?
• Comment vous pouvez y accéder ?
• Quelles sont les limites et comment les contourner si possible ?

=> Où sont enregistrées vos données ?

Vous pouvez avoir :

• des données statiques contenues dans des fichiers fournis lors du déploiement.
  Ces fichiers statiques sont pour des raisons d’efficacité servis par des serveurs différents de ceux qui font tourner vos servlets.
  Ces fichiers pourront être accédés seulement en lecture. (Non mais, vous vouliez quand même pas vous baladez sur le système de fichier de Google !)

  An application cannot write to the file system. An app can read files, but only files uploaded with the application code.

  Cette contrainte peut se comprendre dans une architecture de cloud sinon il faudrait que soit prévu un mécanisme de synchronisation entre les différentes machines hébergeant ces fichiers (ce qui ne semble pas être le cas).

• des données dynamiques créées, modifiées, supprimées pendant l’utilisation de l’application.
  Pour cela, GAE met à votre disposition un service de stockage de données distribué, supportant les requêtes et les transactions.
  Ce datastore repose sur BigTable dans l’environnement de GAE et est simulé en local sur votre machine de développement.
  Pour une petite application, cela peut paraître inadapté car leur système est conçu pour gérer des quantités de données importantes. Mais là encore, ce choix peut se comprendre dans une architecture de cloud où les impératifs ne sont pas les mêmes et où l’usage classique des SGBD est remis en cause.
  Notez également que le datastore est « Schema Less« , cela signifie que pour un type d’entité donnée, les attributs peuvent être présents ou non et être même de types différents dans des instances différentes. C’est donc à l’application de contrôler la structure des données.

=> Comment vous pouvez y accéder ?

• Pour les fichiers, classiquement, en utilisant l’api des fichiers du JDK, tant que vous ne faites pas de création de fichier ou d’accès en écriture.
• Pour le datastore, trois solutions s’offrent à vous :
  • Un accès direct via une API « bas niveau » fournie par Google.
  • Un accès via Java Data Objects (JDO). L’implémentation utilisée est DataNucleus, qui est le nouveau nom de JPOX, l’implémentation de référence de JDO.
  • Un accès via Java Persistence API (JPA). L’implémentation utilisée est une fois de plus DataNucleus.

  Le choix de JDO peut se comprendre dans la mesure où la spécification JDO a été rédigée pour attaquer n’importe quel système de persistance de données alors que sa petite soeur JPA (venu après, avec le succès d’Hibernate) pour attaquer spécialement des bases de données relationnelles.

=> Quelles sont les limites et comment les contourner si possible ?

• Combien de fichier statiques peut on avoir ? 1000 fichiers.
  Si vous utilisez des wrappers comme SmartGWT, vous serz vite confronté à cette limite car ce framework contient beaucoup de fichiers javascripts et d’icones.
  Google a semble t-il mis cette limite pour pousser à utiliser son système d’image bundle (pour résumer, vous faites une grosse image de toute vos petites images et vous affichez uniquement le morceau qui vous intéresse par css; le but étant de minimiser le nombre de requêtes.)
  Si vous avez trop de petits fichiers, il vous reste la solution de les compresser dans une archive .zip et d’utiliser une servlet pour les lire à la volée dans cette archive.

• Quel espace disposez vous pour ces fichiers ? Dans la documentation Google, vous pouvez lire :
  

  All applications can use up to 500 MB of storage

  Je n’ai pas encore trouvé s’il s’agissait uniquement de l’espace pour les fichiers déployés (statiques + librairies + code applicatif) ou si les données du datastore sont également comprises ? (Je dirai que probablement pas puisque les quotas journaliers sur le datastore vont bien au delà mais cela reste plus un espoir qu’une certitude)

• Comment faire si votre application doit gérer des images, des fichiers de données ?
  Vous devez utiliser le mécanisme d’upload http pour les envoyer à une servlet qui se chargera de les enregistrer dans un champ d’octets ( BLOB ) du datastore. Et pour les récupérer, vous devez appeler une servlet qui se chargera du traitement inverse. Une fois compris la démarche, vous comprendrez mieux pourquoi la taille des requêtes (1 Mo) limite la taille de vos fichiers de données.
  Une variante qui repose sur le même principe est d’utiliser le mécanisme de système de fichier virtuel développé par d’autre.

• Combien de datastore peut on avoir ? Un et un seul par application GAE pour l’instant.
  Une version d’application ne peut accéder qu’à un seul datastore, vous ne pouvez donc pas en avoir plusieurs, ni accéder au datastore d’une autre application.
  Inversement, un datastore ne peut pas être accéder par plusieurs applications. Au mieux, vous pouvez avoir un même datastore accessible par différentes versions d’une même application mais dans ce cas, les différentes versions se partagent les quotas de l’application (toutes versions confondues)

• Quel espace disposez vous pour le datastore ? 1 nouveau Go/Jour ?
  Parmis les différents quotas du datastore (volume en lecture, volume en écriture, …), il y a le quota « Stored Data » de 1 gigabyte/daily.
  De là à dire qu’il n’y a pas de limite dans le temps ???

• Comment importer/exporter des données du datastore ?
  Actuellement, il faut bien reconnaître que même si google y travaille, c’est encore assez pauvre.
  Il existe des scripts d’importation pour GAE/Python,.
  Malheureusement, je n’ai rien trouvé pour GAE/Java.
  Certains suggèrent d’utiliser l’API Rest de DataNucleus ou l’API du datastore mais c’est à écrire …

Si vous avez d’autres questions ou si vous avez des informations complémentaires, vous pouvez laisser un commentaire ;o).