Cómo utilizar el datastore de Google App Engine con su API de nivel inferior

0
15701

CÓMO UTILIZAR EL DATASTORE DE GOOGLE APP ENGINE CON SU API DE NIVEL INFERIOR

1 Introducción

En un tutorial anterior os explicamos qué son el cloud computing y Google App Engine, donde os mostramos en qué consisten estas tecnologías, de qué capas están formadas y cuáles son las ventajas que nos aportan. Aquel introductorio tutorial nos servirá como base para este otro, donde nos centraremos en un apartado del Google App Engine en concreto: su almacén de datos, también como conocido como el datastore.

Todas las aplicaciones web necesitan algún tipo de soporte de almacenamiento de datos, es por ello que conocer el funcionamiento del datastore es realmente importante si quieres publicar tus aplicaciones utilizando la plataforma de Google App Engine.

El texto que vas a leer a continuación va a intentar que entiendas cómo funciona el datastore. Habrá una primera parte puramente teórica con la cual podremos situarnos y, tras ello, una parte práctica en la cual podreis descargar una aplicación de ejemplo. Dicha aplicación está escrita en java y hace uso del API de nivel inferior del datastore.

2 ¿Qué es el datastore?

El datastore es una parte vital de Google App Engine, destinada únicamente al almacenamiento de datos. Eso significa que todos los datos que necesitemos almacenar o recuperar los tendremos allí.

Es importante destacar que bajo el datastore no hay una base de datos relacional. Sirve para almacenar datos de un manera totalmente consecuente pero no funciona como las bases de datos tipo MySQL u Oracle. Aunque el concepto de almacenar y recuperar datos es el mismo, las tecnologías y la manera de trabajar son diferentes, lo que implica que tendrán distintos puntos fuertes y distintos puntos débiles.

Pero, ¿hasta qué punto las tecnologías son distintas?, ¿por qué los chicos de Google no han basado sus tecnologías en otras ya existentes?. Como mencionamos en el tutorial de introducción al cloud computing y a Google App Engine, Google posee unas tecnologías propias basadas en GFS y en BigTable. El primero es un sistema de ficheros propio, mientras que el segundo es un sistema de almacenamiento de información distribuido diseñado para almacenar cantidades de datos del tamaño de petabytes en miles de ordenadores.

¿Y qué diferencia hay entre unas tecnologias y otras?. Tanto GFS como BigTable han sido diseñadas específicamente para poder funcionar de manera distribuida en datacenters con cientos y miles de ordenadores en forma de grid donde, además, se entiende que la mayoría de operaciones que se realizan son lecturas en un espacio de almacenamiento infinito sobre un hardware que puede fallar en cualquier momento.

El datastore es, simplemente, una capa que se sitúa sobre BigTable. Todas las operaciones que realicemos sobre este sistema de almacenamiento tendrán que ser invocadas contra el datastore.

BigTable fue diseñado pensando, entre otras cosas, en la escalabilidad. Es por ello que conceptos propios de las bases de datos relacionales como la normalización o las claves foráneas no existen. En BigTable cuando existe una relación entre datos y se guarda uno de ellos lo que en realidad se hace es guardar los dos juntos como si ambos fueran uno solo. Esto permite escalar y simplificar las búsquedas, ya que al ir a buscar uno de los datos se recuperan los dos sin obligar a BigTable a lanzar una segunda búsqueda utilizando una clave foránea.

3 ¿Qué podemos utilizar para almacenar y recuperar información del datastore?

Actualmente Google da soporte para dos lenguajes diferentes en su Google App Engine: java y python. Es por ello que todas las operaciones que queramos realizar contra el Google App Engine en general y contra el datastore en particular tendrán que utilizar alguno de estos dos lenguajes:

Nosotros, a lo largo de estos tutoriales, nos vamos a centrar en el desarrollo de aplicaciones mediante el lenguaje de programación java. Utilizando este lenguaje dispondremos de tres maneras de poder operar con el datastore:

  • JDO (Java Data Objects)
  • JPA (Java Persistence API)
  • El API de nivel inferior

Donde API son las siglas de Application Programming Interface.

