arquitectura de proyectos de it -...

Arquitectura de Proyectos de IT

Arquitectura de Persistencia

© 2005

Juan AriasGustavo BreyGastón CocoNicolás Passerini

¿Qué es persistencia?

� In computer science, persistence refers to the characteristic of data that outlives the execution of the program that created it.

2 Arquitectura de Proyectos de IT2

� ¿Por qué es necesario?– Los datos en memoria se pierden

– La memoria es acotada

Problemas de persistencia

�Performance– Acceso a disco

– Búsquedas

– Distribución


– Distribución

�Transformación de los datos

Estrategias de Persistencia

�Archivos�Bases de datos

– Relacional

– Objetos


– Objetos

– Otras�Prevalencia�Ortogonal

Archivos

� XML� Ancho fijo� Csv� DBF + IDX� Archivos Indexados - VSAM


� Archivos Indexados - VSAM� Serialización

� Snapshot– Smalltalk

– Self

Prevalencia

� Características– Los datos se mantienen en memoria.

– Regularmente se hace un snapshot a disco

� Implementaciones


� Implementaciones– Prevayler (Java)

– Bamboo (.Net)

– Madeleine (Ruby)

– Sprevayler (Smalltalk)

– Perlvayler (Perl)

Prevalencia

� Ventajas– No hay transformación, los datos se guardan en el

formato que los usa el programa.– Alto grado de transparencia.– La performance es muchísimo más alta.


– La performance es muchísimo más alta.

� Desventajas– La aplicación debe poder ser contenida en memoria.– Interoperabilidad.– Falta la maduración de un sistema híbrido.

Data Base Management Systems

� Independencia de la forma en que se guardan físicamente los datos

� Permite compartir la DB entre varios programas – Comunicación, transacciones, lockeos, seguridad, etc.

� Mecanismos para recuperarse si algo falla– Transacciones, logs, auditoría, herramientas de backup


– Transacciones, logs, auditoría, herramientas de backup

� Permite establecer reglas de integridad– Valores inválidos

– Incoherencias o inconsistencias

� Performance y escalabilidad– Grandes volúmenes de datos o de transacciones

� Puedo ejecutar cosas dentro de la base

Tipos de DBMS

�En red�Jerárquicas�Relacionales�Objetos


�Objetos�Asociativas�Multidimensionales

Bases de Datos Relacionales

� Bases teóricas– Algebra relacional (Ted Codd - 1970)

– Teoría de conjuntos (Georg Cantor – 1874)

– Lógica de predicados


– Lógica de predicados

� Elementos– Tablas, relaciones, constraints, domains, keys

– Operadores relacionales

– Normalización

Bases de Objetos


Bases de Objetos

Frameworks de persistencia– DB4O– Omnibase– (desapareciendo) EJB Entity Beans

Bases de Objetos


Bases de Objetos– Gemstone– Objectivity– GOODS (Generic Object Oriented Database System)

� Lenguajes de Consulta– OQL– LINK

Bases de Objetos

Algunas clasificaciones– Activas / Pasivas

– Transformación nativa / no nativa

– Embebidas


– Embebidas

Reticencia a su uso– Interacción con otras aplicaciones

– No parece tan sencillo cocinar datos

– Miedo

Bases de Objetos

Ventajas– Más simple

– Más rápido (trabajan con punteros en lugar de relaciones, “navegacional” en lugar de “declarativo”)

– Modificabilidad


– Modificabilidad

Desventajas– Son más rápidas para las búsquedas conocidas

previamente.

– Desarrollos sobre múltiples plataformas. Interoperabilidad.

Multidimensionales

�OLAP (cubos)�Fact Table / Dimension Tables�Vistas precalculadas, para las posibles agregaciones


agregaciones�Grandes volúmenes de datos a gran velocidad

�Datos históricos

NO-SQL

� Surgen en parte para suplir limitaciones del modelo relacional

– Escalabilidad

– Distribuidas “por diseño”

– Volumen de datos

– Esquemas flexibles

Pueden o no implementar ACID

17 Arquitectura de Proyectos de IT

– Pueden o no implementar ACID

� Tipos

– Columns

– Key/Value

– Document

17

NO-SQL. Columns

� Es parecido al modelo relacional, pero los datos son guardados ordenados por columna en lugar de por registro.

– Las búsquedas son mucho más rápidas

– Mas fácil calcular proyecciones relativas a una o pocas columnas.


– Mas fácil calcular proyecciones relativas a una o pocas columnas.

– Es más difícil realizar escrituras o consultas complejas (muchas columnas)

� Ejemplos:

– BigTable (Google)

– Hypertable

18

NO-SQL. Key/Value

� La información se guarda organizado como un par clave/valor.

– Tiene una alta flexibilidad, no es necesario modificar estructuras para agregar atributos.

