View
5
Download
0
Category
Preview:
Citation preview
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
3 Arquitectura de Proyectos de IT3
Problemas de persistencia
Performance– Acceso a disco– Búsquedas– Distribución
Transformación de los datos
4 Arquitectura de Proyectos de IT4
Estrategias de Persistencia
ArchivosBases de datos
– Relacional– Objetos– Otras
PrevalenciaOrtogonal
5 Arquitectura de Proyectos de IT5
Archivos
XML Ancho fijo Csv DBF + IDX Archivos Indexados - VSAM Serialización
Snapshot– Smalltalk– Self
6 Arquitectura de Proyectos de IT6
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)
7 Arquitectura de Proyectos de IT7
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.
8 Arquitectura de Proyectos de IT8
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
9 Arquitectura de Proyectos de IT9
Tipos de DBMS
En red JerárquicasRelacionalesObjetosAsociativasMultidimensionales
10 Arquitectura de Proyectos de IT10
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
11 Arquitectura de Proyectos de IT11
Bases de Objetos
12 Arquitectura de Proyectos de IT12
Bases de Objetos
13 Arquitectura de Proyectos de IT13
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
14 Arquitectura de Proyectos de IT14
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
15 Arquitectura de Proyectos de IT15
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.
16 Arquitectura de Proyectos de IT16
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
18 Arquitectura de Proyectos de IT
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
19 Arquitectura de Proyectos de IT
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
20 Arquitectura de Proyectos de IT
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
21 Arquitectura de Proyectos de IT21
Estrategias de Uso
SQL Plano / Embebido / HQL / OQL
Frameworks de persistencia– ORM– No relacionales
Transparentes– Bases de Objetos– Prevalencia– Persistencia Ortogonal
22 Arquitectura de Proyectos de IT22
SQL Plano
Muy difundido
Inclusive desde la vista (por ejemplo JSP)
Puede ser manual o generado
Normalmente se introduce a través de strings
23 Arquitectura de Proyectos de IT23
SQL Plano - Variantes
Stored Procedures Vistas Triggers
SQL Embebido– Pro*C– RPG
Herramientas de Reporting– Jasper Reports
Externalización– XML
DAO
24 Arquitectura de Proyectos de IT24
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").
25 Arquitectura de Proyectos de IT25
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.
26 Arquitectura de Proyectos de IT26
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.
27 Arquitectura de Proyectos de IT
Alternativa: Active Record
Simplifica el uso de un ORM– Convention over configuration– Table per class– Behavioral complete
Ejemplos– Ruby on Rails
27
28 Arquitectura de Proyectos de IT28
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
29 Arquitectura de Proyectos de IT29
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.
30 Arquitectura de Proyectos de IT30
¿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
31 Arquitectura de Proyectos de IT31
¿Qué significa transparente? (II)
Lenguaje de interacción con el repositorio persistente
– Lenguajes embebidos– Mismo lenguaje de programación
Transacciones
32 Arquitectura de Proyectos de IT32
¿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
33 Arquitectura de Proyectos de IT33
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.
34 Arquitectura de Proyectos de IT34
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.
Recommended