Como podeis ver en la imagen, tanto JDO como JPA utilizan el API de nivel inferior para poder hacer uso del datastore debido a que JDO y JPA poseen un mayor nivel de abstracción. Eso no es obstáculo para que nosotros como desarrolladores también podamos acceder al API de nivel inferior para construir nuestras aplicaciones.

Este tutorial gira en torno al API de nivel inferior puesto que mantiene una relación más estrecha con el datastore y porque comprender cómo funciona este API nos permitirá saber mejor cómo funciona el datastore.

3.1 API de nivel inferior

Es el interfaz de programación de aplicaciones de nivel inferior. Se dice que es de nivel inferior ya que es la capa de almacenamiento de datos que se encuentra más cerca del datastore.

Este API opera con datos y con operaciones relativamente primitivos. Al programar con este API hay que ser explícito ya que es necesario indicar no sólo qué quieres almacenar o recuperar sino cómo quieres hacerlo.

Este API, al igual que el propio datastore, opera con entidades. Las entidades son objetos de datos y se explicarán en el apartado 4 de este mismo tutorial. Si conoces JDO o JPA debes tener en cuenta que las entidades del datastore no son como las entidades de JDO o JPA. Las entidades del datastore son lo que en java se conoce como mapas, pares atributo-valor.

La ventaja de trabajar contra esta API es que permite tener un mayor control a costa de tener que comprender mejor cómo funciona el datastore.

3.2 JPA

Es el ‘API de persistencia para Java’, o ‘interfaz de programación de aplicaciones de persistencia para Java’.

Este interfaz define un estándar de almacenamiento de datos en una base de datos relacional que, en este caso, se encuentra adaptado para poder almacenar datos en el datastore (recordemos que el datastore no es una base de datos relacional). Debido a esta adaptación, el soporte de Google App Engine para JPA no admite algunas funciones de JPA.

Del estándar JPA existen varias versiones, de las cuales de momento sólo la 1.0 funciona en Google App Engine y, como ya decimos, con restricciones.

Pero, ¿para qué sirve este estándar y qué ventaja podemos sacar de usar JPA en nuestras aplicaciones?, sirve para definir un marco de trabajo con un nivel de abstracción alto que, mediante la anotación de objetos Java, permita que la recuperación de objetos a través de consultas, que el almacenamiento de las mismas y que la interacción con una base de datos a través de transacciones sea bastante sencilla. Gracias a ello los desarrolladores pueden centrarse más en el qué quieren almacenar o recuperar que en el cómo tienen que hacerlo.

3.3 JDO

Son los ‘objetos de datos de java’ y también consiste en una especificación de almacenamiento de objetos en Java.

Tiene muchas similitudes y algunas diferencias con JPA. La idea de definir un marco de trabajo a un alto nivel de abstracción se mantiene, pero JDO no se centra en almacenar datos en bases de datos relacionales. JDO encaja, por tanto, mejor que JPA con el datastore ya que el éste no es relacional. Sin embargo tambien se encuentra limitado y no podremos utilizar todas las funciones de JDO en nuestra aplicación si esta tiene que funcionar en Google App Engine.

Del estándar JDO también existen varias versiones, funcionando la 2.3 en Google App Engine y, como ya decimos, con algunas restricciones.

4 ¿Qué son las entidades?

Anteriormente comentamos que el datastore opera con lo que se denominan entidades, y también comentamos que este concepto de entidad es diferente al concepto de entidad que existe en JDO y JPA.

Las entidades del datastore son objetos de datos con propiedades, pudiendo estas propiedades ser casi cualquier cosa: textos, números, valores binarios, conjuntos de datos, etc.

Lo exótico del asunto es que las propiedades pueden tener uno o varios valores, y además las entidades de un mismo tipo no tienen por qué tener las mismas propiedades, ya que cada entidad puede definir qué propiedades tiene. Esto se debe a que las entidades en el datastore son pares atributo-valor.

De esta manera podriamos definir entidades de tipo persona que tuvieran sólo coche y casa y entidades de tipo persona que tuvieran sólo mascota y edad. Los atributos son totalmente diferentes, pero para el datastore son entidades del mismo tipo.

Esto en un modelo relacional o en las entidades de JDO o JPA no es posible. Se podría intentar simular pero no se podría conseguir de manera nativa con facilidad.

