Arquitectura de Persistencia

Presentación del tema: "Arquitectura de Persistencia"— Transcripción de la presentación:

1 Arquitectura de Persistencia
Arquitectura de Proyectos de IT Arquitectura de Persistencia Juan Arias Gustavo Brey Gastón Coco Nicolás Passerini © 2005

2 ¿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 2 caracteristicas deseables son: Estabilidad: Es la capacidad de un sistema para registrar su estado (punto de verificación) de manera consistente en un medio seguro, de tal manera que el funcionamiento podría reanudarse a partir de ese punto en el futuro. Resilencia: Un sistema tiene esta propiedad si puede reanudarse el funcionamiento con seguridad después de una caída del sistema inesperada, como por ejemplo un fallo de alimentación. 2 Arquitectura de Proyectos de IT

3 Problemas de persistencia
Performance Acceso a disco Búsquedas Distribución Transformación de los datos 3 Arquitectura de Proyectos de IT

4 Estrategias de Persistencia
Archivos Bases de datos Relacional Objetos Otras Prevalencia Ortogonal Persistencia Prevalencia: Es un metodo donde el almacenamiento y la recuperacion del objeto es transparente a el mismo, lo que s realiza es un snapshot de todos los objetos en memoria y se los guarda generalmente en disco. (Por ejemplo Prevayler es par java) Persistencia Ortogonal, El concepto fue introducido en el 1983 por Atkinson, se refiere a que toda la información puede ser persistente y debe ser manipulada de la misma manera, independientemente del tiempo que deba persistir. La persistencia ortogonal es aplicada a toda la información del sistema (estado del sistema + datos) con esto se consigue proporcionar una abstracción uniforme del almacenamiento. Generalmente es una caracteristica proporcionada por el Sistema Operativo (por ejemplo las Palms, PDA). 4 Arquitectura de Proyectos de IT

5 Archivos XML Ancho fijo Csv DBF + IDX Archivos Indexados - VSAM
Serialización Snapshot Smalltalk Self VSAM - Un tipo de archivo orientado a registro que contiene bloques (data sets) de información de longitud fija. Permite indexar, insertar, etc. de forma mas eficiente que un archivo simple. El VSAM (liberado por IBM en 1972) pretendía reemplazar a sus sistemas de archivos secuenciales, secuenciales indexados y relativos hay tres tipos de archivos VSAM: I) archivos secuenciales por clave para una organización de archivos secuenciales indexados II) archivos de entrada secuenciales para una organización de archivos secuenciales III) archivos de registro relativos para una organización de archivos relativos 5 Arquitectura de Proyectos de IT

6 Prevalencia Características Implementaciones
Los datos se mantienen en memoria. Regularmente se hace un snapshot a disco Implementaciones Prevayler (Java) Bamboo (.Net) Madeleine (Ruby) Sprevayler (Smalltalk) Perlvayler (Perl) Prevayler is an open source persistence library for Java. It is an implementation of the Prevalent System architecture pattern, in which data is kept hot in memory with changes journaled for system recovery. The Prevalent System pattern is illustrated in the diagram shown here. Prevayler [1] serves as a transactional barrier for the business objects [2] of your application, held in memory. You encapsulate all modifications of your business objects into instances of the Transaction interface [3], much like a " command " pattern. Whenever you ask Prevayler to execute a transaction on your business objects [4], Prevayler first writes the transaction object to a journal [5] so that data is not lost if your system crashes. Prevayler can also write a snapshot of your entire business object graph [6] as often as you wish. Prevayler uses the latest snapshot together with the journals to automatically recover your business objects from disk [7] on application startup by restoring the snapshot and then re-executing every transaction that was originally executed after that snapshot was taken. 6 Arquitectura de Proyectos de IT

7 Prevalencia Ventajas Desventajas
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. 7 Arquitectura de Proyectos de IT

8 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 8 Arquitectura de Proyectos de IT

9 Tipos de DBMS En red Jerárquicas Relacionales Objetos Asociativas
Multidimensionales El modelo de datos de red general representa las entidades en forma de nodo de un grafo, y las asociaciones o interrelaciones entre éstas mediante los arcos que unen dichos nodos. El modelo en red general es muy flexible debido a la inexistencia de restricciones, pero también por esta misma razón su instrumentación física resulta difícil y poco eficiente. esta es la causa de que se le suela introducir restricciones al llevarlo a la practica. el modelo jerárquico por ejemplo es un modelo que responde a estructuras del tipo de red pero con restricciones bastante fuertes. Es fácil modelar relaciones muchos a muchos. Bases Jerárquicas: Tiene forma de árbol invertido. Un padre puede tener varios hijos pero cada hijo sólo puede tener un padre. Si se establece una relación entre los nodos hermanos pasamos a tener una Bases de datos de red. A diferencia del modelo relacional, el modelo jerárquico no diferencia una vista lógica de una vista física de la base de datos, los datos se relacionan siempre a nivel físico mediante referencia a direcciones físicas del medio de almacenamiento. Las relaciones son unidireccionales. Cada registro consta de un conjunto de campos, el equivalente a las columnas del modelo relacional. Un conjunto de registros con los mismos campos se denomina fichero (record type, en inglés), el equivalente a las tablas del modelo relacional. Bases de Datos Asociativas: Las bases de datos asociativas parten un registro en unidades significativas (con sentido) mas pequeñas Los datos se almacenan en la forma de registros, el equivalente a las filas del modelo relacional., dividiéndolos en “”items” (el dato en sí) y “links” (su relación). 9 Arquitectura de Proyectos de IT

