Arquitectura de Proyectos de IT © 2005 Arquitectura de Persistencia Juan Arias Gustavo Brey Gastón...

Arquitectura de Proyectos de IT

© 2005

Arquitectura de Persistencia

Juan AriasGustavo BreyGastón CocoNicolás Passerini

2 Arquitectura de Proyectos de IT2

¿Qué es persistencia?

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

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

http://en.wikipedia.org/wiki/Computer_science


Problemas de persistencia

Performance– Acceso a disco– Búsquedas– Distribución

Transformación de los datos


Estrategias de Persistencia

ArchivosBases de datos

– Relacional– Objetos– Otras

PrevalenciaOrtogonal


Archivos

XML Ancho fijo Csv DBF + IDX 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– 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.

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 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árquicasRelacionalesObjetosAsociativasMultidimensionales


Bases de Datos Relacionales

Bases teóricas– Algebra relacional (Ted Codd - 1970)– Teoría de conjuntos (Georg Cantor – 1874)– 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– 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

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

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

previamente.– Desarrollos sobre múltiples plataformas.

Interoperabilidad.


Multidimensionales

OLAP (cubos)Fact Table / Dimension TablesVistas precalculadas, para las posibles agregaciones

Grandes volúmenes de datos a gran velocidad

Datos históricos

17 Arquitectura de Proyectos de IT

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

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.

– 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.

– 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

Transparentes– Bases de Objetos– Prevalencia– Persistencia Ortogonal


SQL Plano

Muy difundido

Inclusive desde la vista (por ejemplo JSP)

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

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. (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– 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

Ejemplos– Ruby on Rails

27


Impedance Mismatch (I)

Conversiones de tipos Imposibilidad de refactor, no hay

entornos integrados. 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

Transacciones


¿Qué significa transparente? (III)

¿Pero entonces cómo funciona?– Programática– Declarativa– 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 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

Transaccionalidad – Entre múltiples repositorios de datos.

Arquitectura de Proyectos de IT © 2005 Arquitectura de Persistencia Juan Arias Gustavo Brey Gastón...

Documents

Transcript of Arquitectura de Proyectos de IT © 2005 Arquitectura de Persistencia Juan Arias Gustavo Brey Gastón...