Las entidades del datastore mantienen una clave que las identifica de manera única. Estas claves tienen varios valores, siendo uno de ellos precisamente el tipo de la entidad que representa.

Por tanto, cuando utilicemos el API de nivel inferior operaremos con entidades del datastore y podremos añadir todas las propiedades que necesitemos con todos los valores que hagan falta. Al utilizar JDO o JPA ganaremos en facilidad pero nos limitaremos a lo que nos permitan perdiendo estas novedosas características.

5 Transaccionalidad

Una transacción, según la wikipedia, es:

«[…] una interacción con una estructura de datos compleja, compuesta por varios procesos que se han de aplicar uno después del otro. La transacción debe ser equivalente a una interacción atómica. Es decir, que se realice de una sola vez y que la estructura a medio manipular no sea jamás alcanzable por el resto del sistema hasta que haya finalizado todos sus procesos.»

http://es.wikipedia.org/wiki/Transacción_(informática)

Según la misma fuente, las transacciones deben cumplir 4 propiedades para poder ser consideradas como tal. A estas propiedades se las conoce como ACID

  • «Atomicidad (Atomicity): es la propiedad que asegura que la operación se ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias.
  • Consistencia (Consistency): es la propiedad que asegura que sólo se empieza aquello que se puede acabar. Por lo tanto, se ejecutan aquellas operaciones que no van a romper la reglas y directrices de integridad de la base de datos.
  • Aislamiento (Isolation): es la propiedad que asegura que una operación no puede afectar a otras. Esto asegura que la realización de dos transacciones sobre la misma información nunca generará ningún tipo de error.
  • Permanencia (Durability): es la propiedad que asegura que una vez realizada la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema.»

El concepto de transaccionalidad tambien existe en el datastore de Google App Engine, ya que vamos a ser capaces de lanzar varias operaciones en una misma transacción y recuperar la transacción entera si falla cualquiera de las operaciones. Recordemos que en el apartado 2 dijimos que el datastore era totalmente consecuente.

Pero, ¿cómo poder definir qué entra y qué no entra en una misma transacción?. Anteriormente mencionamos que el datastore opera con entidades. Pues bien, si necesitamos operar con varias entidades a la vez de manera transaccional es necesario que todas ellas pertencezcan a un mismo grupo de entidades. De este modo grupos de entidades distintos operan con transacciones independientes.

Otro aspecto a tener en cuenta es que el almacén de datos utiliza una política optimista para gestionar las transacciones. Esto es lógico, ya que tanto GFS como BigTable han sido diseñados para que sobre ellos se realicen muchas más búsquedas que escrituras.

6 Ejemplo con API de nivel inferior

A continuación os vamos a mostrar un ejemplo realizado con el API de nivel inferior. Podeis bajar el código fuente del mismo pulsando en este enlace.

La aplicación será un gestor de tutoriales para adictosaltrabajo.com, en el cual podreis publicar nuevos tutoriales y consultar todos los que ya existen.

6.1 Cómo instalar el SDK para Java y el plugin de Eclipse

Lo primero que necesitamos es tener Java instalado en nuestro equipo, y también necesitaremos tener instalado Eclipse para poder desarrollar. El fuente de este tutorial ha sido generado con la versión 3.5 de Eclipse, también llamada Galileo.

Necesitaremos instalar el plugin de Eclipse. Para ello nos basaremos en el siguiente enlace:

http://code.google.com/intl/es/appengine/docs/java/tools/eclipse.html#Installing_the_Google_Plugin_for_Eclipse

IMPORTANTE: Si estás usando Eclipse Galileo la ruta que deberás utilizar es http://dl.google.com/eclipse/plugin/3.5

Tras ello descomprimimos el código fuente del ejemplo. Si todavia no lo has bajado puedes hacerlo pulsando en este enlace.

Una vez tengas:

  • Java,
  • Eclipse y
  • el plugin de Eclipse

podemos importar el proyecto en nuestro workspace de Eclipse. Para ello vamos a [ File > Import > General > Existing Projects into Workspace ] y una vez ahí seleccionamos el directorio con el ejemplo descomprimido.