10 Bases de Datos Relacionales
Bases teóricas Algebra relacional (Ted Codd ) Teoría de conjuntos (Georg Cantor – 1874) Lógica de predicados Elementos Tablas, relaciones, constraints, domains, keys Operadores relacionales Normalización 10 Arquitectura de Proyectos de IT

11 Bases de Objetos 11 Arquitectura de Proyectos de IT

12 Bases de Objetos 12 Arquitectura de Proyectos de IT

13 Bases de Objetos Frameworks de persistencia Bases de Objetos
DB4O Omnibase (desapareciendo) EJB Entity Beans Bases de Objetos Gemstone Objectivity GOODS (Generic Object Oriented Database System) Lenguajes de Consulta OQL LINK 13 Arquitectura de Proyectos de IT

14 Bases de Objetos Algunas clasificaciones Reticencia a su uso
Activas / Pasivas Transformación nativa / no nativa Embebidas Reticencia a su uso Interacción con otras aplicaciones No parece tan sencillo cocinar datos Miedo Base de objetos Activa o Pasiva: las bases pasivas proveen almacenamiento y distribucion de los objetos, dejando que todo el procesamiento de la aplicación se realice en el cliente. Las bases pasivas pueden almacenar descripciones de interfaces de los metodos definidos para las clases en el esquema, pero no almacenan la implementacion de esos metodos y no ejecutan consultas o actualizaciones de objetos en los procesos de la base de datos. Los objetos deben ser movidos desde desde la base hacia la aplicación. Las bases activas almacenan la implementacion de los metodos de una clase y pueden ejecutarlos en el espacio de procesos de la base de datos ( es un ambiente de objetos que opera sobre el disco ). Las bases activas pueden realizar tareas de procesamiento, busquedas asociativas, etc sin mover los datos sobre los que debe trabajar al espacio de precesos de la aplicación. Base de objeto nativa y no nativa: las nativas estan desarrolladas en el mismo lenguaje de programacion con el que se trabajan y almacenan los objetos, esto permite una representacion directa con el lenguaje. Por otra parte las no nativas almacenan los objetos con una representacion propia y pueden estar desarrolladas e cualquuier lenguaje de programacion. Base de datos embebida: es una base de datos que es invisible al usuario final, suelen ser parte de la aplicación. 14 Arquitectura de Proyectos de IT

15 Bases de Objetos Ventajas Desventajas 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. 15 Arquitectura de Proyectos de IT

16 Multidimensionales OLAP (cubos) Fact Table / Dimension Tables
Vistas precalculadas, para las posibles agregaciones Grandes volúmenes de datos a gran velocidad Datos históricos OLAP - On-Line Analytical Processing Fact Table - Tablas creadas con “proyecciones” Dimension Tables - Las “dimension tables” agregan atributos para acotar los datos de las “fact tables” 16 Arquitectura de Proyectos de IT

17 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 -Escalabilidad: están pensadas en escalabilidad horizontal, especialmente -ACID: Atomicidad, Consistencia, Aislamiento, Durabilidad 17 Arquitectura de Proyectos de IT

18 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 Arquitectura de Proyectos de IT

19 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 Los valores pueden ser objetos serializados directamente 19 Arquitectura de Proyectos de IT

20 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 Arquitectura de Proyectos de IT

21 Estrategias de Uso SQL Plano / Embebido / HQL / OQL
Frameworks de persistencia ORM No relacionales Transparentes Bases de Objetos Prevalencia Persistencia Ortogonal 21 Arquitectura de Proyectos de IT

22 SQL Plano Muy difundido Inclusive desde la vista (por ejemplo JSP)
Puede ser manual o generado Normalmente se introduce a través de strings 22 Arquitectura de Proyectos de IT

23 SQL Plano - Variantes Stored Procedures Vistas Triggers SQL Embebido
RPG Herramientas de Reporting Jasper Reports Externalización XML DAO 23 Arquitectura de Proyectos de IT

24 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"). 24 Arquitectura de Proyectos de IT

25 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. 25 Arquitectura de Proyectos de IT

26 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. 26 Arquitectura de Proyectos de IT

27 Alternativa: Active Record
Simplifica el uso de un ORM Convention over configuration Table per class Behavioral complete Ejemplos Ruby on Rails 27 Arquitectura de Proyectos de IT

28 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 28 Arquitectura de Proyectos de IT

29 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. 29 Arquitectura de Proyectos de IT

30 ¿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 30 Arquitectura de Proyectos de IT

31 ¿Qué significa transparente? (II)
Lenguaje de interacción con el repositorio persistente Lenguajes embebidos Mismo lenguaje de programación Transacciones 31 Arquitectura de Proyectos de IT

32 ¿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 32 Arquitectura de Proyectos de IT

33 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. 33 Arquitectura de Proyectos de IT

34 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. 34 Arquitectura de Proyectos de IT