CEIBO

Domingo 15/junio/2008

Eligiendo la persistencia adecuada

Filed under: General — Hernan Galante @ 11:53 pm

En casi todos los proyectos de software tradicional una de las primeras estructuras que se eligen es la base de datos. Se elige en que motor va a guardarse los datos, antes de saber de que datos hablamos, cantidad, volumen y si la solución adecuada es apropiada. Muchas herramientas de programación incluso, no permiten o no dan soporte prácticamente para trabajar con otra alternativa.
En los proyectos Smalltalk en general, la persistencia, es una de las últimas cosas que se plantean y estudian.

¿Porqué estudiar la persistencia a último momento?

Esta pregunta es interesante contestarla para quienes estén familiarizados con la acción inversa. Todos sabemos que en un proyecto orientado a objetos, el uso de una base de datos puede ser una tarea compleja. Para hacer una analogía, sería como pensar que cada vez que guardamos nuestro vehículo en nuestra cochera, de ante mano debemos desarmarlo hasta los tornillos para poder guardarlo. Y para volver a usarlo como tal, debemos rearmarlo nuevamente. Por lo que podemos deducir claramente que no es natural esta táctica. Alguien le puso un nombre en inglés a esto como “impedance mismatch”. Podría traducirse como “acople de impedancia”, pero a efectos de nuestro objetivo no tiene más significado de que estamos conectando dos tecnologías incompatibles. Para compatibilizarlas, generalmente se usan frameworks de persistencia, que no son otra cosa que “adaptadores”. Como en la electricidad, que usamos transformadores para pasar de 220 a 110v, aquí es lo mismo. Estos frameworks suelen tener su complejidad por supuesto.

En los proyectos de lenguajes tradicionales orientados a objetos, ya usan un estándar o estándares que la misma industria les recomienda, como Spring o Hibernate. Este ultimo resuelve exactamente esta incompatibilidad, para lo cual, la mayoría piensa que ha sido una buena elección y sin dudarlo solo acata elegir el motor de base de datos. La realidad, es que en la mayoría de los proyectos usan herramientas inapropiadas sin analizar sin más detalles si realmente la requieren o si con una solución más simple pudieran obtener una solución perfectamente adecuada. La pregunta que se harán muchos es ¿Que está mal al elegir un framework gigante como hibernate para guardar los datos? Bien, la respuesta es simple, si el sistema probablemente use miles de usuarios y miles de datos, la alternativa sería correcta, pero sería mejor post-poner el uso de la persistencia hasta que el modelo esté maduro. Recién allí, nos inclinamos a hacer persistir el modelo, ya maduro, en la base; optimizando y haciendo lo ajustes necesarios. Si esto lo hacemos mucho antes de lo necesario, traerá complicaciones, que se traducen en más tiempo y al final es dinero malgastado. Esto, debería ser así para cualquier proyecto, pero no, la industria en general opta por complicarse de antemano, tener que echarle mano a scripts SQL para migrar cuando el modelo “inmaduro” va cambiando drásticamente su forma o directamente para evadir esto empiezan a dejar residuos en la base de datos. Claro, hay que aclararlo, una base de datos es una entidad absolutamente pasiva, y ni siquiera sabe que datos son usados y que datos podrían ir a parar a la basura. Como los datos son pasivos, al contrario que los objetos que son entidades activas. Estos últimos pueden aplicar la capacidad de un “Garbage Collector” o recolector de basura, que puede decidir por si solo si ciertos objetos ya no están siendo usados, por lo tanto, pueden borrarse. Si imaginamos esto en una base de objetos, entonces, tenemos que las bases de objetos tienen información más confiable que una base de datos por simple naturaleza.
Muchas veces he visto, por ejemplo, que se usa un tremendo y complejo framework de persistencia para solo “persistir” unos 10 objetos en el modelo, lo que se traduce a unas pocas tablas. Y ni hablar que quizás ese sistema solo tenga unos pocos usuarios. Es decir, tranquilamente se puede optar por sistemas de persistencia más simples y menos complejos. ¿Y que soluciones nos traería algo así? Bueno, para seguir dando ejemplos para entender, hace uno tiempo vi como un producto en el mercado tenía esta “sobredimensión” y el producto competencia en el que trabajé solo mantenía la información que requería en un archivo de formato propio (que no era otra cosa que un sistema de persistencia basado en diccionarios, muy simple). A la hora de competir, este sistema nuevo no paga ningún licenciamiento y requería muchísimos menos requisitos para funcionar. El otro sistema requería instalar por separado el motor, y luego los clientes. Como se imaginarán, no solo a nivel técnico hablamos de menos complejidades, a nivel negocio, era más rentable aquel que tenía menos. O sea, menos es más muchas veces. Como moraleja, deberíamos asumir que no hay que intentar matar mosquitos a cañonazos, o mejor dicho, no intentemos solucionar todo a cañonazos. Aunque algunos políticos ese problema sistémico no lo han entendido, esperemos que la gente que desarrolla sistemas si lo entienda.

¿Qué soluciones serían alternativas a usar una Base de datos relacional?

Dependiendo de la magnitud del proyecto y las de exigencias de este, podemos ir desde persistir en archivos, en el image de Smalltalk, en esquemas de persistencia, usar frameworks de persistencia a Base de datos, o base de objetos.

¿Que soluciones son opciones para este proyecto?

Dentro del marco de investigación para lo que necesitamos, van a desde sistemas de base de objetos como Magma o Goods, a un framework de persistencia sobre Base de datos.

Las solución que se elija debe contemplar:

  • Múltiples usuarios
  • Las 4 leyes básicas de persistencia: ACID (Atomicity, Consistency, Isolation, Durability) o en castellano, Atomicidad (ante cualquier eventualidad ninguna acción queda a medias), Consistencia (Es decir, que cada operación que se realice sobre la información asegura que siempre quedará integra), Aislamiento (Una operación no afectará a otras operaciones) y Durabilidad (es decir, que la información se guardará y permanecerá en el tiempo)
  • Pool de Sesiones, generalmente en un proyecto web, donde existen múltiples clientes no vamos a abrir una conexión por cada conexión web que se realice. El tema principal es que no siempre estamos persistiendo y podrían quedar sesiones abierta contra la base sin demasiado sentido más que malgastar los recursos computacionales preciados. Es por ello que se piensa en un pool de conexiones habilitadas para realizar las operaciones, y ciertos planes de contingencia.
  • Loqueo optimista, es de preferencia para un sitio web. El loqueo optimista asume que siempre hay conflictos y traza su política es base a esto. En el pesimista, pretende estar solo, y si va a haber conflicto debes loquear el objeto antes de usarlo.

Resumen

Se estudiarán varias alternativas de persistencia para el proyecto, la que mejor se adecue será la opción final a usar. Por lo pronto, por cada opción haremos una entrada en el blog para recordar los puntos positivos, los puntos negativos y los puntos interesantes de la cada opción.

Dejar un comentario »

Aún no hay comentarios.

RSS feed for comments on this post. TrackBack URI

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Blog de WordPress.com.

A %d blogueros les gusta esto: