Arquitectura de Proyectos de IT - apit.wdfiles.comapit.wdfiles.com/local--files/start/03_apit_persistencia.pdf · – (desapareciendo) EJB Entity Beans Bases de Objetos 13 Arquitectura

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


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 - apit.wdfiles.comapit.wdfiles.com/local--files/start/03_apit_persistencia.pdf · – (desapareciendo) EJB Entity Beans Bases de Objetos 13 Arquitectura

Documents