Hibernate Shard: “de lo centralizado a lo distribuido”

6 Noviembre 2008 por Jose Corcuera Deja una respuesta »

Es un hecho que hoy en día las empresas se han distribuido en forma regional a lo largo del mundo, con sucursales en cada una de estas regiones, en donde se maneja el mismo aplicativo para realizar sus operaciones cotidianas. Es cierto, por ejemplo, si vamos a realizar un depósito en la sucursal X o Y de un banco específico y damos una ojeada (si es que la persona de ventanilla lo permite) a la pantalla de su ordenador, notaremos que se trata de la misma aplicación; y ésta misma trabajando con una o muchas bases de datos.

Las empresas optan por tener en cada sector su propia base de datos para el manejo de los datos locales, éste es un esquema distribuido de la información, en donde la base de datos ha sido particionada horizontalmente. La decisión de seguir este modelo se debe a cuestiones técnicas de diseño, siendo la principal: latencia en la red.

Diseñar un aplicativo que unifique la información de estas N bases de datos como si fuera una suele ser un poco engorroso debido al manejo de distintas fuentes de datos a nivel de la aplicación (datasources) y en el manejo de los recursos.

Navegando por la web me topé con un framework que realiza el trabajo mencionado en el párrafo anterior, me refiero a Hibernate Shard.

Hibernate Shard

El framework Hibernate Shard es una extensión de Hibernate Core que encapsula y minimiza la complejidad de trabajar con un modelo de datos particionado horizontalmente. Debido a que está basado en Hibernate Core, Hibernate Shards ofrece un conjunto de clases las cuales extienden de las clases base de Hibernate Core (Session, SessionFactory, entre otras).

Características

  • Se puede definir la forma en la que se hará la distribución de la data en las particiones que se tiene, siguiendo determinada lógica.
  • Si conoces Hibernate Core, entonces Hibernate Shard te resultará fácil de aprender.
  • Ofrece un mecanismo de redistribución de la data, ésto se da por ejemplo cuando se agrega una nueva base de datos; la solución es hacer uso de Particiones Virtuales. Las particiones virtuales estan asociadas a particiones fisicas, siendo éstas mapeadas una a una para luego realizar una determinada configuración.

Limitaciones

  • No se permite la relación de objetos de diferentes particiones.
  • No se tiene una implementación completa del API de Hibernate Core.
  • No soporta el uso de transacciones distribuidas, si queremos hacer manejo de esto debemos utilizar una herramienta alternativa.

Conclusión

Se puede apreciar que es una herramienta atractiva en el caso que se nos presente trabajar con un modelo de datos particionado horizontalmente, sin embargo; dado que tiene varias funcionalidades por implementar, seria bueno darle un tiempo para luego ver que tanto ha mejorado.

No related posts.

Deja un comentario