Para ejecutarlo seguiremos las indicaciones publicadas en esta dirección: http://code.google.com/intl/es/appengine/docs/java/tools/eclipse.html#Running_the_Project

6.2 Estructura del proyecto

Nos vamos a encontrar dos capas bien diferenciadas: la primera va a ser la capa con la lógica y la persistencia mientras que la segunda se va a encargar de gestionar la interfaz.

La capa con la lógica y la persistencia está formada por tres clases:

  • La factoría encargada de crear servicio del datastore, llamada DSF. Es un singleton para asegurarnos de que no hay más que una factoria, ya que crear el servicio del datastore es computacionalmente bastante costoso.
  • http://code.google.com/intl/es/appengine/docs/java/javadoc/com/google/appengine/api/datastore/DatastoreServiceFactory.html
    http://code.google.com/intl/es/appengine/docs/java/javadoc/com/google/appengine/api/datastore/DatastoreService.html

  • La entidad Tutorial, la cual es una clase simple que incluye en su interior una entidad del datastore. En este caso la clase Tutorial actua como envoltorio para simplificarnos el desarrollo. Observad que la clase Tutorial opera con la entidad como si fuese un simple mapa o una tabla hash.
  • http://code.google.com/intl/es/appengine/docs/java/javadoc/com/google/appengine/api/datastore/Entity.html
    http://code.google.com/intl/es/appengine/docs/java/javadoc/com/google/appengine/api/datastore/Key.html

  • La clase encargada de almacenar y recuperar entidades, TutorialUtils. En esta clase hay un ejemplo sencillo de cómo lanzar una búsqueda. Las búsquedas son la base primordial datastore y es por ello que posee un API muy potente en ese sentido, donde puedes indicar no sólo qué búsqueda quieres lanzar sino, además, de qué manera quieres recuperar los resultados:
  • http://code.google.com/intl/es/appengine/docs/java/javadoc/com/google/appengine/api/datastore/Query.html
    http://code.google.com/intl/es/appengine/docs/java/javadoc/com/google/appengine/api/datastore/FetchOptions.html

    Por otro lado tenemos la capa encargada de gestionar el interfaz del ejemplo, la cual no vamos a mostrar en el tutorial ya que carece de interés por ser totalmente independiente al funcionamiento del datastore.

    7 Conclusiones

    Una necesidad constante en el desarrollo de aplicaciones web es la de disponer de un soporte sobre el cual poder almacenar y recuperar datos. Es por ello que si vamos a dejar nuestras aplicaciones en la nube de Google necesitaremos conocer cómo poder realizar estas tareas sobre sus soportes de almacenamiento.

    Como hemos podido ver en este tutorial el soporte de almacenamiento de Google para Google App Engine se conoce como datastore, el cual se apoya a su vez en BigTable, tecnología que no consiste en ser una base de datos relacional aunque es totalmente consecuente. Esto responde a las necesidades de escalabilidad que requieren las aplicaciones de Google, ya que el modelo relacional posee un punto que no es posible escalar: las propias relaciones.

    También hemos conocido algunos de los aspectos propios del datastore, como son las entidades, sus propiedades y las transacciones, las cuales se delimitan creando grupos de entidades.

    Hemos visto que para la recuperación y almacenaje de información utilizando el soporte para Java tenemos dispone de 3 alternativas: el API de nivel inferior, JDO y JPA. Hemos situado cada una de estas tecnologías y hemos dejado un ejemplo que utiliza la primera de ellas.

    El uso del API de nivel inferior es relativamente simple. Nos otorga flexibilidad, nos da todo el control y es muy potente a la hora de lanzar consultas, aparte de que como habeis podido ver no es dificil de utilizar, ya que podemos pensar que las entidades son mapas o tablas hash que se guardan en base de datos.

    8 Referencias

    ¿Qué son el Cloud Computing y Google App Engine?


    Google I/O 2008 – App Engine Datastore Under the Covers


    Google I/O 2009 – Java Persistence & App Engine Datastore

    El API Java de almacén de datos

    El API de nivel inferior

    Instalación del SDK de Java


    Instalación del complemento de Google para Eclipse

    Dejar respuesta

    Please enter your comment!
    Please enter your name here