– No es necesario lidiar con tipos de datos


– Es complicado hacer búsquedas por más de un campo (AND y OR)

� Ejemplos:

– Cassandra (Facebook, Twitter, Digg)

– Tyrant

19

NO-SQL. Document

� Guardan cualquier “documento” arbitrario, independientemente de la estructura.

– Es mas fácil guardar estructuras que varían pese a referirse al mismo tipo de entidad.

– Suelen usar XML, YAML o JSON para retornar los datos a través de un protocolo REST.


de un protocolo REST.

– No es tan fácil hacer consultas complejas (proyecciones, por ejemplo)

� Ejemplos:

– MongoDB (sourceforge, github)

– CouchDB

20

Estrategias de Uso

� SQL Plano / Embebido / HQL / OQL

� Frameworks de persistencia– ORM

– No relacionales


– No relacionales

� Transparentes– Bases de Objetos

– Prevalencia

– Persistencia Ortogonal

SQL Plano

� Muy difundido

� Inclusive desde la vista (por ejemplo JSP)

� Puede ser manual o generado


� Puede ser manual o generado

� Normalmente se introduce a través de strings

SQL Plano - Variantes

� Stored Procedures� Vistas� Triggers

� SQL Embebido– Pro*C– RPG


– RPG

� Herramientas de Reporting– Jasper Reports

� Externalización– XML

� DAO

SQL Plano – Ventajas

� Es facil generar diferentes vistas de los datos. El clasico "mostrame este y este dato en la pantallita". O "modificame solo este campito“

� No necesitan generar abstracciones ni modelo.


� No necesitan generar abstracciones ni modelo. (esto no es una ventaja, pero si somos cortoplacistas, sale con fritas. Recordar RAD)

� Facilita la generación de Reportes (cuando son datos "cuadrados").

SQL Plano – Desventajas

� ¡¡¡NO se generan abstracciones ni modelo!!!

� La lógica de negocio se entremezcla en los INSERT / UPDATES / DELETE


� La lógica se hace parte de la infraestructura.

� Triggers y su promiscuidad oculta -> tocan los datos, se meten en la lógica. Y encima es oculta, NO es explícita.

Mapeo Objetos-Relacional

� Permite concentrarse en el negocio� Puede tener problemas de performance.

Ejemplos– Hibernate / NHibernate


– Hibernate / NHibernate

– Castor JDO

– TopLink

Dos niveles– Mapeador de objetos

– Framework de persistencia.

Alternativa: Active Record

�Simplifica el uso de un ORM– Convention over configuration

– Table per class

– Behavioral complete


– Behavioral complete

�Ejemplos– Ruby on Rails

27

Impedance Mismatch (I)

� Conversiones de tipos� Imposibilidad de refactor, no hay entornos integrados.

� Inflexibilidad de las tablas, no polimorfismo.


� Inflexibilidad de las tablas, no polimorfismo.

�Herencia� Identidad vs. Clave Primaria. Unicidad

Impedance Mismatch (II)

� Interfaces de datos vs. interfaces de comportamiento

� Relaciones bidireccionales, navegabilidad, consistencia, relaciones inversas.


En realidad esto de a poco se va solucionando� Ausencia del concepto de “proyección”� Declarativo vs. Imperativo (4GL vs. 3GL)

– Manejo de conjuntos versus iteración.

– Conjuntos por comprensión.

¿Qué significa transparente? (I)

� ¿Cómo y dónde persistir?

� Qué objetos persistir– Persistence by Reachability


� Qué objetos traer del repositorio persistente– Lazy– Resolución múltiples– Eliminación

¿Qué significa transparente? (II)

� Lenguaje de interacción con el repositorio persistente

– Lenguajes embebidos

– Mismo lenguaje de programación


– Mismo lenguaje de programación

� Transacciones

¿Qué significa transparente? (III)

¿Pero entonces cómo funciona?

– Programática

– Declarativa

– Automática / Inteligente / Heurística


– Automática / Inteligente / Heurística

¿Transparente para quién?

– Servicios

– Objetos de negocio

– Presentación

Combinando esquemas de persistencia

� Para qué pueden servir cada una de las formas de persistencia.

¿Cómo combinarlas?– Prototipado

– Para guardar información de configuración no hace falta una


– Para guardar información de configuración no hace falta una base de datos.

– Una persistencia bien objetosa podría ser útil para una configuración más feliz.

– Otra posibilidad es que la configuración sea código.

– La base está buena para datos que son muchos y cuadrados.

– Si son muchos y complicados entonces es un problema.

Otros problemas de persistencia

� Cachés

� Distribución del acceso a los datos

� Distribución de los datos


� Distribución de los datos

� Transaccionalidad – Entre múltiples repositorios de datos.

arquitectura de proyectos de it -...

Documents